Quantcast
Channel: unorganisiertes sammelsurium (Artikel mit Tag elektronen und bits)
Viewing all articles
Browse latest Browse all 12

SSL und Key Revocation

$
0
0

Als ich bei Fefe einen Eintragüber das OpenSSL-Debakel bei Debian und dessen Auswirkungen gelesen habe, insbesondere der "Spaß" mit kompromittierten Keys, solange sie nicht abgelaufen sind und der passende Private Key berechnet wurde. Dazu kamen mir folgende Gedanken:

Wir haben das Problem, dass es bei SSL bzw X.509 zwar die Möglichkeit gibt, Zertifikate zurückzurufen, wobei diese Informationen dann über die so genannte "Revocation List" einsehbar ist, dieses Verfahren aber kaum eingesetzt wird. Außerdem bringt es prinzipbedingt das Problem mit sich, dass nur der negative Status eines Zertifikats überprüfbar ist, also ob es gesperrt wurde.

Dieses Problem sollte durch OCSP beseitigt werden, hier gibt es nun auch die (optionale) Möglichkeit auf die Abfrage hin ein Zertifikat eindeutig als gut auszuweisen. Nur kann ich mir weiterhin nicht vorstellen, wer freiwillig solche Server betreiben möchte. Die Last dürfte doch sehr hoch sein.

Aber so an sich haben wir eine einzige brauchbare, wirklich skalierende, verteilte Datenbank. Das Domain Name System. Es gibt zwar gewisse Latenzen durch das Caching, aber eine Lösung die mir mit ein paar Stunden zurückgerufene Keys anzeigt ist mir immer noch lieber als eine theoretisch existierende, aber nicht verwendete. Dazu müssten ein oder zwei neue Record-Typen eingeführt werden, und schon könnten der Fingerprint des aktuell gültigen und/oder der zurückgerufenen Schlüssel dort abgelegt werden. Mittels DNSSEC könnte die Authentizität dieser Angaben gesichert werden.

Disclaimer: Ich bin kein Experte was Kryptographie angeht, daher bitte ich bei Fehlern in meinen Gedanken um Rücksicht und entsprechende Kommentare


Viewing all articles
Browse latest Browse all 12