Браузеры отказываются от поддержки TLS 1.0 и 1.1

[vesper-bot]

Теперь на свежую XP SP3 уже и файрфокс не поставишь… Печально.

[khanid]

Ну уже с пол года как было сообщение в самом браузере, что в xp/win2k3 поддержка ff прекращается.

[vesper-bot]

Понятное дело, но мне не обновлять его надо, а запускать, причем не очень важно, насколько древний — для особо противных железок 3.6.28 вполне себе подходит, а если надо серфить, можно взять 42LTS (или сколько он там был), но вообще в этом случае правильнее поставить ОС поновее.

[oleg-x2001]

А зачем вообще ставить XP??? Не троллинг, реально интересно.

[vesper-bot]

Запускать старые игры, которые писались под 98ю. Imperialism, например. Ещё как вариант — поддержка какого-ниудь легаси ПО вроде старой-престарой учетной системы. Был, помнится, такой ИНФИН, вообще досовая штуковина по факту. Хотя со временем и это всё помрет, и тогда уже не понадобится ставить ХР.

Но игры будет жалко :)

[JerleShannara]

Старое сетевое железо например. Весь Avocent имеет афигенную совместимость с новыми версиями жабы и браузеров. И если жаба правится уничтожением безопасности на корню, то с браузерами косяки вылезают.

[robux]

Почему кто-то за меня решает, какими стандартами я не должен пользоваться?

Добавьте новые протоколы, но оставьте поддержку старых. Если уж совсем неймётся («мы очень беспокоимся о безопасности пользователя», ага) — ну сделайте настройку:
«Блокировать сайты с TLS1.0/TLS1.1» — on/off (default «on», так и быть).

Но выпиливать-то зачем?! А если у меня в офисе какой-нибудь видео-регистратор с веб-мордой на TLS1.1, ну или там мини-АТС Panasonic — я больше не смогу их настраивать?

Когда я чувствую на себе такую форсированную «заботу», у меня автоматически появляются смутные сомнения в её благожелательности…

[nanshakov]

Почему ты просто не пользоваться той версией где это есть?

[JediPhilosopher]

Через некоторое время эта версия отовсюду исчезнет, и привет.
Я вот уже столкнулся с таким, не могу на убунте по VPN связаться с одним древним сервером. Там используется какой-то старый шифр, который из всех линуксовых впн клиентов выпилен. В итоге в 14 убунте оно работало, хоть и с плясками (надо было какие-то дополнительные deprecated пакеты ставить) а в 16 уже перестало вообще. И что делать, если я не хочу пользоваться древней версией ОС?

[Barafu_Albino_Cheetah]

Загрузите в Docker старинную Убунту и в ней старинный VPN клиент. Оттуда подключитесь. Дальше в зависимости от ваших нужд либо в тот же контейнер поставьте проксю, и ходите через неё, либо используйте его как gateway.

[force]

Наверняка так и сделают — скрытую настройку, запрятанную глубоко, но т.к. раз есть настройка, то её можно и включить, это затянет проблему и её решение.
Простой абстрактный пример из головы: предположим, TLS1.0 взломали полностью, с потрохами. Вы коннектитесь к сайту и ради поддержки старых протоколов и браузер и сервер поддерживают TLS1.0, человек по середине, перехватывает запросы и понижает уровень безопасности до TLS1.0, всё, приехали.

А для древних вещей всегда же можно использовать специально выделенные виртуалки, древние версии браузеров, и прочие костыли. Плохо — да, очень. Но современный мир такой.

[aim]

потому что Сеть — это коммуналка. если один сосед не моется — вши потом у всех.

[robux]

А кто сказал, что в TLS 1.0 и 1.1 есть «вши»? Сами алгоритмы ни разу не были скомпрометированы, а баги в библиотеках, которые были обнаружены, все закрыты.

На OpenNet недавно наоборот заметили, что когда наконец за 10 лет в библиотеках с реализацией TLS1.0/1.1 вычистили баги и вылизали код, так сразу кому-то приспичило менять стандарты и проталкивать новые (весьма витиеватые) реализации, в которых ещё неизвестно сколько дыр будет найдено.

[achekalin]

Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
Тип сертификата: ECDSA
Эллиптические кривые для сертификата: prime256v1, secp384r1, secp521r1
Подпись сертификата: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512
Размер ключа RSA: 2048 (если нет ECDSA)
Размер DH Parameter: Нет (полностью отключен)
Размер ECDH Parameter: 256

Было бы хорошо написать мануал «как настроить apache и nginx на работу по этим рекомендациям».

А то и Хабр, и вообще инет набит советами «как», только там по традиции dh-параметры длиной 2048 (особые маньяки, не очень задумываясь о последствиях для клиентов, пишут в своих текстах про 4096 и выше), а вот про «размер ECDH Parameter» вообще никто не пишет.

Про prime256v1 тоже поискать нужно, а если и встретится, то видно, что автор сам не знает, что к чему.

В общем — ликбез бы не помешал, вместе с инструкцией «делай минимум и нормально так»! Тем более, можно сказать, в блоге такой компании сам Бог велел такое написать.

Да, Mozilla SSL Configuration Generator, похоже, про упомянутые изыски не очень в курсе, похоже, это от ненужности таких точных настроек?

