La Xina ha començat a bloquejar les connexions HTTPS establertes amb TLS 1.3 i ESNI

Xina implementat bloqueig totes les connexions HTTPS que utilitzen el protocol TLS 1.3 i l'extensió TLS ESNI (Encrypted Server Name Indication), que proporciona xifratge de dades sobre l'amfitrió sol·licitat. El bloqueig es realitza als encaminadors de trànsit tant per a connexions establertes des de la Xina al món exterior com des del món exterior fins a la Xina.

El bloqueig es fa deixant caure paquets del client al servidor, en lloc de la substitució de paquets RST que es feia anteriorment mitjançant el bloqueig selectiu de contingut SNI. Després d'activar el bloqueig d'un paquet amb ESNI, tots els paquets de xarxa corresponents a la combinació d'IP d'origen, IP de destinació i número de port de destinació també es bloquegen durant 120 a 180 segons. Les connexions HTTPS basades en versions anteriors de TLS i TLS 1.3 sense ESNI es permeten com és habitual.

Recordem que per organitzar el treball en una adreça IP de diversos llocs HTTPS, es va desenvolupar l'extensió SNI, que transmet el nom de l'amfitrió en text clar en el missatge ClientHello transmès abans d'establir un canal de comunicació xifrat. Aquesta característica permet per part del proveïdor d'Internet filtrar selectivament el trànsit HTTPS i analitzar quins llocs obre l'usuari, cosa que no permet assolir la confidencialitat completa quan s'utilitza HTTPS.

La nova extensió TLS ECH (antigament ESNI), que es pot utilitzar conjuntament amb TLS 1.3, elimina aquesta mancança i elimina completament la filtració d'informació sobre el lloc sol·licitat en analitzar connexions HTTPS. En combinació amb l'accés a través d'una xarxa de lliurament de contingut, l'ús d'ECH/ESNI també permet ocultar l'adreça IP del recurs sol·licitat al proveïdor. Els sistemes d'inspecció de trànsit només veuran les sol·licituds a la CDN i no podran aplicar el bloqueig sense la falsificació de la sessió TLS, en aquest cas es mostrarà una notificació corresponent sobre la falsificació de certificats al navegador de l'usuari. El DNS continua sent un possible canal de filtració, però el client pot utilitzar DNS sobre HTTPS o DNS sobre TLS per ocultar l'accés DNS del client.

Els investigadors ja ho han fet identificat Hi ha diverses solucions per evitar el bloqueig xinès al costat del client i del servidor, però poden ser irrellevants i només s'han de considerar com a mesura temporal. Per exemple, actualment només els paquets amb l'ID d'extensió ESNI 0xffce (nom_servidor_xifrat), que s'utilitzava a cinquena versió de l'esborrany de la norma, però de moment paquets amb l'identificador actual 0xff02 (encrypted_client_hello), proposat a setè esborrany de l'especificació ECH.

Una altra solució alternativa és utilitzar un procés de negociació de connexió no estàndard, per exemple, el bloqueig no funciona si s'envia per endavant un paquet SYN addicional amb un número de seqüència incorrecte, manipulacions amb senyals de fragmentació de paquets, enviant un paquet amb FIN i SYN. marcats establerts, substitució d'un paquet RST amb una quantitat de control incorrecta o enviament abans que comenci la negociació de connexió de paquets amb els indicadors SYN i ACK. Els mètodes descrits ja s'han implementat en forma d'un complement per al conjunt d'eines Ginebra, desenvolupat per evitar els mètodes de censura.

Font: opennet.ru

Compreu allotjament fiable per a llocs amb protecció DDoS, servidors VPS VDS 🔥 Compra allotjament web fiable amb protecció DDoS, servidors VPS VDS | ProHoster