Funktionsweise SSL/TSL

[Garack]

hey Wikipedia und Internet haben mir bisher nicht weitergeholfen denn eins ist unklar:

Es wird ja zuerst eine unverschlüsselte Verbindung zwischen Client und Server aufgebaut. Dort kommt es u.U. zur Identifizierung durch Zertifikate und es werden Daten ausgetauscht um so den Verschlüsselungsalgorithmus zu
definieren.

Meine Fragen:

1. Hier kann doch jeder (der das technische know-how hat) mithören und so die Verschlüsselung durch den Algorithmus knacken...

2. Beispie Email: Ich sende eine SSL Email über Gmail-Account und Thunderbird los-) Diese geht doch direkt an Gmail. Wer sollte da mithören? Mein Provider? Geht diese Mail von Gmail dann auch verschlüsselt weiter an den Empfänger?

3. Heute kam bei AVAStTeine Einblendung das AVAST nun auch verschlüsselte Mails überprüfen kann. Wie kann das gehen?

Danke Leute!

 

[benneq]

Für 1.: Die Sicherheit steht und fällt mir den Zertifikaten. Du lädst dir das Zertifikat von Gmail runter und dann schaut dein Browser in der Datenbank der gültigen Zertifikate nach, ob es gültig ist. Dann wird mittels asymmetrischer Verschlüsselung verarbeitet, was die Verbindung besonders sicher macht.
D.h. natürlich ist das ganze relativ(!) simpel hackbar: "Man in the Middle" heißt das Zauberwort. Man schaltet einen Rechner zwischen dich und Gmail und in Wirklichkeit kommunizierst du mit diesem Rechner. Bsp:
a. Du forderst den Loginbereich von Gmail an: Aber in Wirklichkeit forderst du den Loginbereich von diesem Rechner an und der fordert ihn von Gmail an und leitet nur die Daten weiter.
b. Du forderst das Zertifikat an: Hier wird's tricky. Der Rechner (in the Middle) schickt dir SEIN Zertifikat, der 0815 User klickt dann einfach auf `Annehmen`. Gleichzeitig baut aber auch der Rechner (in the Middle) eine Verbindung zu Gmail auf und fordert dessen Zertifikat an. So gesehen ist deine Verbindung nur auf diesem Rechner (in the Middle) unverschlüsselt und alles kann mitgelesen und/oder manipuliert werden.

Für 2.: Ganz einfach: Zwischen dir und Gmail sitzen zig andere Rechner. Z.B. könntest du deinen Router (für's Gedankenexperiment) einfach durch einen anderen Computer ersetzen, der könnte ohne Verschlüsselung problemlos deine Email lesen.

 

[DjNDB]

Wenn du einen Eindruck haben möchtest wie unsicher HTTPS im Bezug auf das Zertifikatsystem ist, kann ich dir den unterhaltsamen Vortrag Certificate Authority Collapse vom 29C3 empfehlen.
http://www.youtube.com/watch?v=CNXl56HuJaE

Man kann festhalten, bisher gibt es keine bessere Alternative, und es ist besser als nichts.

Dann wird mittels asymmetrischer Verschlüsselung verarbeitet, was die Verbindung besonders sicher macht.

Asymm. Verschlüsselung wird nur verwendet um einen symmetrischen schlüssel auszutauschen, der anschließend verwendet wird.

 

[Garack]

Für 2.: Ganz einfach: Zwischen dir und Gmail sitzen zig andere Rechner. Z.B. könntest du deinen Router (für's Gedankenexperiment) einfach durch einen anderen Computer ersetzen, der könnte ohne Verschlüsselung problemlos deine Email lesen.

Danke, welche Rechner sitzen denn da ausser der DNS Server beim ISP?

Ja das mit den Zertifikaten ist klar und man in the middle, aber zuerst wird doch eh nur eine unverschlüsselte verbindung aufgebaut und darin der entschlüsselungsalgorithmus getauscht. das alleine sollte ja schon super unsicher sein.

 

[DjNDB]

Danke, welche Rechner sitzen denn da ausser der DNS Server beim ISP?

Der DNS Server sitzt nicht "dazwischen". Du solltest dich mal einlesen wie das Internet funktioniert.
Zwischen dir und GMail sitzen allerlei Router. Eine Eindruck davon bekommst du wenn du wenn du ein traceroute laufen lässt. Unter Windows z.B. in der Kommandozeile mit

tracert www.gmail.com

Das sind alles Systeme denen du implizit vertraust, dass sie die Daten nicht verändern. Du kannst selbst nicht auswählen welche Route deine IP Pakete nehmen, hast also keinen Einfluss wo sie landen.

Ergänzung (4. März 2013)

Ja das mit den Zertifikaten ist klar und man in the middle, aber zuerst wird doch eh nur eine unverschlüsselte verbindung aufgebaut und darin der entschlüsselungsalgorithmus getauscht. das alleine sollte ja schon super unsicher sein.

Der erste Schlüsselaustausch ist Immer ein Problem.
Wie soll der sicher geschehen?
Man hat ja eben noch keine verschlüsselte Verbindung, über die man den Schlüssel austauschen könnte.
Dafür gibt es aber zumindest den Asymm. Schlüssel oder Diffie-Hellman.

Man sollte HTTPS nicht als Rundumschutz sondern als zusätzliche Hürde für Angreifer betrachten.

 

[misu]

Das hier ist nicht ganz richtig.

Man-in-the-middle funktioniert im Allgm. nicht. Der Public-Key ist Teil des Zertifikats (nach X.509). Die gültigkeit eines Zertifikats kann über eine Chain-of-Trust zuverlässig(!) verifiziert werden. Die Root-Zertifikate sind im Browser fest eingebaut und werden nur bei der installation des Browser heruntergeladen.

Die einzige Möglichkeit für Man-in-the-middle ist die Installation des Browser oder wenn der Zertifikatherausgeber schlampt (selten, aber siehe Digicert). Wenn das beides nicht der Fall ist, ist die Verbindung 100% sicher.

 

[Daaron]

So siehts aus.
Tatsächlich sind sogenannte Snakeoil-Zertifikate sogar noch sicherer als reguläre, wenn man sie richtig einsetzt. Indem ich als MENSCH genau weiß, dass das Snakeoil zu meiner gewünschten Gegenstelle gehört, kann sich kein Feind dazwischen klemmen. Niemand kann den übergeordneten Cert manipulieren, oder meinen Browser.

 

[Garack]

Hey danke was ist ein übergeordneter CERT?

 

[misu]

Zertifikate sind hierarchisch organisiert. Es gibt sogenannte Root-Certs, die stehen an der Spitze und dürfen beliebige untergeordnete Zertifikate unterschreiben. Die untergeorneten Zertifikate sind vom übergeordneten Zertifikataussteller unterschrieben, nach unten hin nehmen die Rechte ab. Auf Webseiteneben besitzen die Seiten nur noch Zertifikate, die keine weiteren Zertifikate unterschreiben dürfen.

Wenn du jetzt eine Webseite anrufst, dann passiert folgendes. Dein Browser lädt das Zertifikat. Er prüft, von wem es unterschrieben ist. Wenn es kein Root Zertifikat ist, dann fragt er den Unterschrieber nach seinem Zertifikat. Das ganze wiederholt sich, bis sich jemand selbst unterschreibt oder man bei einem Root Zertifikat angelangt (das ja bereits im Browser vorhanden ist). Da das unterschreiben mittels krypografischer Hashsummen erfolgt, ist der Schritt von einem Zertifikat zum nächsten in der Kette abgesichert. Nur wenn am Schluss ein Root-Zertifikat steht, ist das Zertifikat, das gerade getestet werden soll, gültig.

Die Hierarchie ist übrigens auch eines der großen Probleme. Es gibt sehr viel Zertifikatsaussteller. Und wenn einer Bullshit macht/gehackt wird, jedenfalls ein böses Zertifikat ausstellt (z.b. für google.com), dann kann sich dir gegenüber jemand glaubhaft als Google ausgeben. Je mehr Zertifikatsaussteller, je großer die Zertifikatshierarchie, desto problematischer ist das ganze.

Für die Praxis ist das aber bisher nicht relevant gewesen. Schließlich muss ja der böse Hacker nicht nur ein passendes Zertifikat haben (was schwer ist), er muss dazu auch noch den Man-in-the-middle machen. Bisher ists wohl noch mit deutlich einfacheren Mitteln möglich, den Leuten mittels Malware das Geld aus der Tasche zu ziehen.

Andererseits werden wahrscheinlich Staaten in der Lage sein, sowohl valide Zertifikate zu bekommen, als auch sich zwischen die Kommunikation zu schalten. Hoffen wir also, dass wir nix zu verbergen haben, respektive es nur nette Leute auf der anderen Seite gibt.

 

[Daaron]

Für die Praxis ist das aber bisher nicht relevant gewesen. Schließlich muss ja der böse Hacker nicht nur ein passendes Zertifikat haben (was schwer ist), er muss dazu auch noch den Man-in-the-middle machen.

http://en.wikipedia.org/wiki/DigiNotar
Das ist der erste Schritt, um eine gefälschte Seite ins Netz zu stellen. Die nächste sinnvolle Komponente in einem solchen Angriff wären z.B. Phishing-Mails oder ein DNS-Changer - Virus. Cross Site Scripting würde natürlich auch gehen. Schwupp-di-wupp, schon hast du eine komplette Sammlung Zugangsdaten für Banken, PayPal, Mail, Foren,...

 

[mensch183]

hey Wikipedia und Internet haben mir bisher nicht weitergeholfen denn eins ist unklar:

Es wird ja zuerst eine unverschlüsselte Verbindung zwischen Client und Server aufgebaut.
...
1. Hier kann doch jeder (der das technische know-how hat) mithören und so die Verschlüsselung durch den Algorithmus knacken...

zu 1) Nein. Hast nur die richtige Stelle in Wikipedia nicht gefunden: http://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol

Damit du verstehst, was da steht, solltest du die beiden folgenden Dinge wenigstens grundlegend verstanden haben:
http://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem
http://de.wikipedia.org/wiki/Public-Key-Infrastruktur

 

[misu]

@Daaron: Das wird aber niemand machen, solange er die gefakte Seite auch einfach ohne Certificate ins Netz stellen kann, und ohne SSL dann natürlich. Angriffe auf die TLS/SSL Infrastruktur werden wohl erst dann passieren, wenns ohne nicht mehr geht, was aber momentan noch nicht der Fall ist. Phishing ist im Moment einfach noch zu einfach

 

[Daaron]

DigiNotar wurde ja bereits kompromittiert. Wer sagt, dass das bei anderen Root Certs besser aussieht?
Aber ja, es ist die Mühe nicht wert. Mit viel weniger Aufwand kriegt man bereits 90% der potentiellen "Kunden" eines komplexen CA-Hacks.

http://www.zdnet.com/spy-agencies-hit-by-ca-hack-iran-suspected-2062301930/
Es hat sich aber echt gelohnt, DigiNotar zu überfallen...

 

[misu]

Ich bin übrigens jedes Jahr auf dem Chaos Communication Congress, ich hab die verlinkte Präsentation live gesehen

Zur Problematik der CAs (und vor allem Sub-CAs) gabs diese tolle Geschichte: Honest Achmed - Used Cards and Certificates

Ergänzung (5. März 2013)

Da gabs übrigens auch letztlich ein Statements von ein paar Crypto Experten (u.a. Bruce Schneide, wenn ich mich richtig erinnere) auf der RSA Con. Deren Kommentar war, dass die Sicherheit beim Transport eigentlich eh egal ist, da bei Bedarf sowieso beide End-Points gehackt sind.

 

[Garack]

zu 1) Nein. Hast nur die richtige Stelle in Wikipedia nicht gefunden: http://de.wikipedia.org/wiki/Transport_Layer_Security#TLS_Handshake_Protocol

