Leserreporter: Wer schöne Verschwörungslinks für mich hat: ab an felix-bloginput (at) fefe.de!
[zurück][ältere Posting][neuere Posting] Freitag, 24 Januar 2014 | Blog: 10 | No: 28509
Mit den aktuellen Chrome-Betas ging unter Linux SSL mit blog.fefe.de nicht mehr. Ich habe das jetzt mal debugged. Die Geschichte geht damit los, das vor einiger Zeit mal jemand ein paar populäre Torrents in Umlauf gebracht hatte, die die blog.fefe.de:443 als Tracker announced haben, woraufhin mein damals noch deutlich schwachbrüstigerer Server unter der Last der ganzen fehlschlagenden SSL-Handshakes litt. Damals habe ich in gatling einen Hack eingebaut, der sich vor dem SSL-Handshake die Daten auf dem SSL-Port anguckt und die Verbindung direkt entsorgt, wenn das nicht wie ein SSL-Handshake aussieht.
Ich prüfe da nicht viel, im Wesentlichen will ich, dass das Opcode-Byte sagt, dass es ein Handshake ist, und dass die TLS-Version gültig aussieht, und dass die Länge des Handshake-Paketes nicht größer als 256 ist. Warum 256? Weil das nach damaligen Verhältnissen exorbitant viel war und weil 256 in Binärdarstellung ein 1-Byte in der höherrangigen Hälfte des Längenfeldes war, was sich dann leicht testen ließ.
Was jetzt passiert ist, ist dass Chrome so viel Bloat mitschickt, dass bei denen 0x200 als Länge im Header steht, also 512. Wir erinnern uns: Chrome, das waren die Leute, die wegen des angeblichen HTTP-Header-Bloats ein eigenes Konkurrenzprotokoll namens SPDY erfunden haben, das so super toll optimiert ist, dass für die zwei e kein Platz mehr im Namen war. DIE Leute haben jetzt ihr SSL-Handshake soweit aufgebläht, dass es in meinen Sanity-Check rannte.
SPDY basiert übrigens auch auf SSL.
Einmal mit Profis arbeiten!
[zurück]
[ältere Posting][neuere Posting]
[zurück][ältere Posting][neuere Posting] Freitag, 24 Januar 2014 | Blog: 10 | No: 28509
Warum 256?
Es gibt eine Erklärung, wieso der SSL-Header so groß ist
Ich prüfe da nicht viel, im Wesentlichen will ich, dass das Opcode-Byte sagt, dass es ein Handshake ist, und dass die TLS-Version gültig aussieht, und dass die Länge des Handshake-Paketes nicht größer als 256 ist. Warum 256? Weil das nach damaligen Verhältnissen exorbitant viel war und weil 256 in Binärdarstellung ein 1-Byte in der höherrangigen Hälfte des Längenfeldes war, was sich dann leicht testen ließ.
Was jetzt passiert ist, ist dass Chrome so viel Bloat mitschickt, dass bei denen 0x200 als Länge im Header steht, also 512. Wir erinnern uns: Chrome, das waren die Leute, die wegen des angeblichen HTTP-Header-Bloats ein eigenes Konkurrenzprotokoll namens SPDY erfunden haben, das so super toll optimiert ist, dass für die zwei e kein Platz mehr im Namen war. DIE Leute haben jetzt ihr SSL-Handshake soweit aufgebläht, dass es in meinen Sanity-Check rannte.
SPDY basiert übrigens auch auf SSL.
Einmal mit Profis arbeiten!
Update: Vier der Extensions sind so neu (oder Google-proprietär?), dass Wireshark sie noch nicht kennt.
Update: Es gibt eine Erklärung, wieso der SSL-Header so groß ist. Das ist kein Bloat, sondern die machen das absichtlich, um um eine ranzige F5-Firmware herumzuarbeiten. m(
Twiter-Ticker
Fefes Latest Youtube Video Links
Der Betrieb der KraftZeitung kostet Geld. Da wir auch weiterhin unabhängig, überparteilich und ohne kommerzieller Werbung für Sie da sein wollen, sind wir auf Ihre Spende angewiesen. Vielen Dank.
