Ранее мы писали ^[1], что Инженерный совет Интернета (IETF) одобрил новую версию TLS — 1.3. На прошлой неделе протокол был признан стандартом. Сегодня — поговорим о его возможностях.

^[2]
/ фото Charles Dyer ^[3] CC ^[4]

Особенности TLS 1.3

Над обновлением протокола начали работать еще в 2014 году. Неофициально работа над TLS 1.3 закончилась в марте этого года, однако инженерам понадобилось еще несколько месяцев на проведение дополнительных проверок.

Создатели утверждают, что итоговый вариант TLS 1.3 — более безопасный и производительный: в его алгоритмах шифрования закрыты все известные (на сегодняшний день) уязвимости TLS 1.2, а процесс «рукопожатия» проходит в два раза быстрее, чем у предшественника. Разработчики также добавили ^[1] forward secrecy и новые фичи вроде 0-RTT.

В TLS 1.3 внесли самое большое количество значимых изменений за всю историю протокола. По этой причине некоторые даже предлагали ^[5] назвать его TLS 2.0.

Теперь, когда новая версия протокола TLS 1.3 (RFC 8446 ^[6]) официально одобрена, осталось реализовать его для всех подключений по сети.

Сложности с реализацией

TLS обладает своеобразной обратной совместимостью. При установлении соединения между клиентом и сервером происходит обмен поддерживаемыми версиями протокола и выбирается та, с которой могут работать обе стороны. Однако эта возможность используется не везде. С появлением TLS 1.3 более 3% серверов с поддержкой TLS 1.2 просто разрывали ^[7] соединение вместо того, чтобы отправлять клиенту номер поддерживаемой версии.

Похожая проблема возникла с промежуточными узлами (middlebox ^[8]). Из-за того, что TLS особо не менялся, штуки вроде файрволов, NAT и балансировщиков нагрузки отказались работать с новой версией протокола.

Этот феномен инженеры окрестили оссификацией (окостенение). Тот факт, что некоторые разработчики не используют гибкие возможности протокола, внедрение новых его реализаций затрудняется. В качестве аналогии участники индустрии приводят пример ^[9] со старой дверью. Если ее долго не трогать, петли ржавеют, и та открывается со скрипом.

/ фото Christopher Sessums ^[10] CC ^[11]

Получается, что предыдущий протокол устарел, но внедрить новый по умолчанию не получится. Больше по теме можно почитать, например, в прошлогоднем исследовании от IEEE (PDF ^[12]).

Решение проблемы нашел Дэвид Бенджамин (David Benjamin), работающий над Chromium. Он предложил замаскировать первое сообщение от клиента, поддерживающего TLS 1.3, под сообщение TLS 1.2. И это сработало: упомянутые 3% серверов перестали разрывать соединение. Для узлов-посредников Кайл Некритц (Kyle Nekritz) из Facebook предложил использовать тот же подход. Это позволило сократить число сбоев на 6,5% в Chrome и на 2% в Firefox.

Чтобы проверить, совместимы ли middlebox’ы с новой версией протокола, можно воспользоваться тестом ^[13], разработанным в Cloudflare.

Как упростить внедрение

Как утверждает ^[5] Эрик Рескорла (Eric Rescorla), один из разработчиков спецификаций для TLS и HTTPS, в целом внедрить TLS 1.3 не так уже и сложно. Инженерный совет старался сделать этот процесс максимально простым. TLS 1.3 использует те же ключи и сертификаты, что и TLS 1.2. Это позволяет клиенту и серверу автоматически устанавливать соединение по TLS 1.3, если они оба поддерживают новую версию протокола.

Кроме того, есть ряд библиотек, которые помогут развернуть протокол быстрее. К примеру, в начале прошлой недели Facebook передали ^[14] свою библиотеку TLS 1.3 Fizz в open source ^[15]. Fizz уменьшает ^[16] латентность при трансляции данных, а также нагрузку на CPU.

Разработчики подготовили руководство, как начать пользоваться Fizz на Ubuntu 16.04 LTS. Оно находится в официальном репозитории на GitHub ^[15] (там также есть руководство для MacOS).

Сперва нужно установить необходимые зависимости folly ^[17] и libsodium ^[18]:

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 ^[19], GnuTLS ^[20] или rustls ^[21].

Будущее протокола

Чтобы окончательно разрешить проблему с «окостенением» протокола, Дэвид Бенджамин предложил ^[22] помимо официальной версии стандарта использовать ряд его вариаций, которые будут выпускаться каждые шесть недель (вместе с релизами новых версий Chrome). Таким образом, серверы и промежуточные узлы будут обязаны соблюдать все правила установления соединения, иначе большая часть клиентов не сможет подключаться к сервисам.

За счет этого разработчики надеются избежать возможных сбоев загрузки веб-страниц, а также аналогичных проблем с будущими версиями TLS.

Ожидается, что общая безопасность в сети после внедрения TLS 1.3 значительно вырастет. А поспособствовать массовому распространению должны будут библиотеки, упрощающие развертывание новой версии протокола.

---

P.S. Другие материалы из нашего блога о корпоративном IaaS:

• Облачные технологии в финансовой сфере: опыт российских компаний ^[23]
• Что скрывается за термином vCloud Director – взгляд изнутри ^[24]
• Как разместить 100% инфраструктуры в облаке IaaS-провайдера и не пожалеть об этом ^[25]

Автор: ИТ-ГРАДовец

Источник ^[26]