Mozilla најави вклучување на поддршка за корисниците на стабилната гранка на Firefox за механизмот ECH (Encrypted Client Hello), кој го продолжува развојот на технологијата ESNI (Encrypted Server Name Indication) и е дизајниран да шифрира информации за параметрите на TLS сесиите , како што е бараното име на домен. Кодот за работа со ECH првично беше додаден во изданието на Firefox 85, но стандардно беше оневозможен. Хром постепено почна да вклучува поддршка за ECH, почнувајќи со објавувањето на Chrome 115.
Бидејќи покрај поврзувањето со сервер Бараните информации за доменот се протекуваат преку DNS. За целосна заштита, покрај ECH, мора да користите DNS преку HTTPS или DNS преку TLS за шифрирање на DNS сообраќајот. Firefox нема да користи ECH без да овозможи DNS преку HTTPS во поставките. Можете да ја проверите поддршката за ECH во вашиот прелистувач на оваа страница.
Еден од факторите што стандардно ја овозможи поддршката за ECH во Firefox беше вклучувањето на поддршката за ECH од Cloudflare во својата мрежа за испорака на содржина пред неколку дена. Од практичната страна, бидејќи податоците за бараните хостови при користење на ECH се скриени од анализата, филтрирањето и блокирањето на несаканите страници со користење на Cloudflare CDN сега ќе бара блокирање на целата мрежа на Cloudflare, блокирање на сите барања од ECH или организирање пресретнување на HTTPS користејќи лажни root сертификати на корисничкиот систем.
Првично, за да се организира работа на една IP адреса на неколку HTTPS-локации, се користеше TLS екстензија SNI, во која името на бараниот домаќин беше означено во пораката ClientHello пренесена пред да се воспостави шифриран канал за комуникација. Оваа функција овозможи да се дистрибуираат барањата низ виртуелните хостови во рана фаза на обработка на конекцијата, но исто така овозможи на страната на интернет провајдерот селективно да се филтрира сообраќајот на HTTPS и да се анализираат кои страници ги отвора корисникот, што не дозволува да се постигне целосна доверливост при користење HTTPS.
За да се реши овој проблем и да се спречи истекување на информации за бараната локација, подоцна беше предложена екстензија ESNI која имплементира шифрирање на податоците со името на домаќинот. За време на имплементацијата на ESNI, беше откриено дека предложениот механизам не ги покрива сите можни извори на истекување на податоци од домаќинот и неговата употреба не е доволна за да се обезбеди целосна доверливост на сесиите на HTTPS. Конкретно, при продолжување на претходно воспоставена сесија, името на доменот во јасен текст продолжи да се одредува меѓу параметрите на наставката PSK (Pre-Shared Key) TLS. Дополнително, напорите за имплементација на 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 исто така користи различна шема за дистрибуција на клучеви за шифрирање: информациите за јавниот клуч се пренесуваат во HTTPSSVC DNS записи, наместо во TXT записи. За добивање и шифрирање на клучот се користи автентицирано шифрирање од крај до крај базирано на механизмот HPKE (хибридно шифрирање со јавен клуч). ECH исто така поддржува безбедно повторно пренесување на клучот од серверот, што може да се користи во случај на ротација на клучот. сервер и да се решат проблемите со преземање на застарени клучеви од DNS кешот.
Извор: opennet.ru
