Своими наблюдениями за процентным содержанием расширения TLS SNI протокола TLS (RFC 4366) в общем объеме шифрованных HTTPS запросов делятся специалисты Akamai.

В последние несколько лет наблюдается бурный рост числа клиентов, поддерживающих TLS SNI (стандарт, позволяющий сделать HTTPS намного более масштабируемым). Если в начале 2014 года только 85% клиентских HTTPS запросов было сделано с использованием TLS SNI, то сегодня многие пользователи сервиса Akamai до 99% запросов получают в формате TLS SNI.

Это говорит о глобальном тренде развертывания сайтов, использующих только SNI. При этом, 31% сайтов из рейтинга Alexa Top 100k с действующими HTTPS-сертификатами сообщают этот сертификат клиенту только в том случае, если запрос идет в формате TLS SNI.



При переводе трафика на стандарт HTTPS было две серьезных проблемы: первая – труднодоступность самих сертификатов, и вторая – технические сложности с виртуальным хостингом TLS. Легкодоступные автоматически выдаваемые сертификаты Domain Validation (DV), предоставляемые такими сервисами, как Let’s Encrypt, решили первую проблему. TLS Server Name Indication (SNI) – технология, которая решает вторую проблему. До недавнего времени широкое ее внедрение было затруднено большим количеством клиентов, не поддерживающих этот стандарт.

Рост применения TLS SNI доказывает, что его уже можно считать всеобщим стандартом. Оставшаяся часть клиентов, которая не поддерживает TLS SNI, может решить эту проблему примерно в течение года, если вообще хочет иметь доступ ко всем сайтам. Особенно с растущим применением HTTPS – уже примерно половина страниц загружается по HTTPS, по данным Firefox.

TLS лежит в основе HTTPS, и с его помощью осуществляется шифрование и аутентификация. Когда Netscape разработали протокол SSL v3 и его довольно успешного IETF-стандартизированного потомка TLS 0.1, они столкнулись с тем, что виртуальные хостинги не готовы их использовать. Для аутентификации клиент посылает серверу сообщение «ClientHello» и ожидает в ответ сообщение «ServerHello», содержащее сертификат безопасности, идентифицирующий имя сервера. Если имя в сертификате не соответствует тому имени, которое ожидает получить клиент, правильно настроенный клиент должен прервать коннект и выдать сообщение об ошибке. Но в случае виртуального хостинга один сервер обслуживает десятки, сотни, тысячи, а хотя бы и миллионы сайтов и в этом случае сервер должен знать, какой именно сертификат вернуть клиенту.

Если в запросе ClientHello не содержится имени сайта, серверу, обслуживающему HTTPS на порту 443, не остается ничего другого, кроме как выделять для каждого сертификата (и, соответственно, сайта) отдельный IP. Для CDN сервисов, таких, как Akamai, развернутых в сотнях и тысячах локаций, это означает необходимость выделения сотен и тысяч виртуальных IP для каждого сертификата. А в связи с конечностью пула свободно выдаваемых IPv4, это быстро превращается в фундаментальную проблему, затрудняющую рост и масштабирование.

Идентификация по имени сервера (SNI) была введена в TLS в 2003 году в RFC 3546. Это позволило клиентам включать имя сервера, с которым они хотели бы установить соединение, в запрос ClientHello, давая возможность серверу понять, какой именной сертификат нужно сообщить в ответ клиенту в сообщении ServerHello. Это SNI-расширение и стало той самой информацией о маршруте, которая сделала возможным виртуальный хостинг, аналогично маршрутизирующей роли заголовков HTTP, которые были введены с самого начала, в момент принятия HTTP/1.0 в 1997 году. Кроме того, балансировщики нагрузки в дата-центрах теперь получили возможность использовать TLS SNI для распределения направленного на общий IP адрес трафика по правильным бэкенд-серверам.


IPv6 и HTTP/2, конечно, могли бы помочь решить проблему. HTTP/2 сам по себе уже требует, чтобы клиенты отправляли TLS SNI. А практически бесконечное пространство адресов IPv6 решает проблему виртуальных адресов, и по этой причине Akamai вводит для своих клиентов IPv4+IPv6 двойную адресацию «по умолчанию» с 2016 года. Но большинство тех самых клиентов, которые не поддерживают TLS SNI, не поддерживают также и HTTP/2 и IPv6.

Недостаточно полное принятие клиентами затрудняло практическое внедрение TLS SNI. Широко распространенные ранее операционные системы, такие как Windows XP и Android 2.2, не поддерживали TLS SNI, и введение жесткого требования наличия SNI запроса в протоколе HTTPS оставило бы их за бортом. В 2013 году в Akamai видели, что только 80% клиентов поддерживают этот протокол. Даже еще в апреле 2015 года только 90% HTTPS запросов содержало SNI. Снижение числа не поддерживающих этот стандарт клиентов вызвано также и другими причинами, изменяющими общую ситуацию с HTTPS-протоколами, например, прекращением поддержки SHA-1 сертификатов.

