%3F.png)
Hintergrund
IETF RFC 9460definiert SVCB
einen HTTPS
DNS-Ressourceneintrag (RR), der zum Upgrade von Verbindungen auf HTTPS verwendet werden kann und auch die unterstützten Anwendungsschichtprotokolle (ALPN) angibt.
Am 7. September 2021 wurde Firefox 92 veröffentlicht, dasUnterstützung für HTTPS RR hinzugefügt:
Firefox aktualisiert eine HTTP-Anfrage automatisch auf HTTPS, wenn ein verwendbarer HTTPS-RR verfügbar ist. Außerdem werden die in einem HTTPS-RR enthaltenen Informationen verwendet, um den Prozess der Herstellung von HTTPS-Verbindungen zu optimieren. Dies ist konzeptionell ähnlich der Verwendung des Alt-Svc-Headers. (Firefox-Fehler 1721132).
Prüfen
Ich versuche, dies mit zu testen www.google.com
.
Zuerst habe ich versucht herauszufinden, ob es ein HTTPS
RR gibt:
$ dig 8.8.8.8 www.google.com HTTPS
...
;; ANSWER SECTION:
www.google.com. 3358 IN HTTPS 1 . alpn="h2,h3"
Hier sehen wir, dass das HTTPS
RR vorhanden ist, und wir stellen fest, dass HTTP/3 ein unterstütztes Protokoll ist, was durch den h3
Wert des alpn
Parameters angezeigt wird.
Als nächstes habe ich versucht, den DNS-Cache meines Betriebssystems zu leeren. Unter Windows habe ich beispielsweise ausgeführt ipconfig /flushdns
. Dies habe ich auch direkt vor dem Drücken der Eingabetaste in der Adressleiste ausgeführt, da Firefox und Chrome (oder ein anderer Prozess) auf einem der Systeme, mit denen ich getestet habe, häufig versuchen, google.com zu erreichen.
Habe Firefox v120 geöffnet und versucht, Folgendes zu besuchen: www.google.com
.
Problem
Obwohl in der Version 92 von Firefox v120 angegeben wird, dass zum Upgrade und zur Optimierung ein HTTPS RR verwendet wird, scheint dies nicht erforderlich zu sein.
Wireshark zeigt, dass nur A
und AAAA
RR abgefragt werden:
Und man kann sehen, dass Firefox aufgrund des Alt-Svc
Headers zunächst eine HTTP/2-Verbindung öffnet, bevor er zu HTTP/3 wechselt:
Tatsächlich scheint es auf mehreren Websites keine Desktop-Anwendung (Chrome, IceCat, Edge usw.) zu geben, die HTTPS
überhaupt nach dem RR fragt, denn wenn ich nach dns.qry.type == "HTTPS"
oder dns.qry.type == 65
auf WireShark filtere, erhalte ich keine Treffer. Ich erhalte nur Treffer, wenn ich explizit eine Suche über durchführe dig
.
Frage
Warum scheint es, dass der HTTPS
RR nie abgefragt wird?
Um das Problem zu verstehen, stelle ich auch die folgenden Leitfragen, die bei der Suche nach der Grundursache hilfreich sein könnten:
- Ist dies eine Funktion, die standardmäßig deaktiviert ist?
- Hängt dies von der Hostkonfiguration ab (außer der Einrichtung des
HTTPS
RR)? Keine der von mir gelesenen Ressourcen wies darauf hin, dass zusätzliche Schritte erforderlich sind. - Wer ist dafür verantwortlich, den RR anzufordern
HTTPS
? Der Browser oder das Betriebssystem? Bisher habe ich es mit aktualisierten Versionen von Guix System 1.4, Windows 10 und Windows 11 und allen oben genannten Browsern versucht. - Ist das hardwareabhängig?
Antwort1
Ich denke, das ist ein Windows-bezogenes Problem, da nslookup keine HTTPS-Lookups unterstützt und intern in Win32 verwendet wird. Ich denke, die Browser sind von den Win32-Funktionen abhängig. Wenn ich es auf Safari Chrome oder Firefox auf meinem iPhone teste, funktioniert es perfekt.