{"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":"Domain Fronting auf Basis von TLS 1.3","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Einf\u00fchrung<\/h3>\n

\"Domain
\nModerne Unternehmenssysteme zur Inhaltsfilterung, von namhaften Herstellern wie Cisco, BlueCoat, FireEye, weisen viele \u00c4hnlichkeiten mit ihren leistungsst\u00e4rkeren Verwandten auf \u2013 den DPI-Systemen, die auf nationaler Ebene intensiv implementiert werden. Das wesentliche Ziel beider Systeme ist es, den ein- und ausgehenden Internetverkehr zu kontrollieren und auf Grundlage von Schwarz-\/Wei\u00dflisten Entscheidungen \u00fcber die Blockierung von Internetverbindungen zu treffen. Da beide Systeme in ihren Grundprinzipien \u00e4hnlich arbeiten, werden auch die Methoden, sie zu umgehen, viele Gemeinsamkeiten aufweisen.<\/p>\n

Eine der Technologien, die es erm\u00f6glicht, sowohl DPI- als auch Unternehmenssysteme relativ effektiv zu umgehen, ist die Technologie des Domain Fronting. Dabei greifen wir auf eine blockierte Ressource zu, indem wir uns hinter einer anderen, \u00f6ffentlich zug\u00e4nglichen Domain mit gutem Ruf verbergen, die sicher nicht von irgendeinem System blockiert wird, beispielsweise google.com.<\/p>\n

\u00dcber diese Technologie wurden bereits viele Artikel verfasst und zahlreiche Beispiele angef\u00fchrt. Dennoch erm\u00f6glichen beliebte und in letzter Zeit viel diskutierte Technologien wie DNS-over-HTTPS und encrypted-SNI sowie die neue Version des Protokolls TLS 1.3, eine weitere Variante des Domain Fronting zu betrachten.
\n<\/a><\/p>\n

Lassen Sie uns die Technologie n\u00e4her untersuchen.<\/h3>\n

Zun\u00e4chst sollten wir uns ein wenig mit den grundlegenden Begriffen befassen, damit jeder versteht, wer wer ist und warum das alles notwendig ist. Wir haben den Mechanismus eSNI erw\u00e4hnt, dessen Funktionsweise weiter unten erl\u00e4utert wird. Der Mechanismus eSNI (encrypted Server Name Indication) ist eine sichere Variante von SNI, die nur f\u00fcr das Protokoll TLS 1.3 verf\u00fcgbar ist. Das Hauptziel besteht darin, unter anderem Informationen dar\u00fcber zu verschl\u00fcsseln, an welche Domain die Anfragen gerichtet werden.<\/p>\n

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

Nehmen wir an, wir haben eine Internetressource, die durch eine moderne DPI-L\u00f6sung blockiert wird (nehmen wir zum Beispiel den ber\u00fchmten Torrent-Tracker \u2013 rutracker.nl). Beim Versuch, auf die Seite des Torrent-Trackers zuzugreifen, sehen wir das Standard-Banner des Anbieters, das anzeigt, dass die Ressource blockiert ist:<\/p>\n

\"Domain<\/p>\n

Auf der Website des RKN ist diese Domain tats\u00e4chlich in den Sperrlisten enthalten:<\/p>\n

\"Domain<\/p>\n

Bei einer whois-Anfrage ist zu erkennen, dass die Domain selbst hinter dem Cloud-Anbieter Cloudflare 'versteckt' ist.<\/p>\n

\"Domain<\/p>\n

Aber im Gegensatz zu den \"Spezialisten\" aus der RKN haben die technisch versierteren Mitarbeiter von Beeline (oder aufgrund der schlechten Erfahrung mit unserem ber\u00fchmten Regulierer) die Website nicht einfach nach der IP-Adresse gesperrt, sondern haben speziell den Domainnamen<\/a>. Das l\u00e4sst sich leicht \u00fcberpr\u00fcfen, wenn man sieht, welche anderen Domains sich hinter dieser IP-Adresse<\/a>verbergen, eine davon besucht und sieht, dass der Zugriff nicht blockiert ist:<\/p>\n

\"Domain<\/p>\n

Wie kommt es dazu? Wie erkennt der Provider-DPI, auf welcher Domain sich mein Browser befindet, obwohl alle Kommunikationen \u00fcber das Protokoll https laufen und wir bislang keine https-Zertifikats\u00e4nderungen von Beeline bemerkt haben? Ist er etwa ein Hellseher, oder werde ich \u00fcberwacht?<\/p>\n

Lassen Sie uns versuchen, diese Frage zu beantworten, indem wir den Verkehr \u00fcber Wireshark betrachten.<\/p>\n

\"Domain<\/p>\n

Auf dem Screenshot sieht man, dass der Browser zun\u00e4chst die IP-Adresse des Servers \u00fcber DNS erh\u00e4lt, dann findet ein Standard-TCP-Handshake mit dem Zielserver statt, und danach versucht der Browser, eine SSL-Verbindung mit dem Server herzustellen. Dazu sendet er ein Paket SSL<\/a> Client Hello, in dem der Name der urspr\u00fcnglichen Domain im Klartext enthalten ist. Dieses Feld ist f\u00fcr den Frontend-Server von Cloudflare notwendig, um die Verbindung richtig zu routen. Hier f\u00e4ngt uns der Provider-DPI und trennt unsere Verbindung. Dabei erhalten wir keine Fehlermeldung vom Provider, sondern sehen einen Standardfehler des Browsers, als ob die Seite nicht verf\u00fcgbar oder einfach nicht erreichbar ist:<\/p>\n

\"Domain<\/p>\n

Jetzt aktivieren wir den eSNI-Mechanismus im Browser, wie in den Anweisungen f\u00fcr Firefox <\/a>:
\nDas machen wir, indem wir die Konfigurationsseite von Firefox \u00f6ffnen about:config<\/b> und die folgenden Einstellungen aktivieren:<\/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 unter dem Link<\/a> und versuchen noch einmal den Trick mit unserem Torrent-Tracker.<\/p>\n
\"Domain<\/p>\n
Voil\u00e0. Unser beliebter Tracker \u00f6ffnete sich ohne VPN oder Proxy-Server. Lassen Sie uns nun den Datenverkehrsdump in Wireshark betrachten, um herauszufinden, was passiert ist.<\/p>\n
\"Domain<\/p>\n
Diesmal enth\u00e4lt das SSL-Client-Hello-Paket keinen expliziten Zielnamen, stattdessen gibt es ein neues Feld im Paket \u2013 encrypted_server_name \u2013 genau dort befindet sich der Wert rutracker.nl, und nur der Frontend-Server von Cloudflare kann dieses Feld entschl\u00fcsseln. Da das so ist, bleibt dem DPI-Anbieter nichts anderes \u00fcbrig, als sich die H\u00e4nde zu waschen und diesen Datenverkehr zuzulassen. Es gibt keine anderen Optionen f\u00fcr die Verschl\u00fcsselung.<\/p>\n
So funktioniert die Technologie im Browser \u2013 das haben wir gesehen. Jetzt versuchen wir, sie f\u00fcr spezifischere und interessantere Dinge anzuwenden. Zun\u00e4chst bringen wir curl bei, eSNI f\u00fcr die Arbeit mit TLS 1.3 zu verwenden, und schauen uns gleichzeitig an, wie das 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 sicherstellen, dass eSNI dort unterst\u00fctzt wird. In den Master-Branches von OpenSSL gibt es bisher keine Unterst\u00fctzung f\u00fcr eSNI, daher m\u00fcssen wir einen speziellen OpenSSL-Branch herunterladen, kompilieren und installieren.<\/p>\n
Wir klonen das Repository von GitHub und kompilieren 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
Anschlie\u00dfend klonen wir das Repository von curl und konfigurieren die Kompilierung unter Verwendung unserer kompilierten 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 korrekt anzugeben, in denen OpenSSL gefunden wird (in unserem Fall ist das \/opt\/openssl\/) und sicherzustellen, dass der Konfigurationsprozess fehlerfrei verl\u00e4uft.<\/p>\n
Im Falle einer erfolgreichen Konfiguration sehen wir die Zeile:<\/p>\n
WARNING: esni ESNI aktiviert, aber als EXPERIMENTAL gekennzeichnet. Mit Vorsicht verwenden!<\/b><\/p>\n
$ make<\/code><\/pre>\n
Nach erfolgreicher Erstellung des Pakets verwenden wir eine spezielle Bash-Datei aus dem OpenSSL-Set zur Konfiguration und zum Start von curl. Wir kopieren sie bequem 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 aus, w\u00e4hrend wir gleichzeitig DNS- und TLS-Pakete in Wireshark mitschneiden.<\/p>\n
$ ESNI_COVER=\"www.hello-rkn.ru\" .\/curl-esni https:\/\/cloudflare.com\/<\/code><\/pre>\n
Im Server-Antwort erhalten wir neben zahlreichen 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 hindeutet, dass unsere Anfrage erfolgreich an den Zielserver \u00fcbermittelt, geh\u00f6rt und bearbeitet wurde.<\/p>\n
Schauen wir uns nun den Datenverkehrsdump in Wireshark an, d.h. was der Anbieter-DPI in diesem Fall gesehen hat.<\/p>\n
\"Domain<\/p>\n
Es ist zu erkennen, dass curl zuerst den DNS-Server nach dem \u00f6ffentlichen eSNI-Schl\u00fcssel f\u00fcr den Cloudflare-Server anfragte \u2013 eine TXT-DNS-Abfrage an _esni.cloudflare.com (Paket Nr. 13). Dann, unter Verwendung der OpenSSL-Bibliothek, sendete curl eine TLS 1.3-Anfrage an den Cloudflare-Server, bei der das SNI-Feld mit dem \u00f6ffentlichen Schl\u00fcssel verschl\u00fcsselt wurde, der in der vorherigen Phase erhalten wurde (Paket Nr. 22). Aber neben dem eSNI-Feld wurde auch ein regul\u00e4res \u2013 offenes SNI-Feld in das SSL-Hello-Paket eingef\u00fcgt, das wir in beliebiger Reihenfolge angeben k\u00f6nnen (in diesem Fall \u2013 www.hello-rkn.ru<\/a>). <\/b><\/p>\n
Dieses offene SNI-Feld wurde bei der Verarbeitung durch die Cloudflare-Server nicht ber\u00fccksichtigt und diente lediglich als Tarnung f\u00fcr den Anbieter-DPI. Der Cloudflare-Server akzeptierte unser SSL-Hello-Paket, entschl\u00fcsselte eSNI, extrahierte das originale SNI und bearbeitete es, als w\u00e4re nichts geschehen (es wurde alles so gemacht, wie es bei der Entwicklung von eSNI geplant war).<\/p>\n
Das Einzige, woran sich der DPI in diesem Fall festhalten k\u00f6nnte, ist die urspr\u00fcngliche DNS-Anfrage an _esni.cloudflare.com. Aber wir haben die DNS-Anfrage offen gemacht, nur um zu zeigen, wie dieser Mechanismus von innen funktioniert.<\/p>\n
Um dem DPI endg\u00fcltig die Grundlage zu entziehen, verwenden wir den bereits erw\u00e4hnten Mechanismus DNS-over-HTTPS. Eine kurze Erl\u00e4uterung \u2013 DOH ist ein Protokoll, das es erm\u00f6glicht, sich vor der \u201eMan-in-the-Middle\u201c-Attacke zu sch\u00fctzen, indem der DNS-Anfrage \u00fcber das Protokoll HTTPS gesendet wird.<\/p>\n
Wir werden die Anfrage wiederholen, aber dieses Mal erhalten wir die \u00f6ffentlichen eSNI-Schl\u00fcssel \u00fcber das HTTPS-Protokoll, 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 Datenverkehrsdump der Anfrage ist im Screenshot unten dargestellt:<\/p>\n
\"Domain<\/p>\n
Es ist zu erkennen, dass curl zun\u00e4chst den Server mozilla.cloudflare-dns.com \u00fcber das DoH-Protokoll anfragt (HTTPS-Verbindung zum Server 104.16.249.249), um von ihnen die Werte der \u00f6ffentlichen Schl\u00fcssel zur Verschl\u00fcsselung des SNI zu erhalten, und dann bereits zum Zielserver, wobei er sich dabei 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\u00fchmten b\u00f6sen Corporation.
\nWir werden eine solche Anfrage ausf\u00fchren:<\/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 eine Antwort:<\/p>\n
< HTTP\/1.1 301 Moved Permanently\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
\"Domain<\/p>\n
In diesem Fall haben wir auf den gesperrten Server rutracker.nl zugegriffen, wobei wir den DoH-Resolver dns.google verwendet haben (es gibt hier keinen Schreibfehler, jetzt hat das ber\u00fchmte Unternehmen eine eigene Top-Level-Domain) und uns bereits hinter einer anderen Domain versteckt haben, deren Blockierung von allen DPI strikt untersagt ist, unter Androhung der Todesstrafe. Anhand der erhaltenen Antwort kann man erkennen, dass unsere Anfrage erfolgreich verarbeitet wurde.<\/p>\n
Als zus\u00e4tzliche \u00dcberpr\u00fcfung, dass der DPI des Providers auf den offenen SNI reagiert, den wir als Tarnung senden \u2014 k\u00f6nnen wir eine Anfrage an rutracker.nl stellen, indem wir uns hinter einer anderen, ebenfalls gesperrten Ressource verstecken, zum Beispiel einem weiteren 'guten' Torrent-Tracker:<\/p>\n
$ ESNI_COVER=\"rutor.info\" DOH_URL=https:\/\/dns.google\/dns-query .\/curl-esni https:\/\/rutracker.nl\/<\/code><\/pre>\n
Wir erhalten keine Antwort vom Server, da unsere Anfrage vom DPI-System blockiert wird.<\/p>\n
Eine kleine Schlussfolgerung zum ersten Teil<\/h3>\n
Wir haben also die Funktionsf\u00e4higkeit von eSNI mit Hilfe von openssl und curl demonstriert und die Funktion des Domain-Frontening basierend auf eSNI \u00fcberpr\u00fcft. Auf die gleiche Weise k\u00f6nnen wir unsere bevorzugten Werkzeuge, die die openssl-Bibliothek verwenden, anpassen, um unter der Tarnung anderer Domains zu arbeiten. Weitere Informationen dazu finden Sie 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 auf Basis von TLS 1.3 | ProHoster","description":"Einf\u00fchrung in moderne Unternehmensfiltersysteme.","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.","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","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\/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}]}}