{"id":53317,"date":"2019-11-29T00:00:00","date_gmt":"2019-11-28T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/domen-fronting-na-baze-tls-1-3-chast-2"},"modified":"2020-02-18T14:01:12","modified_gmt":"2020-02-18T11:01:12","slug":"domen-fronting-na-baze-tls-1-3-chast-2","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","title":{"rendered":"Domain-Fronting auf Basis von TLS 1.3. Teil 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h3>\n

\nIm ersten Teil einem Artikel<\/a><\/noindex> haben wir eine kurze Beschreibung des Mechanismus des encrypted SNI (eSNI) gegeben. Wir haben gezeigt, wie man mit Hilfe dieses Mechanismus modernen DPI-Systemen (am Beispiel des DPI von Beeline und des verbotenen RKN Torrent-Trackers) entkommen kann, und einen neuen Ansatz des Domain-Fronting basierend auf diesem Mechanismus betrachtet.<\/p>\n

Im zweiten Teil des Artikels werden wir zu praktischeren Aspekten \u00fcbergehen, die f\u00fcr RedTeam-Spezialisten in ihrer anspruchsvollen Arbeit n\u00fctzlich sein werden. Letztendlich ist unser Ziel nicht der Zugang zu gesperrten Ressourcen (f\u00fcr solche banalen Dinge haben wir unseren alten, bew\u00e4hrten VPN). Gl\u00fccklicherweise gibt es viele VPN-Anbieter, wie man so sch\u00f6n sagt, f\u00fcr jeden Geschmack, jedes Budget und jede Vorliebe.<\/p>\n

Wir werden versuchen, den Mechanismus des Domain-Fronting auf moderne RedTeam-Tools anzuwenden, wie z.B. Cobalt Strike, Empire usw., und ihnen zus\u00e4tzliche M\u00f6glichkeiten zur Mimikry und zum Entkommen vor modernen Inhaltsfilterungssystemen zu geben.
\n<\/a><\/noindex>
\nBeim letzten Mal haben wir den eSNI-Mechanismus in die OpenSSL-Bibliothek integriert und erfolgreich in dem weit verbreiteten Tool curl verwendet. Aber mit nur curl wird man nicht satt, wie man so sch\u00f6n sagt. Nat\u00fcrlich will man etwas \u00c4hnliches in Hochsprachen umsetzen. Leider entt\u00e4uscht uns eine schnelle Suche im Internet, denn die Unterst\u00fctzung des eSNI-Mechanismus ist nur in GOLANG vollst\u00e4ndig realisiert. Damit haben wir nicht viel Wahl: Entweder wir programmieren in reinem C oder C++ unter Verwendung einer gepatchten OpenSSL-Bibliothek, oder wir nutzen einen separaten GOLANG-Fork von CloudFlare und versuchen, unser Toolkit dorthin zu portieren. Prinzipiell gibt es noch eine andere M\u00f6glichkeit, die klassischere, aber auch zeitaufw\u00e4ndige \u2013 n\u00e4mlich die Unterst\u00fctzung von eSNI in Python zu implementieren. Schlie\u00dflich verwendet Python ebenfalls OpenSSL f\u00fcr die Arbeit mit https. Aber diese Option lassen wir jemand anderem zur Entwicklung und sind zufrieden mit der Umsetzung in Golang, insbesondere da unser Lieblingswerkzeug Cobalt Strike hervorragend mit einem \u00fcber externe Mittel aufgebauten Kommunikationskanal (External C2 channel) arbeiten kann \u2013 dar\u00fcber werden wir am Ende des Artikels berichten.<\/p>\n

Versuchen Sie es h\u00e4rter\u2026<\/h3>\n

\nEin von uns entwickeltes Go-Tool \u2013 unser interner Tunneler rsockstun<\/a><\/noindex>, das \u00fcbrigens heutzutage von Microsoft und Symantec als hochgradig schadhafter Software zur St\u00f6rung der globalen Stabilit\u00e4t erkannt wird\u2026<\/p>\n

\"Domain-Fronting
\n
\nEs w\u00e4re gro\u00dfartig, die vorherige Entwicklung auch in diesem Fall zu nutzen. Doch hier gibt es ein kleines Problem. Die Sache ist die, dass rsockstun urspr\u00fcnglich eine synchrone SSL-Verbindung zum Server voraussetzt. Das bedeutet, dass die Verbindung einmal hergestellt wird und w\u00e4hrend der gesamten Laufzeit des Tunnelers bestehen bleibt. Wie Sie verstehen, ist das https-Protokoll jedoch nicht wirklich f\u00fcr diesen Betriebsmodus geeignet \u2013 es funktioniert im Anforderungs-Antwort-Modus, wo jede neue http-Anfrage im Rahmen einer neuen tcp-Verbindung existiert.<\/p>\n

Der Hauptnachteil eines solchen Schemas besteht darin, dass der Server keine Daten an den Client \u00fcbertragen kann, solange der Client keine neue HTTP-Anfrage sendet. Gl\u00fccklicherweise gibt es viele L\u00f6sungen f\u00fcr dieses Problem \u2013 die Daten\u00fcbertragung \u00fcber das HTTP-Protokoll (schlie\u00dflich gelingt es uns ja irgendwie, unsere Lieblingsserien zu streamen und Musik von Portalen zu h\u00f6ren, die \u00fcber HTTPS arbeiten, und die \u00dcbertragung von Video und Audio ist nichts anderes als Datenstreaming). Eine Technologie, die die Funktionalit\u00e4t einer vollst\u00e4ndigen TCP-Verbindung \u00fcber das HTTP-Protokoll emuliert, ist die WebSocket-Technologie, deren Hauptzweck darin besteht, eine vollst\u00e4ndige Netzwerkverbindung zwischen Client und Webserver zu erm\u00f6glichen.<\/p>\n

Zu unserem Gl\u00fcck (hurra!!!) ist diese Technologie standardm\u00e4\u00dfig in allen CloudFlare-Tarifen aktiviert und funktioniert hervorragend in Kombination mit eSNI. Genau diese werden wir verwenden, um unseren Tunnel zu lehren, Domain-Fronting zu nutzen und sich vor modernen DPI zu verbergen. <\/p>\n

Ein wenig \u00fcber WebSockets<\/h3>\n

\nZun\u00e4chst werden wir in einfachen Worten kurz \u00fcber WebSockets sprechen, damit alle ein Verst\u00e4ndnis f\u00fcr das haben, womit wir arbeiten werden. <\/p>\n

Die WebSocket-Technologie erm\u00f6glicht es, tempor\u00e4r von einer HTTP-Verbindung auf einen standardm\u00e4\u00dfigen Datenstrom \u00fcber einen Netzwerksocket umzuschalten, ohne die bestehende TCP-Verbindung zu unterbrechen. Wenn der Client zu WebSocket wechseln m\u00f6chte, sendet er in seiner HTTP-Anfrage mehrere HTTP-Header. Zwei erforderliche Header sind: Connection: Upgrade<\/b><\/i> und Upgrade: websocket<\/b><\/i>. Au\u00dferdem kann er die Version des WebSocket-Protokolls erzwingen (Sec-WebSocket-Version: 13<\/b><\/i>) und einen Art von Base64-Identifikator f\u00fcr den WebSocket (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==<\/b><\/i>). Der Server antwortet ihm mit dem HTTP-Code 101 Switching Protocols und setzt auch die Header Connection, Upgrade<\/b><\/i> und Sec-WebSocket-Accept<\/b><\/i>. Der Prozess des Umschaltens wird im Screenshot unten anschaulich dargestellt:<\/p>\n

\"Domain-Fronting
\n
\nDanach kann die Einrichtung der WebSocket-Verbindung als abgeschlossen betrachtet werden. Jegliche Daten, sowohl vom Client als auch vom Server, werden nun nicht mehr mit HTTP-, sondern mit WebSocket-Headern versehen (sie beginnen mit dem Byte 0x82). Der Server muss nicht mehr auf eine Anfrage des Clients warten, um Daten zu senden, da die TCP-Verbindung nicht unterbrochen wird.<\/p>\n

In Go gibt es mehrere Bibliotheken f\u00fcr die Arbeit mit WebSockets. Die bekanntesten sind Gorilla WebSocket<\/a><\/noindex> und die Standardbibliothek. WebSocket<\/a><\/noindex>. Wir werden die letzte Option nutzen, da sie einfacher, kleiner und, wie man sagt, etwas schneller ist.<\/p>\n

Im Client-Code von rsockstun m\u00fcssen wir die Aufrufe von net.dial oder tls.dial durch die entsprechenden WebSocket-Aufrufe ersetzen:<\/p>\n

\"Domain-Fronting
\n
\n\"Domain-Fronting
\n
\nWir m\u00f6chten den Client-Teil unseres Tunnelers universell gestalten, sodass er sowohl \u00fcber eine direkte SSL-Verbindung als auch \u00fcber das WebSocket-Protokoll funktioniert. Dazu werden wir eine separate Funktion erstellen: func connectForWsSocks(address string, proxy string) error {\u2026}<\/b><\/i> analog zu connectForSocks()<\/b><\/i> und wir werden sie f\u00fcr die Arbeit mit WebSockets verwenden, falls die Serveradresse, die beim Start des Clients festgelegt wurde, mit ws: oder wss: beginnt (im Falle von Secure WebSocket).<\/p>\n

F\u00fcr den Serverteil des Tunnelers werden wir ebenfalls eine separate Funktion f\u00fcr die Arbeit mit WebSockets erstellen. Darin wird eine Instanz der http-Klasse erstellt und der http-Verbindungs-Handler (Funktion wsHandler) festgelegt: <\/p>\n

\"Domain-Fronting
\n
\nDie gesamte Logik zur Verarbeitung der Verbindung (Authentifizierung des Clients mit Passwort, Einrichtung und Beendigung der yamux-Sitzung) werden wir in den WebSocket-Verbindungs-Handler einf\u00fcgen:<\/p>\n

\"Domain-Fronting
\n
\nLassen Sie uns das Projekt kompilieren und den Serverteil starten:<\/p>\n

.\/rsockstun \u2013listen ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nUnd dann den Clientteil:<\/p>\n
.\/rsockstun -connect ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nUnd wir \u00fcberpr\u00fcfen die Funktion auf dem lokalen Host:<\/p>\n
\"Domain-Fronting
\n
\n\"Domain-Fronting
\n<\/p>\n
Lassen Sie uns zu Domain-Fronteing\u00e4ngen \u00fcbergehen<\/h3>\n
\nMit Web-Sockets scheinen wir bereits klarzukommen. Lassen Sie uns nun direkt zu eSNI und Domain-Fronteing\u00e4ngen gehen. Wie bereits erw\u00e4hnt, ben\u00f6tigen wir f\u00fcr die Arbeit mit DoH und eSNI einen speziellen Branch von Golang von der Firma CloudFlare<\/a><\/noindex>. Wir ben\u00f6tigen den Branch mit eSNI-Unterst\u00fctzung (pwu\/esni).<\/p>\n
Klonen Sie ihn lokal oder laden Sie die entsprechende Zip-Datei herunter und entpacken Sie sie:<\/p>\n
git clone -b pwu\/esni https:\/\/github.com\/cloudflare\/tls-tris.git<\/code><\/pre>\n
\nAnschlie\u00dfend m\u00fcssen wir das GOROOT-Verzeichnis kopieren, die entsprechenden Dateien aus dem geklonten Branch ersetzen und es als Hauptverzeichnis festlegen. Um den Entwickler von diesem Kopfzerbrechen zu befreien, haben die Leute von CloudFlare ein spezielles Skript vorbereitet \u2013 _dev\/go.sh. Starten Sie es einfach. Das Skript wird zusammen mit dem Makefile alles selbst erledigen. Zum Interesse \u2013 Sie k\u00f6nnen ins Makefile schauen, um Details zu erfahren.<\/p>\n
Nach der Ausf\u00fchrung des Skripts m\u00fcssen wir bei der Kompilierung des Projekts das lokale Verzeichnis, das durch das Skript vorbereitet wurde, als GOROOT angeben. In unserem Fall sieht es so aus:<\/p>\n
GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" go build \u2026.<\/code><\/pre>\n
\nZun\u00e4chst m\u00fcssen wir im Tunnel die Funktionalit\u00e4t f\u00fcr die Abfrage und das Parsen der \u00f6ffentlichen eSNI-Schl\u00fcssel f\u00fcr die entsprechende Domain implementieren. In unserem Fall handelt es sich um die \u00f6ffentlichen eSNI-Schl\u00fcssel von den Frontend-Servern von CloudFlare. Daf\u00fcr werden wir drei Funktionen erstellen:<\/p>\n
func makeDoTQuery(dnsName string) ([]byte, error)\nfunc parseTXTResponse(buf []byte, wantName string) (string, error)\nfunc QueryESNIKeysForHost(hostname string) ([]byte, error)<\/code><\/pre>\n
\nDie Funktionsnamen sprechen eigentlich f\u00fcr sich. Die Implementierung werden wir aus der Datei esni_query.go entnehmen, die Teil von tls-tris ist. Die erste Funktion erstellt ein Netzwerkpaket f\u00fcr die Abfrage beim DNS-Server von CloudFlare unter Verwendung des Protokolls DoH (DNS-over-HTTPS), die zweite analysiert die Ergebnisse der Anfrage und erh\u00e4lt die Werte der \u00f6ffentlichen Schl\u00fcssel der Domain, w\u00e4hrend die dritte als Container f\u00fcr die ersten beiden dient.<\/p>\n
Als N\u00e4chstes f\u00fcgen wir in unsere neu geschaffene Funktion zur Verbindung mit dem Websocket connectForWsSocks<\/b><\/i> die Funktionalit\u00e4t zur Abfrage der eSNI-Schl\u00fcssel f\u00fcr die Domain ein. Dort, wo der Serverbetrieb erfolgt, setzen wir die TLS-Parameter und definieren den Namen der fiktiven \"Maskierungsdomain\":<\/p>\n
\"Domain-Fronting
\n
\nEs ist wichtig zu beachten, dass der tls-tris-Branch urspr\u00fcnglich nicht f\u00fcr die Verwendung von Domain-Fronting vorgesehen ist. Daher wurde dem gef\u00e4lschten Servernamen (das serverName-Feld im client-hello-Paket wird leer \u00fcbermittelt) keine Beachtung geschenkt. Um dies zu beheben, m\u00fcssen wir das entsprechende Feld FakeServerName in die TlsConfig-Struktur einf\u00fcgen. Das Standardfeld ServerName der Struktur k\u00f6nnen wir nicht verwenden, da es von internen tls-Mechanismen genutzt wird und, wenn es von der urspr\u00fcnglichen Bezeichnung abweicht, der tls-Handshake mit einem Fehler endet. Die Beschreibung der TlsConfig-Struktur befindet sich in der Datei tls\/common.go<\/b> \u2013 die wir anpassen m\u00fcssen:<\/p>\n
\"Domain-Fronting
\n
\n\"Domain-Fronting
\n
\nZus\u00e4tzlich m\u00fcssen wir \u00c4nderungen in der Datei tls\/handshake_client.go<\/b>vornehmen, um unser Feld FakeServerName bei der TLS-Handshakerstellung zu verwenden:<\/p>\n
\"Domain-Fronting
\n
\nDas w\u00e4re alles! Sie k\u00f6nnen Ihr Projekt jetzt kompilieren und testen. Aber bevor Sie mit dem Test starten, m\u00fcssen Sie Ihr Cloudflare-Konto einrichten. Eigentlich ist es einfach \u2013 erstellen Sie einfach ein Konto bei Cloudflare und verkn\u00fcpfen Sie Ihre Domain damit. Alle Funktionen in Bezug auf DoH, WebSocket und ESNI sind bei Cloudflare standardm\u00e4\u00dfig aktiviert. Nachdem die DNS-Eintr\u00e4ge aktualisiert wurden, k\u00f6nnen Sie die Funktionalit\u00e4t Ihrer Domain \u00fcberpr\u00fcfen, indem Sie eine Anfrage nach den eSNI-Schl\u00fcsseln durchf\u00fchren:<\/p>\n
dig +short txt _esni.df13tester.info <\/code><\/pre>\n
\n\"Domain-Fronting
\n
\nWenn Sie etwas \u00c4hnliches f\u00fcr Ihre Domain sehen, bedeutet das, dass alles funktioniert und Sie mit den Tests fortfahren k\u00f6nnen.<\/p>\n
Starten Sie einen Ubuntu VPS, zum Beispiel bei DigitalOcean. P.S. In unserem Fall war die gerade vom Anbieter zugewiesene IP-Adresse des VPS auf den Blacklists der RK-Beh\u00f6rden. Seien Sie also nicht \u00fcberrascht, wenn Ihnen etwas \u00c4hnliches passiert. Wir mussten einen VPN verwenden, um auf unseren VPS zuzugreifen.<\/p>\n
Wir kopieren das bereits kompilierte rsockstun auf den VPS (\u00fcbrigens ein weiterer Vorteil von Go \u2013 Sie k\u00f6nnen das Projekt auf Ihrem System kompilieren und dann auf jedem Linux-Betriebssystem ausf\u00fchren, solange die Systemarchitektur \u00fcbereinstimmt) und starten den Serverteil:<\/p>\n
\"Domain-Fronting
\n
\nUnd dann den Client-Teil:<\/p>\n
\"Domain-Fronting
\n
\nWie wir sehen, hat der Kunde erfolgreich \u00fcber den CloudFlare-Frontend-Server eine Verbindung zum Server \u00fcber WebSocket hergestellt. Um zu \u00fcberpr\u00fcfen, ob das Tunnel wirklich als Tunnel funktioniert, kann man eine Curl-Anfrage \u00fcber den lokal auf dem Server offenen Socks5 durchf\u00fchren:<\/p>\n
\"Domain-Fronting
\n
\nSchauen wir uns jetzt an, was die DPI im Kommunikationskanal sieht:<\/p>\n
\"Domain-Fronting
\n
\nZun\u00e4chst kontaktiert der Tunnel mit dem DoH-Mechanismus den DNS-Server von Cloudflare, um eSNI-Schl\u00fcssel f\u00fcr die Ziel-Domain abzurufen (Pakete Nr. 1-19), und verbindet sich dann mit dem Frontend-Server, um eine TLS-Verbindung aufzubauen, w\u00e4hrend er sich hinter der Domain www.google.com<\/a><\/noindex> (dies ist der Standardwert, wenn beim Start des Clients keine gef\u00e4lschte Domain angegeben ist). Um eine eigene gef\u00e4lschte Domain anzugeben, muss der Parameter -fronfDomain verwendet werden:<\/p>\n
\"Domain-Fronting
\n
\n\"Domain-Fronting
\n
\nEin weiterer Punkt. Standardm\u00e4\u00dfig ist im CloudFlare-Konto die Flexible SSL-Arbeitsweise aktiviert. Das bedeutet, dass HTTPS-Anfragen an die CloudFlare-Frontend-Server von den Kunden in unverschl\u00fcsseltem (HTTP) Format an unseren Server weitergeleitet werden. Aus diesem Grund haben wir die Server-Teile des Tunnelers im non-ssl-Modus (-listen ws:0.0.0.0) gestartet, und nicht (-listen wss:0.0.0.0).<\/p>\n
\"Domain-Fronting
\n
\nUm in den vollst\u00e4ndigen Verschl\u00fcsselungsmodus zu wechseln, m\u00fcssen Sie w\u00e4hlen Voll<\/b>, oder Voll (streng)<\/b> bei Vorhandensein eines g\u00fcltigen Zertifikats auf dem Server. Nach dem Wechsel des Modus k\u00f6nnen wir Verbindungen von CloudFlare \u00fcber das HTTPS-Protokoll annehmen. Vergessen Sie nicht, ein selbstsigniertes Zertifikat f\u00fcr den Serverteil des Tunnels zu generieren.<\/p>\n
\"Domain-Fronting
\n
\nEin aufmerksamer Leser k\u00f6nnte fragen: \u201eWie sieht es mit dem Client f\u00fcr Windows aus? Schlie\u00dflich ist die Hauptanwendung des Tunnels, eine Back-Connection mit Unternehmensrechnern und Servern herzustellen, und dort l\u00e4uft in der Regel immer Windows. Wie kompiliere ich den Tunnel f\u00fcr Windows, und das noch mit einem spezifischen TLS-Stack?\u201c Lassen Sie uns nun eine weitere Funktion vorstellen, die zeigt, wie benutzerfreundlich Go ist. Wir kompilieren direkt unter Windows aus Kali, indem wir einfach den Parameter GOOS=windows hinzuf\u00fcgen:<\/p>\n
GOARCH=amd64 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\nOder die 32-Bit-Variante:<\/p>\n
GOARCH=386 GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" GOOS=windows go build -ldflags=\"-s -w\"<\/code><\/pre>\n
\nDas ist alles! Keine weiteren Komplikationen n\u00f6tig. Das funktioniert wirklich! <\/p>\n
\"Domain-Fronting
\n
\nDie Compiler-Flags -w und -s sind notwendig, um \u00fcberfl\u00fcssigen M\u00fcll aus der ausf\u00fchrbaren Datei zu entfernen und sie um einige Megabyte kleiner zu machen. Zus\u00e4tzlich kann die Datei sp\u00e4ter mit UPX verpackt werden, um die Gr\u00f6\u00dfe weiter zu reduzieren.<\/p>\n
Abschlie\u00dfend<\/h3>\n
\nIn diesem Artikel zeigen wir anhand eines in Go geschriebenen Tunnellers anschaulich die Anwendung der neuen Technologie des Domain-Fronting, die auf einer interessanten Eigenschaft des TLS 1.3-Protokolls basiert. Ebenso kann das bestehende Werkzeug, das in Go geschrieben wurde, f\u00fcr die Arbeit \u00fcber Servers von CloudFlare angepasst werden, beispielsweise. Merlin<\/a><\/noindex> \u2014 ein bekannter C2, oder um CobaltStrike Beacon zu zwingen, eSNI Domain-Fronting bei der Kommunikation mit dem Teamserver \u00fcber External C2 Channel<\/a><\/noindex>, realisiert in Go oder der Standard-C++-Version mit einer gepatchten OpenSSL-Version, \u00fcber die wir im letzten Teil des Artikels berichtet haben. In der Tat sind der Fantasie keine Grenzen gesetzt.<\/p>\n
Das Beispiel mit dem Tunneller und CloudFlare wird als Konzept pr\u00e4sentiert, und es ist derzeit schwierig, \u00fcber die weitreichenden Perspektiven dieser Art des Domain-Frontings zu spekulieren. Momentan wird eSNI nur von CloudFlare unterst\u00fctzt, und theoretisch k\u00f6nnte nichts sie daran hindern, diese Art des Frontings auszuschalten und beispielsweise TLS-Verbindungen zu unterbrechen, wenn SNI und eSNI nicht \u00fcbereinstimmen. Die Zukunft wird es zeigen. Doch derzeit sieht die Perspektive, unter dem \"Schutz von kremlin.ru\" zu arbeiten, ziemlich verlockend aus. Oder etwa nicht?<\/p>\n
Der aktualisierte Tunnel-Code sowie die kompilierten ausf\u00fchrbaren exe-Dateien sind in einem separaten Projektzweig auf github<\/a><\/noindex>. Bei m\u00f6glichen Problemen mit dem Tunnel ist es besser, ein Issue auf der Projektseite auf GitHub zu erstellen.
\n
Quelle: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043c\u044b \u0434\u0430\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430 encrypted SNI (eSNI). \u041f\u043e\u043a\u0430\u0437\u0430\u043b\u0438 \u043a\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043d\u0430 \u0435\u0433\u043e \u043e\u0441\u043d\u043e\u0432\u0435 \u043c\u043e\u0436\u043d\u043e \u0443\u043a\u043b\u043e\u043d\u044f\u0442\u044c\u0441\u044f \u043e\u0442 \u0434\u0435\u0442\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c\u0438 DPI-\u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438 (\u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u0438\u043b\u0430\u0439\u043d\u043e\u0432\u0441\u043a\u043e\u0433\u043e DPI \u0438 \u0437\u0430\u043f\u0440\u0435\u0449\u0435\u043d\u043d\u043e\u0433\u043e \u0420\u041a\u041d \u0440\u0443\u0442\u0440\u0435\u043a\u0435\u0440\u0430), \u0430 \u0442\u0430\u043a\u0436\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043b\u0438 \u043d\u043e\u0432\u044b\u0439 \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u0434\u043e\u043c\u0435\u043d-\u0444\u0440\u043e\u043d\u0442\u0438\u043d\u0433\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u0430\u043d\u043d\u043e\u0433\u043e \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430. \u0412\u043e \u0432\u0442\u043e\u0440\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u0435\u0449\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0443\u0442 \u043f\u043e\u043b\u0435\u0437\u043d\u044b […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-53317","post","type-post","status-publish","format-standard","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Domain-Fronting auf Basis von TLS 1.3. Teil 2 | ProHoster","description":"Einf\u00fchrung In Teil eins des Artikels haben wir eine kurze Beschreibung des Mechanismus f\u00fcr encrypted SNI (eSNI) gegeben. Wir haben aufgezeigt, wie man auf dieser Basis moderne DPI-Systeme (am Beispiel des DPI von Beeline und des verbotenen RKN-Torrents) umgehen kann, sowie eine neue Variante des Domain-Fronting auf Basis dieses Mechanismus untersucht. In Teil zwei des Artikels kommen wir zu praktischeren Themen, die n\u00fctzlich sein werden.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0414\u043e\u043c\u0435\u043d-\u0444\u0440\u043e\u043d\u0442\u0438\u043d\u0433 \u043d\u0430 \u0431\u0430\u0437\u0435 TLS 1.3. \u0427\u0430\u0441\u0442\u044c 2 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0412 \u043f\u0435\u0440\u0432\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043c\u044b \u0434\u0430\u043b\u0438 \u043a\u0440\u0430\u0442\u043a\u043e\u0435 \u043e\u043f\u0438\u0441\u0430\u043d\u0438\u0435 \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430 encrypted SNI (eSNI). \u041f\u043e\u043a\u0430\u0437\u0430\u043b\u0438 \u043a\u0430\u043a\u0438\u043c \u043e\u0431\u0440\u0430\u0437\u043e\u043c \u043d\u0430 \u0435\u0433\u043e \u043e\u0441\u043d\u043e\u0432\u0435 \u043c\u043e\u0436\u043d\u043e \u0443\u043a\u043b\u043e\u043d\u044f\u0442\u044c\u0441\u044f \u043e\u0442 \u0434\u0435\u0442\u0435\u043a\u0442\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u043c\u0438 DPI-\u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438 (\u043d\u0430 \u043f\u0440\u0438\u043c\u0435\u0440\u0435 \u0431\u0438\u043b\u0430\u0439\u043d\u043e\u0432\u0441\u043a\u043e\u0433\u043e DPI \u0438 \u0437\u0430\u043f\u0440\u0435\u0449\u0435\u043d\u043d\u043e\u0433\u043e \u0420\u041a\u041d \u0440\u0443\u0442\u0440\u0435\u043a\u0435\u0440\u0430), \u0430 \u0442\u0430\u043a\u0436\u0435 \u0438\u0441\u0441\u043b\u0435\u0434\u043e\u0432\u0430\u043b\u0438 \u043d\u043e\u0432\u044b\u0439 \u0432\u0430\u0440\u0438\u0430\u043d\u0442 \u0434\u043e\u043c\u0435\u043d-\u0444\u0440\u043e\u043d\u0442\u0438\u043d\u0433\u0430 \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0435 \u0434\u0430\u043d\u043d\u043e\u0433\u043e \u043c\u0435\u0445\u0430\u043d\u0438\u0437\u043c\u0430. \u0412\u043e \u0432\u0442\u043e\u0440\u043e\u0439 \u0447\u0430\u0441\u0442\u0438 \u0441\u0442\u0430\u0442\u044c\u0438 \u043f\u0435\u0440\u0435\u0439\u0434\u0435\u043c \u043a \u0431\u043e\u043b\u0435\u0435 \u043f\u0440\u0430\u043a\u0442\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0432\u0435\u0449\u0430\u043c, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0431\u0443\u0434\u0443\u0442 \u043f\u043e\u043b\u0435\u0437\u043d\u044b","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3-chast-2","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-11-28T21:00:00+00:00","article:modified_time":"2020-02-18T11:01:12+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"53317","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-24 06:55:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:27:38","updated":"2026-01-24 06:55:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53317","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=53317"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/53317\/revisions"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=53317"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=53317"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=53317"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}