{"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-Frontrunning auf der Basis von TLS 1.3. Teil 2","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h3>\n

\nIm ersten Teil des Artikels<\/a><\/noindex> haben wir eine kurze Beschreibung des Mechanismus des verschl\u00fcsselten SNI (eSNI) gegeben. Wir zeigten, wie man mithilfe dessen modernen DPI-Systemen (am Beispiel des DPI von Beeline und dem verbotenen RKN-Rutracker) ausweichen kann, und untersuchten eine neue Variante des Domain-Fronting auf Grundlage dieses Mechanismus.<\/p>\n

Im zweiten Teil des Artikels wenden wir uns den praktischeren Aspekten zu, die f\u00fcr RedTeam-Spezialisten in ihrer schwierigen Arbeit n\u00fctzlich sein werden. Schlie\u00dflich ist unser Ziel nicht der Zugang zu gesperrten Ressourcen (f\u00fcr so banale Dinge haben wir das gute alte VPN). Gl\u00fccklicherweise gibt es viele VPN-Anbieter, wie man sagt, f\u00fcr jeden Geschmack, jede Farbe und jedes Budget.<\/p>\n

Wir werden versuchen, den Mechanismus des Domain-Frontings f\u00fcr moderne RedTeam-Tools anzuwenden, wie zum Beispiel Cobalt Strike, Empire und andere, und ihnen zus\u00e4tzliche M\u00f6glichkeiten f\u00fcr die Mimicry und das Ausweichen vor modernen Inhaltsfilter-Systemen zu bieten.
\n<\/a><\/noindex>
\nBeim letzten Mal haben wir den eSNI-Mechanismus in die OpenSSL-Bibliothek integriert und erfolgreich in dem jedem bekannten Tool curl verwendet. Aber mit curl allein, wie man sagt, ist man nicht satt. Nat\u00fcrlich m\u00f6chte man etwas \u00c4hnliches in Hochsprachen umsetzen. Leider entt\u00e4uscht uns eine fl\u00fcchtige Suche im Internet, denn die vollst\u00e4ndige Unterst\u00fctzung des eSNI-Mechanismus ist nur in GOLANG realisiert. Somit ist unsere Auswahl nicht besonders gro\u00df: entweder wir programmieren in reinem C oder C++ unter Verwendung einer gepatchten OpenSSL-Bibliothek, oder wir verwenden einen separaten Fork von GOLANG von CloudFlare und versuchen, unser Toolkit dorthin zu portieren. Prinzipiell gibt es noch eine andere, klassischere aber gleichzeitig arbeitsintensivere Option \u2013 die Unterst\u00fctzung von eSNI f\u00fcr Python zu implementieren. Schlie\u00dflich verwendet Python ebenfalls OpenSSL f\u00fcr die Arbeit mit https. Aber diese Option lassen wir f\u00fcr jemand anderen zur Entwicklung \u00fcbrig, w\u00e4hrend wir uns mit der Implementierung in Golang zufriedengeben, zumal unser Lieblings-Cobalt Strike hervorragend mit Kommunikationskan\u00e4len arbeitet, die von Drittmitteln aufgebaut sind (External C2 channel) \u2013 dar\u00fcber werden wir am Ende des Artikels berichten.<\/p>\n

Try Harder\u2026<\/h3>\n

\nEines der in Go umgesetzten Tools ist unsere Entwicklung f\u00fcr das Pivoting ins Netzwerk \u2013 der Tunnel rsockstun<\/a><\/noindex>, die \u00fcbrigens heutzutage von Microsoft und Symantec als sehr sch\u00e4dliche Software erkannt wird, die darauf abzielt, die weltweite Stabilit\u00e4t zu st\u00f6ren\u2026<\/p>\n

\"Domain-Frontrunning
\n
\nEs w\u00e4re gro\u00dfartig, die vorherige Entwicklung auch in diesem Fall zu nutzen. Doch hier gibt es ein kleines Problem. Das liegt daran, dass rsockstun urspr\u00fcnglich den Einsatz eines synchronen SSL-Kommunikationskanals mit dem Server vorsieht. Das bedeutet, dass die Verbindung einmal hergestellt wird und w\u00e4hrend der gesamten Laufzeit des Tunnels besteht. Und wie Sie verstehen k\u00f6nnen, ist das https-Protokoll nicht unbedingt f\u00fcr diesen Betriebsmodus geeignet \u2013 es funktioniert im Anfrage-Antwort-Modus, wobei jede neue http-Anfrage im Rahmen einer neuen tcp-Verbindung existiert.<\/p>\n

Der Hauptnachteil eines solchen Schemas besteht darin, dass der Server dem Client keine Daten \u00fcbermitteln kann, solange der Client keine neue http-Anfrage sendet. Aber zum Gl\u00fcck gibt es viele Varianten zur L\u00f6sung dieses Problems \u2013 der Streaming-Daten\u00fcbertragung \u00fcber das https-Protokoll (schlie\u00dflich schaffen wir es ja irgendwie, unsere Lieblingsserien zu schauen und Musik von Portalen zu h\u00f6ren, die auf https arbeiten, und die \u00dcbertragung von Video und Audio ist nichts anderes als Streamen von Daten). Eine der Technologien zur Emulation einer vollst\u00e4ndigen tcp-Verbindung \u00fcber das http-Protokoll ist die WebSocket-Technologie, deren Hauptziel die Schaffung einer vollwertigen Netzwerkverbindung zwischen Client und Webserver ist.<\/p>\n

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

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

\nZuerst werden wir kurz und einfach \u00fcber WebSockets sprechen, damit alle eine Vorstellung davon haben, woran wir arbeiten werden. <\/p>\n

Die WebSocket-Technologie erm\u00f6glicht es, tempor\u00e4r von einer http-Verbindung auf einen Standard-Streaming-Daten\u00fcbertragungsmodus \u00fcber einen Netzwerk-Socket umzuschalten, ohne die bestehende tcp-Verbindung zu unterbrechen. Wenn der Client auf WebSocket umschalten m\u00f6chte, setzt er in seiner http-Anfrage mehrere http-Header. Zwei verpflichtende Header sind Connection: Upgrade<\/b><\/i> und Upgrade: websocket<\/b><\/i>. Er kann auch die Version des WebSocket-Protokolls zwangsweise angeben (Sec-Websockset-Version: 13<\/b><\/i>) und eine Art base64-Bezeichner f\u00fcr den Websocket (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==<\/b><\/i>). Der Server antwortet mit dem http-Code 101 Switching Protocols und setzt ebenfalls die Header Connection, Upgrade<\/b><\/i> und Sec-WebSocket-Accept<\/b><\/i>. Der Prozess des Wechsels wird im Screenshot unten veranschaulicht:<\/p>\n

\"Domain-Frontrunning
\n
\nNach diesem Schritt kann die Einrichtung der WebSocket-Verbindung als abgeschlossen betrachtet werden. Alle Daten, sowohl vom Client als auch vom Server, werden jetzt nicht mehr mit http-, sondern mit WebSocket-Headern versehen (sie beginnen mit dem Byte 0x82). Der Server muss nun nicht mehr auf eine Anfrage des Clients warten, um Daten zu \u00fcbertragen, da die tcp-Verbindung nicht unterbrochen wird.<\/p>\n

In Go gibt es mehrere Bibliotheken f\u00fcr die Arbeit mit WebSockets. Die beliebtesten sind Gorilla WebSocket<\/a><\/noindex> und die Standard- WebSocket<\/a><\/noindex>. Wir werden letzteres verwenden, da es einfacher, kompakter und angeblich 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-Frontrunning
\n
\n\"Domain-Frontrunning
\n
\nWir m\u00f6chten den Client-Teil unseres Tunnels universell gestalten, sodass er sowohl \u00fcber eine direkte SSL-Verbindung als auch \u00fcber das WebSocket-Protokoll arbeiten kann. Dazu erstellen wir eine separate Funktion func connectForWsSocks(address string, proxy string) error {\u2026}<\/b><\/i> analog zu connectForSocks()<\/b><\/i> und werden sie f\u00fcr die Arbeit mit WebSockets verwenden, falls die bei der Client-Start angegebenen Serveradresse mit ws: oder wss: (im Fall von Secure WebSocket) beginnt.<\/p>\n

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

\"Domain-Frontrunning
\n
\nDie gesamte Logik der Verbindungsverarbeitung (Client-Authentifizierung mit Passwort, Einrichtung und Beendigung der yamux-Sitzung) werden wir im WebSocket-Verbindungshandler unterbringen:<\/p>\n

\"Domain-Frontrunning
\n
\nWir kompilieren das Projekt und starten den Serverteil:<\/p>\n

.\\\/rsockstun \u2013listen ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nUnd dann den Client-Teil:<\/p>\n
.\\\/rsockstun -connect ws:127.0.0.1:8080 \u2013pass P@ssw0rd<\/code><\/pre>\n
\nUnd wir \u00fcberpr\u00fcfen die Funktionalit\u00e4t auf dem lokalen Host:<\/p>\n
\"Domain-Frontrunning
\n
\n\"Domain-Frontrunning
\n<\/p>\n
Lass uns zum Domain-Fronting \u00fcbergehen<\/h3>\n
\nMit WebSockets scheinen wir soweit klarzukommen. Lassen Sie uns nun direkt zu eSNI und Domain-Fronting \u00fcbergehen. Wie bereits erw\u00e4hnt, ben\u00f6tigen wir f\u00fcr die Arbeit mit DoH und eSNI einen speziellen Zweig von Go von der Firma CloudFlare<\/a><\/noindex>. Wir ben\u00f6tigen den Zweig mit Unterst\u00fctzung f\u00fcr eSNI (pwu\/esni).<\/p>\n
Wir klonen ihn lokal oder laden ihn herunter und entpacken die entsprechende Zip-Datei:<\/p>\n
git clone -b pwu\/esni https:\/\/github.com\/cloudflare\/tls-tris.git<\/code><\/pre>\n
\nDann m\u00fcssen wir das GOROOT-Verzeichnis kopieren, die entsprechenden Dateien aus dem geklonten Branch ersetzen und es als Hauptverzeichnis festlegen. Um den Entwicklern diese Kopfschmerzen zu ersparen, haben die Jungs von CloudFlare ein spezielles Skript vorbereitet \u2013 _dev\/go.sh. Wir f\u00fchren es einfach aus. Das Skript erledigt zusammen mit dem Makefile alles selbst. Aus Interesse \u2013 Sie k\u00f6nnen gerne ins Makefile schauen, um die Details zu erfahren.<\/p>\n
Nach dem Ausf\u00fchren des Skripts m\u00fcssen wir beim Kompilieren des Projekts das lokale Verzeichnis, das vom Skript vorbereitet wurde, als GOROOT angeben. In unserem Fall sieht das so aus:<\/p>\n
GOROOT=\"\/opt\/tls-tris\/_dev\/GOROOT\/linux_amd64\" go build \u2026.<\/code><\/pre>\n
\nAls N\u00e4chstes m\u00fcssen wir im Tunnel einen Funktionsaufruf und das Parsen der \u00f6ffentlichen eSNI-Schl\u00fcssel f\u00fcr die ben\u00f6tigte Domain implementieren. In unserem Fall werden dies die \u00f6ffentlichen eSNI-Schl\u00fcssel von den Frontend-Servern von CloudFlare sein. Dazu erstellen wir drei Funktionen:<\/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 im Grunde f\u00fcr sich. Die Inhalte werden wir aus der Datei esni_query.go entnehmen, die Teil von tls-tris ist. Die erste Funktion erstellt ein Netzwerkpaket mit der Anfrage an den DNS-Server von CloudFlare unter Verwendung des DoH-Protokolls (DNS-over-HTTPS), die zweite analysiert die Ergebnismenge der Anfrage und erh\u00e4lt die Werte der \u00f6ffentlichen Schl\u00fcssel der Domain, w\u00e4hrend die dritte als Container f\u00fcr die ersten beiden fungiert.<\/p>\n
Als N\u00e4chstes f\u00fcgen wir unsere neu erstellte Funktion f\u00fcr die WebSocket-Verbindung ein. connectForWsSocks<\/b><\/i> die Funktionalit\u00e4t zum Abfragen der eSNI-Schl\u00fcssel f\u00fcr die Domain. Dort, wo der Serverteil l\u00e4uft, stellen wir die TLS-Parameter ein und definieren auch den Namen der gef\u00e4lschten \"Cover-Domain\":<\/p>\n
\"Domain-Frontrunning
\n
\nHier sei erw\u00e4hnt, dass der Branch tls-tris urspr\u00fcnglich nicht f\u00fcr die Verwendung von Domain-Fronting ausgelegt ist. Folglich wurde darin der gef\u00e4lschte Servernamen (in dem client-hello-Paket wird ein leeres Feld serverName \u00fcbermittelt) keine Beachtung geschenkt. Um dies zu beheben, m\u00fcssen wir das entsprechende Feld FakeServerName in die Struktur TlsConfig einf\u00fcgen. Das Standardfeld ServerName in der Struktur k\u00f6nnen wir nicht verwenden, da es von internen Mechanismen von tls verwendet wird, und wenn es von dem urspr\u00fcnglichen abweicht, wird der tls-Handshake mit einem Fehler enden. Die Beschreibung der Struktur TlsConfig befindet sich in der Datei tls\/common.go<\/b> \u2013 die m\u00fcssen wir anpassen:<\/p>\n
\"Domain-Frontrunning
\n
\n\"Domain-Frontrunning
\n
\nZus\u00e4tzlich m\u00fcssen wir \u00c4nderungen an der Datei tls\/handshake_client.go<\/b>, um unser Feld FakeServerName bei der TLS-Handshake-Bildung zu verwenden:<\/p>\n
\"Domain-Frontrunning
\n
\nDas war's! Sie k\u00f6nnen das Projekt kompilieren und die Funktionalit\u00e4t \u00fcberpr\u00fcfen. Aber bevor Sie den Test starten, m\u00fcssen Sie Ihr CloudFlare-Konto einrichten. Nun, wie sagt man einrichten \u2013 einfach ein Konto bei CloudFlare erstellen und Ihre Domain damit verkn\u00fcpfen. Alle Funktionen, die mit DoH, WebSocket und ESNI verbunden sind, sind standardm\u00e4\u00dfig in CloudFlare aktiviert. Nachdem die DNS-Eintr\u00e4ge aktualisiert wurden, k\u00f6nnen Sie die Funktionalit\u00e4t der Domain \u00fcberpr\u00fcfen, indem Sie einen eSNI-Schl\u00fcsselabfrage durchf\u00fchren:<\/p>\n
dig +short txt _esni.df13tester.info <\/code><\/pre>\n
\n\"Domain-Frontrunning
\n
\nWenn Sie etwas \u00c4hnliches f\u00fcr Ihre Domain sehen, funktioniert alles und Sie k\u00f6nnen mit dem Testen fortfahren.<\/p>\n
Wir starten einen Ubuntu VPS, zum Beispiel bei DigitalOcean. P.S. In unserem Fall war die gerade ausgegebene IP-Adresse des VPS auf den Blacklists des RKN. Also wundern Sie sich nicht, wenn Ihnen etwas \u00c4hnliches passiert. Ich musste ein VPN benutzen, um auf meinen VPS zuzugreifen.<\/p>\n
Wir kopieren den bereits kompilierten rsockstun auf den VPS (\u00fcbrigens, das ist eine weitere tolle Eigenschaft von Go \u2013 Sie k\u00f6nnen das Projekt bei sich kompilieren und auf jedem Linux-System ausf\u00fchren, solange Sie die Architektur beibehalten) und starten den Serverteil:<\/p>\n
\"Domain-Frontrunning
\n
\nUnd dann den Clientteil:<\/p>\n
\"Domain-Frontrunning
\n
\nWie wir sehen, hat sich der Client erfolgreich \u00fcber den Frontend-Server von CloudFlare mit dem Server verbunden, indem er WebSocket verwendet. Um zu \u00fcberpr\u00fcfen, dass der Tunnel tats\u00e4chlich als Tunnel funktioniert, k\u00f6nnen Sie eine curl-Anfrage \u00fcber den lokalen socks5, der auf dem Server ge\u00f6ffnet ist, durchf\u00fchren:<\/p>\n
\"Domain-Frontrunning
\n
\nJetzt schauen wir, was der DPI im Kommunikationskanal sieht:<\/p>\n
\"Domain-Frontrunning
\n
\nZuerst kontaktiert der Tunnel, unter Verwendung des DoH-Mechanismus, den DNS-Server von Cloudflare, um eSNI-Schl\u00fcssel f\u00fcr die Zieldomain abzufragen (Pakete Nr. 1-19), bevor er sich an den Frontend-Server wendet und eine TLS-Verbindung herstellt, wobei er sich hinter der Domain versteckt www.google.com<\/a><\/noindex> (dies ist der Standardwert, wenn beim Start des Clients keine gef\u00e4lschte Domain angegeben wurde). Um Ihre eigene gef\u00e4lschte Domain anzugeben, m\u00fcssen Sie den Parameter -fronfDomain verwenden:<\/p>\n
\"Domain-Frontrunning
\n
\n\"Domain-Frontrunning
\n
\nJetzt noch ein weiterer Punkt. Standardm\u00e4\u00dfig ist im Konto bei CloudFlare der Modus \"Flexible SSL\" eingestellt. Das bedeutet, dass https-Anfragen von Clients an die Frontend-Server von Cloudflare unverschl\u00fcsselt (http) an unseren Server weitergeleitet werden. Deshalb haben wir den Serverteil des Tunnelers im non-ssl-Modus (-listen ws:0.0.0.0) und nicht (-listen wss:0.0.0.0) gestartet.<\/p>\n
\"Domain-Frontrunning
\n
\nUm in den Modus voller Verschl\u00fcsselung umzuschalten, m\u00fcssen Sie ausw\u00e4hlen Voll<\/b>, oder Voll (streng)<\/b> im Falle des Vorhandenseins 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 Tunnelers zu generieren.<\/p>\n
\"Domain-Frontrunning
\n
\nEin aufmerksamer Leser k\u00f6nnte fragen: \"Was ist mit dem Client f\u00fcr Windows? Schlie\u00dflich wird der Tunneler haupts\u00e4chlich verwendet, um eine Back-Connect von Unternehmensmaschinen und -servern herzustellen, und dort l\u00e4uft in der Regel immer Windows. Wie kann ich den Tunneler f\u00fcr Windows kompilieren, und das noch mit einem spezifischen TLS-Stack?\" Jetzt pr\u00e4sentieren wir ein weiteres Feature, das zeigt, wie n\u00fctzlich 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
\nFertig! Und keine weiteren Komplikationen n\u00f6tig. Das funktioniert wirklich! <\/p>\n
\"Domain-Frontrunning
\n
\nDie Compiler-Flags \u2013w und \u2013s sind notwendig, um \u00fcberfl\u00fcssigen Ballast aus der ausf\u00fchrbaren Datei zu entfernen und sie um ein paar Megabyte zu verkleinern. Zus\u00e4tzlich kann sie sp\u00e4ter mit UPX gepackt werden, um die Gr\u00f6\u00dfe weiter zu reduzieren.<\/p>\n
Zum Abschluss<\/h3>\n
\nIn diesem Artikel haben wir am Beispiel des in Go geschriebenen Tunnelers die Anwendung der neuen Domain-Fronting-Technologie veranschaulicht, die auf einem recht interessanten Merkmal des TLS 1.3-Protokolls basiert. \u00c4hnlich kann das bestehende Werkzeug, das in Go geschrieben wurde, f\u00fcr die Arbeit \u00fcber CloudFlare-Server angepasst werden, zum Beispiel Merlin<\/a><\/noindex> \u2014 ein bekannter C2, oder lassen Sie CobaltStrike Beacon eSNI-Domain-Fronting bei der Arbeit mit dem Teamserver \u00fcber External C2 Channel<\/a><\/noindex>, realisiert in Go, oder auf Standard-C++ mit einer gepatchten Version von OpenSSL, \u00fcber die wir im vorherigen Teil des Artikels gesprochen haben. Kurz gesagt, der Fantasie sind keine Grenzen gesetzt.<\/p>\n
Das Beispiel mit dem Tunneler und CloudFlare wird als Konzept pr\u00e4sentiert und es ist momentan schwer zu sagen, welche Perspektiven diese Art von Domain-Fronting bieten k\u00f6nnte. Derzeit wird eSNI nur von CloudFlare unterst\u00fctzt und theoretisch gibt es nichts, was sie daran hindern k\u00f6nnte, solch ein Fronting abzuschalten und beispielsweise TLS-Verbindungen bei Nicht\u00fcbereinstimmung von SNI und eSNI zu trennen. Die Zukunft wird es zeigen. Aber momentan sieht die Perspektive, \u201eunter dem Deckmantel von kremlin.ru\u201c zu arbeiten, ziemlich verlockend aus. Oder nicht?<\/p>\n
Der aktualisierte Tunnelcode sowie die kompilierte ausf\u00fchrbare exe-Dateien sind in einem separaten Branch des Projekts auf github<\/a><\/noindex>. Bei m\u00f6glichen Problemen mit dem Tunnel ist es besser, ein Issue auf der Projektseite auf GitHub zu schreiben.
\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":"Einleitung Im ersten Teil des Artikels haben wir eine kurze Beschreibung des Mechanismus des encrypted SNI (eSNI) gegeben.","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).","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}