Die kuriose Let’s Encrypt Zertifikatsvernichtung

Ihr habt sicher von der Let’s Encrypt Aktion  gehört, bei der am Mittwoch 4 Millionen Zertifikate für ungültig erklärt werden sollten und nun tatsächlich nur noch 1.3 Millionen entwertet wurden.  Was Ihr nicht gehört habt ist der Umstand, daß die Zahlen komplett überzogen sind und die Begründung auch nicht für alle stimmt.

1.3 Millionen Zertifikate für ungültig erklärt.

Am 3.3. kam folgende Email bei uns an:

ACTION REQUIRED: Renew these Let’s Encrypt certificates by March 4

We recently discovered a bug in the Let’s Encrypt certificate authority code, described here:

https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591

Unfortunately, this means we need to revoke the certificates that were affected by this bug, which includes one or more of your certificates. To avoid
disruption, you’ll need to renew and replace your affected certificate(s) by Wednesday, March 4, 2020. We sincerely apologize for the issue.

… Erklärung was man tun  muß …

Your affected certificate(s), listed by serial number and domain names:

03ecb7303d580891307fd3a47b380d312f4f: einedomain.de www.einedomain.de
030957775b69a991e4dd80c6d598aad621d1: eineanderedomain.de www.eineanderedomain.de
03454b86a0b34e3fced270c8cf31eff99e9c: einedomain.de www.einedomain.de
0380ffb6959d746e0dac1cc397d696e20997: eineanderedomain.de www.eineanderedomain.de
0444954637f2defb07cb113a612ec46b19a9: einedomain.de www.einedomain.de
03bb883d4c37e1a71afdff2d379ffcf3e023: eineanderedomain.de www.eineanderedomain.de
03143a5f2efaba0dc3083ac61b160cd0d9f6: einedomain.de www.einedomain.de
044967b81422a9cb42a24d4c3349a3809106: eineanderedomain.de www.eineanderedomain.de
03ea3701bebb2679bcb5dd9f49308a90ad6e: einedomain.de www.einedomain.de
034d72dd79494e8d34843c3e0dcd99dc0229: eineanderedomain.de www.eineanderedomain.de
032fd14c38423850ea037b09b4868c1d92ff: einedomain.de www.einedomain.de
03dd1bf96a9a77edcde65dd49dcb65c77619: eineanderedomain.de www.eineanderedomain.de
03e2c85073fcf4e4a807e4fe7674a4e8342e: eineanderedomain.de www.eineanderedomain.de
03c802547e5f9b20704cf3385f5d64e4cab4: einedomain.de www.einedomain.de
03a75558e1bef0c4a68d8d437758d0c36743: eineanderedomain.de www.eineanderedomain.de
049ce54f1a025d3581408b7e1f39c82bf761: einedomain.de www.einedomain.de
0389bef9a312c1cf568d9af54f7e20003a37: eineanderedomain.de www.eineanderedomain.de
04a7b495e56693c4847a259f68c1cb3dca0d: einedomain.de www.einedomain.de
03671ac363d115d81991fb78b4efa00b72b8: eineanderedomain.de www.eineanderedomain.de
04dda4b6e006f8fb5c17b8e98ec60cc5c487: einedomain.de www.einedomain.de
04f7293f6e2f18d11f0e7f4ac1b03f32ac66: eineanderedomain.de www.eineanderedomain.de
033f28ecf7cdfdf9094fef13e295a2fb6702: eineanderedomain.de www.eineanderedomain.de
035af3d7a2209dcd5a6eee2ebfb0b774ab9f: pma.{einedrittedomain.de} {einedrittedomain.de} webmail.{einedrittedomain.de} www.{einedrittedomain.de}

Wie man sehen kann, sind das Zerts für eine winzige Anzahl an Domainnamen, die ALLE SAMT schon vor Jahren ausgestellt wurden und schon lange ersetzt und ungültig sind. Ich habe keine Ahnung was Let’s Encrypt da genau gemacht hat, aber es ist defakto Blödsinn gewesen. Offensichtlich hat da niemand die Ablaufdaten geprüft, sonst wäre das nicht passiert. Ganz unbekannt ist das Problem bei Let’s Encrypt nicht:

Q: I received the email telling me I should renew my certificate, however, the online testing tool isn’t indicating my cert needs replacing.
A: Even if you received an email, it’s possible that the affected certificates have been replaced by newer certs not affected by the bug. (Either due to being issued in the last few days since it was fixed, or simply by not meeting the specific timing criteria necessary for the bug to trigger.) In that case, it’s not necessary to renew them again. You can use the checking tool at https://checkhost.unboundtest.com/ to verify if the certificate you’re currently using needs renewal, or verify that the serial number of the cert you’re currently using is present in the list of affected certs at https://letsencrypt.org/caaproblem/.

Da uns Certs teilweilse vom Start des Testbetriebs von LE angegeben wurden, kann man annehmen, daß die Uhren in Amiland anders ticken 🙂 Certs werden 20 Tage vor Ablauf automatisch erneuert, so daß man bei der Menge oben leicht ausrechnen kann, wie alt die sein müßten 😉

CAA & DNS

Kommen wir zu nächsten Ungereihmheit bei der Sache, der CAA Validierung. Wie man in dem Artikel „https://community.letsencrypt.org/t/2020-02-29-caa-rechecking-bug/114591“ nachlesen, daß die ganze Aktion ausgelöst wurde, bei bei CAA Einträgen falsch geprüft wurde. Dafür müßten aber folgende Bedingungen erfüllt sein:

CAA verwenden

Wenn Sie sich nicht für CAA interessieren, müssen Sie im Allgemeinen nichts tun (siehe jedoch unten die CAA-Fehler). Wenn Sie mithilfe von CAA einschränken möchten, welche Zertifizierungsstellen Zertifikate für Ihre Domain ausstellen dürfen, müssen Sie einen DNS-Anbieter verwenden, der die Einstellung von CAA-Einträgen unterstützt. Suchen Sie in der SSLAate CAA-Seite nach einer Liste solcher Anbieter. Wenn Ihr Provider aufgeführt ist, können Sie mit dem SSLMate CAA Record Generator eine Gruppe von CAA-Datensätzen generieren, in denen die CAs aufgelistet sind, die Sie zulassen möchten.

Wir haben aber gar keine CAA Einträge bei unserer Validierung benutzt 😉 Natürlich kann man da immernoch eine DNS Abfrage pro Zertvalidierung machen, aber rauskommt dann halt nichts. Ich vermute mal, daß genau der Fall „nichts“ aka. „Kein Ergebnis“ das eigentliche Problem war.

So oder so wundert es mich nicht, daß die Zahl von 4 Millionen auf 1.3 geschrumpt ist. Ich vermute, die geht eher in die zehntausende, als in die Millionen, wenn man die Fehlerquota bei uns als Maßstab ansetzt. Die Liste oben ist nur ein Auszug der Email, da waren noch viel mehr falsche Ergebnisse drin, als Ihr jetzt erahnen könnt 😉

(An.d.r.Ä. ein „nicht“ im ersten Absatz eingefügt.)

Firefox 70 weiterhin ohne sicheres Fritz!box Interface

Letzte Nacht noch mit Hoffnung auf ein besseres LAN Erlebnis ins Bett gegangen, aber Firefox 70 enttäuscht dann auch heute morgen noch mit dem „SEC_ERROR_INADEQUATE_KEY_USAGE“-Fehler 🙁

Fritz!Box Webinterface weiterhin ohne SSL

Auch mit der Installation von Firefox 70 haben sich alle Hoffnungen auf eine Lösung des SSL Problems vorerst in Luft aufgelöst. Die bei Mozilla für diese Komponente zuständige Entwicklerin Dana Keeler hatte da wohl auch eher das Prinzip Hoffnung in Einsatz. Da ich mittlerweile vom AVM Support eine „Wir schauen mal nach“ Meldung bekommen habe, bin ich insofern beruhigt, als daß sich alle Parteien um eine Lösung bemühen.

Klar, man kann mit dem FF ohne SSL ins Interface, aber das ist natürlich nur eine Notlösung. Chrome benutzen geht zwar auch, aber auch das ist eher unschön.

Wer trotzdem dringend einen Firefox 70 braucht

findet hier die FF70 Downloadlinks:

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc29/x86_64/firefox-70.0-1.fc29.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc30/x86_64/firefox-70.0-1.fc30.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc31/x86_64/firefox-70.0-1.fc31.x86_64.rpm

https://kojipkgs.fedoraproject.org//packages/firefox/70.0/1.fc32/x86_64/firefox-70.0-1.fc32.x86_64.rpm

eine Weisheit

