Android 17 и Encrypted Client Hello: имя сайта уходит из открытой части TLS
27 августа 2026 года в блоге Google вышел анонс «4 new ways Android is protecting your network connections» за подписью инженера Брама Бонне и продакт-менеджера Шуайбо Хуанга. Первым из четырёх пунктов идёт поддержка Encrypted Client Hello — механизма, который убирает имя посещаемого сайта из открытой части TLS-рукопожатия. Ниже — что это меняет по существу и почему из документации самой Google следует, что на практике эффект наступит позже анонса.
Какую щель закрывает ECH
HTTPS шифрует содержимое соединения, но не всё, что уходит в сеть при его установке. В самом начале TLS-рукопожатия клиент отправляет сообщение ClientHello, а в нём — поле Server Name Indication с именем запрашиваемого домена. Поле нужно серверу, чтобы понять, какой из размещённых на одном адресе сайтов вы просите, и до сих пор оно передавалось открытым текстом. То есть содержимое страницы посторонний прочитать не мог, а список посещённых доменов — вполне.
В анонсе Google описывает риск так: незашифрованные имена доменов «видны сетевым операторам и тем, кто прослушивает канал», и эти данные могут использоваться для построения профилей пользователей, а в руках злоумышленника — для адресного фишинга. Encrypted Client Hello шифрует само сообщение ClientHello, закрывая и это поле.
Техническая документация Google формулирует предмет узко и точно: «ECH — это расширение TLS, которое шифрует поле Server Name Indication в сообщении рукопожатия клиента», и оно «помогает сохранить трафик пользователя приватным, не давая сетевым посредникам видеть имена хостов, к которым подключается приложение». Речь именно об именах хостов. IP-адрес сервера, к которому идёт соединение, ECH не скрывает и скрыть на уровне TLS не может — это отдельный слой.
Что именно включено в Android 17
По документации, в Android 17 (уровень API 37) и выше ECH поддерживается по умолчанию. Настройка живёт в Network Security Config через элемент domainEncryption, а библиотеки могут спросить у системы текущий режим через NetworkSecurityPolicy.getDomainEncryptionMode. Режимов четыре, и два из них — ENABLED и OPPORTUNISTIC — предписывают запросить конфигурацию и использовать ECH, если сервер его поддерживает. Отдельной пометкой указано, что режим OPPORTUNISTIC объявлен устаревшим начиная с Android 17.1 (уровень API 37.1).
Если сервер ECH не поддерживает, включается ECH GREASE — отправка расширения со случайным содержимым. Это не защита имени: в такой ситуации домен остаётся видимым. Смысл GREASE в другом — чтобы соединения с настоящим ECH не выделялись на общем фоне по одному факту наличия расширения. Механизм, по документации, обрабатывается платформенной реализацией SSL автоматически, если библиотека пользуется стандартным SSLSocketFactory.
Остальные три пункта анонса к именам сайтов отношения не имеют, но перечислим их: обязательное разрешение на сканирование устройств домашней сети, Certificate Transparency по умолчанию и возможность оператора связи отключать 2G для своих абонентов без действий пользователя. Последнее Google объясняет борьбой с поддельными базовыми станциями: в анонсе названа стоимость такого устройства — от 3 000 долларов, и приведены примеры с автомобильными установками в центре Торонто и переносными «чемоданами» в лондонском метро.
Два условия, из-за которых эффект не мгновенный
Первое условие — сетевые библиотеки. В анонсе разработчикам предлагается «обновиться до OkHttp 5.5.0 и включить ECH». Но техническая страница Google в разделе для разработчиков приложений говорит иначе: «Поддержка скоро появится в OkHttp и HttpEngine». Это расхождение внутри материалов самой компании, и оно существенно: платформенная поддержка включена по умолчанию, а приложение получит эффект только тогда, когда его сетевая библиотека этой поддержкой воспользуется. Пересказы анонса обычно перечисляют OkHttp, WebView и HttpEngine как уже готовые — документация так не утверждает.
Второе условие — DNS. Чтобы начать ECH, клиенту нужна конфигурация EchConfigList, а она лежит не в TLS, а в DNS: в записи типа HTTPS для этого домена. Документация описывает два способа её получить — через DnsResolver.query с типом TYPE_HTTPS либо параллельным сырым запросом rawQuery. Отсюда практический вывод, который стоит держать в голове: ECH опирается на исправно работающий DNS-ответ. Где ответы DNS подменяются или не доходят, конфигурацию взять неоткуда, и соединение уходит без ECH — то есть с открытым именем домена, как раньше.
Наконец, требуется поддержка на стороне сервера. ECH — двусторонний механизм: если сайт не опубликовал ECH-конфигурацию в своей HTTPS-записи, шифровать имя нечем.
Как к этому относиться
Google называет запуск ориентиром для отрасли: по формулировке анонса, Android 17 «создаёт прецедент как первая крупная мобильная ОС с широкой поддержкой ECH». Отдельно упомянуто партнёрство с подразделением Jigsaw, которое опубликовало собственный разбор в своём блоге; его содержимое мы здесь не пересказываем, поскольку открыть первоисточник нам не удалось, а приводить чужие цифры без проверки не станем.
Важно и то, чего в анонсе нет. Россия, отечественные операторы и системы фильтрации в тексте Google не упоминаются ни разу — компания говорит о сетевых операторах вообще и о профилировании пользователей. Соотносить механизм с конкретными национальными практиками фильтрации — уже интерпретация, а не утверждение источника, и мы её здесь не делаем.
Что остаётся по факту: имя сайта перестаёт быть бесплатно доступным всякому, кто наблюдает канал, — при выполнении трёх условий сразу (Android 17, библиотека с поддержкой ECH, сервер с опубликованной конфигурацией). Это заметное улучшение приватности и не замена туннелю: адрес назначения на сетевом уровне по-прежнему виден.
Источник: Блог Google: 4 new ways Android is protecting your network connections, 27.08.2026