SSL-Verschlüsselung - Sicherheit

[max_payne]

Hallo

Mich würde interessieren, was die Verschlüsselung bringt.(Speziell der Aufbau eines Tunnels mit stunnel) Dass die Daten hierdurch nicht im klartext übertragen werden ist mir klar. Allerdings:
Wenn jemand mit Man-in-the-Middle, oä. daherkommt würde er doch auch den Schlüssel mitbekommen, oder?

edit: Titel geändert.....bin heute etwas müde

[preiti]

Kommst du mit Wikipedia auf englisch bzw. deutsch schon weiter? Die Links scheinen sehr interessant zu sein.
Soweit mir bekannt ist SSL gegen eine Man-in-the-Middle-Attake nicht anfällig, da der Tunnel im Normalfall nicht durchbrochen(weder von außen noch von innen) werden kann.

[wicked_one]

Der Wiki Artikel sollte dir alle deine Antworten liefern, sofern du ein bisserl dein Hirn anwirfst

asymmetrische Verschlüsselung ist ein Schlagwort

<ot>ich find ja dein Beitragstitel super... Vorteile von SSL - gegenüber was?</ot>

[martin]

Soweit mir bekannt ist SSL gegen eine Man-in-the-Middle-Attake nicht anfällig, da der Tunnel im Normalfall nicht durchbrochen(weder von außen noch von innen) werden kann.

also in einem LAN ist es überhaupt kein problem, eine ssl verbindung von einem anderen user zu kapern.

man nehme:

1. ein programm welches arp poison routing beherrscht
2. einen sniffer (meistens in punkt 1 schon integriert)
3. ein opfer, welches beim auftretenden zertifikatsfehler brav auf ja drückt - nicht sonderlich schwer zu finden
4. schon ist man der man-in-the-middle

achtung: das ist natürlich reine theorie, gegen den "produktiven" einsatz dieser methode sprechen einige paragraphen

[wicked_one]

Klingt nett, wird aber in der praxis nicht so funktionieren wie du dir das vorstellst

[max_payne]

naja ich denk da an einen "lauschangriff" bei dem der ISP den Traffic einfach auf einen anderen Port "spiegelt"

meine Frage ist konkret: ob der Key bei jedem Tunnelaufbau oder nur beim ersten übermittelt wird.

[wicked_one]

http://www.tecchannel.de/news/themen/business/413770/

hier ein interessanter Artikel, datiert auf 2003. Auch andere Artikel die auf Anfälligkeiten datieren einige Jahre zurück.

der letzte in Relation stehende Beitrag war um 2005, da gings aber darum, dass das iTAN verfahren nicht sicher sei, wenn nicht über SSL gelöst.

naja ich denk da an einen "lauschangriff" bei dem der ISP den Traffic einfach auf einen anderen Port "spiegelt"

darf er (offiziell, wenn überhaupt) ohnehin nur per gerichtsbeschluss. Der ISP müsste in diesem Fall den gesamten Handshake-Ablauf mitsniffen - und dies würde auch maximal erlauben Daten zu lesen, jedoch nicht zu manipulieren. Ausserdem werden bei der Erstellung Hashes verwendet, auch diese sind relativ schwer zurückzurechnen - Aber da du in dieser hinsicht ohnehin eine paranoia zu haben scheinst... vertraue nichts und niemandem.

meine Frage ist konkret: ob der Key bei jedem Tunnelaufbau oder nur beim ersten übermittelt wird.

für jede Session wird ein eigener Key generiert - das wäre alles auf Wiki nachzulesen.

[martin]

Klingt nett, wird aber in der praxis nicht so funktionieren wie du dir das vorstellst

oh doch, mit verbindungen die neu aufgebaut werden funktioniert das sehrwohl.

nachdem das auf einer microsoft security veranstaltung auf großer leinwand von den MS jungs selbst vorgeführt wurde habe ich es auch selbst ausprobiert - natürlich mit einverständnis des gegenübers.

ich werde das programm mit welchem dies (relativ) einfach möglich ist hier nicht verlinken, bei interesse einfach pn an mich.

[wicked_one]

nachdem das auf einer microsoft security veranstaltung auf großer leinwand von den MS jungs selbst vorgeführt wurde habe ich es auch selbst ausprobiert - natürlich mit einverständnis des gegenübers.

Ich hoffe halt, die MS Jungs haben auch die Lösung dafür angeboten...

verzeih die Frage, wann fand diese veranstaltung statt?

[martin]

Ich hoffe halt, die MS Jungs haben auch die Lösung dafür angeboten...

verzeih die Frage, wann fand diese veranstaltung statt?

eine wirklich simple lösung wie man das "abstellen" kann gibt es nicht, siehe http://de.wikipedia.org/wiki/ARP-Spoofing

wenn ich mich richtig erinnere waren das die microsoft big days 2004, die prozedur funktioniert aber nach wie vor.

wie zuvor erwähnt muss der user halt den zertifikatsfehler wegklicken, welche mit IE7 gott sei dank schon um einiges penetranter auf ein problem hinweisen als mit den vorigen versionen...

[wicked_one]

wie zuvor erwähnt muss der user halt den zertifikatsfehler wegklicken, welche mit IE7 gott sei dank schon um einiges penetranter auf ein problem hinweisen als mit den vorigen versionen...

Nun, jede Methode hat ihre anfälligkeiten und die liebste schwäche ist der Mensch... nicht allzu alte Meldungen über Phishing Attacken zeigen dies wieder.

Das ARP-Spoofing einfachst zu bewerkstelligen ist, ist klar...

SSL ist so sicher gestaltet wie ich mir den Mechanismus nur vorstellen kann..., die Attacke auf SSL selbst wurde ja gefixt.
wie gesagt, die schwachstelle bleibt der Mensch.

wenn man wirklich der MITM ist, und den Client dazu bringt einem zu vertrauen (also wirklich gephisht wurde) - dann ist diese Prozedur logischerweise möglich.

[ANOther]

Ich hoffe halt, die MS Jungs haben auch die Lösung dafür angeboten...

nein, haben sie nicht, denn der grund liegt in schicht 8, 1 über dem MS-einflussbereich...
(pkt 3 in martins aufzählung)

[wicked_one]

nein, haben sie nicht, denn der grund liegt in schicht 8, 1 über dem MS-einflussbereich...
(pkt 3 in martins aufzählung)

Hab meine "Denkfehler" auch mittlerweile bemerkt, hatte immer nur SSL an sich betrachtet, und den Layer 8 ausser acht gelassen (schande über mich)

[medice]

Zertifikat wegklicken is halt so eine Sache, denn solang bedeutende Seiten ihre Zertifikate in Unordnung halten wird der Anwender ja geradezu gedrillt das Wegklicken zu üben...

[lordpeng]

>3. ein opfer, welches beim auftretenden zertifikatsfehler brav auf ja drückt
>nicht sonderlich schwer zu finden

ich hab den thread jetzt zwar nur überflogen, daher kanns vielleicht sein, dass ich am thema vorbei red ...

die simpelste methode derlei probleme zu vermeiden, wär per richtlinie keine abgelaufenen oder unsicheren zertifikate zu, dann wird $USER nämlich gar nie auf 'akzeptieren' klicken können ... btw. wird bei uns hier zumindest intern so gehandhabt