Verkettung unglücklicher Umstände

Die Zertifikatfehler könnten Man-in-the-Middle-Attacken bedeuten... Was das mit Glück oder Unglück zu tun hat? keine Ahnung...

Kurz zum technischen Hintergrund:

Ein Zertifikatsfehler, wie er beim Aufruf von de.indymedia.org vor einigen Tagen zu beobachten war, kann ein Man-in-the-Middle-Angriff bedeuten. Einen solchen können zum Beispiel Bullen oder VS fahren, um eure Kommunikation mit Indymedia mitzuschneiden. Sie hängen sich dann zwischen euch und den Server von Indymedia. Da sie selbst kein legitimes Zertifikat haben, taucht ein solcher Fehler auf. Ihr solltet bei solchen Fehlern also immer vorsichtig sein!

In diesem Fall war das aber etwas anderes. Zertifikate haben Ablaufdaten. Danach sind sie nicht mehr gültig. Genau das ist bei de.indymedia.org passiert. Normalerweise sollte natürlich vor Ablauf des Zertifikats ein neues ausgestellt sein und dieses verwendet werden.

Let's encrypt ist ein kostenloser Service, um Zertifikate auszustellen. Dabei sind die Zertifikate nur drei Monate gültig. Die Aktualisierung erfolgt automatisch. Dazu muss der Server von de.indymedia.org gegenüber dem Server von Let's encrypt nachweisen, dass er die Kontrolle über die Domain hat. Dies ist nun - laut obiger Aussage der Admins von de.indymedia.org - wegen einem Fehler an einerm Proxy-Server schiefgegangen. Daher wurde nicht automatisch ein neues Zertifikat ausgestellt. Gleichzeitig fiel das nicht schnell genug auf. Das alte lief aus und ihr habt den Zertifikatsfehler gesehen.

Auf einen Angriff von Bullen, VS oder sonstigen Schweinen deutet dabei nichts. Wäre auch sehr doof von denen, einen solch offensichtlichen Angriff zu fahren. Die Fehlermeldung war ja nun kaum zu übersehen und sie wollen ja kaum Leute warnen, dass sie gerade versuchen de.indymedia.org zu überwachen...

und was soll der onion seiten hinweis? bei onion seiten (ohne funktionierendes ssl) ist durch nichts sichergestellt, dass seiteninhalte während der übertragung modifiziert werden können. einfach nur ein evil exit node und fertig. der böse exit node würde übrigends auch submissions mitlesen können. imho also sinnlos und sogar gefährlich bei nicht laufendem ssl auf tor zu verweisen.

nochmal als info an lesende (nicht betreibende) dieses ssl ding macht auch nur die verbindung zwischen eurem rechner und der indymedia seite sicher; wenn der indy server nicht korrekt abgesichert wurde, das cms mal wieder veraltet ist, oder oder oder...dann ist es für bullen etc nicht allzu schwer an die verbindungsdaten zwischen euch und der indymedia seite heran zu kommen. da hilft dann auch kein ssl mehr ;)

de.indymedia.org liefert wieder teilweise das abgelaufene Zertifikat aus. Einer euer Server scheint da nicht richtig aktualisiert worden zu sein.

Geht um das Zertifikat mit Ablaufdatum 19.10.2017 und Fingerprint (SHA-256) 18:DC:7D:6C:64:BD:2F:97:C7:6C:5E:55:B3:C3:E6:FB:95:CC:B7:35:DE:05:12:FB:DA:66:CB:BF:5B:A4:18:D7.

P.S.: Wollt ihr eventuell mal die kruden Kommentare hier zu irgendwelchen Windows-Registry-Einträgen und Schattenkopien löschen? Teilweise enthalten die ja auch eher uncoole Aufrufe (z.B. Schattenkopien zu löschen)...

Die obigen Ausführungen zu SSL und Tor Hidden Services (.online-Seiten) stimmen leider nicht. Eine SSL-Verbindung ist überflüssig, wenn ein Tor Hidden Service angesprochen wid. In diesem Fall verlässt die Verbindung nicht das Tor-Netz. Dort ist sowohl Verschlüsselung der Daten als auch Verifizierung der Gegenstelle gegeben.

Es wäre echt cool, wenn ihr euch dem weiterhin bestehenden Problem annehmen könntet. Meine aktuelle Verbindung läuft z.B. über das abgelaufene Zertifikat vom 19. Oktober mit Fingerprint 18:DC:7D:6C:64:BD:2F:97:C7:6C:5E:55:B3:C3:E6:FB:95:CC:B7:35:DE:05:12:FB:DA:66:CB:BF:5B:A4:18:D7 und nur dank einer manuell erstellten Ausnahmeregelung.