Re: SSL: unsichere Connections kappen.

[Philipp Schafft <lion@xxxxxxxxx>]

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
> vertrauenswuerdige" 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 ueberwacht 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,
> koennten am Benutzer vorbei auch gefaelschte Zertifikate oder anderweitig
> problematisches Material im Browser landen mit der Folge, dass der
> Browser diese kuenftig 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 koennte auch weiter reichende Funktionen anbieten, zum
> Beispiel 
> 
> * Statisik fuehren, wie oft Zertifikate von verschiedenen CAs angeboten
>   werden
> * sich merken, welcher Server welches Zertifikat verwendet und bei
>   *Aenderung* zum Beispiel neues Ablaufdatum oder andere CA das
>   entsprechend vermerkt (oder blockiert), aehnlich wie "known_hosts" bei
>   OpenSSH
> * Asyncrones Update von Revocation-Lists, verschiedene Anbieter
> * Analysieren, welche (vor kurzem noch gueltige) Zertifikate
>   zwischenzeitlich zurueckgezogen wurden
> * Whitelists unabhaengig vom Webbroser, d.h. der kann selbst bei einmal
>   akzeptierten Zertifikaten keine Verbindung mehr dahin aufbauen, d.h.
>   man muss es zusaetzlich an zentraler Stelle (im Daemon) konfigurieren
> * DNS-Lookups zwecks Plausibilitaetschecks, Speicherung, Warnung bei
>   IP-(Range-)Aenderung, (zB Key wurde entfuehrt und DNS kompromittiert) 
> * DNS-Lookups gegen Blacklists etwa wie dnsbl?
> * DNS-Lookups ueber 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 koennte auch zB Anhand einer Bookmark-Liste oder einer wie
> auch immer aufgebauten Hostliste periodisch SSL-Zertifikate pruefen und
> Warnungen erzeugen, falls bestimmte Zertifikate in naechster Zeit
> ablaufen (zB wenn man selbst eigene SSL-Server irgendwo laufen hat),
> bzw. fuer solche VIP-SSL-Zertifikate auch regelmaessig pruefen, dass es
> damit keine Probleme gibt, etwa weil die (eigene?) CA zwischenzeitlich
> auf der Blackliste gelandet ist oder Intermediate-Zertifikate
> zurueckgezogen wurden, etc.
> 
> Die Kommunikation zwischen dem Daemon und zB einem Webbrowser koennte
> mglw. ueber bestehende "safe browsing"-Schnittstellen erfolgen, etwa
> indem man dort "http://localhost:10443/path/to/service"; angibt. Die
> Warnung wuerde 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?


> Ueber eine Webseite koennte man per Webbrowser auf den daemon zugreifen,
> aehnlich wie bei http://localhost:631/"; wenn man cups laufen hat.

> Das Teil waere unabhaengig von einer bestimmten Client-Implementierung und
> wuerde zB gleichmassen bei Firefox, Thunderbird (IMAPs/POP3s/...),
> wget/curl/lynx/... funktionieren. Denkbar waere auch der Einsatz auf
> NAT-Routern, um bspw. SSL-Pannen fuer Windows-Rechner zu verhindern.
> 
> Gibts sowas in der Art schon? Waere 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/