Индикация имени сервера ( SNI ) - это расширение компьютерного сетевого протокола Transport Layer Security (TLS) , с помощью которого клиент указывает, к какому имени хоста он пытается подключиться, в начале процесса установления связи. [1] Это позволяет серверу предоставлять несколько сертификатов на один и тот же IP-адрес и номер порта TCP и, следовательно, позволяет использовать несколько защищенных ( HTTPS ) веб-сайтов (или любой другой службычерез TLS), чтобы они обслуживались одним и тем же IP-адресом, не требуя, чтобы все эти сайты использовали один и тот же сертификат. Это концептуальный эквивалент виртуального хостинга на основе имен HTTP / 1.1 , но для HTTPS. Это также позволяет прокси-серверу перенаправлять клиентский трафик на нужный сервер во время установления связи TLS / SSL. Желаемое имя хоста не зашифровано в исходном расширении SNI, поэтому перехватчик может видеть, какой сайт запрашивается.
Предыстория проблемы
При создании TLS-соединения клиент запрашивает цифровой сертификат с веб-сервера. После того, как сервер отправляет сертификат, клиент изучает его и сравнивает имя, к которому он пытался подключиться, с именем (именами), включенным в сертификат. В случае совпадения соединение продолжается в обычном режиме. Если совпадение не найдено, пользователь может быть предупрежден о несоответствии, и соединение может быть прервано, поскольку несоответствие может указывать на попытку атаки типа «злоумышленник в середине» . Однако некоторые приложения позволяют пользователю обойти предупреждение, чтобы продолжить соединение, при этом пользователь берет на себя ответственность за доверие к сертификату и, соответственно, к соединению.
Однако может быть сложно - или даже невозможно из-за отсутствия заранее полного списка всех имен - получить единый сертификат, охватывающий все имена, за которые будет отвечать сервер. Серверу, который отвечает за несколько имен хостов, вероятно, потребуется предоставить разные сертификаты для каждого имени (или небольшой группы имен). Можно использовать subjectAltName для хранения нескольких доменов, контролируемых одним человеком [2], в одном сертификате. Такие «сертификаты унифицированных коммуникаций» необходимо перевыпускать каждый раз при изменении списка доменов.
Виртуальный хостинг на основе имен позволяет размещать несколько имен хостов DNS на одном сервере (обычно веб-сервере) на одном IP-адресе. Для этого сервер использует имя хоста, представленное клиентом как часть протокола (для HTTP имя представлено в заголовке хоста ). Однако при использовании HTTPS квитирование TLS происходит до того, как сервер увидит какие-либо заголовки HTTP. Следовательно, сервер не мог использовать информацию в заголовке узла HTTP, чтобы решить, какой сертификат представить, и поэтому только имена, охватываемые одним и тем же сертификатом, могли обслуживаться с одного и того же IP-адреса.
На практике это означало, что сервер HTTPS мог обслуживать только один домен (или небольшую группу доменов) на каждый IP-адрес для безопасного и эффективного просмотра. Назначение отдельного IP-адреса для каждого сайта увеличивает стоимость хостинга, поскольку запросы на IP-адреса должны быть обоснованы в региональном интернет-реестре, а IPv4-адреса теперь исчерпаны . Для IPv6 он увеличивает административные издержки за счет наличия нескольких IP-адресов на одной машине, даже если адресное пространство не исчерпано. В результате многие веб-сайты были фактически лишены возможности использовать безопасную связь.
Технические принципы
SNI решает эту проблему, заставляя клиента отправлять имя виртуального домена как часть сообщения ClientHello согласования TLS . [3] Это позволяет серверу заранее выбрать правильный виртуальный домен и предоставить браузеру сертификат, содержащий правильное имя. Следовательно, с клиентами и серверами, реализующими SNI, сервер с одним IP-адресом может обслуживать группу доменных имен, для которых нецелесообразно получить общий сертификат.
SNI был добавлен в IETF «s Интернет РЛК в июне 2003 года через RFC 3546, Extensions Transport Layer Security (TLS) . Последняя версия стандарта - RFC 6066.
Последствия для безопасности
Полезные данные Server Name Indication не зашифрованы, поэтому имя хоста сервера, к которому пытается подключиться клиент, видно пассивному перехватчику. Эта слабость протокола использовалась программным обеспечением безопасности для фильтрации и мониторинга сети [4] [5] [6] и правительствами для введения цензуры. [7] В настоящее время существует несколько технологий, пытающихся зашифровать указание имени сервера.
Фронтинг домена
Фронтинг домена - это метод замены желаемого имени хоста в SNI на другое имя хоста, размещенное на том же сервере или, что более часто, в сети серверов, известной как сеть доставки контента. Когда клиент использует выход на домен, он заменяет домен сервера в SNI (незашифрованный), но оставляет его в заголовке хоста HTTP (который зашифрован TLS), чтобы сервер мог обслуживать правильный контент. Фронтирование домена нарушает стандарт, определяющий сам SNI, поэтому его совместимость ограничена (многие службы проверяют соответствие хоста SNI хосту заголовка HTTP и отклоняют соединения с SNI с выходом из домена как недействительные). Хотя в прошлом использование доменного фронтинга использовалось во избежание правительственной цензуры [8], его популярность упала, поскольку основные облачные провайдеры (Google, Amazon AWS и CloudFront) явно запрещали его в своих УО и накладывали технические ограничения на него. [9]
Зашифрованный клиент Hello
Зашифрованное приветствие клиента ( ECH ) - это расширение протокола TLS 1.3, которое обеспечивает шифрование всего сообщения приветствия клиента, которое отправляется на ранней стадии согласования TLS 1.3. ECH шифрует полезную нагрузку с помощью открытого ключа, который проверяющая сторона (веб-браузер) должна знать заранее, что означает, что ECH наиболее эффективен с большими CDN, которые заранее известны поставщикам браузеров.
Первоначальная версия этого расширения 2018 года называлась Encrypted SNI ( ESNI ) [10], и ее реализации были развернуты в «экспериментальном» режиме для устранения этого риска перехвата доменов. [11] [12] [13] В отличие от ECH, зашифрованный SNI шифрует только SNI, а не все приветствие клиента. [14] Поддержка этой версии была включена в Firefox в октябре 2018 года [15] и требовала включения DNS-over-HTTPS. [16]
В марте 2020 года ESNI был переработан в расширение ECH после того, как анализ показал, что шифрования только SNI недостаточно. Например, спецификации позволяют расширению Pre-Shared Key содержать любые данные для облегчения возобновления сеанса, даже передачу открытой текстовой копии точно такого же имени сервера, которое зашифровано ESNI. Кроме того, для пошагового шифрования расширений по одному потребуется зашифрованный вариант каждого расширения, каждое из которых имеет потенциальные последствия для конфиденциальности, и даже при этом раскрывается набор рекламируемых расширений. Наконец, реальное развертывание ESNI выявило ограничения взаимодействия. [17] Краткое название было ECHO в марте 2020 года [14] и изменено на ECH в мае 2020 года. [18]
И ESNI, и ECH совместимы только с TLS 1.3, поскольку они полагаются на KeyShareEntry, который был впервые определен в TLS 1.3. [19] Кроме того, для использования ECH клиент не должен предлагать версии TLS ниже 1.3. [20]
В августе 2020 года Великий брандмауэр Китая начал блокировать трафик ESNI, но по-прежнему разрешал трафик ECH. [21]
В октябре 2020 года российский интернет-провайдер Ростелеком и его мобильный оператор Tele2 начали блокировать трафик ESNI. [22]
Выполнение
В 2004 году проектом EdelKey был создан патч для добавления TLS / SNI в OpenSSL . [23] В 2006 году этот патч был затем перенесен в ветвь разработки OpenSSL, а в 2007 году он был перенесен на OpenSSL 0.9.8 (впервые выпущен в 0.9.8f [24] ).
Чтобы прикладная программа реализовывала SNI, библиотека TLS, которую она использует, должна реализовывать его, а приложение должно передавать имя хоста в библиотеку TLS. Еще больше усложняет ситуацию то, что библиотека TLS может быть либо включена в прикладную программу, либо быть компонентом базовой операционной системы. Из-за этого некоторые браузеры реализуют SNI при работе в любой операционной системе, в то время как другие реализуют его только при работе в определенных операционных системах. [ необходима цитата ]
Служба поддержки
Программное обеспечение | Тип | Поддерживается | Заметки | Поддерживается с |
---|---|---|---|---|
Alpine (почтовый клиент) | Почтовый клиент IMAP | да | Начиная с версии 2.22 [26] | 2019-02-18 |
Internet Explorer | веб-браузер | да | Начиная с версии 7 в Vista (не поддерживается в XP) | 2006 г. |
Край | веб-браузер | да | Все версии | |
Mozilla Firefox | веб-браузер | да | Начиная с версии 2.0 | 2006 г. |
cURL | Инструмент и библиотека командной строки | да | Начиная с версии 7.18.1 | 2008 г. |
Сафари | веб-браузер | да | Не поддерживается в Windows XP | |
Гугл Хром | веб-браузер | да | 2010 г. | |
BlackBerry 10 | веб-браузер | да | Поддерживается во всех выпусках BB10 | 2013 |
ОС BlackBerry | ||||
Barracuda WAF | Обратный прокси | да | Поддерживается с версии 7.8 [27] | 2013 |
Barracuda ADC | Балансировщик нагрузки | да | Поддержка внешнего интерфейса, начиная с версии 4.0, и внутреннего интерфейса, начиная с версии 5.2 [28] | Фронтенд 2013 / Бэкэнд 2015 |
Windows Mobile | веб-браузер | Через некоторое время после 6.5 | ||
Браузер Android по умолчанию | веб-браузер | да | Honeycomb (3.x) для планшетов и Ice Cream Sandwich (4.x) для телефонов | 2011 г. |
Firefox для Android | веб-браузер | да | Поддерживается для просмотра. Синхронизация и другие службы поддерживают SNI только с версии 86. [29] | |
wget | Инструмент командной строки | да | Начиная с версии 1.14 | 2012 г. |
Браузер Nokia для Symbian | веб-браузер | Нет | ||
Opera Mobile для Symbian | веб-браузер | Нет | Не поддерживается на Series60 | |
Дилло | веб-браузер | да | Начиная с версии 3.1 | 2016 г. |
IBM HTTP Server | веб сервер | да | Начиная с версии 9.0.0 [30] [31] | |
Apache Tomcat | веб сервер | да | Не поддерживается до 8.5 (бэкпорт с 9) | |
HTTP-сервер Apache | веб сервер | да | Начиная с версии 2.2.12 | 2009 г. |
Microsoft IIS | веб сервер | да | Начиная с версии 8 | 2012 г. |
nginx | веб сервер | да | Начиная с версии 0.5.23 | 2007 г. |
Причал | веб сервер | да | Начиная с версии 9.3.0 | 2015 г. |
HCL Domino | веб сервер | да | Начиная с версии 11.0.1 | 2020 г. |
Qt | Библиотека | да | Начиная с версии 4.8 | 2011 г. |
Сторона сервера Mozilla NSS | Библиотека | Нет | [32] | |
4-е измерение | Библиотека | Нет | Не поддерживается в версии 15.2 или более ранней. | |
Ява | Библиотека | да | Начиная с версии 1.7 | 2011 г. |
ColdFusion / Люси | Библиотека | да | ColdFusion с версии 10, обновление 18, 11, обновление 7, Lucee с версии 4.5.1.019, версия 5.0.0.50 | 2015 г. |
Erlang | Библиотека | да | Начиная с версии r17 | 2013 |
Идти | Библиотека | да | Начиная с версии 1.4 | 2011 г. |
Perl | Библиотека | да | Начиная с Net::SSLeay версии 1.50 и IO::Socket::SSL версии 1.56 | 2012 г. |
PHP | Библиотека | да | Начиная с версии 5.3 | 2014 г. |
Python | Библиотека | да | Поддерживается в 2.x из 2.7.9 и 3.x из 3.2 (in ssl , urllib[2] и httplib модули) | 2011 для Python 3.x и 2014 для Python 2.x |
Рубин | Библиотека | да | Начиная с версии 2.0 (in net/http ) | 2011 г. |
Гайавата | веб сервер | да | Начиная с версии 8.6 | 2012 г. |
lighttpd | веб сервер | да | Начиная с версии 1.4.24 | 2009 г. |
HAProxy | Балансировщик нагрузки | да | Начиная с версии 1.5-dev12 [33] | 2012 г. |
Рекомендации
- ^ Блейк-Уилсон, Саймон; Нистром, Магнус; Хопвуд, Дэвид; Миккельсен, Ян; Райт, Тим (июнь 2003 г.). «Указание имени сервера» . Расширения безопасности транспортного уровня (TLS) . IETF . п. 8. сек. 3.1. DOI : 10,17487 / RFC3546 . ISSN 2070-1721 . RFC 3546 .
- ^ "Что такое сертификат SSL для нескольких доменов (UCC)?" . GoDaddy .
- ^ «Указание имени сервера TLS» . Журнал Павла .
- ^ «Веб-фильтр: функция расширения SNI и блокировка HTTPS» . www3.trustwave.com . Проверено 20 февраля 2019 .
- ^ «Sophos UTM: понимание веб-фильтрации Sophos» . Сообщество Sophos . Проверено 20 февраля 2019 .
- ^ Крисмент, Изабель; Гойшо, Антуан; Холез, Тибо; Шбаир, Вазен М. (11 мая 2015 г.). «Эффективный обход фильтрации HTTPS на основе SNI» . 2015 Международный симпозиум IFIP / IEEE по интегрированному управлению сетью (IM) . С. 990–995. DOI : 10.1109 / INM.2015.7140423 . ISBN 978-1-4799-8241-7. S2CID 14963313 .
- ^ «Южная Корея вводит цензуру в Интернете, отслеживая трафик SNI» . BleepingComputer . Проверено 18 февраля 2019 .
- ^ «Зашифрованное приложение для чата Signal обходит государственную цензуру» . Engadget . Проверено 4 января 2017 года .
- ^ «Amazon угрожает заблокировать аккаунт AWS Signal из-за обхода цензуры» . Сигнал . Проверено 2 мая 2018 .
- ^ https://tools.ietf.org/html/draft-ietf-tls-esni
- ^ «ESNI: переход на HTTPS с защитой конфиденциальности» . Блог EFF DeepLinks .
- ^ Клэберн, Томас (17 июля 2018 г.). «Не паникуйте по поводу фронтинга домена, исправление SNI взламывают» . Регистр . Проверено 10 октября 2018 года .
- ^ «Зашифруй или потеряй: как работает зашифрованный SNI» . Блог Cloudflare . 24 сентября 2018 . Дата обращения 13 мая 2019 .
- ^ а б «ESNI -> ECHO · tlswg / draft-ietf-tls-esni» .
- ^ Эрик, Рескорла. «Зашифрованный SNI приходит в Firefox Nightly» . Блог по безопасности Mozilla . Проверено 15 июня 2020 .
- ^ Даниэль, Стенберг. "архив списка рассылки curl-библиотеки" . curl.haxx.se . Проверено 15 июня 2020 .
- ^ Джейкобс, Кевин. «Зашифрованный клиент Hello: будущее ESNI в Firefox» . Блог по безопасности Mozilla . Проверено 9 января 2021 года .
- ^ "s / ECHO / ECH · tlswg / draft-ietf-tls-esni" .
- ^ «Сделайте ESNI TLS 1.2 совместимым. · Проблема №38 · tlswg / draft-ietf-tls-esni» . GitHub . Дата обращения 9 августа 2020 .
- ^ Рескорла, Эрик. «Привет, зашифрованный клиент TLS» . tlswg.org . Проверено 24 февраля 2021 года .
Клиент ... ДОЛЖЕН предложить согласовать TLS 1.3 или выше.
- ^ Чимпану, Каталин. «Китай сейчас блокирует весь зашифрованный HTTPS-трафик, использующий TLS 1.3 и ESNI» . ZDNet . Дата обращения 9 августа 2020 .
- ^ «Почему Ростелеком блокирует ESNI трафик?» . qna.habr.com (на русском языке). 11 октября 2020 . Проверено 30 октября 2020 .
- ^ «Проект ЭдельКей» . www.edelweb.fr . Проверено 20 февраля 2019 .
- ^ "OpenSSL ИЗМЕНЕНИЯ" . Архивировано из оригинального 20 апреля 2016 года.
- ^ "CAcert VHostTaskForce" . CAcert Wiki . Архивировано из оригинального 22 августа 2009 года . Проверено 27 октября 2008 года .
- ^ https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500
- ^ «Примечания к выпуску версии 7.8» . Кампус @ Barracuda . Сентябрь 2013 . Проверено 5 января 2021 года .
- ^ «Примечания к выпуску версии 5.2» . Кампус @ Barracuda . Сентябрь 2015 . Проверено 5 января 2021 года .
- ^ «Ошибка 765064 - HttpClient, используемый Sync и другими службами, не поддерживает SNI» . Bugzilla @ Mozilla . 29 октября 2017 . Проверено 9 ноября 2017 года .
- ^ «Вопросы и ответы IBM HTTP Server SSL» . IBM . Проверено 8 марта 2011 года .
- ^ "IHS 8 на базе Apache 2.2.x?" . IBM . 17 октября 2013. Архивировано из оригинала 26 декабря 2015 года . Проверено 9 ноября 2017 года .
- ^ «Ошибка 360421 - Реализация указания имени сервера TLS для серверов» . Bugzilla @ Mozilla . 11 ноября 2006 . Проверено 30 октября 2012 года .
- ^ «Журнал изменений HAProxy 1.5» . Проверено 28 декабря 2020 .
Внешние ссылки
- RFC 6066 (устарел RFC 4366, который устарел RFC 3546)