Comments 9
UFO landed and left these words here
тока широковат там списочек. лучше так:

ssl_prefer_server_ciphers on;
ssl_protocols TLSv1.1 TLSv1.2;
ssl_ciphers 'kEECDH+ECDSA+AES128 kEECDH+ECDSA+AES256 kEECDH+AES128 kEECDH+AES256 +SHA !aNULL !eNULL !LOW !MD5 !EXP !DSS !PSK !SRP !kECDH !CAMELLIA !RC4 !SEED';

А почему https нужно больше настроек, чем ssh'у?
У меня sshd прекрасно работает на таком конфиге:


ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem   sftp    /usr/lib/openssh/sftp-server

И я как-то удачно на дефолтах имею нормальный безопасный ssh. Что-то в SSL сломано, если ему нужно СТОЛЬКО опций.

Имхо, тут несколько смешано теплое с мягким. Авторы исследования подчеркивают, что основной источник опасности — загрузка скриптов с хостов, которые могут контролировать злоумышленники. В этом случае есть SSL или нет — не слишком существенно.

Куча опций SSL нужна для отключения уязвимых алгоритмов, которые использует древнее ПО. Используя приведенные опции можно отключить легаси, если доступ из старого ПО не нужен.
В ssh тоже, к примеру можно выбрать поддержку протоколов v1/v2(уже, похоже, нет), выбрать список поддерживаемых алгоритмов, отключить авторизацию по паролю и т.п.
А почему https нужно больше настроек, чем ssh'у?

Ну хотя бы потому, что в каждой major версии OpenSSH удаляют из списка по умолчанию старые алгоритмы, и, чтобы включить их, как раз нужно «раздувать» конфигурационный файл SSH так же, как выше «раздут» конфигурационный файл веб-сервера.

Сравнительно большее число алгоритмов обусловлено, в том числе, принципиально большим числом пользователей TLS, по сравнению с SSH.

Для TLS важна возможность разгрузки процессора в ущерб надежности шифрования (для тысяч одновременных пользователей веб-сервера это имеет значение, для полутора админов и двух скриптов, подключенных к SSH-серверу — нет), что умножает число алгоритмов в списке, хоть отличаются они только длиной ключа.

Не стоит забывать и про то, что SSL с 1995 года существует и используется (хоть сейчас и принципиально шире, чем раньше), типов клиентов существует бесчисленное количество. SSH реально начал использоваться в середине 2000-х, а программы-клиенты SSH можно пересчитать по пальцам. Совместимость с клиентами важна для публичных веб-серверов, а для частных SSH-серверов — нет. Даже условно публичных SSH/SFTP серверов, по моему впечатлению — единицы, и у них те же проблемы с совместимостью и поддержкой устаревших алгоритмов, что и у веб-серверов. С SMTP серверами вообще дикая ситуация: их вообще никто десятилетиями не обновляет, а регуляторы требуют отключать старые алгоритмы, что невозможно без нарушения SMTP-связности, потому что старые сервера хотят TLS1.0, и, если его не дают, то отключаются, вместо того, чтобы откатиться к нешифрованному соединению.

С другой стороны, PFS в SSH от рождения, а в SSL/TLS — нет. В этом смысле в SSL/TLS что-то было «сломано», это правда, и «починка» привела к дополнительной куче алгоритмов в списке. Но, опять же, 1995 есть 1995.

Вообще говоря, SSL/TLS — это, как мне кажется, двигатель современного шифрования. Новые алгоритмы обкатываются на нём, хэкеры пытаются его взломать, а потом другие технологии, такие как SSH и PGP/GPG не торопясь принимают лучшие, проверенные в «боевых» условиях SSL/TLS решения.
Рекомендуется всегда использовать полный набор шифров и последнюю версию OpenSSL.

Но Firefox, например, не использует OpenSSL. У него и не только NSS. Поэтому правильнее говорить по крайней мере о последних версиях OpenSSL и NSS. Более того кто из них более продвинутый на данный момент — вопрос открытый.
В наборе шифров отсутствуют российские шифрсьюты. А интересно было бы проверить по этой методике порталы ФНС, Госуслуг и иже с ними.

Такой вопрос, если есть страница, на ней вводятся какие-то данные, нажимается определенная кнопка и введенные данные отправляются на другую страницу, то есть некая синхронизация данных, так вот можно ли в браузере на первой странице при просмотре кода увидеть ссылку на ту вторую страницу? если да, то где именно это прописывается?
Теоретически можно. Форма создаётся тегом form. Вот пример кода простой формы:
<form method="post" action="/cgi-bin/form.cgi">
 <label>
  Как вас зовут?
  <input type="text" name="name" size="10" maxlength="15">
 </label>
 <input type="submit" value="Отправить">
</form>
Обратите внимание на открывающий тег form (первая строчка кода). Значение его атрибута action — это адрес серверного скрипта, которому передаются введённые пользователем данные и который генерирует страницу, показываемую пользователю после отправки заполненной формы.

На практике иногда бывает именно так, а бывает сложнее. Во-первых, форма может быть создана броузерным скриптом, причём это не обязательно простой скрипт, состоящий всего лишь из нескольких document.write(); и вызываемый строчкой вида
<script type="text/javascript" src="/js/form.js"></script>
Броузерный скрипт может динамически генерироваться другим броузерным скриптом, и для нахождения интересующего Вас адреса может понадобиться многочасовой труд, даже если код не обфусцирован (обфускация — переделка кода таким образом, что он работает по-прежнему, но прочитать его становится крайне затруднительно).

Во-вторых, указанный в атрибуте action серверный скрипт может перенаправлять куда-то ещё, причём наличие и адрес перенаправления могут зависеть от введённых пользователем данных, времени суток, температуры воздуха в деревне Тимбукту и чего угодно ещё — от чего именно, зависит исключительно от автора серверного скрипта. Увидеть же код серверного скрипта посторонние не могут.
Only those users with full accounts are able to leave comments. Log in, please.
Information
Founded

1 January 1996

Location

Япония

Employees

Unknown

Registered

30 January 2018