[linux-l] tor sicherheitsfrage

[Steffen Schulz]

On 070111 at 13:40, Benjamin Schieder wrote:
> On 11.01.2007 13:09:03, Ivan F. Villanueva B. wrote:
> Damit waere es moeglich. Drei Schwachstellen sehe ich hier:
> 	1) Du verwendest Tor um den DNS Namen deiner Bank aufzuloesen.
> 	   Schlechte Idee, sollte man in die /etc/hosts eintragen.
> 	2) Ich habe zufaellig ein SSL Zertifikat fuer den DNS Namen deiner
> 	   Bank. Merke: Pro IP Adresse und Service (HTTP in dem Fall) kann
> 	   nur ein Zertifikat verwendet werden.

Die beiden halte ich fuer Unsinn. Ob am anderen Ende deine Bank steht,
kannst du am effektivsten ueber das Zertifikat beurteilen. 

Im uebrigen ist es mit Anonymitaet nicht mehr weit her, wenn man DNS
nicht ueber Tor macht.

> 	3) Du weisst den SSL Fingerprint deiner Bank nicht und klickst die
> 	   Browsermeldung ueber ein geaendertes Zertifikat einfach weg.
> 
> Punkt 3) ist wohl der, den du ansprichst. Ja, FF meldet geaenderte
> Zertifikate. Hoffe ich. Mozilla hat es gemacht.

Geaenderte Zertifikate? Mozilla merkt sich Zertifikate und sagt
gesondert bescheid, wenn ein neues(womoeglich gueltiges) kommt?
Wohl kaum, oder?

Mozilla/FF und andere kennen die ueblichen CA-Certifikate. Wenn du was
bekommst, was nicht von diesen unterschrieben ist und was nicht in
deiner whitelist steht, bekommst du eine entsprechende Meldung.


Aus der CACert-Diskussion kam ich uebrigens zu dem Schluss, dass man
eher whitelists betreiben sollte als CAs oder gar zusaetzlichen CAs zu
trauen. Die Unterschrift von einer 'trusted' CA kann in den meisten
Faellen nur einen guten Hinweis auf die Gueltigkeit geben.

Das mag als extrem erscheinen, aber zumindest fuer die typischen
kleineren CAs von cacert abwaerts fahr ich diese Policy.

Ich riskiere zB lieber, dass jmd meine erste Verbindung zum 23C3-Wiki
angreift und ich das falsche Cert akzeptiere(was ich dann vermutlich
spaeter merke, wenn der Angreifer mal nicht angreift), als dass ich das
CCC-CA-certificate einbinde und dann den Luxus habe, weitere CCC-Sites
nicht whitelisten zu muessen. Denn wenn dieses mal kompromittiert ist,
kann so ein Angriff auf wichtige Anwendungen(Banking) uebergreifen und
ich werde genau gar nichts bemerken.


Es gibt uebrigens durchaus Moeglichkeiten, die grandios mangelhafte
Sicherheit von SSL zu verbessern. Zum Beispiel, kurz gesagt, indem man
den kritischen Login als zusaetzlichen Exponenten im DH-Keyexchange
benutzt: http://www.bmoeller.de/pdf/soke-asiaccs2006.pdf

Damit kann ein Angreifer je Login genau einmal das Passwort raten.
Raet er falsch, klappt der Login nicht. Offline-bruteforce erfordert
das brechen des DH-Problems.

Sowas ist gerade auf dem Weg in die reale Welt. Ich hoffe es kommt an..

mfg
pepe
-- 
       _----------------
 (o< ·-_    Less CO2    |  _o)                          +47/611-344-01
 //\    | for more ice! |  /\\  .o) .o)        gpg --recv-key A04D7875
 V_/_    ---------------  _\_V _(\)_(\)    mailto: pepe at cbg.dyndns.org
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 189 bytes
Beschreibung: Digital signature
URL         : <https://mlists.in-berlin.de/pipermail/linux-l-mlists.in-berlin.de/attachments/20070111/83c4b726/attachment.sig>