Skip to content

Zertifikate und CAs ...

gedanken Nach dem Artikel CAs hinzufügen bin ich zurecht darauf "hingewiesen" worden, dass ich ein Wort zum Prüfen von Fingerprints hätte verlieren sollen, dass habe ich als Achtung noch nachträglich getan.

Allerdings muss ich gestehen, dass ich das Thema rund um Zertifikate und wie die Strukturen implementiert sind für maximal kaputt halte.

Jedem muss bewusst sein, dass mehr als 95% (geschätzt) aller Nutzer Zertifikatsfehler einfach akzeptieren und wegklicken.

Wenn dann noch dazu kommt, dass selbst gehackte Certificate Authorities (CAs) - das sind die, die bestätigen (unterschreiben), dass die Zertifikate korrekt sind - nicht automatisch aus den Browsern entfernt werden, muss man sich schon fragen, was das alles soll.

Als letztes sollte man sich einmal anschauen, wie die CAs arbeiten und welche Art von Identitäsnachweisen verlangt werden. Für die einfachsten Beglaubigungen wird nur eine E-Mail an den Webmaster der Domain versendet. Diese E-Mail wird unverschlüsselt verschickt und kann abgefangen werden.

Tatsächlich finde ich das Verfahren von CAcert, dass eine Identität wenigstens von drei Leuten (Assurers) bestätigt werden muss besser als viele andere, aber CAcert schafft es seit Jahren leider nicht in die Browser.

Aber es ist auch mit Fingerprints - einer Art Prüfsumme - nicht trivial herauszufinden, ob das Zertifikat der Authorisierungsstelle wirklich korrekt ist. Wenn das Zertifikat auf dem Transportweg ausgetauscht wird, kann auch der Fingerprint auf dem gleichen Weg getauscht werden. Am besten wäre es den Fingerprint auf einer dritten Seite zu finden, oder die Webseite mit dem Zertifikat durch eine andere Authorisierungsstelle zertifizieren zu lassen.

Let's Encrypt ist eine grossartige Initiative der Electronic Frontier Foundation (EFF), die sicher dafür sorgen wird, dass mehr verschlüsselt wird. Aber auch da wird nur bestätigt, dass derjenigem, der das Zertifikat bestellt auch die Webseite betreibt, ohne zu prüfen, wer das eigentlich ist.

Worüber ich an dieser Stelle noch gar nichts geschrieben habe, ist, dass ich keinen Einfluss darauf habe, welche CA-Zertifikate der Browser, den ich benutze, standardmässig installiert hat. Ich kann mir noch nicht einmal sicher sein, dass der Browser nicht mit falschen oder gefälschten Zertifikaten ausgeliefert wird. Es ist alles eine Frage des Vertrauens.

Also zusammengefasst:

Wir haben kein technologisches, sondern ein strukturelles Problem.

Zertifikate taugen dazu, Verschlüsselung zwischen einem Client und einem Server sicher zu stellen. Da der Entschlüsselungs-Key nicht herausgegeben wird, kann sichergestellt werden, dass es niemand mitlesen kann (davon ausgenommen sind lange laufende Brute-Force-Attacken, die mit ausreichend Rechenleistung Erfolge haben könnten, nicht müssen!). Der Identität hinter "einfachen" Zertifikaten, wie sie von Hobbyisten verwendet werden, würde ich nicht vertrauen. Höherwertige Zertifikate machen eine erweiterte Identitätsprüfung, da ist es sicherer - auch nicht 100% - dass der Betreiber auch wirklich der Betreiber ist.


Und wer das alles für Humbug hält, dem sei gesagt, dass einer der grössten Hoster Deutschlands 99% der Zertifikate mit dem einfachsten Verfahren ausstellen lässt.

Trackbacks

Keine Trackbacks

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Alphager am :

*Ich finde deine Kritik an host-verified Zertifikaten zwar verständlich, aber überzogen.

Ein einfaches Beispiel: Wenn ich https://deimeke.net aufrufe und deinen Blog lese reicht es mir vollkommen, dass der Server, mit dem Ich rede, tatsächlich unter deimeke.net erreichbar war, als die CA nachgefragt hat. Ich muss nicht wissen, dass du als Mensch tatsächlich du bist und dass du in XY wohnst.

Dirk Deimeke am :

*Das ist exakt das, was ich mit "Also zusammengefasst" geschrieben habe - soweit unterschiedlich ist es also nicht.

Jens Link am :

*Und wer tiefer in das Thema einsteigen will, dem sei https://www.feistyduck.com/books/bulletproof-ssl-and-tls/ empfohlen.

Bernd Wachter am :

*
QUOTE:
Höherwertige Zertifikate machen eine erweiterte Identitätsprüfung, da ist es sicherer - auch nicht 100% - dass der Betreiber auch wirklich der Betreiber ist.


Das Problem hier ist weniger die Identitaetspruefung, sondern eher dass auf jedem System eine Liste nicht vertrauenswuerdiger CAs vorinstalliert ist. Ueblicherweise sogar mehr als eine -- NSS und gnutls/openssl haben schon laenger keinen kompatiblen CA store mehr, und Chrome bringt seine eigene Liste mit (unter Windows ist das ganze auch nicht besser). p11-kit fixt das langsam -- und behebt auch ein anderes grosses Problem: Ein User sollte in der Lage sein eigene Zertifikate zu blacklisten oder hinzuzufuegen, ohne den CA-Store des Systems anzufassen.

Mit der Infrastruktur CAs sinnvoll zu verwalten kommen wir aber wieder zurueck zum urspruenglichen Problem: Ohne CA pinning ist die Identitaetspruefung wertlos, da ein Angreifer einfach eine der kaputteren CAs nimmt um sich ein Zertifikat zu beschaffen. CA pinning skaliert aber nicht, und * ist eine recht gute Methode um einzugrenzen welche CAs problematisch sein koennten.

Das System mit "wir laden jede Menge vertauenswuerdige CAs" ist unrettbar kaputt, aber alle Versuche der Browserentwickler etwas zu verbessern drehen sich darum die Position eben dieser problematischen CAs zu staerken.

allo am :

*Schlimmer: Du hast nicht die Kontrolle, wem deine Nutzer trauen.

DU kannst alle CAs rauswerfen und Zertifikate selber prüfen.
Aber dein Nutzer kommt zu dir. Du hast dir die beste CA die du finden konntest ausgesucht. Die NSA faked deine Seite und hat ein Zertifikat von der korruptesten. Der Browser des Nutzers akzeptiert es. Und du hast keine Chance es zu verhindern oder auch nur zu merken.

Dirk Deimeke am :

*Yip, das stimmt selbstverständlich, es sei denn, ich setze einen Proxy ein, der die Zertifikate prüft. So passiert es bei uns in der Bank.

Kommentar schreiben

Gravatar, Favatar, Pavatar, Identica, Twitter, MyBlogLog Autoren-Bilder werden unterstützt.
BBCode-Formatierung erlaubt
Umschließende Sterne heben ein Wort hervor (*wort*), per _wort_ kann ein Wort unterstrichen werden.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
:'(  :-)  :-|  :-O  :-(  8-)  :-D  :-P  ;-) 
Formular-Optionen