Firefox und HTTP/2 Connection Coalescing

  • 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

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 12 times, last by KB19 ().

  • 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. ^^

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 3 times, last by KB19 ().

  • 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/

  • 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.

  • 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 ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

  • 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?


    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.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 2 times, last by KB19 ().

  • 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.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited once, last by 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? 😄

  • 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.

  • 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";
    }

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 4 times, last by 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.

  • 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

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 5 times, last by KB19: Wunsch zur Aufteilung in ein neues Thema entfernt. Danke für die Durchführung! ().

    Thanks 1