В блог

Как TLS 1.3 стал новым стандартом безопасности передачи данных

TLS 1.3 — это новейшая версия протокола транспортного уровня TLS, который отвечает за безопасною передачу и целостность сообщения.

Когда появился TLS 1.3

TLS 1.3 был разработан в августе 2018 года и описан в RFC 8446. Работать над ним начали ещё в 2014 году. К этому моменту 80% трафика в Chrome и 70% в Firefox шло через защищённое соединение. Однако предыдущая версия протокола — TLS 1.2 — уже не отвечала требованиям безопасности и производительности.

Какие проблемы были у TLS 1.2

TLS 1.2 разрабатывался в 2008 году. Тогда для доступа в интернет использовались только стационарные компьютеры. Но сейчас у каждого есть смартфон, и люди выходят в интернет с мобильных устройств чаще, чем с компьютеров. А у них вычислительные возможности меньше, чем у ПК. И чтобы сайты со смартфонов открывались достаточно быстро, нужно было уменьшить время установки соединения.

Другая проблема TLS 1.2 была связана с многочисленными атаками. Их было настолько много, что для описания создали отдельный документ — RFC 7457.

В TLS 1.3 эти проблемы удалось решить. Рассказываем, чем новая версия отличается от TLS 1.2 и какие у неё особенности.

Чем TLS 1.3 отличается от TLS 1.2

Основные преимущества TLS 1.3 — это лучшая производительность и безопасность.

Безопасность

1. Запрет устаревших технологий. TLS 1.2 поддерживает много устаревших технологий, которые сейчас не считаются безопасными, например MD5, SHA-1, 3DES, DES или AES-CBC. В TLS 1.3 от этих технологий отказались.

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

В протокол добавили несколько новых шифров. В итоге TLS 1.3 поддерживает только шифры AEAD — они обеспечивают одновременно и шифрование данных, и создание MAC. Такие шифры считаются более безопасными, и вот почему.

Если за шифрование сообщения и создание MAC отвечают разные шифры и по отдельности они обеспечивают безопасность, то это не значит, что в сочетании друг с другом они тоже будут обеспечивать безопасность. Чтобы решить эту проблему, в TLS 1.2 использовались наборы шифров. Но они уязвимы для некоторых атак. А шифры AEAD избавляют протокол от этой проблемы.

2. Совершенная прямая секретность. В TLS 1.3 используются только алгоритмы, которые обеспечивают PFS — совершенную прямую секретность. Эта технология требует, чтобы для каждой новой сессии генерировались новые ключи шифрования. Таким образом, даже если злоумышленнику удастся перехватить сообщение, а потом через какое-то время получить доступ к ключу, он всё равно не сможет расшифровать данные, так как ключ будет уже другим. Поэтому в TLS 1.3 запрещены алгоритм со статическим закрытым ключом RSA и алгоритм Диффи — Хеллмана со статическими параметрами.

Получается, что в протоколе остаётся только ограниченный набор шифров, что помогает не только усилить безопасность, но и улучшить производительность. Но об этом чуть позже.

3. Запрет повторного согласования TLS. Повторное согласование в TLS 1.2 позволяло менять детали рукопожатия (handshake) после того, как соединение уже было установлено. И это было уязвимым местом в протоколе. В TLS 1.3 оно запрещено.

Производительность

1. Упрощённый процесс рукопожатия. Его удалось сократить до 1-RTT. Это позволило уменьшить время установки соединения почти в 2 раза.

В TLS 1.2:

1. Клиент отправляет серверу сообщение Client Hello и список шифров, которые он поддерживает.
2. Сервер выбирает набор шифров, с которыми может работать, и передаёт его клиенту в сообщении Server Hello.
3. Только после этого между клиентом и сервером происходит обмен ключами.

В TLS 1.3 более узкий набор шифров. Поэтому в первом же сообщении клиент предполагает, какой шифр сервер поддерживает.

1. Вместе с сообщением Client Hello клиент отправляет информацию для обмена ключами.
2. В ответ сервер отправляет сообщение Server Hello, свою информацию для обмена ключами, сертификат и сообщение Finished.

Если вдруг предположение клиента оказалось неверным и сервер не поддерживает нужный шифр, тогда в ответ сервер отправляет HelloRetryRequest (запрос на повторную отправку Hello) и информацию о шифрах, которые он поддерживает. А дальше всё происходит по стандартной схеме.

2. 0-RTT — новый подход к возобновлению соединения. Он позволяет максимально быстро восстановить сессию. Если пользователь заходил на сайт, потом закрыл его, а через какое-то время снова решил зайти, то клиент и сервер не будут проводить весь процесс рукопожатия полностью.

1. В сообщение Client Hello клиент включает информацию о предыдущей сессии и вместе с этим отправляет зашифрованные данные. Они зашифрованы с помощью ключей, которые использовались в прошлый раз.
2. Сервер в сообщении Server Hello отправляет свою информацию о ключах и зашифрованные данные.

Получается, что обмен данными происходит ещё до того, как соединение возобновлено, в первых сообщениях. Это сильно ускоряет процесс загрузки страницы, особенно на смартфонах.

Сейчас TLS 1.3 автоматически поддерживает большинство популярных браузеров: Chrome, Firefox, все браузеры компании Microsoft. Полный переход всего интернета на новую версию протокола — это лишь вопрос времени.

Как мы используем TLS 1.3 при доставке контента

Наши клиенты часто спрашивают, поддерживает ли наша CDN новую версию протокола. Отвечаем.

TLS 1.3 мы внедрили сразу, как только он появился, в 2018 году. В протоколе по умолчанию задействованы все технологии, в том числе 0-RTT.

Как настроить передачу данных по TLS 1.3

Протокол поддерживается по умолчанию для всех клиентов. Если вы уже подключили G-Core Labs CDN, дополнительно ничего делать не нужно.

Если вы пока не используете CDN, то самое время попробовать. Благодаря нашей сети ваш контент будет доставлен не только максимально быстро, но и предельно безопасно.