В августе 2018 года IETF утвердил стандарт TLS 1.3
TLS 1.0 и TLS 1.1 скоро фактически прекратят своё существование. Уже сейчас телеметрия Firefox показывает, что эти протоколы составляют ничтожную долю HTTPS-трафика: 1,11% и 0,09%, соответственно. Подавляющее большинство сайтов сейчас используют TLS 1.2. А в 2019?2020 годы все ведущие браузеры намерены полностью отказаться от поддержки TLS 1.0 и TLS 1.1. На серверной стороне рекомендуется отключить эти протоколы уже сейчас.
Почему отключают TLS 1.0 и 1.1
Стандарту TLS 1.0 в январе будущего года исполняется 20 лет. Он выполнил свою роль: за эти годы протокол зашифровал миллиарды, если не триллионы соединений. Со временем стало лучше понятно, как следует проектировать протоколы шифрования. Выросли требования к надёжности шифров. К сожалению, TLS 1.0 и 1.1 не соответствуют этим требованиям.
В TLS 1.0 и 1.1 есть некоторые аспекты, которые внушают опасения, пишет Mozilla Security Blog. Самое плохое, что они не поддерживают работу с современными криптографическими алгоритмами. Например, при рукопожатии обязательно требуют использования алгоритма хэширования SHA-1. В этих версиях TLS невозможно установить более сильный алгоритм хэширования для подписей ServerKeyExchange или CertificateVerify. Поэтому единственный выход — обновление на новую версию TLS.
14 сентября 2018 года Internet Engineering Task Force (IETF) опубликовала черновик официального документа, в котором не рекомендует использовать TLS 1.0 и 1.1. В числе прочего там упоминается, что SHA-1 с криптостойкостью 2^77 нельзя считать безопасным по современным меркам: «2^77 операций [для атаки] — это ниже допустимой границы безопасности».
Фрагмент документа IETF об отказе от старых версий TLS
В документе приводится более подробная техническая информация о причинах такого решения. Там говорится об атаке BEAST (Browser Exploit Against SSL/TLS) на TLS 1.0, а именно — на блочные шифры, где в качестве вектора инициализации для сообщения n используется последний блок шифрования предыдущего сообщения (n-1).
TLS 1.1 выводится из обращения вместе с TLS 1.0, потому что он кардинально не отличается и имеет по сути те же недостатки. В этой версии исправили лишь некоторые ограничения TLS 1.0, которых можно избежать иными способами (речь опять идёт об атаке BEAST).
Согласно рекомендациям NIST, веб-сервисам предлагалось до июля 2018 года удалить поддержку старых версий TLS. Это сделали Amazon, CloudFlare, GitHub, KeyCDN, PayPal и многие другие веб-сервисы.
Сроки отключения
Разработчики всех ведущих браузеров согласились выполнить рекомендации IETF.
Браузер Chrome первым откажется от поддержки старых версий TLS. Разработчики планируют начать процесс с версии Chrome 72, которая выйдет в январе 2019 года: с этого момента для сайтов с устаревшими протоколами будет выводиться предупреждение в консоли DevTools. Полное отключение состоится в версии Chrome 81, которая запланирована к выходу в марте 2020 года (предварительные версии — с января 2020 года).
Microsoft обещает отключить протоколы «в первой половине 2020 года». Mozilla объявила, что отключит TLS 1.0 и 1.1 в Firefox в марте 2020 года. Apple планирует удалить поддержку из браузеров Safari в марте 2020 года.
Пресс-релизы от разработчиков всех ведущих браузеров вышли очень скоординированно:
Современный профиль TLS 1.2
Согласно рекомендации IETF, минимальной криптографической базой для HTTPS-соединений должен быть TLS 1.2. По данным телеметрии Firefox, сейчас он составляет 93,12% HTTPS-трафика (94% по данным Qualys), так что де-факто рекомендации выполняются уже сегодня.
Использование версий TLS для всех HTTPS-соединений в Firefox Beta 62, данные телеметрии за август-сентябрь 2018 года
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
- Размер ключа RSA: 2048 (если нет ECDSA)
- Размер DH Parameter: Нет (полностью отключен)
- Размер ECDH Parameter: 256
- HSTS: max-age=15768000
- Переключение сертификатов: Нет
Специалисты отмечают, что сейчас немногие удостоверяющие центры поддерживают ECDSA-подписи, поэтому в рекомендациях разрешены RSA-подписи для ECDSA-сертификатов.
Протокол обмена ключами DHE полностью удалён из набора шифров, потому что он медленнее ECDHE, а все современные клиенты поддерживают эллиптические кривые.
Алгоритм подписи SHA1 тоже полностью удалён из набора: вместо него используются SHA384 для AES256 и SHA256 для AES128.
Эта конфигурация поддерживается с версий Firefox 27, Chrome 30, IE 11 на Windows 7, Edge, Opera 17, Safari 9, Android 5.0 и Java 8. Если нужна поддержка более старых браузеров, то требования к набору шифров придётся снизить до «среднего» уровня, он же установлен как уровень по умолчанию. Только в самом крайнем случае советуют опускаться до обратно совместимого набора шифров с поддержкой Windows XP/IE6.
К сожалению, сегодня далеко не все вендоры соблюдают рекомендации по безопасной настройке TLS 1.2.
24 сентября 2018 года на arXiv.org было опубликовано академическое исследование этой проблемы, выполненное исследователями из Университета Конкордиа в Монреале (Канада). Авторы проанализировали поведение 17 версий 13 сетевых TLS-инструментов разного класса (бесплатных, с открытым кодом, низко- и высокоуровневых).
Выводы неутешительные: уязвимыми оказались почти все рассматривавшиеся продукты:
Например, выяснилось, что WebTitan, UserGate и Comodo не выполняют валидацию TLS. Comodo и Endian по умолчанию считают всё сертификаты проверенными, а Cacheguard принимает самостоятельно подписанные сертификаты TLS.
Trend Micro, McAfee и Cacheguard используют предварительно сгенерированные пары ключей (хотя документация McAfee и утверждает обратное). Четыре устройства — от UserGate, WebTitan, Microsoft и Comodo — принимают собственные сертификаты для контента, доставляемого извне. Частные ключи хранятся на устройстве и их можно легко извлечь, используя другие уязвимости.
Атака BEAST позволяет получить аутентификационные файлы куки пользователей TLS-средств от Microsoft, Cisco и TrendMicro, а клиенты Sophos, Cacheguard, OpenSense, Comodo и Endian принимают сертификаты RSA-512, приватные ключи для которых легко подделываются в течение четырёх часов.
Будущее за TLS 1.3
В августе 2018 года IETF утвердил стандарт TLS 1.3, о котором подробно рассказывали на Хабре. Основные нововведения в новой версии:
- новый протокол рукопожатия: процесс проходит в два раза быстрее за счёт объединения нескольких шагов, механизм рукопожатия стал более безопасным, так как разработчики удалили все алгоритмы, которые не используют AEAD-режимы блочного шифрования;
- новый процесс выработки ключа с использованием HMAC-функции Extract-and-Expand Key Derivation Function (HKDF);
- удаление шифронаборов, использующих RSA или обмен ключами DH, режим CBC и SHA-1.
Сейчас версию 1.3 в предварительном варианте поддерживают Chrome и Firefox. Согласно телеметрии, браузер Firefox сейчас устанавливает больше соединений по TLS 1.3, чем по TLS 1.0 и 1.1.
Понятно, что обновление одного из важнейших протоколов затронет множество сайтов и займёт долгое время, но в итоге интернет станет безопаснее.
Комментарии (21)
robux
29.10.2018 12:53+1Почему кто-то за меня решает, какими стандартами я не должен пользоваться?
Добавьте новые протоколы, но оставьте поддержку старых. Если уж совсем неймётся («мы очень беспокоимся о безопасности пользователя», ага) — ну сделайте настройку:
«Блокировать сайты с TLS1.0/TLS1.1» — on/off (default «on», так и быть).
Но выпиливать-то зачем?! А если у меня в офисе какой-нибудь видео-регистратор с веб-мордой на TLS1.1, ну или там мини-АТС Panasonic — я больше не смогу их настраивать?
Когда я чувствую на себе такую форсированную «заботу», у меня автоматически появляются смутные сомнения в её благожелательности…nanshakov
29.10.2018 12:58Почему ты просто не пользоваться той версией где это есть?
JediPhilosopher
29.10.2018 13:12Через некоторое время эта версия отовсюду исчезнет, и привет.
Я вот уже столкнулся с таким, не могу на убунте по VPN связаться с одним древним сервером. Там используется какой-то старый шифр, который из всех линуксовых впн клиентов выпилен. В итоге в 14 убунте оно работало, хоть и с плясками (надо было какие-то дополнительные deprecated пакеты ставить) а в 16 уже перестало вообще. И что делать, если я не хочу пользоваться древней версией ОС?Barafu_Albino_Cheetah
29.10.2018 21:20+1Загрузите в Docker старинную Убунту и в ней старинный VPN клиент. Оттуда подключитесь. Дальше в зависимости от ваших нужд либо в тот же контейнер поставьте проксю, и ходите через неё, либо используйте его как gateway.
force
29.10.2018 13:55Наверняка так и сделают — скрытую настройку, запрятанную глубоко, но т.к. раз есть настройка, то её можно и включить, это затянет проблему и её решение.
Простой абстрактный пример из головы: предположим, TLS1.0 взломали полностью, с потрохами. Вы коннектитесь к сайту и ради поддержки старых протоколов и браузер и сервер поддерживают TLS1.0, человек по середине, перехватывает запросы и понижает уровень безопасности до TLS1.0, всё, приехали.
А для древних вещей всегда же можно использовать специально выделенные виртуалки, древние версии браузеров, и прочие костыли. Плохо — да, очень. Но современный мир такой.
aim
29.10.2018 14:09+2потому что Сеть — это коммуналка. если один сосед не моется — вши потом у всех.
robux
29.10.2018 15:53А кто сказал, что в TLS 1.0 и 1.1 есть «вши»? Сами алгоритмы ни разу не были скомпрометированы, а баги в библиотеках, которые были обнаружены, все закрыты.
На OpenNet недавно наоборот заметили, что когда наконец за 10 лет в библиотеках с реализацией TLS1.0/1.1 вычистили баги и вылизали код, так сразу кому-то приспичило менять стандарты и проталкивать новые (весьма витиеватые) реализации, в которых ещё неизвестно сколько дыр будет найдено.ReklatsMasters
30.10.2018 20:55+1вычистили баги и вылизали код
Сами алгоритмы ни разу не были скомпрометированы, а баги в библиотекахВот тут вы не правы. Есть реальные уязвимости в самом протоколе и алгоритмах. Именно поэтому и нужны новые протоколы и отказ от старых. Вот почитайте эту статью, там много всего объясняется.
achekalin
29.10.2018 13:01Эллиптические кривые для 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
29.10.2018 14:11вообще-то это в точности перезказ упомянутого Mozilla SSL Configuration Generator в позиции «Modern».
achekalin
29.10.2018 14:16Мне на 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>; .... }
Komei
30.10.2018 05:56Меня вот больше всего беспокоит попытка уничтожить RSA и DHE.
Во-первых, хотя они и требуют больше вычислительной мощности, но значительно более стойкие к атакам со стороны квантовых компьютеров (требуется намного больше кубитов, а, насколько я понимаю, у квантовых компьютеров как раз с масштабированием и проблемы).
Во-вторых, в отличии от DHE, где можно использовать самостоятельно сгенерированное основание, в ECHDE только из заранее заложенных. А про них есть слухи что они не надёжны. Плюс возникает угроза различных атак на основание (по смыслу подобным радужным таблицам).ReklatsMasters
30.10.2018 21:40+1Позвольте я уточню. Вместо того, чтоб опираться на мнение специалистов в области безопасности, которые несколько лет разрабатывали новый стандарт, используя весь современный опыт, вы доверяете каким-то слухам. На мой взгляд это контрпродуктивный подход.
Кастомный DHE не только медленный. Не все в мире являются специалистами в области безопасности. Самостоятельно настраивая эти параметры неспециалисты могут подвергнуть себя опасности, используя небезопасные параметры. Самые современные кривые ed25519 и ed448 уже достаточно безопасны.
Если вы беспокоитесь о квантовых компьютерах, то как только они появятся, они всю современную криптографию превратят в тыкву. Так что тут дело не только в rsa. К тому же я думаю, что разработчики скорее всего думают об устройствах IoT, в которых важно энергопотребление при сопоставимой безопасности.
Komei
30.10.2018 22:49+1Вместо того, чтоб опираться на мнение специалистов в области безопасности
Этим специалистам плачу не я, не я их контролирую. Откуда мне знать что они не заангажированы в чью-то пользу? Объём математических знаний чтобы понять RSA и DHE нужен намного меньше (мне моих хватает). А вот с элиптичискими кривыми уже намного хуже.
несколько лет разрабатывали новый стандарт, используя весь современный опыт
Уже были случаи с слабыми генераторами случайных чисел и т.п. Проблема не в том что им не хватает знаний, а в том, что спец службы очень не хотят чтобы криптография была сильной.
Кастомный DHE не только медленный.
Ну и что? Зачастую безопасность ценнее. Я же не требую убрать ECDHE, пусть будет. А вот принудительный запрет обычного это уже очень не приятно. Я бы понял если бы он был не безопасен, но только из-за скорости…
Самостоятельно настраивая эти параметры неспециалисты могут подвергнуть себя опасности
Хм… а какие там параметры? Размер основания и всё. Ну там вы его генерируете с помощью OpenSSL в 99% случаев. Сам аглоритм генерации тоже простой (говорю, т.к. реализовывал его сам) и проверить результаты его работы не так уж и сложно.
С размером основания достаточно рекомендаций по размеру (а так даже дилетанту понятно что чем больше тем надёжнее).
P.S. У меня работал сайт на DHE с основанием 8192 бита. И никаких проблем с ним не было (хотя конечно скоростью он не блистал).
Самые современные кривые ed25519 и ed448 уже достаточно безопасны.
Что значит достаточно? Они или безопасны или нет. И простых алгоритмов их проверки на эту самую безопасность я пока не встречал. Кроме того это не отменяет проблемы одного основания (пароли весь солят не просто так, правда?).
Если вы беспокоитесь о квантовых компьютерах, то как только они появятся, они всю современную криптографию превратят в тыкву.
Они уже есть. Вот только кол-во кубитов наращивать получается плохо. Если я не путаю то ed25519 станет тыквой при 1536 кубитах, а RSA 8192 при 16384 кубитах. Даже если взять 4096, это всё ещё 8192 кубита. А ведь при угрозе таких компьютеров остаются ещё 16 и 32Кбита. Да они медленные, но это меры которые можно принять немедленно.
Собственно поэтому меня и настораживает попытка выдавливания. Не появления новых, а именно принудительного уничтожения старых.
К тому же я думаю, что разработчики скорее всего думают об устройствах IoT, в которых важно энергопотребление при сопоставимой безопасности.
Ну так на нём и пусть используют. Зачем везде то удалять?ReklatsMasters
31.10.2018 03:31Мне кажется, что вы ищете теорию заговоров там, где её нет.
Ответы на ваши вопросы уже даны в новых RFC, черновиках. В конце концов, вы можете поискать обсуждение участников комитета на форуме https://datatracker.ietf.org/wg/tls/about/, посмотреть материалы встреч. Ну или даже просто задать им вопрос по почте, уверен, они могут ответить.
vesper-bot
Теперь на свежую XP SP3 уже и файрфокс не поставишь… Печально.
khanid
Ну уже с пол года как было сообщение в самом браузере, что в xp/win2k3 поддержка ff прекращается.
vesper-bot
Понятное дело, но мне не обновлять его надо, а запускать, причем не очень важно, насколько древний — для особо противных железок 3.6.28 вполне себе подходит, а если надо серфить, можно взять 42LTS (или сколько он там был), но вообще в этом случае правильнее поставить ОС поновее.
oleg-x2001
А зачем вообще ставить XP??? Не троллинг, реально интересно.
vesper-bot
Запускать старые игры, которые писались под 98ю. Imperialism, например. Ещё как вариант — поддержка какого-ниудь легаси ПО вроде старой-престарой учетной системы. Был, помнится, такой ИНФИН, вообще досовая штуковина по факту. Хотя со временем и это всё помрет, и тогда уже не понадобится ставить ХР.
Но игры будет жалко :)
JerleShannara
Старое сетевое железо например. Весь Avocent имеет афигенную совместимость с новыми версиями жабы и браузеров. И если жаба правится уничтожением безопасности на корню, то с браузерами косяки вылезают.