China is begonnen met het blokkeren van HTTPS-verbindingen die zijn opgezet met TLS 1.3 en ESNI.

China geïmplementeerd blokkering van alle HTTPS-verbindingen die gebruikmaken van het TLS 1.3-protocol en de TLS-extensie ESNI (Encrypted Server Name Indication), die zorgt voor versleuteling van gegevens over de opgevraagde host. De blokkering vindt plaats op transitrouters voor zowel verbindingen die vanuit China naar de buitenwereld worden opgezet als vanuit de buitenwereld naar China.

Voor de blokkering worden pakketten van de klant naar de server weggegooid, en niet pakketten met de RST-vlag geïnjecteerd, zoals eerder gebeurde bij selectieve blokkering op basis van SNI-inhoud. Na activatie van de blokkering van een ESNI-pakket worden binnen 120 tot 180 seconden ook alle netwerkpakketten geblokkeerd die overeenkomen met de combinatie van het bron-IP, doellip en het doelpoortnummer. HTTPS-verbindingen op basis van oudere TLS-versies en TLS 1.3 zonder ESNI worden zoals gewoonlijk doorgelaten.

Laten we herinneren dat voor het functioneren van meerdere HTTPS-sites op één IP-adres de SNI-extensie is ontwikkeld, die de naam van de host in platte tekst in het ClientHello-bericht verzendt, voordat er een versleuteld communicatiekanaal wordt opgezet. Deze functie stelt de internetprovider in staat om selectief HTTPS-verkeer te filteren en te analyseren welke sites de gebruiker bezoekt, wat volledige privacy tijdens het gebruik van HTTPS belemmert.

De nieuwe TLS-extensie ECH (voorheen ESNI), die samen met TLS 1.3 kan worden gebruikt, verhelpt dit probleem en sluit volledig de mogelijkheid uit om informatie over de opgevraagde site te lekken bij het analyseren van HTTPS-verbindingen. In combinatie met het gebruik van een content delivery network, maakt de toepassing van ECH/ESNI het ook mogelijk om het IP-adres van de opgevraagde bron voor de provider te verbergen. Verkeersinspectiesystemen zullen alleen verzoeken aan de CDN zien en kunnen geen blokkering toepassen zonder het TLS-sessie te vervangen, waarvan in de browser van de gebruiker een bijbehorende melding over het vervangen van het certificaat zichtbaar zal zijn. Een mogelijke lekkanalen blijven DNS, maar om verzoeken aan DNS door de client te verbergen kan DNS-over-HTTPS of DNS-over-TLS worden gebruikt.

Onderzoekers hebben al hebben aangetoond Er zijn enkele alternatieve methoden om de Chinese blokkade aan zowel de cliënt- als de serverzijde te omzeilen, maar deze kunnen hun relevantie verliezen en moeten slechts als een tijdelijke oplossing worden beschouwd. Bijvoorbeeld, op dit moment worden alleen pakketten met de extensie-ID ESNI 0xffce (encrypted_server_name) geblokkeerd, die is gebruikt in de vijfde versie van de standaardontwerp, maar pakketten met de actuele ID 0xff02 (encrypted_client_hello), voorgesteld in de zevende ontwerp specificatie ECH, worden nog steeds doorgelaten..

Een andere manier om te omzeilen is het gebruik van een niet-standaard verbindingsonderhandelingsproces. Bijvoorbeeld, de blokkade wordt niet geactiveerd bij het vooraf verzenden van een extra SYN-pakket met een onjuiste volgnummer, manipulaties met fragmentflaggen, het verzenden van een pakket met zowel FIN- als SYN-vlaggen ingesteld, het invoegen van een RST-pakket met een onjuiste checksum, of het verzenden van een pakket met SYN- en ACK-vlaggen voorafgaand aan de verbinding onderhandelingen. De beschreven methoden zijn al geïmplementeerd in de vorm van een plugin voor de toolkit Genève, wordt ontwikkeld om censuurmethoden te omzeilen.

Bron: opennet.ru

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers 🔥 Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster