Inihayag ng Mozilla ang pagsasama ng suporta para sa mga gumagamit ng matatag na sangay ng Firefox para sa mekanismo ng ECH (Encrypted Client Hello), na nagpapatuloy sa pagbuo ng teknolohiya ng ESNI (Encrypted Server Name Indication) at idinisenyo upang i-encrypt ang impormasyon tungkol sa mga parameter ng mga session ng TLS , gaya ng hiniling na domain name. Ang code para sa pagtatrabaho sa ECH ay orihinal na idinagdag sa paglabas ng Firefox 85, ngunit hindi pinagana bilang default. Unti-unting nagsimulang isama ng Chrome ang suporta sa ECH simula sa paglabas ng Chrome 115.
Dahil bukod sa pakikipag-ugnayan sa server Ang hiniling na impormasyon ng domain ay lumalabas sa pamamagitan ng DNS. Para sa ganap na proteksyon, bukod sa ECH, dapat mong gamitin ang DNS over HTTPS o DNS over TLS upang i-encrypt ang trapiko ng DNS. Hindi gagamitin ng Firefox ang ECH nang hindi pinapagana ang DNS over HTTPS sa mga setting. Maaari mong tingnan ang suporta ng ECH sa iyong browser sa pahinang ito.
Ang isa sa mga salik na nagpagana ng suporta sa ECH bilang default sa Firefox ay ang pagsasama ng Cloudflare ng suporta sa ECH sa network ng paghahatid ng nilalaman nito ilang araw na ang nakalipas. Sa praktikal na bahagi, dahil ang data tungkol sa mga hiniling na host kapag gumagamit ng ECH ay nakatago mula sa pagsusuri, ang pag-filter at pag-block ng mga hindi gustong mga site gamit ang Cloudflare CDN ay mangangailangan na ngayon ng pagharang sa buong network ng Cloudflare, pagharang sa lahat ng mga kahilingan mula sa ECH, o pag-aayos ng HTTPS interception gamit ang mga pekeng root certificate. sa sistema ng gumagamit.
Sa una, upang ayusin ang trabaho sa isang IP address ng ilang HTTPS site, ginamit ang TLS extension na SNI, kung saan ang pangalan ng hiniling na host ay ipinahiwatig sa mensahe ng ClientHello na ipinadala bago magtatag ng isang naka-encrypt na channel ng komunikasyon. Ginawang posible ng feature na ito na ipamahagi ang mga kahilingan sa mga virtual host sa isang maagang yugto ng pagpoproseso ng koneksyon, ngunit ginawa rin nitong posible sa panig ng ISP na piliing i-filter ang trapiko ng HTTPS at pag-aralan kung aling mga site ang bubuksan ng user, na hindi nagpapahintulot sa pagkamit ng kumpletong kumpidensyal kapag gumagamit HTTPS.
Upang malutas ang problemang ito at maiwasan ang pagtagas ng impormasyon tungkol sa hiniling na site, iminungkahi ang isang extension ng ESNI na nagpapatupad ng pag-encrypt ng data gamit ang pangalan ng host. Sa panahon ng pagpapatupad ng ESNI, ipinahayag na ang iminungkahing mekanismo ay hindi sumasaklaw sa lahat ng posibleng pinagmumulan ng pagtagas ng data ng host at ang paggamit nito ay hindi sapat upang matiyak ang kumpletong pagiging kumpidensyal ng mga sesyon ng HTTPS. Sa partikular, kapag ipinagpatuloy ang isang dating naitatag na session, ang domain name sa malinaw na text ay patuloy na tinukoy sa mga parameter ng PSK (Pre-Shared Key) TLS extension. Bilang karagdagan, ang mga pagsisikap na ipatupad ang ESNI ay natukoy ang pagiging tugma at pag-scale ng mga isyu na humadlang sa malawakang paggamit ng ESNI.
Isinasaalang-alang ang mga natukoy na pagkukulang ng ESNI, isang bagong unibersal na mekanismo ng ECH ang binuo na nagbibigay-daan sa pag-encrypt ng mga parameter ng anumang mga extension ng TLS. Sa teknikal, ang pangunahing pagkakaiba sa pagitan ng ECH at ESNI ay sa halip na mga indibidwal na field, ang buong mensahe ng ClientHello ay naka-encrypt nang sabay-sabay. Kasama sa ECH ang paghahati sa ClientHello sa dalawang magkahiwalay na mensahe - ang naka-encrypt na mensahe ng ClientHelloInner (SNI Inner) at ang hindi naka-encrypt na pinagbabatayan na mensahe ng ClientHelloOuter (SNI Outer). Ang isang hindi naka-encrypt na SNI Outer ay nagdadala ng hindi privacy na data gaya ng bersyon ng TLS at isang listahan ng mga cipher na ginamit, pati na rin ang isang karaniwang domain name na hindi nag-o-overlap sa aktwal na pangalan ng hiniling na domain. Halimbawa, para sa lahat ng kliyente ng Cloudflare, ang hindi naka-encrypt na SNI Outer ay tumutukoy sa karaniwang host na "cloudflare-ech.com", ngunit ang aktwal na pangalan ng hiniling na host ay ipinadala sa naka-encrypt na SNI Inner at hindi magagamit para sa pagsusuri.
Gumagamit din ang ECH ng ibang pamamaraan ng pamamahagi ng encryption key: ang impormasyon ng public key ay ipinapadala sa mga HTTPSSVC DNS record sa halip na mga TXT record. Ang authenticated end-to-end encryption batay sa mekanismo ng HPKE (Hybrid Public Key Encryption) ay ginagamit upang makuha at i-encrypt ang key. Sinusuportahan din ng ECH ang secure key retransmission mula sa server, na maaaring gamitin sakaling magkaroon ng key rotation. server at upang malutas ang mga isyu sa pagkuha ng mga lumang key mula sa DNS cache.
Pinagmulan: opennet.ru