Damit du verstehst, was da steht, solltest du die beiden folgenden Dinge wenigstens grundlegend verstanden haben:
http://de.wikipedia.org/wiki/Asymmetrisches_Kryptosystem
http://de.wikipedia.org/wiki/Public-Key-Infrastruktur

Ja das habe ich nun verstanden. Der Hacker allerdings kriegt ja am Anfang alles mit, auch den Zertifikataustausch. Das Zertifikat von Beispielsweise Paypal muss ja auch irgendwie geprüft werden. also auf dem Rechner (Im Browser) des Anzugreifenden liegen..Das ist wohl die Schwachstelle..Oder auch die Fälschung von Zertifikaten...

 

[misu]

Das schöne ist, der Hacker darf ruhig alles mitbekommen. Solange die Zertifikate in Ordnung sind, ist man trotzdem sicher.

Nur wenn er einen auf Man-in-the-middle macht und gleichzeitig ein gültiges Zertifikat besitzt, dann hat man ein Problem. Beides zusammen ist aber sehr schwer und eher unwahrscheinlich.
Viel eher wird infiziert man sich mit einem DNS-umleitenden Trojaner. Wenn man aber einen Nutzer schon auf eine gefakte Seite umleiten kann, dann kann man die gefakte Seite auch einfach NICHT mit SSL sichern, und es wird überhaupt kein gefälschtes Zertifikat benötigt. Der Großteil der Nutzer wirds nicht bemerken, dass er sich auf einer unverschlüsselten Seite bewegt.
Deswegen: Zertifikate fälschen ist im Moment einfach nicht besonders attraktiv, weils viel einfacher geht.

 

