Стандарт 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 объясняют, что существует четыре основных способа утечки истории посещённых страниц:

    1. сообщение сертификата TLS,
    2. разрешение имен DNS,
    3. IP-адрес сервера,
    4. TLS Server Name Indication.

    К настоящему времени они добились хорошего прогресса в закрытии первых двух каналов утечки: новый стандарт TLS 1.3 шифрует сертификат сервера по умолчанию (канал 1), а в течение последних нескольких месяцев Mozilla изучает использование DNS по HTTPS для защиты трафика DNS (канал 2). Результаты тестирования неплохие, и в ближайшие месяцы функцию выкатят для всех пользователей Firefox. IP-адрес остаётся проблемой, но во многих случаях несколько сайтов совместно используют тот же IP-адрес, так что главным каналом утечки является SNI.

    В своё время технологию 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, следует совершить следующие действия:

    1. Убедиться, что у вас есть включен DNS по HTTPS (DoH):
      • about:config
      • установить network.trr.mode в значение 2

      • выставить network.trr.uri на сервер DoH (например, https://mozilla.cloudflare-dns.com/dns-query).

      • about:config
      • установить network.security.esni.enabled в значение true


    Это должно автоматически включить ESNI для любого сайта, который его поддерживает. В данный момент из крупных хостеров и CDN это только Cloudflare, но разработчики Firefox надеются, что вскоре подключатся и другие провайдеры. Проверить работу шифрования можно по этой ссылке.



    В ближайшие месяцы Mozilla будет проверять, как ESNI взаимодействует с разными типами файрволов и других сетевых устройств. Если вы включили шифрование и что-то сломалось — просьба сообщить разработчикам через баг-трекер.



    GlobalSign
    156,69
    Компания
    Поделиться публикацией

    Комментарии 34

      +1
      Что помешает подменять публичный ключ на известный тебе при запросе его из DNS? Насколько я помню, доля зон с DNSSEC довольно мала
        0
        Прямо в статье же:
        Убедиться, что у вас есть включен DNS по HTTPS (DoH):
          0
          По аналогии с SNI, предположу, что ESNI — это расширение TLS и тогда он к DoH напрямую не относиться и это два параллельно развивающихся концепта. Хорошо что вопрос пользовательской криптографии развивается, но пока это лишь концепты. И обрести жизнь может любой из них и ни один из них.

          Кстати, насколько DoH медленее чем обычный через UDP? Я бегло поискал, но не нашел
            0
            Я использую DoH на OpenWRT — разницы незаметно. Гораздо сильнее проявляется разница между обычным DNS-резолвером и резолвером, валидирующим DNSSEC. Ещё лучше скрадываются задержки TCP если использовать несколько разных DoH-резолверов и dnsmasq, отправляющий запросы сразу во все и принимающий наиболее быстрый ответ.
        +1

        … Ну и главные каналы утечки информации — сами сайты. Скрипты, кросс-доменные запросы и прочие радости.

          0

          Это противодействие блокированию и слежению со стороны провайдера. А остальное на совести админа сайта.

            0

            Да нет совести ни у кого. Как минимум, реклама есть у всех — вот ваш персональный трекер.

              0

              С этим можно бороться плагинами блокировщиками.

          +4
          Цензорам придётся блокировать IP-адреса, а это сомнительная практика

          В России, к сожалению, это мало кого останавливает. Заблокировать пару-другую миллионов IP? Пфф, да не вопрос.

          Мне интересно, когда поддержка ESNI появится в веб-серверах?

          ЗЫ: Mozilla — мои герои.
            0
            Мне интересно, когда поддержка ESNI появится в веб-серверах?
            Разработчики nginx говорят, что поддержка появится тогда, когда она появится в OpenSSL и\или BoringSSL. Для BoringSSL, судя по всему, уже есть приватные патчи.
              0
              Как разработчик одного SNI-capable HTTP сервера ответственно заявляю, что поддержка со стороны криптографической библиотеки не обязательна — выбор сертификата и обработка SNI идентификатора производится самим сервером.
            0
            А сколько времени сервер будет определять, ключом от какого домена зашифровано имя домена?
              0

              Читайте внимательнее, имя домена не шифруется ключами от доменов.


              Хотя вообще это самое очевидное решение, непонятно почему оно не было сразу реализовано как опция для защиты SNI там где это применимо.

              –2
              каким ключом шифруется имя хоста?
              если ключ всегда один и тот же, то это ничем не отличается от открытого имени
                +3

                Из факта использования одного ключа не следует неизменность шифротекста.

                  0
                  публичным ключом, пришедшим от dns-сервера. Если у тебя есть домен foo.com, делаешь, условно, text-запись с публичным ключом. Браузер при попытке входа на foo.com берёт ip и публичный ключ, которым шифрует домен. И шлёт запрос по ip. Сервер имеет приватный ключ (админ сам создаёт пару, публичную часть которой кладёт в dns), поэтому может расшифровать запрашиваемый домен.
                  Там правда должна быть пачка тонкостей, когда один домен живёт на целой пачке ip-адресов, но было бы логично иметь по публичному ключу на ip-адрес.
                    0
                    публичный ключ меняется раз в год, или когда там истекает срок,
                    так вот если домен, который не меняется, и ключ который не меняется в течении срока жизни ключа будут давать одну и туже комбинацию в зашифрованном виде.

                    чем список доменных имен отличается от списка доменных имен в зашифрованном виде, если они не меняются во времени?
                      0

                      Публичный ключь шифрует временный ключь. Временный ключь шифрует SNI. Благодаря временному ключу запросы на один и тот же домен будут разными.

                    0
                    В оригинальной статье blog.cloudflare.com/encrypt-that-sni-firefox-edition есть скриншот wireshark image
                    Хорошо видно, что шифруется имя сервера с помощью AES, и наверняка с рандомным ключем.
                    Т.ч. каждый запрос на один сервер будет разным.
                    0
                    Все это чудесно. Но как, в этом случае, резать доступ в корпоративной среде к внешним сайтам с поддержкой ESNI?
                      0

                      Видимо только непосредственно на ПК пользователя.

                        0
                        В корпоративной среде — можно тупо по ip.
                        Ситуация, когда очень нужный сервис настолько невелик, что на его ip висят ещё 10 сервисов, доступ к которым дать нельзя, видится крайне маловероятной.
                          +1

                          Напомню что в новости упоминается CDN Cloudflare.

                          0

                          В идеале никак, ибо это явный случай нарушения приватности, против которого и идёт борьба.

                            0
                            MITM в ssl
                            0
                            Это хорошая новость. Сейчас блокировки РКН, кроме IP адреса, делаются такими способами:

                            — перехват DNS-запросов — DoH решает проблему
                            — провайдерский DNS-сервер блокирует запр. сайты
                            — чтение SNI в SSL трафике и блокировка по нему — ESNI решает проблему

                            Таким образом, если DoH и ESNI будут включены по умолчанию, для обхода блокировки по домену достаточно будет поменять DNS с провайдерского на 8.8.8.8, 1.1.1.1 или еще что-нибудь за пределами российской юрисдикции. В устройствах на Андроид часто встроен 8.8.8.8 по умолчанию.

                            Останутся только блокировки по IP. Их можно обходить, меняя IP адреса быстрее, чем провайдеры их блокируют (это не так дорого стоит). При этом каждому запрещенному сайту не обязательно покупать свои адреса — можно сделать единый «центр» обхода блокировок, предоставляющий меняющиеся IP адреса. Причем узлы с временными IP для обхода блокировки не обязаны быть мощными — это делается на уровне iptables и тут хватит машинки с 256 Мб памяти или даже меньше.

                            То есть фактически механизм блокировок перестанет работать «из коробки», без установки сомнительных опасных сторонних плагинов или программ, платных сервисов.

                            Будет интересно посмотреть, как продолжится битва. Я вижу такие варианты:

                            — РКН каждые 5 минут резолвит домен запрещенного сайта, провайдеры в срочном порядке вносят его в бан-лист. Это можно решить тем, что заблокированный сайт будет периодически отдавать IP адреса сбербанка, пенсионного фонда, госсайтов, вконтакте, mail.ru, создавая тем самым негативное воздействие на власть
                            — создается пограничный фаерволл, полностью отсекающий заграничный трафик — это будет самый веселый вариант, в ответ на это придется создавать внутрироссийский Tor и сидеть в нем. После введения наказания за Tor (им ведь пользуются террористы и наркоманы) и несколько показательных дел, энтузиасты прекращают его поддерживать.
                            — создается пограничный фаерволл, делающий MITM всему SSL трафику с блокировкой других видов шифрованного трафика. Для получения доступа к заграничным сайтам необходимо установить госсертификат (издевательская версия: госсертификат выдается на Почте России после заполнения и обработки заявки с указанием цели получения). Обходится вторым слоем шифрования внутри SSL. Минус — не работает из коробки и потому не будет использоваться людьми.
                            — создается пограничный фаерволл в рамках БРИКС — ерунда, братья-китайцы за деньги дадут нам китайские IP для обхода блокировки.
                            — создается дорогой умный пограничный фаерволл, анализирующий паттерны в трафике и блокирующий только немассовые протоколы вроде SSH, VPN, DoH. Нанимается большое число операторов и анализаторов трафика. Ютубчик работает, обход блокировок — нет.
                            — блокируется DoH или DNS-сервера с поддержкой DoH. Интересный вариант.
                              +1
                              При этом каждому запрещенному сайту не обязательно покупать свои адреса — можно сделать единый «центр» обхода блокировок, предоставляющий меняющиеся IP адреса.

                              Если вспомнить, что РКН не поперхнувшись блокировал IP сразу подсетками вплоть до /10, то не всё так радужно на самом деле.
                              0
                              Не сработало на 68.0.1 (64-bit) Ubuntu (не Nightly). Видимо, спустя почти год не пошло в стандартный дистрибутив.
                                0

                                Уже давно работает на обычном FF

                                  0

                                  Действительно работает. Но только если включить DNS через HTTPS. Ну и на сайтах которые его поддерживают. Я кроме cloudflare.com таких не знаю.

                                0
                                Как я понял, в настройках Firefox присутствуют две разные процедуры: включение DoH и включение ESNI. Но могут ли эти технологии работать самостоятельно, отдельно друг от друга? Серверу недостаточно иметь поддержку TLS 1.3, нужно еще дополнительно устанавливать примочку в виде ESNI.
                                Кстати говоря, сами криптографическте DNS-сервера тоже можно заблокировать.
                                  0
                                  Очень извиняюсь, но хотелось бы уточнить один момент: только у меня в 63 лисе нет в about:config параметра network.security.esni.enabled?

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое