stringtranslate.com

Индикация имени сервера

Индикация имени сервера ( SNI ) — это расширение протокола компьютерной сети Transport Layer Security (TLS), с помощью которого клиент указывает , к какому имени хоста он пытается подключиться, в начале процесса установления связи. [1] Расширение позволяет серверу предоставлять один из нескольких возможных сертификатов на один и тот же IP-адрес и номер TCP-порта и, следовательно, позволяет обслуживать несколько защищенных ( HTTPS ) веб-сайтов (или любую другую службу через TLS) по одному и тому же IP-адресу без требование, чтобы все эти сайты использовали один и тот же сертификат. Это концептуальный эквивалент виртуального хостинга на основе имен HTTP/1.1 , но для HTTPS. Это также позволяет прокси-серверу перенаправлять клиентский трафик на нужный сервер во время установления связи TLS/SSL. Желаемое имя хоста не зашифровано в исходном расширении SNI, поэтому перехватчик может увидеть, какой сайт запрашивается. Расширение SNI было указано в 2003 году в RFC  3546.

Предыстория проблемы

До SNI при установлении соединения TLS у клиента не было возможности указать, к какому сайту он пытается подключиться. Следовательно, если на одном сервере размещено несколько сайтов на одном прослушивателе, сервер не сможет узнать, какой сертификат использовать в протоколе TLS. Более подробно, при установлении 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 был добавлен в Интернет -RFC IETF в июне 2003 года посредством RFC 3546, Расширения безопасности транспортного уровня (TLS) . Последней версией стандарта является RFC 6066.

Последствия для безопасности

Полезная нагрузка индикации имени сервера не шифруется, поэтому имя хоста сервера, к которому пытается подключиться клиент, видно пассивному перехватчику. Эта слабость протокола использовалась программным обеспечением безопасности для сетевой фильтрации и мониторинга [4] [5] [6] и правительствами для введения цензуры. [7] В настоящее время существует множество технологий, пытающихся скрыть указание имени сервера.

Фронтирование домена

Фронтирование домена — это метод замены желаемого имени хоста в SNI на другое, размещенное на том же сервере или, что чаще, в сети серверов, известной как сеть доставки контента. Когда клиент использует фронтирование домена, он заменяет домен сервера в SNI (незашифрованном), но оставляет его в заголовке хоста HTTP (который зашифрован TLS), чтобы сервер мог обслуживать правильный контент. Фронтинг домена нарушает стандарт, определяющий сам SNI, поэтому его совместимость ограничена (многие службы проверяют, что хост SNI соответствует хосту заголовка HTTP, и отклоняют соединения с SNI, ориентированным на домен, как недействительные). Хотя в прошлом доменное фронтирование использовалось, чтобы избежать государственной цензуры, [8] его популярность снизилась, поскольку крупные поставщики облачных услуг (Google, Amazon AWS и CloudFront) явно запрещают его в своих TOS и имеют против него технические ограничения. [9]

Зашифрованный клиент Привет!

Зашифрованное сообщение Client Hello ( ECH ) — это расширение протокола TLS 1.3 , которое позволяет шифровать все сообщение Client Hello, которое отправляется на ранней стадии согласования TLS 1.3. [10] ECH шифрует полезную нагрузку с помощью открытого ключа, который проверяющая сторона (веб-браузер) должна знать заранее. Это означает, что ECH наиболее эффективен при использовании больших CDN , заранее известных поставщикам браузеров.

Первоначальная версия этого расширения 2018 года называлась Encrypted SNI ( ESNI ) [11] , и ее реализации были развернуты «экспериментальным» способом для устранения риска перехвата домена. [12] [13] [14] В Firefox 85 удалена поддержка ESNI. [15] В отличие от ECH, Encrypted SNI шифрует только SNI, а не весь клиентский Hello. [16] Поддержка этой версии по согласию была включена в Firefox в октябре 2018 года [17] и требовала включения DNS через HTTPS (DoH). [18]

В марте 2020 года ESNI был переработан в расширение ECH после того, как анализ показал, что шифрования только SNI недостаточно. Например, спецификации позволяют расширению Pre-Shared Key содержать любые данные для облегчения возобновления сеанса, даже передачу открытой текстовой копии точно такого же имени сервера, зашифрованной ESNI. Кроме того, для шифрования расширений по одному потребуется зашифрованный вариант каждого расширения, каждое из которых может иметь потенциальные последствия для конфиденциальности, и даже это раскрывает набор рекламируемых расширений. Наконец, реальное развертывание ESNI выявило ограничения совместимости. [19] В марте 2020 года краткое название было ECHO [16] , а в мае 2020 года оно было изменено на ECH. [20]

И ESNI, и ECH совместимы только с TLS 1.3, поскольку они полагаются на KeyShareEntry, который был впервые определен в TLS 1.3. [21] [22] Кроме того, для использования ECH клиент не должен предлагать версии TLS ниже 1.3. [23]

Другой интернет-проект включает параметр для передачи открытых ключей ECH через типы DNS-записей HTTPS и SVCB , что сокращает процесс установления связи. [24] [25]

В августе 2020 года Великий китайский файрвол начал блокировать трафик ESNI, но при этом разрешал трафик ECH. [26]

В октябре 2020 года российский интернет-провайдер «Ростелеком» и его оператор мобильной связи Tele2 начали блокировать ESNI-трафик. [27] В сентябре того же года российское министерство цензуры Роскомнадзор планировало запретить ряд протоколов шифрования, среди которых были TLS 1.3 и ESNI, которые препятствовали цензуре доступа к веб-сайтам. [28] [29] [30]

В июле 2023 года на собрании IETF117 участники, работающие над ECH, сообщили, что Chrome и Firefox проводят выборочное испытание на 1%, и команда ожидает, что окончательный проект будет представлен на оценку IESG к январю 2024 года .

В сентябре 2023 года Cloudflare начала поддерживать ECH для размещенных доменов. [33]

В октябре 2023 года Mozilla по умолчанию включила ECH в Firefox v118 при условии, что DNS over HTTPS (DoH) также включен [34] [35] для защиты DNS- запросов к записи ресурсов HTTPS от подслушивания в компьютерной сети. [36] В сентябре 2023 года Chromium версии 117 (используемый в Google Chrome , Microsoft Edge , Samsung Internet и Opera ) включил его по умолчанию, а также потребовало развертывания ключей в DNS-записях HTTPS. [37] [38]

Выполнение

В 2004 году проект EdelKey создал патч для добавления TLS/SNI в OpenSSL . [39] В 2006 году этот патч был перенесен в ветку разработки OpenSSL, а в 2007 году он был перенесен обратно в OpenSSL 0.9.8 (впервые выпущен в версии 0.9.8f [40] ). Первые веб-браузеры с поддержкой SNI появились в 2006 году (Mozilla Firefox 2.0, Internet Explorer 7), позже — веб-серверы (Apache HTTP Server в 2009 году, Microsoft IIS в 2012 году).

Чтобы прикладная программа реализовала SNI, используемая ею библиотека TLS должна реализовать его, а приложение должно передать имя хоста в библиотеку TLS. Ситуация еще больше усложняется тем, что библиотека TLS может быть либо включена в прикладную программу, либо быть компонентом базовой операционной системы. По этой причине некоторые браузеры реализуют SNI при работе в любой операционной системе, а другие реализуют его только при работе в определенных операционных системах. [ нужна цитата ]

Поддерживать