Wenn man die Scheisse Anderer nicht auslöffeln will,
sollte man den Stein, unter dem sie zu finden ist, nicht umdrehen.

Ein Teaser

Es folgt (vermutlich) bald(tm) ein Beitrag zum Thema Mailserver-TLS und es kommen oft die Worte „WIESO?“ ,“unsicher“,“gebrochen“ und vermutlich „args!“ darin vor. Die Liste der Verdächtigen beinhaltet das Who-is-Who nationaler und internationaler Konzerne.

hmm

Da ich ja schon früher über TLS geschrieben habe, wär es dann nicht eigentlich ein Cliffhanger in einer Endlos-Storyline ? 🙂

Sparkassen-Shop mit Tracking und unsicheren Webseiten

Da wollte man so harmlos mal die Webseiten der Braunschweigischen Landessparkasse aka. Norddeutsche Landesbank oder kurz NORD/LB, benutzen, da zieht ein merkwürdiger Werbelink meine Aufmerksamkeit auf sich : http://www.sparkassen-shop.de

Hätte ich mal nicht hingeschaut :

SSL-Report des Sparkassen-shops mit Fehlermeldungen. Die Webseite ist als unsicher markiert und der Schlüssel entspricht nciht mehr so ganz den Ansprüchen an einen sicheren SSL Key

SSL-Report des Sparkassen-shops

Wie man schön sehen kann, stimmt was mit der HTTPS Seite nicht, weil der Browser schon von sich aus warnt, daß unsichere Links enthalten sind. Da sowas mein Job ist, kurz mal FireBug aktiviert und nachgesehen. Das hätte ich mal besser nicht machen sollen 😀

oh wie peinlich :  ERWISCHT beim Tracken

Da fand sich dann folgender Trackinglink der hauseigenen PIWIK Installation:

<img src=“http://piwik.sparkassenverlag.de/piwik/piwik.php?idsite=18″ style=“border:0;“ alt=““ />

sowas gehört auf einer HTTPS Seite natürlich auch mit HTTPS:// eingebunden !
Lustigerweise macht der Code-Schnippsel von PIWIK selbst, das richtig 🙂

Damit haben wir die Quelle der Browsermeldung, aber wenn wir schon dabei sind,  was zum Geier soll das sein ?!?

<a href=“http://www.blsk.de“ target=“_blank“>

Seit wann braucht man hardgecodete HTML Entitätsersatzanweisungen aus dem UTF-8 Zeichensatz für ein simples „://“ ?!?

Da kann man nur mit dem Kopfschütteln 🙂

Schlüssellängen

Aber warum habe ich jetzt eigentlich in dem SSL-Report die Schlüssellänge und den HASH-Algo markiert ?

Für die meisten (Männer) gilt die Formel :  Länge * Angelerfahrung => Menge(Selbstbewußtsein), lustigerweise gilt das auch für Webseitenverschlüsselungen. 2048bit Schlüssellänge waren vor Jahren mal empfohlen als ausreichend, ein paar konservative Fachmenschen würden das heute noch empfehlen, aber für eine Bank, da kann man nur zu einer vernünftigen Schlüssellänge von 4096+ Bits raten. Denn das sollte ja wohl sicher sein, oder war Fort Knox mit Wattebällchen abgesichert ?

Fazit

Diese Webseite gehört zu Kategorie: „Hätten Sie mal jemanden ohne Zertifikat gefragt“. Aber nicht alles ist schlecht, denn insgeheim hatte ich mit Google Analytics gerechnet zum Tracken der Benutzer und da ist mir PIWIK auf den eigenen Servern des Webseitenbetreibers natürlich lieber.

Da diese Grafik (oben) aber geladen wird, noch bevor man die Chance hatte, die Datenschutzerklärung zu lesen und die Seite ohne Tracking wieder zu verlassen, ist es wohl nur eine Frage der Zeit, bis der Datenschutz die Seite dicht macht. Wir sind ja hier in der EU, die auch eine Einwilligung zum Tracking per Einsatz von Cookies vorraussetzt.

Nur so ein Denkanstoß an die Verantwortlichen: Auf der Startseite brauch man noch kein Tracking, wie oft die aufgerufen wurde, sagt einem auch ohne weiteres das Apache Domlog.

Weiter als die Startseite durchzusehen, habe ich mich dann nicht getraut, ich hatte Angst, daß ich heute Nacht noch an dem Artikel sitzen würde 😉