Kina af alle HTTPS-forbindelser, der bruger TLS 1.3-protokollen og TLS-udvidelsen ESNI (Encrypted Server Name Indication), som sikrer kryptering af data om den anmodede vært. Blokeringen udføres på transitroutere både for forbindelser, der etableres fra Kina til omverdenen, og fra omverdenen til Kina.
For blokeringen kasseres pakker fra klienten til serveren, i stedet for at indsætte pakker med RST-flag, som tidligere blev udført ved selektiv blokering baseret på SNI-indhold. Efter en blokering af en pakke med ESNI vil alle netværkspakker, der svarer til forbindelsen fra den oprindelige IP, den mål-IP og destinationsporten, også blive blokeret i en periode på 120 til 180 sekunder. HTTPS-forbindelser baseret på ældre versioner af TLS og TLS 1.3 uden ESNI slipper igennem som normalt.
Lad os minde om, at udvidelsen SNI blev udviklet for at muliggøre drift af flere HTTPS-websteder på samme IP-adresse, hvilket overfører værtsnavnet i klar tekst i ClientHello-beskeden, der sendes før etableringen af den krypterede kommunikationskanal. Denne funktion giver internetudbyderen mulighed for selektivt at filtrere HTTPS-trafik og analysere, hvilke websteder brugeren besøger, hvilket ikke tillader fuld fortrolighed ved brug af HTTPS.
Den nye TLS-udvidelse ECH (tidligere ESNI), som kan anvendes sammen med TLS 1.3, fjerner denne ulempe og udelukker fuldstændig lækage af oplysninger om det anmodede websted ved analyse af HTTPS-forbindelser. I kombination med adgang gennem indholdsleveringsnetværk giver anvendelsen af ECH/ESNI også mulighed for at skjule IP-adressen for den anmodede ressource for udbyderen. Trafikinspektionssystemer vil kun se anmodninger til CDN og vil ikke kunne anvende blokering uden at ændre TLS-sessionen, hvilket i så fald vil vise en tilsvarende meddelelse om certifikatændring i brugerens browser. Den mulige lækagekanal forbliver DNS, men for at skjule DNS-anmodningen kan klienten anvende DNS-over-HTTPS eller DNS-over-TLS.
Forskere har allerede Flere måder at omgå den kinesiske blokade på klientsiden og serversiden, men de kan miste relevans og bør kun betragtes som en midlertidig løsning. For eksempel blokeres der i øjeblikket kun pakker med udvidelsesidentifikatoren ESNI 0xffce (encrypted_server_name), som blev brugt i , men der sendes stadig pakker med den aktuelle identifikator 0xff02 (encrypted_client_hello), som er foreslået i .
En anden metode til at omgå blokeringen er at bruge en ikke-standardiseret forhandlingsproces, for eksempel aktiveres blokeringen ikke, når der sendes et ekstra SYN-pakke med et forkert sekvensnummer, manipulation af fragmenteringsflaggene i pakker, sending af en pakke med både FIN- og SYN-flaggene aktiveret, indsættelse af en RST-pakke med en forkert checksum, eller sending af en pakke med SYN- og ACK-flag, inden forhandlingen starter. De beskrevne metoder er allerede implementeret som en plugin til værktøjet , til omgåelse af censureringsmetoder.
Kilde: opennet.ru
