sni ssl что это
Настройка HTTPS-серверов
Чтобы настроить HTTPS-сервер, необходимо включить параметр ssl на слушающих сокетах в блоке server, а также указать местоположение файлов с сертификатом сервера и секретным ключом:
Сертификат сервера является публичным. Он посылается каждому клиенту, соединяющемуся с сервером. Секретный ключ следует хранить в файле с ограниченным доступом (права доступа должны позволять главному процессу nginx читать этот файл). Секретный ключ можно также хранить в одном файле с сертификатом:
при этом права доступа к файлу следует также ограничить. Несмотря на то, что и сертификат, и ключ хранятся в одном файле, клиенту посылается только сертификат.
С помощью директив ssl_protocols и ssl_ciphers можно ограничить соединения использованием только “сильных” версий и шифров SSL/TLS. По умолчанию nginx использует “ ssl_protocols TLSv1 TLSv1.1 TLSv1.2 ” и “ ssl_ciphers HIGH:!aNULL:!MD5 ”, поэтому их явная настройка в общем случае не требуется. Следует отметить, что значения по умолчанию этих директив несколько раз менялись.
Оптимизация HTTPS-сервера
SSL-операции потребляют дополнительные ресурсы процессора. На мультипроцессорных системах следует запускать несколько рабочих процессов, не меньше числа доступных процессорных ядер. Наиболее ресурсоёмкой для процессора является операция SSL handshake, в рамках которой формируются криптографические параметры сессии. Существует два способа уменьшения числа этих операций, производимых для каждого клиента: использование постоянных (keepalive) соединений, позволяющих в рамках одного соединения обрабатывать сразу несколько запросов, и повторное использование параметров SSL-сессии для предотвращения необходимости выполнения SSL handshake для параллельных и последующих соединений. Сессии хранятся в кэше SSL-сессий, разделяемом между рабочими процессами и настраиваемом директивой ssl_session_cache. В 1 мегабайт кэша помещается около 4000 сессий. Таймаут кэша по умолчанию равен 5 минутам. Он может быть увеличен с помощью директивы ssl_session_timeout. Вот пример конфигурации, оптимизированной под многоядерную систему с 10-мегабайтным разделяемым кэшем сессий:
Цепочки SSL-сертификатов
Некоторые браузеры могут выдавать предупреждение о сертификате, подписанном общеизвестным центром сертификации, в то время как другие браузеры без проблем принимают этот же сертификат. Так происходит потому, что центр, выдавший сертификат, подписал его промежуточным сертификатом, которого нет в базе данных сертификатов общеизвестных доверенных центров сертификации, распространяемой вместе с браузером. В подобном случае центр сертификации предоставляет “связку” сертификатов, которую следует присоединить к сертификату сервера. Сертификат сервера следует разместить перед связкой сертификатов в скомбинированном файле:
Полученный файл следует указать в директиве ssl_certificate:
Если сертификат сервера и связка сертификатов были соединены в неправильном порядке, nginx откажется запускаться и выдаст сообщение об ошибке:
поскольку nginx попытается использовать секретный ключ с первым сертификатом из связки вместо сертификата сервера.
В этом примере субъект (“s”) сертификата №0 сервера www.GoDaddy.com подписан издателем (“i”), который в свою очередь является субъектом сертификата №1, подписанного издателем, который в свою очередь является субъектом сертификата №2, подписанного общеизвестным издателем ValiCert, Inc., чей сертификат хранится во встроенной в браузеры базе данных сертификатов (которая в тёмном чулане хранится в доме, который построил Джек).
Если связку сертификатов не добавили, будет показан только сертификат сервера №0.
Единый HTTP/HTTPS сервер
Можно настроить единый сервер, который обслуживает как HTTP-, так и HTTPS-запросы:
До версии 0.7.14 SSL нельзя было включить выборочно для отдельных слущающих сокетов, как показано выше. SSL можно было включить только для всего сервера целиком, с помощью директивы ssl, что не позволяло настроить единый HTTP/HTTPS сервер. Для решения этой задачи был добавлен параметр ssl директивы listen. Поэтому использование директивы ssl в современных версиях не рекомендуется.
Выбор HTTPS-сервера по имени
Типичная проблема возникает при настройке двух и более серверов HTTPS, слушающих на одном и том же IP-адресе:
Наиболее старым и надёжным способом решения этой проблемы является назначение каждому HTTPS-серверу своего IP-адреса:
SSL-сертификат с несколькими именами
Лучше поместить сведения о файле сертификата с несколькими именами и файле с его секретным ключом на уровне конфигурации http, чтобы все серверы унаследовали их единственную копию в памяти:
Указание имени сервера
Более общее решение для работы нескольких HTTPS-серверов на одном IP-адресе — расширение Server Name Indication протокола TLS (SNI, RFC 6066), которое позволяет браузеру передать запрашиваемое имя сервера во время SSL handshake, а значит сервер будет знать, какой сертификат ему следует использовать для соединения. Сейчас SNI поддерживается большинством современных браузеров, однако может не использоваться некоторыми старыми или специализированными клиентами.
В SNI можно передавать только доменные имена, однако некоторые браузеры могут ошибочно передавать IP-адрес сервера в качестве его имени, если в запросе указан IP-адрес. Полагаться на это не следует.
Чтобы использовать SNI в nginx, соответствующая поддержка должна присутствовать как в библиотеке OpenSSL, использованной при сборке бинарного файла nginx, так и в библиотеке, подгружаемой в момент работы. OpenSSL поддерживает SNI начиная с версии 0.9.8f, если она была собрана с опцией конфигурации Начиная с OpenSSL 0.9.8j эта опция включена по умолчанию. Если nginx был собран с поддержкой SNI, то при запуске nginx с ключом “-V” об этом сообщается:
Однако если nginx, собранный с поддержкой SNI, в процессе работы подгружает библиотеку OpenSSL, в которой нет поддержки SNI, nginx выдаёт предупреждение:
Совместимость
Как защитить свой публичный сайт с ESNI
Привет Хабр, меня зовут Илья, я работаю в платформенной команде компании Exness. Мы разрабатываем и внедряем базовые инфраструктурные компоненты, которые используют наши продуктовые команды разработки.
В этой статье я бы хотел поделиться опытом внедрения технологии encrypted SNI (ESNI) в инфраструктуре публичных веб-сайтов.
Использование этой технологии позволит повысить уровень безопасности при работе с публичным веб-сайтом и соответствовать внутренним стандартам безопасности, принятым в Компании.
Прежде всего, хочу обратить внимание, что технология не стандартизована и все еще находится в драфте, однако CloudFlare и Mozilla уже поддерживают ее (в draft01). Это и мотивировало нас на такой эксперимент.
Немного теории
ESNI – это расширение к протоколу TLS 1.3, которое позволяет шифровать SNI в сообщении «Client Hello» TLS handshake. Вот, как выглядит Client Hello с поддержкой ESNI (вместо привычного SNI мы видим ESNI):
Чтобы использовать ESNI, необходимы три составляющие:
Необходимо добавить две DNS записи – A, и TXT (TXT запись содержит публичный ключ, с помощью которого клиент может зашифровать SNI) – см. ниже. Кроме того, должна быть поддержка DoH (DNS over HTTPS), так как доступные клиенты (см. ниже) не активируют поддержку ESNI без DoH. Это логично, так как ESNI подразумевает шифрацию имени ресурса, к которому мы обращаемся, то есть бессмысленно обращаться к DNS по UDP. Более того, использование DNSSEC позволяет защититься от «cache poisoning» атак в этом сценарии.
На текущий момент доступно несколько DoH провайдеров, среди них:
TXT запись, запрос формируется по шаблону _esni.FQDN:
Итак, с точки зрения DNS, мы должны использовать DoH (желательно с DNSSEC) и добавить две записи.
Поддержка со стороны клиента
Если мы говорим о браузерах, то на сегодняшний момент поддержка реализована только в FireFox. Здесь приведена инструкция, как активировать поддержку ESNI и DoH в FireFox. После того, как браузер настроен, мы должны увидеть примерно такую картину:
Ссылка для проверки браузера.
Разумеется, для поддержки ESNI должен быть использован TLS 1.3, так как ESNI – это расширение к TLS 1.3.
Для целей тестирования бэкенда с поддержкой ESNI мы реализовали клиента на go, но об этом чуть позже.
Поддержка со стороны сервера
На текущий момент ESNI не поддерживается web-серверами типа nginx/apache и т.д., так как они работают с TLS посредством OpenSSL/BoringSSL, в которых ESNI официально не поддерживается.
Поэтому мы решили создать свой front-end компонент (ESNI reverse proxy), который бы поддерживал терминацию TLS 1.3 с ESNI и проксирование HTTP(S) траффика на апстрим, не поддерживающий ESNI. Это позволяет применять технологию в уже сложившейся инфраструктуре, без изменения основных компонентов – то есть использовать текущие web-серверы, не поддерживающие ESNI.
Для наглядности приведем схему:
Отмечу, что прокси задумывался с возможностью терминировать TLS соединение без ESNI, для поддержки клиентов без ESNI. Также, протокол общения с апстримом может быть как HTTP, так и HTTPS c версией TLS ниже 1.3 (если апстрим не поддерживает 1.3). Такая схема дает максимальную гибкость.
Реализацию поддержки ESNI на go мы позаимствовали у CloudFlare. Сразу отмечу, что сама реализация достаточно нетривиальная, так как подразумевает изменения в стандартной библиотеке crypto/tls и поэтому требует «патчинга» GOROOT перед сборкой.
Для генерации ESNI ключей мы использовали esnitool (тоже детище CloudFlare). Данные ключи используются для шифрации/дешифрации SNI.
Мы протестировали сборку с использованием go 1.13 на Linux (Debian, Alpine) и MacOS.
Пара слов об эксплуатационных особенностях
ESNI reverse proxy предоставляет метрики в формате Prometheus, например, такие, как rps, upstream latency & response codes, failed/successful TLS handshakes & TLS handshake duration. На первый взгляд это показалось достаточным для оценки того, как прокси справляется с трафиком.
Также перед использованием мы провели нагрузочное тестирование. Результаты ниже:
Нагрузочное тестирование мы проводили чисто качественное, для сравнения схемы с использованием ESNI reverse proxy и без. Мы «наливали» трафик локально для того, чтобы исключить «помехи» в промежуточных компонентах.
Итак, с поддержкой ESNI и проксированием на апстрим с HTTP, мы получили в районе
550 rps с одного инстанса, при этом среднее потребление CPU/RAM ESNI reverse proxy:
Для сравнения, RPS для того же апстрима nginx без терминации TLS (HTTP протокол)
Наличие таймаутов говорит о том, что есть нехватка ресурсов (мы использовали 4 vCPU, 4 GB RAM хосты, Linux), и по факту потенциальный RPS выше (мы получали цифры до 2700 RPS на более мощных ресурсах).
В заключение отмечу, что технология ESNI выглядит достаточно перспективно. Есть еще много открытых вопросов, например, вопросы хранения публичного ESNI ключа в DNS и ротирование ESNI-ключей – эти вопросы активно обсуждаются, а последняя версия драфта (на момент написания) ESNI уже 7.
Распространение стандарта TLS SNI
Своими наблюдениями за процентным содержанием расширения 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 в их число входят:
Переход к использованию исключительно 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. Разработчики клиентского ПО должны понимать это и иметь в виду необходимость корректной реализации данного протокола в своих пакетах.
Стандарт Encrypted SNI реализован в Firefox Nightly
Firefox стал первым браузером, который реализовал шифрование TLS Server Name Indication (SNI). Поддержку ESNI внедрили в последнюю версию Firefox Nightly, на которой обкатывают все нововведения перед их добавлением в основную ветку.
О важности этого стандарта месяц назад рассказывал CDN-провайдер Cloudflare. Если вкратце, то благодаря ESNI шифруется информация о том, к какому домену вы отправляете запрос. В стандартном HTTPS заголовки с именами доменов не шифруются и доступны для просмотра провайдеру или другому «человеку посередине». Теперь он видит только IP-адрес. Поскольку в современном интернете на одном IP-адресе могут располагаться сотни доменов, то ESNI эффективно скрывает информацию, на какой домен заходит пользователь.
Таким образом, блокировки по именам перестают работать, а цензура в интернете сильно усложнится. Цензорам придётся блокировать IP-адреса, а это сомнительная практика. Такая блокировка может затронуть непричастные сайты, а блокируемый сервис легко (автоматически) переключается на другой IP-адрес.
Почему в обычном TLS SNI «светятся» имена хостов? Дело в том, что перед началом шифрования серверу необходимо знать, к какому домену обращается клиент, чтобы предъявить нужный сертификат. По этой причине имя хоста передаётся открытым текстом (ниже иллюстрации из блога Cloudflare).
В зашифрованном SNI (ESNI) эта проблема решена так: клиент берет публичный ключ сервера из DNS и шифрует им все данные до установления TLS сессии.
Поддержка браузером Firefox Nightly означает, что ESNI будет работать с каждым сайтом/провайдером, который его поддерживает.
Разработчики из Mozilla объясняют, что существует четыре основных способа утечки истории посещённых страниц:
В своё время технологию Server Name Indication (SNI) начали использовать именно потому, что на одном IP-адресе располагается несколько хостов. В этом случае поле SNI сообщает серверу, к какому хосту вы пытаетесь подключиться, позволяя ему выбрать правильный сертификат. Другими словами, SNI помогает обеспечить работу крупномасштабного TLS-хостинга. То есть эту функцию вводили ради безопасности, а теперь приходится с ней бороться как с каналом утечки данных.
О проблеме SNI было известно давно, пишут разработчики Mozilla, и было понятно, что это поле нужно зашифровать. Но каждый дизайн, какой они пробовали, включал какой-то компромисс производительности. Был ещё один важный недостаток: сам факт, что конкретный сайт переходит на ESNI, являлся сигналом, что ему «есть, что скрывать», то есть у цензоров появлялась возможность банально фильтровать трафик по ESNI. В конце концов было решено выпустить стандарт TLS 1.3 без ESNI.
Только в начале 2018 года разработчики поняли, что существует довольно хороший вариант: большие сети распространения контента (CDN) хостят много сайтов на одних и тех же физических серверах. Если они согласятся перевести на ESNI сразу всех клиентов, то внезапно ESNI перестаёт быть полезным сигналом для злоумышленника. Таким образом появилась возможность реализовать ESNI в TLS 1.3, путём массовой настройки множества сайтов на имеющемся наборе серверов.
ESNI — совершенно новая технология, и Firefox является первым браузером, который её реализовал. Чтобы активировать её в Firefox Nightly, следует совершить следующие действия:
Это должно автоматически включить ESNI для любого сайта, который его поддерживает. В данный момент из крупных хостеров и CDN это только Cloudflare, но разработчики Firefox надеются, что вскоре подключатся и другие провайдеры. Проверить работу шифрования можно по этой ссылке.
В ближайшие месяцы Mozilla будет проверять, как ESNI взаимодействует с разными типами файрволов и других сетевых устройств. Если вы включили шифрование и что-то сломалось — просьба сообщить разработчикам через баг-трекер.