Отключение протокола TLS 1.0

Эволюция протоколов безопасности идёт непрерывно – разрабатываются новые, более быстрые и надёжные криптоалгоритмы, находятся проблемы и ошибки как в стандартах, так и в конкретных реализациях.

В своё время так завершилась карьера протоколов семейства SSL – вначале 2.0, а потом и 3.0.

Теперь настало время TLS 1.0.

По сути, на данный момент соединения, установленные с поддержкой TLS 1.0, визуально обозначаются браузером как безопасные, хотя это уже не так.

Обманывать людей, которые подключаются к сайту – где и личный кабинет, и системы для оплаты – что их данные в безопасности – как-то неправильно. Поэтому старую версию надо отключить. Мы сделаем это 1 августа 2018 года.

Перейдём к конкретике того, что изменится.

Поддержка TLS 1.2

Краткую историю протоколов семейства TLS вы можете увидеть в нашей статье про безопасность TLS.

Говоря очень просто, TLS 1.2 (версия 1.1 откровенно “промежуточная” и реализации, где есть TLS 1.1, но нет TLS 1.2, встретить крайне маловероятно) существует уже десяток лет и встроен в ОС начиная с Windows 7.

Все современные – да, в общем и не-современные, а, скажем, пятилетней давности – браузеры отлично поддерживают TLS 1.2, поэтому никаких проблем быть не должно – разве что если пользоваться встроенным в Windows XP Internet Explorer’ом. Ну или встроенным в старую версию Android (например, 4.2) браузером – у него тоже будут проблемы.

Нужны ли спец.настройки?

Нет, согласование версии протокола идёт автоматически.

В теории, если вы подключаетесь с рабочего компьютера, входящего в домен Active Directory, системными администраторами могут применяться групповые политики, влияющие на “комплекты шифров” (cipher suites), и можно настроить это так, что TLS 1.2 не сможет согласоваться. Однако это сугубо теоретическая тема, на практике никому не нужно умышленно “мешать” подключаться к веб-сайтам по более новому и безопасному протоколу TLS 1.2.

Станет быстрее или медленнее?

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

Почему столько внимания этой мелочи?

Потому что компетентность в тех вопросах, про которые мы ведём курсы, должна как-то подтверждаться на практике. Сейчас крайне распространёна подмена образования т.н. “инфотренерством” – когда биологический организм используется как переносчик текста со слайдов на аудиодорожку. Это недорого и не требует никакой квалификации – поэтому используется достаточно массово. Проблема в том, что “натасканный на скиллы” слушатель, по сути, не получает обратной связи, т.к. на любые вопросы на тему практики или отклонения от стандартных и предлагаемых реализаций технологии он получает что-то вида “это всё можно нагуглить”.

Мы переучиваем по акции “Повторное прослушивание курса у нас со скидкой” достаточно много людей, и наглядно видим текущий уровень ситуации. Он таков, что люди реально думают, что скачав несколько роликов “Где нажать какие кнопки чтобы развернуть продукт N” они начнут как-то разбираться в этом продукте, хотя просто заучивают примитивные действия.

Говоря проще, никакого обучения при “натаскивании на скиллы” не происходит – и жертвы начинают ощущать это на себе достаточно быстро.

Но так как расходы на преподавателей при этом резко снижаются (им не нужна квалификация для ведения авторизованных курсов или начитки кратких ликбезов класса “howto videos”), то организаторов обучения такая тема вполне устраивает.

Ну а IT-рынок получает дисбаланс вида “low-end сегмент дико перегружен людьми, которые зазубрили очень несложные действия и почему-то ждут, что за это им вот-вот начнут платить много денег”.

Наглядный пример. Вот так выглядит настроенный TLS-доступ к сайту (проверка осуществляется через стандартный SSLLabs):

А вот ситуация, когда либо нет квалификации для правильной настройки, либо хотя бы рамочного представления о том, как вообще всё должно работать (проверка осуществляется через стандартный SSLLabs) – картинки кликабельны:

Т.е. всё настолько “по дефолтам”, что ниже любого приемлемого минимума. На скриншотах цифрами подписаны проблемы в конфигурации (на картинках проще кликнуть для просмотра в полноэкранном формате) – перечислим их по порядку:

