Comments 9
UFO just landed and posted this here
А почему https нужно больше настроек, чем ssh'у?
У меня sshd прекрасно работает на таком конфиге:
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
И я как-то удачно на дефолтах имею нормальный безопасный ssh. Что-то в SSL сломано, если ему нужно СТОЛЬКО опций.
0
Имхо, тут несколько смешано теплое с мягким. Авторы исследования подчеркивают, что основной источник опасности — загрузка скриптов с хостов, которые могут контролировать злоумышленники. В этом случае есть SSL или нет — не слишком существенно.
Куча опций SSL нужна для отключения уязвимых алгоритмов, которые использует древнее ПО. Используя приведенные опции можно отключить легаси, если доступ из старого ПО не нужен.
В ssh тоже, к примеруможно выбрать поддержку протоколов v1/v2(уже, похоже, нет), выбрать список поддерживаемых алгоритмов, отключить авторизацию по паролю и т.п.
Куча опций SSL нужна для отключения уязвимых алгоритмов, которые использует древнее ПО. Используя приведенные опции можно отключить легаси, если доступ из старого ПО не нужен.
В ssh тоже, к примеру
0
А почему 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 решения.
+1
Рекомендуется всегда использовать полный набор шифров и последнюю версию OpenSSL.
Но Firefox, например, не использует OpenSSL. У него и не только NSS. Поэтому правильнее говорить по крайней мере о последних версиях OpenSSL и NSS. Более того кто из них более продвинутый на данный момент — вопрос открытый.
В наборе шифров отсутствуют российские шифрсьюты. А интересно было бы проверить по этой методике порталы ФНС, Госуслуг и иже с ними.
-1
Такой вопрос, если есть страница, на ней вводятся какие-то данные, нажимается определенная кнопка и введенные данные отправляются на другую страницу, то есть некая синхронизация данных, так вот можно ли в браузере на первой странице при просмотре кода увидеть ссылку на ту вторую страницу? если да, то где именно это прописывается?
0
Теоретически можно. Форма создаётся тегом form. Вот пример кода простой формы:
На практике иногда бывает именно так, а бывает сложнее. Во-первых, форма может быть создана броузерным скриптом, причём это не обязательно простой скрипт, состоящий всего лишь из нескольких
Во-вторых, указанный в атрибуте action серверный скрипт может перенаправлять куда-то ещё, причём наличие и адрес перенаправления могут зависеть от введённых пользователем данных, времени суток, температуры воздуха в деревне Тимбукту и чего угодно ещё — от чего именно, зависит исключительно от автора серверного скрипта. Увидеть же код серверного скрипта посторонние не могут.
<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 серверный скрипт может перенаправлять куда-то ещё, причём наличие и адрес перенаправления могут зависеть от введённых пользователем данных, времени суток, температуры воздуха в деревне Тимбукту и чего угодно ещё — от чего именно, зависит исключительно от автора серверного скрипта. Увидеть же код серверного скрипта посторонние не могут.
+2
Sign up to leave a comment.
HTTPS не всегда такой безопасный, как кажется. Уязвимости найдены у 5,5% сайтов HTTPS