Firefox und HTTP/2 Connection Coalescing

KB19 · 13. November 2023

Diese Diskussion fand ursprünglich im "Längsten Thema" statt. Danke an die Moderator:innen fürs Splitten in einen eigenen Thread!

--------------------------------------------------------------------------------

Ich glaube, ich habe gerade einen Bug in Firefox gefunden. Oder soll das wirklich so sein?

https://ip.example.net/ aufgerufen: Verbindung wird über IPv6 hergestellt.
https://ip4.example.net/ aufgerufen: Verbindung läuft weiterhin über IPv6?!

ip4 hat aber gar keinen AAAA-Record! (Genauso wie ip6 logischerweise keinen A-Record hat.)

ip hat natürlich A und AAAA-Records und alle drei Hostnamen sind mittels Wildcard im SAN des Zertifikats abgedeckt.

Chrome verhält sich übrigens korrekt und mischt hierbei nicht die Verbindungen.

[EDIT] Interessanter Lesestoff, wobei das nicht ganz mein Szenario beschreibt: https://bugzilla.mozilla.org/show_bug.cgi?id=1420777

H6G · 14. November 2023

Zitat von KB19

Ich glaube, ich habe gerade einen Bug in Firefox gefunden.

Bei perryflynn auf der Seite? Könnte ein KeepAlive der Verbindung sein, die nach IP geführt wird, und nicht nach DNS Name.

okay... das ist wirklich interessant.

Bildschirmfoto zu 2023-11-14 14-22-41.png

perryflynn · 14. November 2023

Zitat von H6G

Bei perryflynn auf der Seite? Könnte ein KeepAlive der Verbindung sein, die nach IP geführt wird, und nicht nach DNS Name.

Zitat von KB19

[EDIT] Interessanter Lesestoff, wobei das nicht ganz mein Szenario beschreibt

Ui, dass ist ja wirklich spannend.

KB19 · 14. November 2023

Zitat von H6G

Bei perryflynn auf der Seite?

Nein, eigenes System für interne Zwecke. Prinzipiell eine simple IP-Ausgabe (Plaintext) nur mittels Nginx

Keepalive zu deaktivieren scheint jedenfalls nichts zu bringen, das dürfte an HTTP/2 liegen.

Aber beruhigend zu sehen, dass es bei perryflynn genauso ist.

perryflynn · 14. November 2023

Muss mal schauen ob ich irgendwo einen IPv6 fähigen Firefox herbekomme, dann teste ich auch mal n bisschen rum. Wenn man das wie beschrieben mit der Origin erkennen kann müsste ich ja einfach nur in der API nen Status 421 schicken wenn da sowas kommt.

Wobei ich die Entscheidung das so zu machen schon echt schwierig finde.

Auch interessant:

https://daniel.haxx.se/blog/2016/08/18/http2-connection-coalescing/

H6G · 14. November 2023

Zitat von perryflynn

Muss mal schauen ob ich irgendwo einen IPv6 fähigen Firefox herbekomme, dann teste ich auch mal n bisschen rum.

Kann man dich dabei unterstützen?

Edit: eine Möglichkeit wären natürlich keine SAN / Wildcard Zertifikate zu verwenden.

mainziman · 14. November 2023

perryflynn welche Adressen sind das, die er bei Local Addresses anzeigt?

irgendwie kommen die mir wie ein Zufallsadressgenerator vor, jedesmal nach Refresh [F5] sind es andere ...

perryflynn · 14. November 2023

Vor ein paar Jahren hat man da die echte lokale IP sehen können. Seit einiger Zeit wird wegen privacy und so da aber gewürfelt. Ist letztenendes ne Altlast.

Schau gerne ins Javascript für Details. Ist nicht minifiziert.

KB19 · 14. November 2023

Zitat von perryflynn

Wenn man das wie beschrieben mit der Origin erkennen kann müsste ich ja einfach nur in der API nen Status 421 schicken wenn da sowas kommt.

Habe ich irgendwas überlesen? Wie kann man das erkennen, ohne Unterstützung durch den Webserver?

Zitat von H6G

eine Möglichkeit wären natürlich keine SAN / Wildcard Zertifikate zu verwenden.

Das ist nun auch mein Workaround. Gefällt mir zwar nicht, weil der interne Hostname dadurch im Certificate Transparency Log auftaucht, aber das Ding hat sowieso einen speziellen Pfad, den man nicht so leicht errät. Durch die negativen Erfahrungen von perryflynn mit den massenhaften Requests durch Schadsoftware, möchte ich die genaue Adresse nämlich keinesfalls öffentlich verbreiten.

H6G · 14. November 2023

Zitat von KB19

Wie kann man das erkennen, ohne Unterstützung durch den Webserver?

