SSL: unsichere Connections kappen.

Autor: Raphael Eiselstein <rabe_at_uugrn.org>
Datum: Wed, 23 Mar 2011 22:40:17 +0100
Hallo zusammen,

angesichts der aktuellen SSL-Security-Diskussion (zB
http://heise.de/-1212986) stellt sich mir die Frage, ob man "nicht
vertrauenswürdige" SSL-Connections nicht auf tcp-ebene erkennen und dort
direkt kappen kann?

Mir schwebt sowas vor, dass ein daemon-Prozess per pcap permanent
SSL-Handshakes überwacht und je nach "Schweregrad" Warnungen ausgibt
oder die jeweilige TCP-Session direkt blockiert, wenn ein
Server-Zertifikat von einer in Ungnade gefallenen CA signiert wurde oder
schwache Hashes wie md5 verwendet werden.

Nachteil bei browsergebundenen Checks: die laufen alle mit
Benutzerrechten, d.h. sobald der Browser einmal kompromittiert ist,
könnten am Benutzer vorbei auch gefälschte Zertifikate oder anderweitig
problematisches Material im Browser landen mit der Folge, dass der
Browser diese künftig einfach so akzeptiert.

So ein Daemon könnte auch weiter reichende Funktionen anbieten, zum
Beispiel 

* Statisik führen, wie oft Zertifikate von verschiedenen CAs angeboten
  werden
* sich merken, welcher Server welches Zertifikat verwendet und bei
  *Änderung* zum Beispiel neues Ablaufdatum oder andere CA das
  entsprechend vermerkt (oder blockiert), ähnlich wie "known_hosts" bei
  OpenSSH
* Asyncrones Update von Revocation-Lists, verschiedene Anbieter
* Analysieren, welche (vor kurzem noch gültige) Zertifikate
  zwischenzeitlich zurückgezogen wurden
* Whitelists unabhängig vom Webbroser, d.h. der kann selbst bei einmal
  akzeptierten Zertifikaten keine Verbindung mehr dahin aufbauen, d.h.
  man muss es zusätzlich an zentraler Stelle (im Daemon) konfigurieren
* DNS-Lookups zwecks Plausibilitätschecks, Speicherung, Warnung bei
  IP-(Range-)Änderung, (zB Key wurde entführt und DNS kompromittiert) 
* DNS-Lookups gegen Blacklists etwa wie dnsbl?
* DNS-Lookups über verschiedene DNS-Server um DNS-Spooling zu erkennen
...

So ein daemon könnte auch zB Anhand einer Bookmark-Liste oder einer wie
auch immer aufgebauten Hostliste periodisch SSL-Zertifikate prüfen und
Warnungen erzeugen, falls bestimmte Zertifikate in nächster Zeit
ablaufen (zB wenn man selbst eigene SSL-Server irgendwo laufen hat),
bzw. für solche VIP-SSL-Zertifikate auch regelmäßig prüfen, dass es
damit keine Probleme gibt, etwa weil die (eigene?) CA zwischenzeitlich
auf der Blackliste gelandet ist oder Intermediate-Zertifikate
zurückgezogen wurden, etc.

Die Kommunikation zwischen dem Daemon und zB einem Webbrowser könnte
mglw. über bestehende "safe browsing"-Schnittstellen erfolgen, etwa
indem man dort "http://localhost:10443/path/to/service" angibt. Die
Warnung würde dann nicht von zB google kommen sondern von localhost.

Über eine Webseite könnte man per Webbrowser auf den daemon zugreifen,
ähnlich wie bei http://localhost:631/" wenn man cups laufen hat.

Das Teil wäre unabhängig von einer bestimmten Client-Implementierung und
würde zB gleichmaßen bei Firefox, Thunderbird (IMAPs/POP3s/...),
wget/curl/lynx/... funktionieren. Denkbar wäre auch der Einsatz auf
NAT-Routern, um bspw. SSL-Pannen für Windows-Rechner zu verhindern.

Gibts sowas in der Art schon? Wäre das nicht eine Antwort auf generische
SSL-Probleme mit Anwendungssoftware?

Gruß
Raphael

-- 
Raphael Eiselstein <rabe@uugrn.org>               http://rabe.uugrn.org/
xmpp:freibyterægmx.de  | https://www.xing.com/profile/Raphael_Eiselstein   
GnuPG:                E7B2 1D66 3AF2 EDC7 9828  6D7A 9CDA 3E7B 10CA 9F2D
.........|.........|.........|.........|.........|.........|.........|..


-- 
UUGRN e.V. http://www.uugrn.org/
http://mailman.uugrn.org/mailman/listinfo/uugrn
Wiki: https://wiki.uugrn.org/UUGRN:Mailingliste
Archiv: http://lists.uugrn.org/

Empfangen am 23.03.2011

Dieses Archiv wurde generiert von hypermail 2.2.0 : 23.03.2011 CET