Кампанія 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
