SSL/TLS: Sind die Daten oder die Verbindung verschlüsselt ?!

[Steffo]

Hallo liebe FI-Gemeinde...

Ich hatte eben eine ausführliche Diskussion über SSL bzw. TLS. Ich soll eine Präsentation darüber halten und habe auch schon einige Informationen zusammengetragen und dachte, dass ich die Funktionsweise verstanden habe.

Das Problem was ich jetzt habe ist, dass mein Gesprächspartner der Meinung ist, dass bei SSL (ich schreib jetzt nich mehr zusätlich TLS) nicht die Daten, sondern die Verbindung verschlüsselt ist.

So wie ich das verstehe tauschen Client und Server zuerst (unverschlüsselt) Informationen aus die zum einen Zertifikate (inkl. Public-key) und zum anderen die möglichen Verschlüsselungsalgorithmen beindhalten. [Handshake]

Im folgenden erstellt dann der Client einen "Master Key" oder auch Private Key, wie man es nun nennen mag, und verschlüsselt diesen mit dem Public Key des Servers. Der Server kann dann diese Schlüssel entschlüsseln indem er seinen zu dem Public Key passenden Privaten Schlüssel benutzt. Soweit ist noch alles gut und wir stimmen überein.

Wenn es aber nun um das versenden der Daten geht bin ich der Meinung, dass diese mit dem "Master Key", den ja nun beide Seiten kennen, verschlüsselt werden! [Record Layer] Hier werden die Daten fragmentiert, komprimiert, die MAC (Message Authentification Code) hinzugefügt und das Datenpaket inklusive der MAC verschlüsselt. Am Ende kommt noch der SSL-Header vor dieses nun verschlüsselte Paket.

Das geht dann meiner Meinung nach einfach rüber zum Server der dass dann entschlüsseln kann.

Demnach bin ich der Meinung, dass wenn man bei SSL von einer verschlüsselten Verbindung spricht, eigentlich meint, dass nach anfängerlichem Austausch über die Verfahren sowie der Schlüssel die Daten selbst verschlüsselt übertragen werden.

Mein Gesprächspartner ist aber der Meinung, dass die Verbindung verschlüsselt ist (was genau er damit meint kann er mir nicht einleuchtend erklären). Ich kenne leider keinen der sich noch damit auskennt/beschäftigt und hoffe hier auf Kollegen zu stoßen, die sich damit eventuell schonmal befasst haben oder sogar täglich damit zu tun haben ... Wie auch immer, ich würde mich über konstruktive Antworten zu dem Thema freuen und hoffe, dass sich am Ende klärt ob nun die Daten oder die Verbindung zwischen Server und Client verschlüsselt ist (apropos: Er vergleich die verschlüsselte Verbdinung mit einem "Tunnel", was meiner Meinung nach irgenwdie fehl am Platz ist ... [bezug auf VPN]).

Viele Grüße, Stefan

[bigvic]

Ich finde hier ist es schön erklärt.

[Steffo]

Schade, irgendwie ist die Seite nicht erreichbar ... Ich versuchs immer mal wieder ... Hat sonst noch wer Ahnung davon ?

[RipperFox]

Der Unterschied zwischen "Verbindung" und "Daten" :confused:

"Verbindung":

beschreibt einen logischen Zustand (eben, dass irgendwas mit irgendwas verbunden ist). Kann zusätzlich auch physikalisch sein.

"Daten": Daten eben - Informationen welche meistens über irgendeine "Verbindung" übertragen werden.

Von daher: Verschlüsselte Verbindung bedeutet, dass die übertragenen Daten verschlüsselt werden (was auch sonst!?). Ergo: Beide Aussagen haben für mich die selbe Bedeutung.

"Tunnel" bedeutet im Internet meist das Verpacken von einem Protokoll in ein anderes. Bsp.: HTTP wird verpackt in SSL, jenes in TCP, dieses in IP, PPP, Ethernet und das in ATM (bevor die Reise weiter geht).

Hier würde HTTP, welches eigentlich direkt in TCP verpackt wird, eben in SSL "getunnelt". Ebenso wird bei DSL oft IP in PPP gekapselt, statt direkt auf Ethernet verschickt.

Auch ein VPN macht nichts anderes: Z.B. Ethernet und alles was darüber lauft in via SSL verschlüsseln und in UDP verpacken -> IP -> usw..

Die Verschlüsselung ist bei Tunneln allerdings optional. (Bsp: GRE-Tunnel - Ist dann halt nicht besonders "Private")

Irgendwelche Unklarheiten?

Grüße Ripper

[hades]

SSL (Secure Socket Layer) ist nicht gleich TLS (Transport Layer Security).

TLS wird erst nachtraeglich mit einem Kommando auf der bereits bestehenden Verbindung (auf dem selben Port) aktiviert, z.B. geht bei SMTP beides (unverschluesselt und mit TLS verschluesselt) idR ueber TCP Port 25.

Eine mit SSL aktivierte Verschluesselung lauscht auf einem separaten Port, z.B. bei HTTPS idR auf TCP Port 443, und laesst auf diesem Port keine unverschluesselte Uebertragung zu.

[RipperFox]

