В августе 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.
Понятно, что обновление одного из важнейших протоколов затронет множество сайтов и займёт долгое время, но в итоге интернет станет безопаснее.
