{"id":52639,"date":"2019-11-13T00:00:00","date_gmt":"2019-11-12T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/domen-fronting-na-baze-tls-1-3"},"modified":"2026-05-20T19:54:20","modified_gmt":"2026-05-20T17:54:20","slug":"domen-fronting-na-baze-tls-1-3","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3","title":{"rendered":"TLS 1.3 basiertes Domain-Fronting","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h3>\n

\"TLS
\nModerne Unternehmenssysteme zur Filterung von Inhalten, von renommierten Herstellern wie Cisco, BlueCoat, FireEye, haben viele Gemeinsamkeiten mit ihren leistungsst\u00e4rkeren Br\u00fcdern \u2013 den DPI-Systemen, die auf nationaler Ebene intensiv implementiert werden. Der Kern beider Systeme besteht darin, den eingehenden und ausgehenden Internetverkehr zu \u00fcberwachen und basierend auf schwarzen und wei\u00dfen Listen Entscheidungen \u00fcber das Verbot von Internetverbindungen zu treffen. Da beide Systeme in ihren Grundlagen auf \u00e4hnlichen Prinzipien basieren, werden auch die Umgehungsmethoden viele Gemeinsamkeiten aufweisen.<\/p>\n

Eine der Technologien, die es erm\u00f6glicht, sowohl DPI- als auch Unternehmenssysteme effektiv zu umgehen, ist die Technologie des Domain-Fronting. Das Prinzip besteht darin, auf eine blockierte Ressource zuzugreifen, indem man sich hinter einer anderen, \u00f6ffentlich zug\u00e4nglichen Dom\u00e4ne mit einem guten Ruf verbirgt, die mit Sicherheit von keinem System blockiert wird, wie zum Beispiel google.com.<\/p>\n

Zu dieser Technologie wurden bereits viele Artikel verfasst und Beispiele angef\u00fchrt. Allerdings erm\u00f6glichen die in letzter Zeit viel diskutierten Technologien DNS-over-HTTPS und encrypted-SNI sowie die neue Version des TLS 1.3-Protokolls, einen weiteren Aspekt des Domain-Fronting zu betrachten.
\n<\/a><\/p>\n

Wir kl\u00e4ren die Technologie<\/h3>\n

Zun\u00e4chst sollten wir einige grundlegende Begriffe kl\u00e4ren, damit jeder versteht, wer wer ist und warum das alles wichtig ist. Wir haben den Mechanismus eSNI erw\u00e4hnt, dessen Funktionsweise im Folgenden behandelt wird. Der Mechanismus eSNI (encrypted Server Name Indication) ist eine gesicherte Variante von SNI, die nur f\u00fcr das TLS 1.3-Protokoll verf\u00fcgbar ist. Das Hauptziel besteht darin, unter anderem Informationen dar\u00fcber zu verschl\u00fcsseln, an welche Domain die Anfrage gesendet wird.<\/p>\n

Lassen Sie uns nun die Funktionsweise des eSNI-Mechanismus in der Praxis betrachten.<\/p>\n

Angenommen, wir haben eine Internet-Ressource, die von einer modernen DPI-L\u00f6sung blockiert wird (nehmen wir beispielsweise den ber\u00fchmten Torrent-Tracker \u2014 rutracker.nl). Beim Versuch, auf die Website des Torrent-Trackers zuzugreifen, sehen wir die standardm\u00e4\u00dfige Meldung des Anbieters, dass die Ressource blockiert ist:<\/p>\n

\"TLS<\/p>\n

Auf der Website der RK\u041d ist diese Domain tats\u00e4chlich auf den Sperrlisten vermerkt:<\/p>\n

\"TLS<\/p>\n

Bei einer Whois-Abfrage ist zu sehen, dass die Domain hinter dem Cloud-Anbieter Cloudflare \"verborgen\" ist.<\/p>\n

\"TLS<\/p>\n

Im Gegensatz zu den \"Spezialisten\" aus dem RKN haben die technisch versierten Mitarbeiter von Beeline (oder die durch die bittere Erfahrung unseres ber\u00fchmten Regulators belehrt wurden) die Website nicht einfach nach der IP-Adresse gesperrt, sondern sie haben gezielt das Domainnamen<\/a>auf die Sperrliste gesetzt. Das l\u00e4sst sich leicht \u00fcberpr\u00fcfen, indem man schaut, welche anderen Domains hinter derselben IP-Adresse<\/a>versteckt sind, eine davon besucht und sieht, dass der Zugang nicht blockiert ist:<\/p>\n

\"TLS<\/p>\n

Wie kann das sein? Wie erkennt das DPI des Anbieters, auf welche der Domains mein Browser zugreift, wenn all die Kommunikation \u00fcber das Protokoll https erfolgt, und wir bisher keine Zertifikats\u00e4nderungen von Beeline bemerkt haben? Ist er etwa Hellseher oder werde ich etwa \u00fcberwacht?<\/p>\n

Lass uns versuchen, diese Frage zu beantworten, indem wir den Verkehr mit Wireshark analysieren.<\/p>\n

\"TLS<\/p>\n

Auf dem Screenshot sieht man, dass der Browser zun\u00e4chst die IP-Adresse des Servers \u00fcber DNS abrufen muss, dann erfolgt das Standard-TCP-Handschlag mit dem Zielserver, und anschlie\u00dfend versucht der Browser, eine SSL-Verbindung mit dem Server herzustellen. Daf\u00fcr sendet er ein Paket. SSL<\/a> Client Hello, der den urspr\u00fcnglichen Domainnamen im Klartext enth\u00e4lt. Dieses Feld ist f\u00fcr den Frontend-Server von Cloudflare erforderlich, um die Verbindung korrekt zu routen. Hier ger\u00e4t uns der Anbieter-DPI in die Quere und trennt unsere Verbindung. Dabei erhalten wir keinerlei Fehlermeldung vom Anbieter und sehen einfach den Standardfehler des Browsers, als ob die Website abgeschaltet oder nicht erreichbar ist:<\/p>\n

\"TLS<\/p>\n

Jetzt aktivieren wir den eSNI-Mechanismus im Browser, wie in der Anleitung f\u00fcr Firefox <\/a>:
\nDazu \u00f6ffnen wir die Konfigurationsseite von Firefox about:config<\/b> und aktivieren die folgenden Einstellungen:<\/p>\n

network.trr.mode = 2;\nnetwork.trr.uri = https:\/\/mozilla.cloudflare-dns.com\/dns-query\nnetwork.security.esni.enabled = true\n<\/code><\/pre>\n
Anschlie\u00dfend \u00fcberpr\u00fcfen wir die Funktionalit\u00e4t der Einstellungen auf der Cloudflare-Seite \u00fcber \u00fcber diesen Link verf\u00fcgbar<\/a> und versuchen noch einmal, unser Torrent-Tracker-Trick anzuwenden.<\/p>\n
\"TLS<\/p>\n
Voil\u00e0. Unser bevorzugter Tracker ist ohne VPN und Proxy-Server zug\u00e4nglich. Lassen Sie uns nun den Datenstrom in Wireshark betrachten und sehen, was passiert ist.<\/p>\n
\"TLS<\/p>\n
In dieser Version enth\u00e4lt das SSL-Client-Hello-Paket nicht mehr explizit die Ziel-Domain. Stattdessen ist ein neues Feld - encrypted_server_name - im Paket vorhanden, das den Wert rutracker.nl enth\u00e4lt. Nur der Frontend-Server von Cloudflare kann dieses Feld entschl\u00fcsseln. Somit bleibt der DPI-Anbieter keine andere Wahl, als die H\u00e4nde in Unschuld zu waschen und diesen Datenverkehr zuzulassen. Alternativen zur Verschl\u00fcsselung gibt es nicht.<\/p>\n
Nun haben wir gesehen, wie die Technologie im Browser funktioniert. Lass uns versuchen, sie f\u00fcr spezifischere und interessante Anwendungen zu nutzen. Zun\u00e4chst werden wir lernen, wie man mit Curl eSNI f\u00fcr die Arbeit mit TLS 1.3 anwendet und gleichzeitig betrachten, wie Domain-Fronting auf Basis von eSNI funktioniert.<\/p>\n
Domain-Fronting mit eSNI<\/h3>\n
Da Curl f\u00fcr die Verbindung \u00fcber das HTTPS-Protokoll die Standardbibliothek OpenSSL verwendet, m\u00fcssen wir zun\u00e4chst die Unterst\u00fctzung f\u00fcr eSNI dort sicherstellen. In den Master-Branches von OpenSSL gibt es derzeit keine Unterst\u00fctzung f\u00fcr eSNI, daher m\u00fcssen wir einen speziellen Branch von OpenSSL herunterladen, kompilieren und installieren.<\/p>\n
Wir klonen das Repository von GitHub und kompilieren es wie gewohnt:<\/p>\n
$ git clone https:\/\/github.com\/sftcd\/openssl\n$ cd openssl\n$ .\/config\n\n$ make\n$ cd esnistuff\n$ make\n<\/code><\/pre>\n
Als n\u00e4chstes klonen wir das Repository mit curl und konfigurieren dessen Kompilierung unter Verwendung unserer zusammengestellten OpenSSL-Bibliothek:<\/p>\n
$ cd $HOME\/code\n$ git clone https:\/\/github.com\/niallor\/curl.git curl-esni\n$ cd curl-esni\n\n$ export LD_LIBRARY_PATH=\/opt\/openssl\n$ .\/buildconf\n$ LDFLAGS=\"-L\/opt\/openssl\" .\/configure --with-ssl=\/opt\/openssl --enable-esni --enable-debug\n<\/code><\/pre>\n
Hier ist es wichtig, alle Verzeichnisse, in denen OpenSSL zu finden ist (in unserem Fall \/opt\/openssl\/), korrekt anzugeben und sicherzustellen, dass der Konfigurationsprozess fehlerfrei verl\u00e4uft.<\/p>\n
Bei erfolgreicher Konfiguration sehen wir die Zeile:<\/p>\n
WARNING: esni ESNI enabled but marked EXPERIMENTAL. Use with caution!<\/b><\/p>\n
$ make<\/code><\/pre>\n
Nach erfolgreicher Erstellung des Pakets verwenden wir eine spezielle Bash-Datei aus dem Lieferumfang von OpenSSL zur Konfiguration und Ausf\u00fchrung von curl. Wir kopieren sie zur besseren Handhabung in das Verzeichnis von curl:<\/p>\n
cp \/opt\/openssl\/esnistuff\/curl-esni <\/code><\/pre>\n
und f\u00fchren eine Test-HTTPS-Anfrage an den Cloudflare-Server durch, w\u00e4hrend wir gleichzeitig DNS- und TLS-Pakete in Wireshark aufzeichnen.<\/p>\n
$ ESNI_COVER=\"www.hello-rkn.ru\" .\/curl-esni https:\/\/cloudflare.com\/<\/code><\/pre>\n
Im Serverantwort erhalten wir neben vielen Debug-Informationen von OpenSSL und curl eine HTTP-Antwort mit dem Statuscode 301 von Cloudflare.<\/p>\n
HTTP\/1.1 301 Moved Permanently\n< Date: Sun, 03 Nov 2019 13:12:55 GMT\n< Transfer-Encoding: chunked\n< Connection: keep-alive\n< Cache-Control: max-age=3600\n< Expires: Sun, 03 Nov 2019 14:12:55 GMT\n< Location: https:\/\/www.cloudflare.com\/\n<\/code><\/pre>\n
was darauf hinweist, dass unsere Anfrage erfolgreich an den Zielserver \u00fcbermittelt, empfangen und bearbeitet wurde.<\/p>\n
Schauen wir uns nun den Verkehrs-Dump in Wireshark an, also das, was in diesem Fall der Provider-DPI gesehen hat.<\/p>\n
\"TLS<\/p>\n
Man sieht, dass curl zuerst den DNS-Server nach dem \u00f6ffentlichen eSNI-Schl\u00fcssel f\u00fcr den Cloudflare-Server angefragt hat \u2013 eine TXT-DNS-Anfrage an _esni.cloudflare.com (Paket Nr. 13). Danach hat curl unter Verwendung der OpenSSL-Bibliothek eine TLS 1.3-Anfrage an den Cloudflare-Server gesendet, in der das SNI-Feld mit dem zuvor erhaltenen \u00f6ffentlichen Schl\u00fcssel verschl\u00fcsselt war (Paket Nr. 22). Zus\u00e4tzlich zum eSNI-Feld wurde im SSL-hello-Paket auch ein Feld mit dem normalen \u2013 unverschl\u00fcsselten SNI eingef\u00fcgt, das wir in beliebiger Reihenfolge angeben k\u00f6nnen (in diesem Fall \u2013 www.hello-rkn.ru<\/a>). <\/b><\/p>\n
Dieses Feld des unverschl\u00fcsselten SNI wurde bei der Verarbeitung durch die Cloudflare-Server nicht ber\u00fccksichtigt und diente lediglich der Tarnung f\u00fcr den Provider-DPI. Der Cloudflare-Server hat unser SSL-hello-Paket angenommen, das eSNI entschl\u00fcsselt, den urspr\u00fcnglichen SNI extrahiert und ihn wie vorgesehen bearbeitet (so wie es bei der Entwicklung des eSNI geplant war).<\/p>\n
Das Einzige, was in diesem Fall aus Sicht von DPI relevant ist, ist die prim\u00e4re DNS-Anfrage an _esni.cloudflare.com. Wir haben die DNS-Anfrage jedoch nur offengelegt, um zu zeigen, wie dieser Mechanismus im Hintergrund funktioniert.<\/p>\n
Um der DPI endg\u00fcltig die Grundlage zu entziehen, verwenden wir das bereits erw\u00e4hnte Verfahren DNS-over-HTTPS. Eine kurze Erkl\u00e4rung \u2013 DOH ist ein Protokoll, das Schutz vor der \"Man-in-the-Middle\"-Attacke bietet, indem es die DNS-Anfrage \u00fcber das HTTPS-Protokoll sendet.<\/p>\n
Wir f\u00fchren die Anfrage erneut aus, allerdings erhalten wir diesmal die \u00f6ffentlichen eSNI-Schl\u00fcssel \u00fcber das https-Protokoll und nicht \u00fcber DNS:<\/p>\n
ESNI_COVER=\"www.hello-rkn.ru\" DOH_URL=https:\/\/mozilla.cloudflare-dns.com\/dns-query .\/curl-esni https:\/\/cloudflare.com\/<\/code><\/pre>\n
Der Traffic-Dump der Anfrage ist im Screenshot unten dargestellt:<\/p>\n
\"TLS<\/p>\n
Es ist zu erkennen, dass curl zun\u00e4chst den Server mozilla.cloudflare-dns.com \u00fcber das DoH-Protokoll aufruft (HTTPS-Verbindung zum Server 104.16.249.249), um von dort die Werte der \u00f6ffentlichen Schl\u00fcssel f\u00fcr die Verschl\u00fcsselung von SNI zu erhalten, und anschlie\u00dfend den Zielserver ansteuert, w\u00e4hrend er sich hinter der Domain versteckt. www.hello-rkn.ru<\/a>.<\/p>\n
Neben dem oben genannten DoH-Resolver mozilla.cloudflare-dns.com k\u00f6nnen wir auch andere beliebte DoH-Dienste nutzen, zum Beispiel von der ber\u00fcchtigten b\u00f6sen Corporation.
\nWir f\u00fchren eine solche Anfrage durch:<\/p>\n
ESNI_COVER=\"www.kremlin.ru\" DOH_URL=https:\/\/dns.google\/dns-query .\/curl-esni https:\/\/rutracker.nl\/<\/code><\/pre>\n
Und wir erhalten die Antwort:<\/p>\n
< HTTP\/1.1 301 Permanently Moved\n< Date: Sun, 03 Nov 2019 14:10:22 GMT\n< Content-Type: text\/html\n< Transfer-Encoding: chunked\n< Connection: keep-alive\n< Set-Cookie: __cfduid=da0144d982437e77b0b37af7d00438b1a1572790222; expires=Mon, 02-Nov-20 14:10:22 GMT; path=\/; domain=.rutracker.nl; HttpOnly; Secure\n< Location: https:\/\/rutracker.nl\/forum\/index.php\n< CF-Cache-Status: DYNAMIC\n< Expect-CT: max-age=604800, report-uri="https:\/\/report-uri.cloudflare.com\/cdn-cgi\/beacon\/expect-ct"\n< Server: cloudflare\n< CF-RAY: 52feee696f42d891-CPH\n<\/code><\/pre>\n
\"TLS<\/p>\n
In diesem Fall haben wir einen blockierten Server rutracker.nl erreicht, wobei wir den DoH-Resolver dns.google verwendet haben (keine Schreibfehler, das ber\u00fchmte Unternehmen hat jetzt eine eigene Top-Level-Domain) und uns mit einer anderen Domain gedeckt haben, deren Blockierung jeglichem DPI unter Androhung der Todesstrafe strikt untersagt ist. Anhand der erhaltenen Antwort kann man erkennen, dass unsere Anfrage erfolgreich bearbeitet wurde.<\/p>\n
Zur zus\u00e4tzlichen \u00dcberpr\u00fcfung, dass der Provider-DPI auf das offene SNI reagiert, das wir als Deckung \u00fcbermitteln \u2014 k\u00f6nnen wir eine Anfrage an rutracker.nl senden, indem wir uns mit einer anderen verbotenen Ressource, beispielsweise einem weiteren \u201aguten\u2018 Torrent-Tracker, verstecken:<\/p>\n
$ ESNI_COVER=\"rutor.info\" DOH_URL=https:\/\/dns.google\/dns-query .\/curl-esni https:\/\/rutracker.nl\/<\/code><\/pre>\n
Eine Antwort vom Server erhalten wir nicht, da unsere Anfrage von dem DPI-System blockiert wird.<\/p>\n
Eine kleine Zusammenfassung zum ersten Teil<\/h3>\n
Wir konnten die Funktionalit\u00e4t von eSNI mit openssl und curl demonstrieren und die Funktionsweise des Domain-Fronting auf Basis von eSNI \u00fcberpr\u00fcfen. Ebenso k\u00f6nnen wir unsere bevorzugten Tools, die die OpenSSL-Bibliothek verwenden, anpassen, um 'unter dem Deckmantel' anderer Domains zu arbeiten. Mehr dazu in unseren n\u00e4chsten Artikeln.<\/p>\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 \u0421\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0444\u0438\u043b\u044c\u0442\u0440\u0430\u0446\u0438\u0438 \u043a\u043e\u043d\u0442\u0435\u043d\u0442\u0430, \u043e\u0442 \u0442\u0430\u043a\u0438\u0445 \u0438\u043c\u0435\u043d\u0438\u0442\u044b\u0445 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u043a Cisco, BlueCoat, FireEye \u0438\u043c\u0435\u044e\u0442 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0431\u043e\u043b\u0435\u0435 \u043c\u043e\u0449\u043d\u044b\u043c\u0438 \u0438\u0445 \u0441\u043e\u0431\u0440\u0430\u0442\u044c\u044f\u043c\u0438 \u2014 DPI \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0443\u0441\u0438\u043b\u0435\u043d\u043d\u043e \u0432\u043d\u0435\u0434\u0440\u044f\u044e\u0442\u0441\u044f \u043d\u0430 \u043d\u0430\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u043c \u0443\u0440\u043e\u0432\u043d\u0435. \u0421\u0443\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u0438 \u0442\u0435\u0445 \u0438 \u0434\u0440\u0443\u0433\u0438\u0445 \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e\u0431\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u044c \u0434\u043e\u0441\u043c\u043e\u0442\u0440 \u0432\u0445\u043e\u0434\u044f\u0449\u0435\u0433\u043e \u0438 \u0438\u0441\u0445\u043e\u0434\u044f\u0449\u0435\u0433\u043e \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0438, \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0447\u0435\u0440\u043d\u044b\u0445\/\u0431\u0435\u043b\u044b\u0445 \u0441\u043f\u0438\u0441\u043a\u043e\u0432, \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u0442\u044c \u0440\u0435\u0448\u0435\u043d\u0438\u0435 […]<\/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-52639","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 basierend auf TLS 1.3 | ProHoster","description":"Einf\u00fchrung Moderne Unternehmenssysteme zur Inhaltsfilterung, von renommierten Herstellern wie Cisco, BlueCoat und FireEye, teilen viele Gemeinsamkeiten mit ihren leistungsst\u00e4rkeren Gegenst\u00fccken \u2013 den DPI-Systemen, die intensiv auf nationaler Ebene implementiert werden. Das Ziel beider Systeme besteht darin, den ein- und ausgehenden Internetverkehr zu \u00fcberwachen und auf Grundlage von schwarz\/wei\u00df-Listen Entscheidungen zu treffen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3","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 | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0421\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u044b\u0435 \u043a\u043e\u0440\u043f\u043e\u0440\u0430\u0442\u0438\u0432\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u0444\u0438\u043b\u044c\u0442\u0440\u0430\u0446\u0438\u0438 \u043a\u043e\u043d\u0442\u0435\u043d\u0442\u0430, \u043e\u0442 \u0442\u0430\u043a\u0438\u0445 \u0438\u043c\u0435\u043d\u0438\u0442\u044b\u0445 \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u0435\u0439 \u043a\u0430\u043a Cisco, BlueCoat, FireEye \u0438\u043c\u0435\u044e\u0442 \u0434\u043e\u0432\u043e\u043b\u044c\u043d\u043e \u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0449\u0435\u0433\u043e \u0441 \u0431\u043e\u043b\u0435\u0435 \u043c\u043e\u0449\u043d\u044b\u043c\u0438 \u0438\u0445 \u0441\u043e\u0431\u0440\u0430\u0442\u044c\u044f\u043c\u0438 \u2014 DPI \u0441\u0438\u0441\u0442\u0435\u043c\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0443\u0441\u0438\u043b\u0435\u043d\u043d\u043e \u0432\u043d\u0435\u0434\u0440\u044f\u044e\u0442\u0441\u044f \u043d\u0430 \u043d\u0430\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u043c \u0443\u0440\u043e\u0432\u043d\u0435. \u0421\u0443\u0442\u044c \u0440\u0430\u0431\u043e\u0442\u044b \u0438 \u0442\u0435\u0445 \u0438 \u0434\u0440\u0443\u0433\u0438\u0445 \u0432 \u0442\u043e\u043c, \u0447\u0442\u043e\u0431\u044b \u043f\u0440\u043e\u0438\u0437\u0432\u043e\u0434\u0438\u0442\u044c \u0434\u043e\u0441\u043c\u043e\u0442\u0440 \u0432\u0445\u043e\u0434\u044f\u0449\u0435\u0433\u043e \u0438 \u0438\u0441\u0445\u043e\u0434\u044f\u0449\u0435\u0433\u043e \u0438\u043d\u0442\u0435\u0440\u043d\u0435\u0442 \u0442\u0440\u0430\u0444\u0438\u043a\u0430 \u0438, \u043d\u0430 \u043e\u0441\u043d\u043e\u0432\u0430\u043d\u0438\u0438 \u0447\u0435\u0440\u043d\u044b\u0445\/\u0431\u0435\u043b\u044b\u0445 \u0441\u043f\u0438\u0441\u043a\u043e\u0432, \u043f\u0440\u0438\u043d\u0438\u043c\u0430\u0442\u044c \u0440\u0435\u0448\u0435\u043d\u0438\u0435","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/domen-fronting-na-baze-tls-1-3","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-12T21:00:00+00:00","article:modified_time":"2026-05-20T17:54:20+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"52639","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 04:19:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-02-28 20:39:27","updated":"2026-01-24 04:19:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52639","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=52639"}],"version-history":[{"count":3,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52639\/revisions"}],"predecessor-version":[{"id":173323,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/52639\/revisions\/173323"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=52639"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=52639"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=52639"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}