Компанія Mozilla оголосила про включення для користувачів стабільної гілки Firefox підтримки механізму ECH (Encrypted Client Hello), що продовжує розвиток технології ESNI (Encrypted Server Name Indication) та призначеного для шифрування інформації про параметри TLS-сеансів, таких як запитане доменне ім'я. Спочатку код для роботи з ECH був доданий у випуск Firefox 85, але був вимкнений за замовчуванням. У Chrome підтримку ECH почали поступово вмикати, починаючи з випуску Chrome 115.
Оскільки крім з'єднання з сервером витік відомостей про запитані домени відбувається через DNS, для повноцінного захисту крім ECH необхідно застосування технології DNS over HTTPS або DNS over TLS для шифрування DNS-трафіку. Firefox не буде використовувати ECH без увімкнення DNS over HTTPS у налаштуваннях. Перевірити підтримку ECH у браузері можна на цій сторінці.
Одним із факторів активації за промовчанням підтримки ECH у Firefox стало включення кілька днів тому компанією Cloudflare підтримки ECH у своїй мережі доставки контенту. З практичного боку, оскільки дані про запитаних хостів при застосуванні ECH приховані від аналізу, для фільтрації та блокування неугодних сайтів, що використовують CDN Cloudflare, тепер буде потрібно блокування всієї мережі Cloudflare, блокування всіх запитів з ECH або організація перехоплення HTTPS за допомогою підставних кореневих сертифікатів системі користувача.
Спочатку для організації роботи на одній IP-адресі декількох сайтів HTTPS застосовувалося TLS-розширення SNI, при якому ім'я запитаного хоста вказувалося в повідомленні ClientHello, що передається до установки шифрованого каналу зв'язку. Подібна особливість давала можливість на ранньому етапі обробки з'єднання розподіляти запити по віртуальним хостам, але також дозволяла на стороні інтернет-провайдера вибірково фільтрувати HTTPS-трафік та аналізувати які сайти відкриває користувач, що не дозволяло досягти повної конфіденційності при застосуванні HTTPS.
Для вирішення цієї проблеми та виключення витоку відомостей про запитуваний сайт пізніше було запропоновано розширення ESNI, що реалізує шифрування даних з ім'ям хоста. У процесі впровадження ESNI було виявлено, що запропонований механізм не охоплює всі можливі джерела витоку даних про хост та його застосування недостатньо для забезпечення повної конфіденційності HTTPS-сеансів. Зокрема, при поновленні раніше встановленого сеансу ім'я домену у відкритому вигляді продовжувало вказуватися серед параметрів TLS-розширення PSK (Pre-Shared Key). Крім того, спроби впровадження ESNI виявили проблеми із сумісністю та масштабуванням, які заважали поширенню ESNI.
З урахуванням виявлених недоліків ESNI було розроблено новий універсальний механізм ECH, що дозволяє шифрування параметрів будь-яких TLS-розширень. Технічно головна відмінність ECH від ESNI у тому, що замість окремих полів шифрується одразу все повідомлення ClientHello. ECH має на увазі поділ ClientHello на два окремі повідомлення - шифроване повідомлення ClientHelloInner (SNI Inner) і незашифроване базове повідомлення ClientHelloOuter (SNI Outer). У незашифрованому SNI Outer передаються дані, які не стосуються конфіденційності, такі як версія TLS і список використовуваних шифрів, а також загальне ім'я домену, яке не перетинається з фактичним ім'ям запитаного домену. Наприклад, для всіх клієнтів Cloudflare у незашифрованому SNI Outer вказується загальний хост «cloudflare-ech.com», а фактичне ім'я запитаного хоста передається в зашифрованому SNI Inner і не доступне для аналізу.
ECH також використовує іншу схему розповсюдження ключа для шифрування - інформація про відкритий ключ передається в DNS запису HTTPSSVC, а не запису з типом TXT. Для отримання та шифрування ключа застосовується аутентифіковане наскрізне шифрування на основі механізму HPKE (Hybrid Public Key Encryption). ECH також підтримує безпечну повторну передачу ключа із сервера, що може застосовуватись у разі ротації ключів на сервері та для вирішення проблем при отриманні застарілих ключів із кешу DNS.
Джерело: opennet.ru
