Kurzfassung: a) Nein. b) ich weiss es nicht genau, und ich weiss auch nicht genau, ob es eine eindeutige Antwort darauf gibt. Möglicherweise weiss das jemand anders, dann lerne ich gerne dazu.
Langfassung: Ich hab jetzt ne Latte HTTPS-Migrationen eigener Seiten und Kundenseiten hinter mir, und aus Marketingsicht ist ja mal das Gröbste in Ordnung, wenn die Weiterleitungen rennen, die Google-Properties neu bestätigt/verknüpft sind und keine obskuren Browser/Certwarnungen aufpoppen. Sobald man sich aber anfängt, ein wenig Gedanken um a) faktische Sicherheit und b) Erreichbarkeit zu machen, scheint mir sich da ein Spagat aufzutun, weiter einige notwendige Lernschleifen. Ich klopp einfach mal drei SSLLabs-Ergebnisauszüge hier rein.
Die Palettenbett.com, selber migriert auf eine LetsEncrypt-Default-Lösung via Plesk. Die hat insgesamt einen Grade A, alles an sich prima. Google ist glücklich, indexiert alles, aktuelle Browser und mein iPhone ebenso. Wir sehen ein paar kleinere Probleme, die ich analog auf einer Latte weiterer Seiten mit dem gleichen Setup auf dieser Kiste messen kann.
Wir sehen: FF-Varianten, die es hinter sich haben sollten, kommen mit HTTP/2 nicht klar. Wer mit IE6/XP unterwegs ist, hat generell ein Problem, nicht deshalb, weil er nicht auf meine Seite kommt. Bei 8/XP fällts mir schon schwer zu lästern, wer weiss, wer warum dazu gezwungen wird. Was es mit der java6-Kiste auf sich hat, kann ich ehrlich gesagt nicht einschätzen. Chrome 49 *sollte* mir an sich egal sein, aber stellt euch meine Überraschung vor, als ich feststellte, das das nach wie vor die Engine vom Chromium auf meinem hochaktuellen Kubuntu-Linux ist. Dasselbe gilt für Chrome auf alten MacOS-Varianten. Ich ließ mir sagen, dass letzteres keine komplett ungängige Situation sei, weil es teure Software gebe, die MacOS-Updates irgendwann zu einer kostspieligen Angelegenheit machen wegen Lizenzwechsel/Switch von Kauf- zu Mietsoftware. Details sind mir nicht bekannt, aber nun.
Weiter gehörte Aufrufprobleme: unbekannte Opera-Varianten, die auch nicht korrekt die Ciphers aushandeln. Grundsätzlicher Gedanke:
– kann ich mir jetzt aussuchen, ob auch veraltete Kisten auf meine Seiten kommen, und dafür das SSL angreifbar machen,
– oder die alten Kisten aussperren und nur vernünftige Krypto anbieten?
– Oder kann ich irgendwelche Fallback-Strukturen so arrangieren, dass auch zumindest vertretbar veraltete Clients eine Chance auf ne Verbindung haben, ohne dass ich geknackten Murks implementiere?
Werfen wir einen vergleichenden Blick auf das Gesamtrating von Facebook.
Da wird beispielsweise RC4 noch genommen, das Schneier als durchaus plausibel hackbar betrachtet und welches sein eigenes „Darf man nicht mehr in TLS verwenden“–RFC bekommen hat. Gespräch mit Axel heute darüber: am plausibelsten scheint uns, dass Facebook da keine Wahl hat, weil ein nicht unbedeutender Teil seiner Milliardenuserschaft mit veralteten Smartphones in Schwellenländern sitzt und schlicht keine Möglichkeit dazu hat, einen moderneren Browser/ein moderneres mobiles OS zu nutzen, das mit was besserem klarkommt.
So, und jetzt ein Problemfall.
Das rennt überall. Die Browser werfen freudig grüne Schlösser, die Migration sieht tadellos aus, aber von RC4 muss ich gar nicht anfangen, weil fucking SSL 3.0 dort rennt und da der Poodle zuschlägt.
Einem Kunden in so einer Situation ein „Hey, das geht so nicht“ durchzugeben, ist per se nicht die Frage. Ist sicherheitsrelevant, muss raus, gegessen. Jetzt aber der Fall, dass man weiss, da sind ein größerer Teil der Klientel auf Altgerät unterwegs? Jetzt die Serie der Phantom-Updates, von der die Weisen sagen, sie habe mit Contentqualität und Usersignalen zu tun, was ist denn los, wenn ich eine Seite raushaue, die dann meinetwegen 0,8% der Nutzer *vollkommen zurecht* mit nem Cert Error wegschickt, aber die eben den Back-Button zurück zu den SERPs klicken und eine dieser großen braunen „Die Seite ist scheiße“-Fahnen Richtung Google schwenken? Ich *glaube*, dass das Google möglicherweise kapiert, aber recht sicher bin ich nicht und vor allem, das ist eine dieser Geschichten, die einem Kunden schwer vermittelbar sind, sollte er grade eine auf den Deckel bekommen haben. „Es ist für die allgemeine Sicherheit des Internets“, ja, und für die der Cookies seiner online zahlenden Kunden. Mich würde das überzeugen, aber ich sitz auch abend um halb acht da und tipper meine Verzweiflung ob der Komplexität diverser Ciphersuite-Fallbacklösungen ins Netz. An sich denke ich, sobalds um mehr als eine verschlüsselte Übertragung ohnehin öffentlicher Seiten geht (also schon mal definitiv auf jedem Shop), geht Poodle-Anfälliges gar nicht mehr. Bei loginfreien Geschichten käme es an sich nicht wirklich drauf an, aber mal ernsthaft: wegen Software, die schnell im Feuer sterben sollte, jetzt die Fallbacks eruieren, die man mit einigermaßen gutem Nachtschlaf noch vereinbaren kann, und an sicherheitsrelevanten Serverconfigs rumpfuschen?
Muss man da nun als Onlinemarketer auch noch zumindest in den Basics durchsteigen? Einem Techie fundiert sagen können, was machbar ist und was welche Nutzer rauswirft und was nicht? Das wollte ich als Schlussfrage mal offenlassen, und dann spült es mir noch diesen bemerkenswerten Text rein, dass das Internet zu einer Lovecraft-Geschichte geworden ist und ja, Cthulhu erwacht, und ein paar Leute sollten die Risse zwischen dieser Welt und dem namenlosen Grauen weiterhin stopfen.
Zum Thema Cipher-Suites kann ich nur sagen, dass das Mozilla Observatory da ziemlich nützlich ist. Die geben einem da nen guten Überblick über Kompatibilität und haben auch einen „Config-Generator“, der äußerst hilfreich ist.
Ich war so frei und hab korrupt.biz mal dort getestet, da sind noch ein paar Kleinigkeiten ausbaufähig. Grad was headers angeht.
Oh, das ist wirklich schön alles auf einmal. Den GHenerator im Mozillawiki hatte ich auch schon gefunden, es war nur eben erst das „Bevor ich da die Ciphers editiere, das grundsätzliche glattziehen“-Ding.
Ob ich in meiner Konstellation ein HSTS überhaupt machen kann, ist mir ehrlich gesagt unklar (und jetzt nicht mein höchstes Ziel) – ist halt default-LetsEncrypt auf Plesk/Linux. An sich war der Plan, eine Config zu finden, die grundsätzlich mal ordentlich ist und den geringsten Schwund bei den alten Kisten mitbringt. Und mal generell besser verstehen, was da eigentlich alles wie mit allem anderen zusammenhängt :)