Re: SSL: unsichere Connections kappen.

Autor: Philipp Schafft <lion_at_uugrn.org>
Datum: Thu, 24 Mar 2011 11:12:53 +0100
reflum,

ich bin mir nicht sicher ob es sinvoll ist auf dieses posting wirklich
zu antworten werde es aber dennoch mal versuchen.


On Wed, 2011-03-23 at 22:40 +0100, Raphael Eiselstein wrote:
> 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.

Ein passender Daemon wuerde genauso mit gewissen rechten laufen. Da er
deiner vorstellung nach Netzwerk steuer funktionen des kernels benutzen
muss, z.b. mit einer firewall interagiren, braucht er auch recht grosse
rechte. Vermutlich ist es also wieder ein Daemon der mit vollen root
rechten leuft weil die rechte seperirung die die verschiedenen Systeme
bitene 'genau diesen Fall nicht abdecken'^TM.

Arbeiten mit libs wie pcap ist offt eine gefaerliche Sache. Das spielen
damit neigt dazu selbst anfaellig zu sein. Z.B. gegen buffer-overflows.
Ich gebe auch zu bedenken dass das was du forderst kein Problem ist das
nur sich mit TCP stroemen beschaeftigt. Man denke an TLS ueber UDP (z.B.
OpenVPN) oder HTTPS ueber HTTP Proxy (also TLS innerhalb der
Anwendungsschicht!). Selbst wenn man diese loesen wuerde kommt man bei
dingen wie TLS ueber Dynamiches SSH portforwarding an, oder was ist mit
Zweibel-Implementierungen wie Tor?

Ich moechte hier nur erstmal zeigen das ein solcher Daemon in seiner
sniff-schicht ziemlich komplex wird bevor er wirklich signifikant
Anwedungsfaelle abdenkt. Das heisst Komplexitaet in einer Sicht voll mit
variablen buffern und vielen void pointern.


> 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
> ...

Im grunde alles verlockende features. Aber mehr dazu spaeder.
Was hier wieder dazu kommt: Wenn man nun benutzer Spezifiche
black/grey/white/sonstwiebunt-Listen will? Auf diesem layer ist _nicht_
(sinvoll) erkennbar zu welchem user ein socket gehoert (Keywords:
iptables manpage, manpage zu unix sockets, SCM_CREDENTIALS, dup*(),
SCM_RIGHTS, disskussion um Ident-Protokoll... (und diese keywords
betreffen nur sockets die auf dem lokalen system enden, durchgehende
sockets wie fuer NAT sind noch deutlich unsicherer zu identifiziren)).
Mehr dazu siehe unten.


> 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.

Meisst du das in form das man ueber einen lokalen dienst auf die
externen inhalte zugreifen kann oder nur ueber diesen den status
erhaelt? Bin mir grade nicht sicher wie du das meinst:

Fuer esten fall:
Das wuerde signifikante browser anpassungen benoetigen weil die rechner
namen und die pfade signifikanter teil er security infrakstrucktur der
browser sind. Angefangen mit dem einfachen fall 'zu wem gehoert das
cookie' oder eben viel komplexere XSS attacken.

Fuer den zweiten fall:
Warum nicht lieber ueber ein deutlich effizienteres unix socket/FIFO
basierendes interface?


> Ü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?

Nun. Nicht das ich wuesste. Ein paar der grunde habe ich oben schon
erleutert.

Mein gegenvorschlag ist einfach: Warum nicht die TLS/SSL
Implementirungen fixen? Nenenswert sind vorallem OpenSSL und GnuTLS.
Meines wissens nach decken diese mit abstand den groessten Teil des
marktes ab. Was spricht dagegenen einfach diese auf einen stand zu
bringen das sie sinvolle defaults haben (also als Beispiel keine
schwachen Algos per default zu lassen, keine schwachen Protokoll
versionen zu lassen...). OpenSSL hat einen store fuer zertifikarte.
warum nicht auch einen fuer CRLs? Viele systeme liefern die Certs eh in
getrenntem packet aus. Warum nicht wie bei OpenSSH unter Debian auch ein
blacklist packet das gewisse dinge von anfang an unterbindet, zusetzlich
zu den CRLs?

Wie ich oben schon gezeigt habe kann ein zentraler Daemon nicht in einer
sicheren weisse Benutzer definierte parameter verwenden. Dass heisst das
die Client implementirung eh vollstaendig vorhanden sein muss. Ist diese
weiterhin bugy so kann sich der Anwender eh nicht drauf verlassen.

Du sprachst oben auch davon das ein bereits infizirter client nicht mehr
in der lage ist sinvoll zu pruefen. Macht es einen unterschied? Eine CA
sellt zerts nicht nach irgend einer form von audits aus. Seiten mit
validem zert koennen genauso boese sein wie welche ohne. Sprich ob ich
nun ueber einen bug von einer 'guten' oder 'schlechten' seite infiziert
werde ist relative egal. Im zweifellsfalle macht ein Schardcode einfach
als naechstes eine plain HTTP verbindung auf und laed dann darueber
code/daten/befehle nach oder redirected alles ueber HTTP, zeigt dem
benutzer einen falschen status an, unterbindet die darstellung von
warnungen oder aehnlichem. Fazit: ist belibige software die mit benutzer
rechten leuft infizirt worden kann man allem was unter diesem benutzer
leuft nimmer trauen (Informations Theory: Ein system kann sich nicht
selbst beurteilen, es kann nur von ausen beurtelt werden, Theologie:
Wenn es einen allmaechtigen Gott (Angreifer) gibt kann er mit seiner
allmacht dafuer sorgen das wir ihn nie nadchweisen koennen).


Ich hoffe das ich dir ein wenig weiter helfen konnte.

-- 
Philipp.
 (Rah of PH2)

-- 
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 24.03.2011

Dieses Archiv wurde generiert von hypermail 2.2.0 : 24.03.2011 CET