Naja, du brauchst schon die Information des Webservers.

In dem Fall müsstest du den Host Header ein zweites Mal überprüfen innerhalb eines Location Blockes.

KB19 · 14. November 2023

Zitat von H6G

In dem Fall müsstest du den Host Header ein zweites Mal überprüfen innerhalb eines Location Blockes.

Der HTTP-Host-Header, den der Client übermittelt? Aber der ist doch immer korrekt, an dem erkennt man diesen "Bug" gar nicht?

Vorausgesetzt ich habe das nicht falsch in Erinnerung. Ich bin mir ziemlich sicher, dass ich das mit den Entwicklertools sofort geprüft habe.

perryflynn · 14. November 2023

Kann durchaus auch sein dass ich's falsch verstanden habe. Wollte es mir wenigstens Mal in Wireshark anschauen.

perryflynn · 14. November 2023

Zitat von KB19

die negativen Erfahrungen von perryflynn mit

Unterm Strich war's ne coole Erfahrung. Ich hab durch die Optimierungen jetzt ne Anwendung die zweistellig Millionen Requests pro Woche verarbeitet. Auf einem ziemlich kleinen Server. Wer kann das schon sagen? 😄

H6G · 14. November 2023

Zitat von KB19

Der HTTP-Host-Header, den der Client übermittelt? Aber der ist doch immer korrekt, an dem erkennt man diesen "Bug" gar nicht?

Der Host Header ist das, was in der Adresszeile angegeben ist.

Wenn du im ip Block plötzlich den Host Header ip4 findest, stimmt da etwas nicht und du kannst Error 421 zurück spielen.

KB19 · 14. November 2023

Zitat von H6G

Der Host Header ist das, was in der Adresszeile angegeben ist.

Wenn du im ip Block plötzlich den Host Header ip4 findest, stimmt da etwas nicht und du kannst Error 421 zurück spielen.

Nein, so einfach ist es leider nicht.

Vorweg: Ich hatte vorhin einen gemeinsamen server Block für alle drei Hosts.

Ich habe das jetzt mal auf eigenständige Blöcke umgebaut und online gestellt.…

Wenn die ip4/ip6 Blöcke jeweils nur auf der passenden IPv4/IPv6 Adresse lauschen, wirft mir Nginx beim zweiten Request einen Error 404 um die Ohren. Der Request erreicht somit gar keinen location Block, in dem ich das abfangen könnte. Prinzipiell ist die Website dann erst recht kaputt, weil sie gar nicht mehr erreichbar ist.
Wenn die ip4/ip6 Blöcke hingegen immer auf beiden IPv4/IPv6 Adressen lauschen, tritt das vorher diskutierte Fehlerbild auf. Aber auch hier kann ich mit dem HTTP-Host-Header baden gehen, weil er immer "korrekt" ist und daher keine Unterscheidung möglich ist:

server_name=http-debug4.fnx.li
http_host=http-debug4.fnx.li
remote_addr=2a02:[…]
request_uri=

Falls Du es testen willst: http-debug.fnx.li / http-debug4.fnx.li / http-debug6.fnx.li

Code

location /
{
    default_type text/plain;
    return 200 "server_name=$server_name\nhttp_host=$http_host\nremote_addr=$remote_addr\nrequest_uri=$request_uri\n";
}

H6G · 14. November 2023

Zitat von KB19

Wenn die ip4/ip6 Blöcke jeweils nur auf der passenden IPv4/IPv6 Adresse lauschen, wirft mir Nginx beim zweiten Request einen Error 404 um die Ohren. Der Request erreicht somit gar keinen location Block, in dem ich das abfangen könnte.

Kann man mit einem Custom Error Handler hier Abhilfe schaffen? Vielleicht sogar die Fehler durch ein CGI Script behandeln lassen - bei kleinen Traffic Volumes.

KB19 · 14. November 2023

Zitat von H6G

Kann man mit einem Custom Error Handler hier Abhilfe schaffen?

Offenbar nicht, der 404er kommt direkt von Nginx.

Diese server-Blöcke sind nun so konfiguriert, dass sie nur auf die richtige IP-Adresse lauschen:

http-strict-debug.fnx.li
http-strict-debug4.fnx.li
http-strict-debug6.fnx.li

Code

        error_page 404 @test;

        location @test
        {
                default_type text/plain;
                return 404 "ERROR 404\nserver_name=$server_name\nhttp_host=$http_host\nremote_addr=$remote_addr\nrequest_uri=$request_uri\n";
        }

        location = /
        {
                default_type text/plain;
                return 200 "OK\nserver_name=$server_name\nhttp_host=$http_host\nremote_addr=$remote_addr\nrequest_uri=$request_uri\n";
        }

Alles anzeigen