China het begin om HTTPS-verbindings wat met TLS 1.3 en ESNI geskep is, te blokkeer

China geïmplementeer sluit alle HTTPS-verbindings wat die TLS 1.3-protokol en die ESNI (Encrypted Server Name Indication) TLS-uitbreiding gebruik, wat enkripsie van data oor die versoekte gasheer verskaf. Blokkering word uitgevoer op transito-roeteerders, beide vir verbindings wat van China na die buitewêreld gevestig is, en van die buitewêreld na China.

Blokkering word gedoen deur pakkies van die kliënt na die bediener te laat val, eerder as die RST-pakkievervanging wat voorheen deur SNI-inhoud-selektiewe blokkering uitgevoer is. Nadat die blokkering van 'n pakkie met ESNI geaktiveer is, word alle netwerkpakkies wat ooreenstem met die kombinasie van bron-IP, bestemmings-IP en bestemmingspoortnommer ook vir 120 tot 180 sekondes geblokkeer. HTTPS-verbindings gebaseer op ouer weergawes van TLS en TLS 1.3 sonder ESNI word soos gewoonlik deurgelaat.

Laat ons onthou dat om werk op een IP-adres van verskeie HTTPS-webwerwe te organiseer, die SNI-uitbreiding ontwikkel is, wat die gasheernaam in duidelike teks oordra in die ClientHello-boodskap wat versend is voordat 'n geënkripteerde kommunikasiekanaal gevestig word. Hierdie kenmerk maak dit aan die internetverskaffer se kant moontlik om HTTPS-verkeer selektief te filter en te ontleed watter werwe die gebruiker oopmaak, wat nie toelaat dat volledige vertroulikheid verkry word wanneer HTTPS gebruik word nie.

Die nuwe TLS-uitbreiding ECH (voorheen ESNI), wat saam met TLS 1.3 gebruik kan word, skakel hierdie tekortkoming uit en skakel die lekkasie van inligting oor die gevraagde webwerf heeltemal uit wanneer HTTPS-verbindings ontleed word. In kombinasie met toegang deur 'n inhoudafleweringsnetwerk, maak die gebruik van ECH/ESNI dit ook moontlik om die IP-adres van die gevraagde hulpbron van die verskaffer weg te steek. Verkeersinspeksiestelsels sal slegs versoeke aan die CDN sien en sal nie blokkering kan toepas sonder TLS-sessie-spoofing nie, in welke geval 'n ooreenstemmende kennisgewing oor sertifikaat-spoofing in die gebruiker se blaaier gewys sal word. DNS bly 'n moontlike lekkanaal, maar die kliënt kan DNS-oor-HTTPS of DNS-oor-TLS gebruik om DNS-toegang deur die kliënt te versteek.

Navorsers het reeds geopenbaar Daar is verskeie oplossings om die Chinese blok aan die kliënt- en bedienerkant te omseil, maar dit kan irrelevant word en moet slegs as 'n tydelike maatreël beskou word. Byvoorbeeld, tans slegs pakkies met die ESNI uitbreiding ID 0xffce (encrypted_server_name), wat gebruik is in vyfde weergawe van die konsepstandaard, maar vir nou pakkies met die huidige identifiseerder 0xff02 (encrypted_client_hello), voorgestel in sewende konsep van die ECH-spesifikasie.

Nog 'n oplossing is om 'n nie-standaard verbinding onderhandeling proses te gebruik, byvoorbeeld, blokkering werk nie as 'n bykomende SYN pakkie met 'n verkeerde volgorde nommer vooruit gestuur word, manipulasies met pakkie fragmentasie vlae, stuur 'n pakkie met beide die FIN en SYN vlae gestel, vervanging van 'n RST-pakkie met 'n verkeerde beheerbedrag of stuur voordat die pakkieverbindingsonderhandeling met die SYN- en ACK-vlae begin. Die beskryfde metodes is reeds geïmplementeer in die vorm van 'n inprop vir die gereedskapstel Genève, ontwikkel om sensuurmetodes te omseil.

Bron: opennet.ru

Voeg 'n opmerking