/ фото Charles Dyer CC
Особенности TLS 1.3
Над обновлением протокола начали работать еще в 2014 году. Неофициально работа над TLS 1.3 закончилась в марте этого года, однако инженерам понадобилось еще несколько месяцев на проведение дополнительных проверок.
Создатели утверждают, что итоговый вариант TLS 1.3 — более безопасный и производительный: в его алгоритмах шифрования закрыты все известные (на сегодняшний день) уязвимости TLS 1.2, а процесс «рукопожатия» проходит в два раза быстрее, чем у предшественника. Разработчики также добавили forward secrecy и новые фичи вроде 0-RTT.
В TLS 1.3 внесли самое большое количество значимых изменений за всю историю протокола. По этой причине некоторые даже предлагали назвать его TLS 2.0.
Теперь, когда новая версия протокола TLS 1.3 (RFC 8446) официально одобрена, осталось реализовать его для всех подключений по сети.
Сложности с реализацией
TLS обладает своеобразной обратной совместимостью. При установлении соединения между клиентом и сервером происходит обмен поддерживаемыми версиями протокола и выбирается та, с которой могут работать обе стороны. Однако эта возможность используется не везде. С появлением TLS 1.3 более 3% серверов с поддержкой TLS 1.2 просто разрывали соединение вместо того, чтобы отправлять клиенту номер поддерживаемой версии.
Похожая проблема возникла с промежуточными узлами (middlebox). Из-за того, что TLS особо не менялся, штуки вроде файрволов, NAT и балансировщиков нагрузки отказались работать с новой версией протокола.
Этот феномен инженеры окрестили оссификацией (окостенение). Тот факт, что некоторые разработчики не используют гибкие возможности протокола, внедрение новых его реализаций затрудняется. В качестве аналогии участники индустрии приводят пример со старой дверью. Если ее долго не трогать, петли ржавеют, и та открывается со скрипом.
/ фото Christopher Sessums CC
Получается, что предыдущий протокол устарел, но внедрить новый по умолчанию не получится. Больше по теме можно почитать, например, в прошлогоднем исследовании от IEEE (PDF).
Решение проблемы нашел Дэвид Бенджамин (David Benjamin), работающий над Chromium. Он предложил замаскировать первое сообщение от клиента, поддерживающего TLS 1.3, под сообщение TLS 1.2. И это сработало: упомянутые 3% серверов перестали разрывать соединение. Для узлов-посредников Кайл Некритц (Kyle Nekritz) из Facebook предложил использовать тот же подход. Это позволило сократить число сбоев на 6,5% в Chrome и на 2% в Firefox.
Чтобы проверить, совместимы ли middlebox’ы с новой версией протокола, можно воспользоваться тестом, разработанным в Cloudflare.
Как упростить внедрение
Как утверждает Эрик Рескорла (Eric Rescorla), один из разработчиков спецификаций для TLS и HTTPS, в целом внедрить TLS 1.3 не так уже и сложно. Инженерный совет старался сделать этот процесс максимально простым. TLS 1.3 использует те же ключи и сертификаты, что и TLS 1.2. Это позволяет клиенту и серверу автоматически устанавливать соединение по TLS 1.3, если они оба поддерживают новую версию протокола.
Кроме того, есть ряд библиотек, которые помогут развернуть протокол быстрее. К примеру, в начале прошлой недели Facebook передали свою библиотеку TLS 1.3 Fizz в open source. Fizz уменьшает латентность при трансляции данных, а также нагрузку на CPU.
Разработчики подготовили руководство, как начать пользоваться Fizz на Ubuntu 16.04 LTS. Оно находится в официальном репозитории на GitHub (там также есть руководство для MacOS).
Сперва нужно установить необходимые зависимости folly и libsodium:
sudo apt-get install \ g++ \ cmake \ libboost-all-dev \ libevent-dev \ libdouble-conversion-dev \ libgoogle-glog-dev \ libgflags-dev \ libiberty-dev \ liblz4-dev \ liblzma-dev \ libsnappy-dev \ make \ zlib1g-dev \ binutils-dev \ libjemalloc-dev \ libssl-dev \ pkg-config \ libsodium-dev Далее нужно собрать и установить folly:
git clone https://github.com/facebook/folly mkdir folly/build_ && cd folly/build_ cmake configure .. make -j $(nproc) sudo make install Затем можно переходить к установке Fizz:
cd ../.. git clone https://github.com/facebookincubator/fizz mkdir fizz/build_ && cd fizz/build_ cmake configure ../fizz make -j $(nproc) sudo make install Помимо Fizz в сети есть и другие библиотеки, например, wolfSSL, GnuTLS или rustls.
Будущее протокола
Чтобы окончательно разрешить проблему с «окостенением» протокола, Дэвид Бенджамин предложил помимо официальной версии стандарта использовать ряд его вариаций, которые будут выпускаться каждые шесть недель (вместе с релизами новых версий Chrome). Таким образом, серверы и промежуточные узлы будут обязаны соблюдать все правила установления соединения, иначе большая часть клиентов не сможет подключаться к сервисам.
За счет этого разработчики надеются избежать возможных сбоев загрузки веб-страниц, а также аналогичных проблем с будущими версиями TLS.
Ожидается, что общая безопасность в сети после внедрения TLS 1.3 значительно вырастет. А поспособствовать массовому распространению должны будут библиотеки, упрощающие развертывание новой версии протокола.
P.S. Другие материалы из нашего блога о корпоративном IaaS:
ссылка на оригинал статьи https://habr.com/post/420521/
Добавить комментарий