[Garack]

Ja das stimmt allerdings misu; Wie siehts denn beim Email-Verkehr aus? Da gibs auch Zertifikate oder? Also wenn ich ne Mail von Thunderbird sende über gmail, dann prüft TB ob das Gmail Zertifikat echt ist oder? Und wenn ich nen eigenen Email Provider habe, nutzt der dann auch Zertifikate?

Antwort:Ja, habs grade in TB gesehen

Noch was zu den Zertifikaten: Ich kann in TB ja alle einsehen. Ein Hacker kann sich ja auch TB installieren und alle Zertifikate einsehen. Wie weiss der Server, z.B. gmail dann dass genau ich es bin der eine Anfrage stellt, denn die Zertifikate sind doch in allen Thunderbird`s gleich ?

 

[misu]

E-Mail ist ein ganz traurige Geschichte, praktisch alles mit E-Mails läuft völlig unverschlüsselt ab. Insbesondere der Austausch zwischen unterschiedlichen E-Mail Providers. Es gibt und gab Versuche für verschlüsselte Mails, einigermaßen erfolgreich PGP und bisher total Flop die DE-Mail, die aber bisher alle gescheitert sind.
D.h. aber nicht, dass E-Mails nicht teilweise abgesichert sind, z.b. wenn man sich in das G-Mail Webinterface einloggt, ist zumindest die letzte Meile zum Enduser verschlüsselt. Aber eben nicht der Versand vom google-Account zum gmx-Account.
Das Problem bei E-Mails ist, dass eigentlich jeder User ein eigenes Zertifikat benötigen würde (das ist genau das, was PGP macht). Aber pro-User-Zertifikate ist halt recht aufwändig und bisher wohl die Mühe nicht wert.
Bei E-Mails darf man auch getrost davon ausgehen, dass das zumindest jeder staatliche Akteur mitlesen kann, weils eben einerseits unverschlüsselt und andererseits ein recht einfach, standardisiertes Textformat ist.

 

[Daaron]

Was meinst du mit "eigenem Mail Provider"? Betreibst du einen eigenen Mailserver?
Ob du eine verschlüsselte Verbindung mit dem Postausgangsserver herstellen kannst hängt davon ab, ob der Server es anbietet. Wenn für den Server keine SSL-Zertifikate hinterlegt sind gehts gar nicht. Wenn er auf Snakeoil-Zertifikaten läuft, dann wirst du wenigstens einmalig eine Warnung erhalten.

WENN ein vollwertiges Zertifikat vorliegt oder du wenigstens dem Snakeoil vertraust, und WENN du es entsprechend in deinem Mailclient anschaltest, dann wird der Client sich per StartTLS zum Server verbinden. Das heißt: Erst wird eine unverschlüsselte Verbindung geöffnet, übre die die Verschlüsselung ausgehandelt wird. Login + Mails werden dann nach erfolgreicher Verhandlung verschlüsselt übertragen.

Was dabei NICHT verschlüsselt ist:
1.) die Mail, während sie sich auf einem der beteiligten Mailserver liegt
2.) die Verbindung vom Posteingangsserver zum Empfänger, außer der Empfänger hat da ebenfalls StartTLS aktiv

Wenn du nicht willst, dass Mails mitgelesen werden, dann hilft nur eine Verschlüsselung z.B. per PGP. Das heißt aber, dass deine Empfänger deinen Schlüssel kennen müssen. Nur wer deinen Public Key kennt, kann deine Mails lesen. Für alle anderen ist es nur Datenbrei, für den selbst große Serverfarmen ein paar Jahrhunderte zur Dekodierung brauchen.
Genauso kann man Mails auch einfach nur signieren. Sie sind nicht verschlüsselt, aber man erkennt, dass die Mail TATSÄCHLICH von Max Müller kommt, und nicht gefälscht wurde.

 

[Garack]

Hey Super das beantwortet alle Meine Fragen. Danke euch.

Und ja ein eigener Mailsever, bzw. ne Homepage die ich bei netcup habe. Sehe aber auch das dort StartTLS im Thunderbird eingestellt ist.