Рекомендации

  1. ^ Блейк-Уилсон, Саймон; Нистром, Магнус; Хопвуд, Дэвид; Миккельсен, Ян; Райт, Тим (июнь 2003 г.). «Имя сервера ssl_ocsp_responderIndicate». Расширения безопасности транспортного уровня (TLS). IETF . п. 8. сек. 3.1. дои : 10.17487/RFC3546 . ISSN  2070-1721. РФК 3546.
  2. ^ «Что такое SSL-сертификат с несколькими доменами (UCC)?» ГоДэдди .
  3. ^ «Индикация имени TLS-сервера» . Журнал Павла .
  4. ^ «Веб-фильтр: функция расширения SNI и блокировка HTTPS» . www3.trustwave.com . Проверено 20 февраля 2019 г.
  5. ^ «Sophos UTM: понимание веб-фильтрации Sophos» . Софос Сообщество . Проверено 20 февраля 2019 г.
  6. ^ Крисмент, Изабель; Гойшо, Антуан; Шолез, Тибо; Шбаир, Вазен М. (11 мая 2015 г.). «Эффективный обход фильтрации HTTPS на основе SNI». Международный симпозиум IFIP/IEEE 2015 по интегрированному управлению сетями (IM) . стр. 990–995. дои : 10.1109/INM.2015.7140423. ISBN 978-1-4799-8241-7. S2CID  14963313.
  7. ^ «Южная Корея подвергает цензуре Интернет, отслеживая трафик SNI» . Мигающий компьютер . Проверено 18 февраля 2019 г.
  8. ^ «Приложение зашифрованного чата Signal обходит государственную цензуру» . Engadget . Проверено 4 января 2017 г.
  9. ^ «Amazon угрожает заблокировать учетную запись AWS Signal из-за обхода цензуры» . Сигнал . Проверено 2 мая 2018 г.
  10. ^ Рескорла, Эрик; Оку, Кадзухо; Салливан, Ник; Вуд, Кристофер А. (9 октября 2023 г.). Приветствие клиента с шифрованием TLS (отчет). Рабочая группа по интернет-инжинирингу.
  11. ^ Рескорла, Эрик; Оку, Кадзухо; Салливан, Ник; Вуд, Кристофер А. (6 апреля 2023 г.). «Проект-ietf-TLS-esni-14».
  12. ^ «ESNI: обновление до HTTPS для защиты конфиденциальности» . Блог EFF DeepLinks . 24 сентября 2018 г.
  13. ↑ Клэберн, Томас (17 июля 2018 г.). «Не паникуйте по поводу фронтинга домена, исправление SNI взломано». Регистр . Проверено 10 октября 2018 г.
  14. ^ «Зашифруй или потеряй: как работает зашифрованный SNI» . Блог Cloudflare . 24 сентября 2018 года . Проверено 13 мая 2019 г.
  15. ^ «1667743 — Очистите неиспользуемый код esni» . bugzilla.mozilla.org . Проверено 7 апреля 2022 г.
  16. ^ ab "ESNI -> ECHO · tlswg/draft-ietf-tls-esni". Гитхаб .
  17. ↑ Эрик, Рескорла (18 октября 2018 г.). «Зашифрованный SNI появляется в Firefox каждую ночь». Блог о безопасности Mozilla . Проверено 15 июня 2020 г.
  18. ^ Дэниел, Стенберг. «Архив списка рассылки библиотеки Curl». Curl.haxx.se. _ Проверено 15 июня 2020 г.
  19. ↑ Джейкобс, Кевин (7 января 2021 г.). «Зашифрованный клиент Hello: будущее ESNI в Firefox». Блог о безопасности Mozilla . Проверено 9 января 2021 г.
  20. ^ "s/ECHO/ECH · tlswg/draft-ietf-tls-esni" . Гитхаб .
  21. ↑ Гедини, Алессандро (24 сентября 2018 г.). «Зашифруй или потеряй: как работает зашифрованный SNI». Блог Cloudflare . Проверено 11 июля 2021 г. это расширение TLS версии 1.3 и выше, оно не работает с предыдущими версиями протокола.
  22. ^ «Сделать ESNI TLS 1.2 совместимым · Проблема № 38 · tlswg/draft-ietf-tls-esni» . Гитхаб . Проверено 9 августа 2020 г.
  23. ^ Рескорла, Эрик. «Клиент с шифрованием TLS, привет». tlswg.org . Проверено 24 февраля 2021 г. Клиент... ДОЛЖЕН предложить согласовать TLS 1.3 или выше.
  24. ^ Шварц, Бенджамин М.; Бишоп, Майк; Нигрен, Эрик (11 марта 2023 г.). «Привязка службы и спецификация параметров через DNS (DNS SVCB и HTTPS RR)». Рабочая группа по интернет-инжинирингу . Проверено 25 июля 2023 г.
  25. ^ Шварц, Бенджамин М.; Бишоп, Майк; Нигрен, Эрик (26 сентября 2023 г.). «Загрузка зашифрованного TLS ClientHello с привязками службы DNS». Рабочая группа по интернет-инжинирингу . Проверено 1 октября 2023 г.
  26. ^ Чимпану, Каталин. «Китай теперь блокирует весь зашифрованный трафик HTTPS, использующий TLS 1.3 и ESNI». ЗДНет . Проверено 9 августа 2020 г.
  27. ^ "Почему Ростелеком блокирует трафик ЕСНИ?". qna.habr.com (на русском языке). 11 октября 2020 г. Проверено 30 октября 2020 г. .
  28. ^ "Минцифры России хочет запретить новейшие технологии шифрования в Рунете". Медуза . Проверено 18 июня 2021 г.
  29. ^ Чимпану, Каталин. «Россия хочет запретить использование безопасных протоколов, таких как TLS 1.3, DoH, DoT, ESNI». ЗДНет . Проверено 18 июня 2021 г.
  30. ↑ Шерман, Джастин (25 сентября 2020 г.). «Россия пытается что-то новое, чтобы изолировать свой Интернет от остального мира». Журнал «Сланец» . Проверено 18 июня 2021 г.
  31. ^ Рабочая группа TLS (26 июля 2023 г.). «Протокол IETF117: tls: среда, 20:00». Трекер данных IETF . Архивировано из оригинала 2 августа 2023 года . Проверено 2 августа 2023 г.
  32. ^ Рабочая группа TLS (26 июля 2023 г.). IETF117-TLS-20230726-2000. YouTube видео). Сан-Франциско: Рабочая группа по интернет-инжинирингу . Проверено 2 августа 2023 г.
  33. ^ Ахиэль ван дер Манделе; Алессандро Гедини; Кристофер Вуд; Рушил Мехра. «Зашифрованный клиентский привет — последний кусочек головоломки конфиденциальности». Блог Cloudflare . Проверено 1 октября 2023 г.
  34. ^ «Понимание зашифрованного клиента Hello (ECH) | Справка Firefox» . support.mozilla.org . Проверено 4 октября 2023 г.
  35. ^ «Передайте (зашифрованное) привет более приватному Интернету. | Блог Mozilla» . blog.mozilla.org . Проверено 4 октября 2023 г.
  36. ^ «Зашифрованный клиент Hello (ECH) — Часто задаваемые вопросы | Справка Firefox» . support.mozilla.org . Проверено 25 ноября 2023 г.
  37. ^ «Как отключить зашифрованный TLS ClientHello в Google Chrome с помощью PowerShell» . Chaser Systems Ltd., 9 октября 2023 г.
  38. ^ «Функция: зашифрованный TLS клиент Hello (ECH)» . Статус платформы Chrome . Google . 12 декабря 2023 г. Проверено 21 февраля 2024 г.
  39. ^ "Проект ЭдельКей". www.edelweb.fr . Проверено 20 февраля 2019 г.
  40. ^ «ИЗМЕНЕНИЯ OpenSSL» . Архивировано из оригинала 20 апреля 2016 года.
  41. ^ «Публичный хостинг Git — alpine.git/Commit» .
  42. ^ «Как улучшить конфиденциальность в Microsoft Edge, включив Encrypted Client Hello» . Неовин . 25 июля 2023 года. Архивировано из оригинала 5 декабря 2022 года . Проверено 25 июля 2023 г.
  43. ^ ab «Разработка ECH для OpenSSL (DEfO)». defo.ie. _ Толерантные Сети Лимитед. 24 августа 2022 года. Архивировано из оригинала 1 сентября 2022 года.
  44. ^ «Понимание зашифрованного клиента Hello (ECH) | Справка Firefox» . support.mozilla.org . Проверено 4 октября 2023 г.
  45. ^ "curl/docs/ECH.md по адресу cbe7fad20d969626a5c4eb0501a273dfe812bcd3 · завиток/завиток". Гитхаб . Проверено 26 июля 2023 г.
  46. ^ "curl/docs/ROADMAP.md по адресу 50490c0679fcd0e50bb3a8fbf2d9244845652cf0 · завиток/завиток". Гитхаб . Проверено 26 июля 2023 г.
  47. ^ «Функция: зашифрованный TLS клиент Hello (ECH)» . Статус платформы Chrome . Архивировано из оригинала 28 мая 2023 года . Проверено 25 июля 2023 г. Сафари: Нет сигнала
  48. ^ «Примечания к выпуску версии 7.8» . Кампус@Барракуда . Сентябрь 2013 . Проверено 5 января 2021 г.
  49. ^ «Примечания к выпуску версии 5.2» . Кампус@Барракуда . Сентябрь 2015 года . Проверено 5 января 2021 г.
  50. ^ «Ошибка 765064 — HttpClient, используемый Sync и другими службами, не поддерживает SNI». Багзилла@Mozilla . 29 октября 2017 года . Проверено 9 ноября 2017 г.
  51. ^ «Вопросы и ответы по SSL-серверу IBM HTTP» . ИБМ . Проверено 8 марта 2011 г.
  52. ^ «IHS 8 на базе Apache 2.2.x?». ИБМ . 17 октября 2013 года. Архивировано из оригинала 26 декабря 2015 года . Проверено 9 ноября 2017 г.
  53. ^ "# 2275 (Поддержка зашифрованного клиента Hello) - nginx" . trac.nginx.org . Проверено 6 июля 2023 г.
  54. ^ «Улучшения производительности». help.hcltechsw.com . Проверено 6 февраля 2024 г.
  55. ^ «ECH от kazuho · Запрос на извлечение № 3164 · h2o/h2o» . Гитхаб . Проверено 6 июля 2023 г.
  56. ^ «Базовые директивы — Настройка» . H2O — оптимизированный HTTP/2-сервер . Архивировано из оригинала 29 мая 2023 года . Проверено 18 июля 2023 г.
  57. ^ «Обновление черновика-ietf-tls-esni-13» . Репозиторий кода BoringSSL . Проверено 6 июля 2023 г.
  58. ^ «Информация о выпуске Dell BSAFE Micro Edition Suite 5.0» . Проверено 18 октября 2022 г.
  59. ^ «Поддержка ECH (# 595) · Проблемы · gnutls / GnuTLS · GitLab» . ГитЛаб . 27 октября 2018 года . Проверено 26 июля 2023 г.
  60. ^ «Поддержка ESNI · Проблема № 546 · libressl/portable» . Гитхаб . Проверено 26 июля 2023 г.
  61. ^ «116168 — Поддержка расширения указания имени сервера TLS в NSS» . bugzilla.mozilla.org . Проверено 6 июля 2023 г.
  62. ^ «D101050 Ошибка 1681585 — Добавлена ​​поддержка ECH для самообслуживания» . phabricator.services.mozilla.com . Проверено 6 июля 2023 г.
  63. ^ «Ошибка 360421 — Внедрение указания имени сервера TLS для серверов» . Багзилла@Mozilla . 11 ноября 2006 г. Проверено 30 октября 2012 г.
  64. ^ «Поддержка зашифрованного клиента Hello (ранее известного как ESNI) · Проблема № 7482 · openssl/openssl» . Гитхаб . Проверено 6 июля 2023 г.
  65. ^ «[ech] переписать ESNI в проект 15 ECH от kazuho · Запрос на извлечение № 437 · h2o/picotls» . Гитхаб . Проверено 6 июля 2023 г.
  66. ^ «Поддержка зашифрованного ClientHellos (ECH, ранее ESNI) · Проблема № 199 · Rustls/Rustls» . Гитхаб . Проверено 5 февраля 2024 г.
  67. ^ «Зашифрованные сообщения конфигурации приветствия клиента и сериализация по процессору · Запрос на извлечение № 1568 · Rustles/rustls» . Гитхаб . Проверено 5 февраля 2024 г.
  68. ^ «Отсутствует выбор сертификата для серверов · Проблема № 310 · apple/swift-nio-ssl» . Гитхаб . Проверено 26 июля 2023 г.
  69. ^ «Добавляет поддержку TLS v1.3 Encrypted Client Hello (ECH) Draft-ietf-tls… · wolfSSL/wolfssl@6b6ad38» . Гитхаб . Проверено 25 июля 2023 г.
  70. ^ «crypto/tls: реализовать черновик-ietf-tls-esni-13 · cloudflare/go@4c13101». Гитхаб . Проверено 25 июля 2023 г.
  71. ^ "src/tls.c · мастер · Веб-сервер Хьюго Лейсинка / Гайаваты · GitLab» . ГитЛаб . 5 апреля 2023 г. Проверено 26 июля 2023 г.
  72. ^ «Журнал изменений HAProxy 1.5» . Проверено 28 декабря 2020 г.
  73. ^ «Поддержка ECH (зашифрованный клиентский привет) · Проблема № 1924 · haproxy/haproxy» . Гитхаб . Проверено 26 июля 2023 г.
  74. ^ «Что нового в OpenBSD 6.1» . Проверено 13 июня 2021 г.
  75. ^ "src/lib/libtls/tls.c в мастере · openbsd/src". Гитхаб . Проверено 26 июля 2023 г.

Внешние ссылки