@Hades: Der Unterschied ist, dass STARTTLS z.B. im Protokoll SMTP ein anderes Protokoll triggert (eben SSL) und dann nach erfolgter Verbindung (Tunnel) SMTP weiter gesprochen wird.

Das gleiche gilt z.B. für SLIP/PPP über serielle Links.

Ich schwelge noch in Erinnerungen an Unis mit Modemeinwahl, bei dem man nach dem Login "startppp" tippte, um dann eine PPP Session zu haben und dann "telnet" nutzen zu können.. Das Internet via PPP im BTX funktionierte ebenso krude.

Vom Prinzip immer noch egal, wie man das Kind nennt, oder?

Grüße

Ripper

[Steffo]

Danke für die Antworten! Die Animation über SSL konnte ich mittlerweile anschauen.

@hades: Im Internet steht überall, dass SSL 3.1 = TLS 1.0 ist... Ab da wird das ja von dieser IETF weiterentwickelt. Das die neueren Versionen von TLS nicht mit SSL gleichzusetzen sind, sind klar. Das mit den Ports hab ich noch nicht gelesen das das unterschiedlich ist... Hast du dazu eine Quelle ?

Zum Thema allgemein: Das war wohl ein Missverständnis. Der Kerl hat meine Aussage von "Daten werden verschlüsselt übertragen" damit verglichen, dass man z.B. mit PGP eine Datei nimmt, die verschlüsselt, und diese dann per E-Mail an jemand versendet. SSL funktioniert ja nicht so. Hierbei wird die E-Mail ja in Blöcke geteilt, diese komprimiert, eine MAC angehängt schließlich verschlüsselt (mit der vorher ausgetauschten Session Key) und mit einem SSL Header versehen. Am anderen Ende der Leitung passiert das Gegenteil...

Viele Grüße, Stefan

[Gnork]

Zum Thema allgemein: Das war wohl ein Missverständnis. Der Kerl hat meine Aussage von "Daten werden verschlüsselt übertragen" damit verglichen, dass man z.B. mit PGP eine Datei nimmt, die verschlüsselt, und diese dann per E-Mail an jemand versendet. SSL funktioniert ja nicht so. Hierbei wird die E-Mail ja in Blöcke geteilt, diese komprimiert, eine MAC angehängt schließlich verschlüsselt (mit der vorher ausgetauschten Session Key) und mit einem SSL Header versehen. Am anderen Ende der Leitung passiert das Gegenteil...

Also ich hab mir das zwar alles nicht angeschaut, aber ich denke mal, dass es hier eher darum geht, dass die Daten symmetrisch verschlüsselt werden.

[ardcore]

Jaja... das gute alte Diffie Hellman Problem.

Sorgt oft für Verwirrung

Diffie-Hellman-Schlüsselaustausch ? Wikipedia

[Gnork]

Jaja... das gute alte Diffie Hellman Problem.

Sorgt oft für Verwirrung

Diffie-Hellman-Schlüsselaustausch ? Wikipedia

Diffie Hellman hat als asymmetrischer Verschlüsselungsalgorithmus allerdings nichts mit der Datenverschlüsselung zu tun, sondern eher mit der Authentifizierung -> eben Schlüsselaustausch Bei der reinen symmetrischen Datenverschlüsselung wird dann eher auf z.B. AES zurückgegriffen.

[ardcore]

Diffie Hellman hat als asymmetrischer Verschlüsselungsalgorithmus allerdings nichts mit der Datenverschlüsselung zu tun

Dann erklär mal wie eine symetrische Verschlüsselung ohne die Zuhilfenahme von asymmetrischer Verschlüsselungsalgorithmen zum Austausch von Session-Schlüsseln funktionieren soll.

Hattest du den Link überhaupt gelesen oder nur nicht verstanden?

Zitat:

Der Diffie-Hellman-Schlüsselaustausch oder Diffie-Hellman-Merkle-Schlüsselaustausch ist ein Protokoll aus dem Bereich der Kryptografie. Mit ihm erzeugen zwei Kommunikationspartner einen geheimen Schlüssel, den nur diese beiden kennen. Dieser Schlüssel wird üblicherweise verwendet, um verschlüsselte Nachrichten mittels eines symmetrischen Kryptosystems zu übertragen.

[Gnork]

Dann erklär mal wie eine symetrische Verschlüsselung ohne die Zuhilfenahme von asymmetrischer Verschlüsselungsalgorithmen zum Austausch von Session-Schlüsseln funktionieren soll.

Hattest du den Link überhaupt gelesen oder nur nicht verstanden?

Nein ich habe den Link nicht gelesen, hatte allerdings geschrieben:

Also ich hab mir das zwar alles nicht angeschaut, aber ich denke mal, dass es hier eher darum geht, dass die Daten symmetrisch verschlüsselt werden.

Hier geht es ja eben um die Datenverschlüsselung, die eigentlich immer mit einem symmetrischen Verschlüsselungsalgorithmus stattfindet. Von einem Schlüsselaustausch habe ich nicht gesprochen, dass da DH Sinn macht, ist schon klar. Die Schlüssel werden über ein asymmetrisches Verfahren sicher ausgetauscht, danach kann man problemlos auf die symmetrische Verschlüsselung der Daten zurückgreifen, weil eben ein sicherer Schlüsselaustausch schon stattgefunden hat.