Die .dev-Domain von Google leitet seltsamerweise zu https weiter

19

Ich habe heute @ domains.google eine .dev-Domain gekauft. Ich habe auch einen dedizierten Nginx-Webserver eingerichtet, auf den die .dev-Domain verweist (A-Einträge).

Sehr seltsamerweise kann ich mit meiner example.devDomain nicht auf meine Nginx-Willkommensseite zugreifen , da ich aus irgendeinem seltsamen Grund zu dieser umgeleitet werde, https://example.devwas dann fehlschlägt (es kann keine Verbindung zu meinem http-Webserver hergestellt werden). Jede andere Domäne, die auf diesen neuen Server verweist, funktioniert jedoch ordnungsgemäß. Wie example.comeinfach funktioniert. Ich habe NICHTS über Nginx konfiguriert, habe es nur installiert (die Demo-Konfiguration erledigt den Job). Dies hat offensichtlich etwas mit Google als Registrar zu tun. OK - also werde ich den Google-Support kontaktieren, oder? Ja. Ich habe das getan, aber sie sagten mir, dass ich das auf meiner Seite erledigen musste und meinten immer "Kontakt zu Ihrem Webhost" (was kein allzu großer Rat ist, da ich der Host bin).

Ich habe alles in der Google-Konsole ausprobiert, kann es aber nicht zum Laufen bringen. Der Google-Support war sehr, sehr enttäuschend und ich hoffe jetzt auf eine Lösung für dieses Problem.

Johnny
quelle

Antworten:

44

.devDomains sind nur HTTPS. Es ist keine Umleitung. Es ist HSTS-Vorspannung.

HSTS ist eine Technologie, mit der Domänen deklarieren können, dass sie nur HTTPS sind. Es ist dazu gedacht, Angriffe auf Protokoll-Downgrades abzuwehren. Wenn Sie zum ersten Mal eine Site besuchen, die HSTS verwenden möchte, erhalten Sie einen Header, der Sie daran hindert, diese Domain jemals über HTTP zu besuchen.

Die HSTS-Vorladeliste ist in Webbrowsern integriert, sodass der Browser bereits vor dem ersten Besuch weiß, dass es sich bei einer Site nur um HTTPS handelt. Wenn sich eine Site in der HSTS-Vorladeliste befindet, kann in diesem Browser niemals über HTTP auf sie zugegriffen werden, sondern nur über HTTPS.

Google hat die gesamte .devTop-Level-Domain auf die HSTS-Preload-Liste gesetzt . Das bedeutet, dass keine .devDomain jemals als HTTP-Site ausgeführt werden kann.

Als Sie Ihre .devDomain registriert haben, hat Ihnen die Google-Registrierung dies auf der Startseite im Abschnitt "Sicherheitsvorteile" mitgeteilt:

Lassen Sie sich in Sicherheit einbinden

Ihre Sicherheit ist unsere Priorität. Die .dev-Top-Level-Domain ist in der HSTS-Pre-Load-Liste enthalten, sodass HTTPS für alle Verbindungen zu .dev-Websites und -Seiten erforderlich ist, ohne dass eine individuelle HSTS-Registrierung oder -Konfiguration erforderlich ist. Sicherheit ist eingebaut.

Derzeit unterstützen nur Firefox und Chrome dieses HSTS-Preload. Wenn Sie Ihre Site testen möchten, bevor Sie HTTPS eingerichtet haben, können Sie einen anderen Browser verwenden. Möglicherweise können Sie auch die Einstellungen Ihres Browsers ändern, um HSTS zu deaktivieren .

Aufgrund der HSTS-Vorlast müssen Sie Ihre .devDomain auf einem HTTPS-Server ausführen , damit Benutzer darauf zugreifen können.

Stephen Ostermiller
quelle
2
Das ist es. Ich muss diese Information verpasst haben, und das Support-Team würde mich nicht noch einmal daran erinnern (obwohl ich denke, dass es ziemlich offensichtlich ist, dass ich genau diese Information verpasst habe).
Johnny
8
Ja, der Support hätte Ihnen dies mitteilen können.
Stephen Ostermiller
4
@ Johnny Übrigens, das könnte Sie interessieren Let's Encrypt: letsencrypt.org
Ave
1
Eine andere von Google erstellte TLD .appist ebenfalls ein reiner HTTPS-Namespace. In acht nehmen.
Alex Jone
4
Für dev-Domänen sind die beiden reservierten Domänen * .test und * .localhost. Sie sind vollständig reserviert und werden daher niemals als echte TLDs übernommen. * .localhost ist eigentlich sehr praktisch, wenn Sie localhost testen, da Sie mehrere Dienste wie bei anderen TLDs verwenden können und es weiterhin 127.0.0.1 zugeordnet ist. * .test ist für DNS-bezogene Inhalte gedacht. Wenn Sie also IPs von virtuellen Maschinen oder Ähnlichem zuordnen müssen, sind Sie hier richtig. In letzter Zeit war ich ein großer Fan von * .localhost mit Docker-Containern, da ich den Reverse-Proxy sowieso 127.0.0.1 zugeordnet habe. Benötigt keine lokalen DNS oder / etc / hosts shenanigans.
Superlinkx