[aim]

вообще-то это в точности перезказ упомянутого Mozilla SSL Configuration Generator в позиции «Modern».

[achekalin]

Мне на Modern для nginx 1.15.5 и свежей openssl выдается несколько другое:

вот такое

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    # Redirect all HTTP requests to HTTPS with a 301 Moved Permanently response.
    return 301 https://$host$request_uri;
}

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;

    # certs sent to the client in SERVER HELLO are concatenated in ssl_certificate
    ssl_certificate /path/to/signed_cert_plus_intermediates;
    ssl_certificate_key /path/to/private_key;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets off;


    # modern configuration. tweak to your needs.
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;

    # HSTS (ngx_http_headers_module is required) (15768000 seconds = 6 months)
    add_header Strict-Transport-Security max-age=15768000;

    # OCSP Stapling ---
    # fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;

    ## verify chain of trust of OCSP response using Root CA and Intermediate certs
    ssl_trusted_certificate /path/to/root_CA_cert_plus_intermediates;

    resolver <IP DNS resolver>;

    ....
}

Ничего по поводу

Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
…
Размер DH Parameter: Нет (полностью отключен)
Размер ECDH Parameter: 256

Я что-то не вижу.

[Komei]

Меня вот больше всего беспокоит попытка уничтожить RSA и DHE.

Во-первых, хотя они и требуют больше вычислительной мощности, но значительно более стойкие к атакам со стороны квантовых компьютеров (требуется намного больше кубитов, а, насколько я понимаю, у квантовых компьютеров как раз с масштабированием и проблемы).

Во-вторых, в отличии от DHE, где можно использовать самостоятельно сгенерированное основание, в ECHDE только из заранее заложенных. А про них есть слухи что они не надёжны. Плюс возникает угроза различных атак на основание (по смыслу подобным радужным таблицам).

[Komei]

Вместо того, чтоб опираться на мнение специалистов в области безопасности

Этим специалистам плачу не я, не я их контролирую. Откуда мне знать что они не заангажированы в чью-то пользу? Объём математических знаний чтобы понять RSA и DHE нужен намного меньше (мне моих хватает). А вот с элиптичискими кривыми уже намного хуже.

несколько лет разрабатывали новый стандарт, используя весь современный опыт

Уже были случаи с слабыми генераторами случайных чисел и т.п. Проблема не в том что им не хватает знаний, а в том, что спец службы очень не хотят чтобы криптография была сильной.

Кастомный DHE не только медленный.

Ну и что? Зачастую безопасность ценнее. Я же не требую убрать ECDHE, пусть будет. А вот принудительный запрет обычного это уже очень не приятно. Я бы понял если бы он был не безопасен, но только из-за скорости…

Самостоятельно настраивая эти параметры неспециалисты могут подвергнуть себя опасности

Хм… а какие там параметры? Размер основания и всё. Ну там вы его генерируете с помощью OpenSSL в 99% случаев. Сам аглоритм генерации тоже простой (говорю, т.к. реализовывал его сам) и проверить результаты его работы не так уж и сложно.

С размером основания достаточно рекомендаций по размеру (а так даже дилетанту понятно что чем больше тем надёжнее).

P.S. У меня работал сайт на DHE с основанием 8192 бита. И никаких проблем с ним не было (хотя конечно скоростью он не блистал).

Самые современные кривые ed25519 и ed448 уже достаточно безопасны.

Что значит достаточно? Они или безопасны или нет. И простых алгоритмов их проверки на эту самую безопасность я пока не встречал. Кроме того это не отменяет проблемы одного основания (пароли весь солят не просто так, правда?).

Если вы беспокоитесь о квантовых компьютерах, то как только они появятся, они всю современную криптографию превратят в тыкву.

Они уже есть. Вот только кол-во кубитов наращивать получается плохо. Если я не путаю то ed25519 станет тыквой при 1536 кубитах, а RSA 8192 при 16384 кубитах. Даже если взять 4096, это всё ещё 8192 кубита. А ведь при угрозе таких компьютеров остаются ещё 16 и 32Кбита. Да они медленные, но это меры которые можно принять немедленно.

Собственно поэтому меня и настораживает попытка выдавливания. Не появления новых, а именно принудительного уничтожения старых.

К тому же я думаю, что разработчики скорее всего думают об устройствах IoT, в которых важно энергопотребление при сопоставимой безопасности.

Ну так на нём и пусть используют. Зачем везде то удалять?

[saipr]

TLS 1.2 является необходимым условием для работы HTTP/2, который повышает производительность сайтов. Mozilla рекомендует использовать на серверной стороне современный профиль TLS 1.2, если нет каких-то специализированных потребностей. Современный профиль обеспечивает высокий уровень безопасности и включает в себя следующие параметры:

Наборы шифров: ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Эллиптические кривые для TLS: prime256v1, secp384r1, secp521r1
Тип сертификата: ECDSA
Эллиптические кривые для сертификата: prime256v1, secp384r1, secp521r1
Подпись сертификата: sha256WithRSAEncryption, ecdsa-with-SHA256, ecdsa-with-SHA384, ecdsa-with-SHA512

А где же российские алгоритмы, шифрсьюты?

[shifttstas]

а они кого-то интересуют?