1. Один сертификат на 2048 бит – для второй половины 2018 года слабовато, может подойти для CDN-ресурса, но не для сайта, где в личном кабинете есть функция платежа и происходит обработка перс.данных. В современных стандартах – например, WPA3 – RSA с ключом ниже 3072 бит уже ниже минимальной приемлемой планки. Возможно, что ключ в 2048 бит выбран по причине более быстрой установки соединения, чем в случае с 4096 – но тогда проще сделать два сертификата, один с длинным RSA, а другой с EC. Скорее всего ситуация проще и RSA 2048 выбрано, потому что это дефолтные настройки.
2. Extended validation – выглядит в браузере круто, но технически не влияет на безопасность. Просто платная опция к докупке сертификата. Кстати, вполне реализуемая на своём локальном PKI.
3. Отсутствие OCSP Must Staple – клиент будет подключаться дольше и может делать лишние обращения к OCSP-серверу, мы рассказывали о том, как правильно настраивать дополнительные опции к OCSP.
4. Отсутствие DNS CAA – отсутствие поддержки обязательной с сентября 2017 года опции, притом крайне несложно настраиваемой, весьма показательно. По факту – открывает возможность для целого класса атак.
5. Отсутствие поддержки TLS 1.3 – самая новая, безопасная и более быстрая версия, которая уже пару лет как есть в большинстве браузеров (последовательно поддерживались draft 18, draft 23 и сейчас draft 28, по сути, финальный) не поддерживается ни в одном из вариантов. Причина неизвестна, но предположим, что в настройке “по умолчанию” на данном веб-сервере её нет.
6. Стандартный набор cipher suites – крайне плохая ситуация, когда сервер в явном виде декларирует поддержку устаревших (некоторые из списка устарели уже 7 лет назад) cipher suites, при согласовании которых передаваемые данные по сути не защищены. Можно было бы предположить, что имеет место хитрый план в части совместимости с самыми старыми версиями браузеров, но наличие и RC4_128_SHA и RC4_128_MD5 мягко намекает, что дело более простое – это настройки “по умолчанию” у старой версии Apache. Соответственно, они и не безопасны, и не дают возможности согласовать более современные и быстрые методы шифрования, и не прибавляют какой-то совместимости. Просто копипаста древних дефолтных настроек.
7. Нет поддержки TLS SCSV – канал уязвим к атакам на пересогласование, потому что сервер не умеет в Signaling Cipher Suite Value. Сигнализация SCSV придумана в 2009 году, вошла в RFC в 2010, сейчас 2018й.
8. Поддержка RC4 – осознанно поддерживается небезопасный устаревший алгоритм RC4, сам факт возможности согласования которого – уже осознанное снижение уровня безопасности. Можно было бы сослаться на “зато он быстрый”, но увы – повсеместно аппаратно реализованный AES или быстрый программный ChaCha20 не оставляют этому утверждению шансов.
9. Отсутствие FS – крайне опасная проблема, приводящая к тому, что взлом одной сессии одного пользователя может послужить для доступа ко всем данным сессий других пользователей. Сервер, говоря проще, не каждому свой комплект ключевого материала придумывает, а работает от одного на всех. Про работу FS/PFS мы подробно писали ранее, ну а поддержка этого “сверхнового” метода повышения безопасности подключения клиентов есть, например, ещё в Windows 2000. То есть очень новая технология, возможно, просто не успели включить.
10. Отсутствие ALPN – Application-Layer Protocol Negotiation с 2014 года помогает переключаться на HTTP/2, куда как более быстрый и безопасный HTTP-протокол, чем ставший стандартным HTTP 1.1. Отсутствие ALPN – отсутствие у клиентов, подключающихся к сайту, возможности быстро и с меньшим объёмом служебного трафика загружать страницы по HTTP/2.
11. Отсутствие NPN – ну, раз ALPN нет, то и NPN тоже. Настройки по дефолту.
12. Отсутствие Session Resumption (tickets) – локальное кэширование данных SSL/TLS-сессий значительно ускоряет переподключение клиента, который, допустим, долго читал страницу сайта и решил кликнуть на ссылке. Для этого кэширования может использоваться механизм Tickets, который несложно настраивается с 2008 года. Но это если настраивать, да.
13. Отсутствие HSTS – доступ к страницам, содержащим персональные данные, а также данные об оплате, возможен и по незашифрованному подключению, и сервер никак не скажет “переключись на TLS”. И это не Windows 95 OSR2, а 2018й год.
14. Отсутствие HSTS Preloading – для того, чтобы клиент сразу же, введя название сайта – например, www.atraining.ru – начал подключаться по безопасному каналу, выбрав https://, сайт можно добавить в HSTS Preload List. Это совсем несложно, но ведь это нельзя докупить, и это не настройка по умолчанию – про это надо знать и это надо сделать. А значит смогли не все.
15. Отсутствие HPKP – подключающийся клиент уязвим к атакам с подделкой сертификата сервера, т.к. сервер не декларирует, какие сертификаты должны попадаться в цепочке доверенных. Настроить HPKP очень несложно.
16. Стандартные DH Primes – это настолько п.., что теме посвящён отдельный сайт, на котором подробно объясняется, что если системный администратор развернул веб-сервер и не удосужился сгенерить новые primes, т.е. юзает те, которые идут “из дистрибутива”, то всё не плохо, а очень плохо. Мы подробно разбирали, как перегенерить DH primes, это совсем несложно. Но разово поставить веб-сервер и ни разу вообще не задуматься о том, что для установки сессии используются стандартные, идущие из дистрибутива “для примера” DH primes – это настолько чёткая профнепригодность, что даже смысла обсуждать нет. Образцовое “зато сертификат докуплен за недорого”.
17. DH Primes (Ys) Reuse – подвид предыдущей ситуации, только добавляющий к “вместо случайных чисел идут стандартные” вариант “могут и не стандартные, но легко вычисляемые и одни на все сессии пользователей”.
18. ECDH Reuse – в дополнение к DH включен ECDH, да вот только с тем же результатом. Включен, но не настроен.
19. Supported Named Groups – мы видим настройки по умолчанию для Apache, характеризующиеся тем, что в первую очередь согласовываются более слабые EC, притом весь список состоит только из утверждённых американским NIST’ом “правильных с точки зрения АНБ эллиптических кривых”, про что давно подробно разобрано. Более безопасные и быстрые – например, 25519 – отсутствуют. Сессия ставится медленнее и сам обмен криптографическим материалом небезопасен.
20. SSL 2 Handshake – протокол SSL 2.0 выключен, да и 3.0 тоже, но согласование в стиле “как в 1996 году” оставлено. Это тоже настройка по умолчанию.

Вполне очевидно, что с такими настройками говорить о какой-либо безопасности – смешно.

Чтобы не попадать в подобные ситуации нужна квалификация и знания, а они могут быть получены у тех, кто знаком с информационной безопасностью не только по слайдам курсов. Про это мы говорим на занятиях по настройке протоколов SSL / TLS на современном ПО – разобрав примеры наподобие вышеприведённого.