Ситуация изменилась резко за последние два года. Сегодня в Akamai в среднем 98% процентов запросов содержат TLS SNI со стороны клиента. Однако большая часть не поддерживающих SNI клиентов, это отдельные приложения, разработанные в частном порядке и использующие старые протоколы на своих индивидуальных маршрутах. Поэтому медианный участник HTTPS-обмена — оборудование, отдающее клиенту сертификат, — видит уже 99% запросов, включающих SNI. И 12% таких точек видят уже 99.9% трафика с аутентификацией по SNI.

Если же исключить из рассмотрения Китай, где SNI используется в гораздо меньшей степени, и США, где есть ряд ботов/агентов не поддерживающих SNI, медианный участник, по выборке из пользователей сервиса Akamai, будет видеть 99.4% запросов, содержащих SNI. Даже в США медианный участник видит 98.4% SNI содержащих запросов.

Если подробнее рассмотреть неиспользующих SNI клиентов, то по данным Akamai в их число входят:

• Современные клиенты, которые используют перехват трафика HTTPS промежуточными прокси, например, для осуществления родительского контроля или контроля трафика корпоративной сети. Эти промежуточные прокси ухудшают надежность TLS шифрования, и логика их работы, вынуждающая подменять имена серверов, противоречит идеологии SNI. Кроме того, зачастую эти системы вообще не проверяют сертификаты.
  
  
• Оставшиеся системы под управлением Windows XP и даже еще более старых версий ОС. Не вполне понятно, как они вообще подключаются после отмены SHA-1, но, возможно, они также находятся за промежуточными прокси, которые не спрашивают сертификаты.
  
  
• Некоторые боты/роботы, принадлежащие поисковым системам. Мы связались с некоторыми из верхних строчек топ-листов, и они сказали, что в ближайшем будущем все-таки будут вводить TLS SNI тоже. Похоже, что существует множество как доброкачественных, так и вредоносных ботов, непрерывно сканирующих все пространство IPv4 в поисках HTTPS-серверов.
  
  
• Различные клиенты и боты, написанные на основе старых версий WebKit, Java, curl и python. Да и те клиенты, которые используют более свежие версии этих библиотек должны все-таки иметь реализованными механизмы правильной инициализации обмена на основе TLS SNI. Сюда входит широкий диапазон клиентов – начиная от вредоносных программ и заканчивая различными беззаголовочными браузерами для анализа производительности сайтов.
  
  
• Некоторые частные приложения (менеджеры загрузки, приложения для игровых консолей, некоторые мобильные приложения). Они, как правило, изолированы на определенных сайтах.

Некоторые сайты хотели перейти полностью на TLS SNI и при этом были готовы потерять от 10% до 20% посетителей. Теперь переход на TLS SNI «отрезает» всего 1% посетителей, которые в основном представляют собой боты, вредоносные программы и небезопасные клиенты, поэтому желающих перейти на TLS SNI будет гораздо больше. Let’s Encrypt выдало около 27 миллионов бесплатных сертификатов, побудив значительное количество операторов сайтов перейти на HTTPS. Akamai с конца 2015 года выдает поддерживающие только TLS SNI сертификаты как часть своих пакетных предложений, побуждая тем самым сайты переходить на этот стандарт и фактически, делая задел на будущее — вынуждая их возможных пользователей также переходить на TLS SNI.

Переход к использованию исключительно SNI уже происходит. На сегодня примерно 75% сайтов из Alexa топ-1000 доступны по протоколу HTTPS, из них 12% используют только TLS SNI (то есть сообщают заверенный сертификат только в ответ на SNI запрос). Среди Alexa топ-100к сайтов уже только 55% используют HTTPS, но среди них 31% исключительно в SNI формате, несмотря на то, что многие из них все еще доступны по HTTP.

Чем больше сайтов будет требовать TLS SNI, тем большее давление будут испытывать клиенты, вынужденные реализовывать SNI-механизм в своих протоколах. Уменьшение числа не-SNI клиентов побуждает сайты быстрее переходить на новые сертификаты, а это, в свою очередь, заставляет не-SNI клиентов переходить на TLS SNI, аналогично тому, как это было в свое время, собственно, с HTTPS как таковым.

Тенденция налицо: TLS SNI становится всеобщим, общепринятым и, возможно, уже даже «дефолтным» стандартом в HTTPS. Разработчики клиентского ПО должны понимать это и иметь в виду необходимость корректной реализации данного протокола в своих пакетах.