SSL Schlüssel aushandlung ab wann gilt es...

[MatzeA]

Servus,

folgender Fall:

Auf einer http://...
Seite befindet sich ein formular mit der aktion="https://....

beim absenden dieses Formulars.
Wie verhält sich der client?
Wird der Schlüssel vorher oder nachher ausgehandelt.
Sprich ist die Übertragung der Formular Daten sicher ja oder nein.

Gruss Matze

[Erwin]

Mahlzeit

folgender Fall:

Auf einer http://...
Seite befindet sich ein formular mit der aktion="https://....
Sprich ist die Übertragung der Formular Daten sicher ja oder nein.

Sischr ;-)

Gruss, Erwin

[MatzeA]

Servus,»»

Sischr ;-)

sicher?
Gibt es da was zum nachlesen wo es definiert ist?

Gruss Matze

[Erwin]

Mahlzeit Matze

sicher?
Gibt es da was zum nachlesen wo es definiert ist?

Guck mal bei Netscape.

Noch ein Beispiel: eine https - Seite mit htacces fordert die Credentials an - auch diese werden verschlüsselt übertragen.

Sowas siehst du beispielsweise auch in einem TCP - Dump.

Gruss, Erwin

[MatzeA]

Mahlzeit Matze

Wohl bekomms.

Guck mal bei Netscape.

Noch ein Beispiel: eine https - Seite mit htacces fordert die Credentials an - auch diese werden verschlüsselt übertragen.

Sowas siehst du beispielsweise auch in einem TCP - Dump.

Vielen Dank

Gruss Matze

[Henryk Plötz]

Moin,

sicher?

"Formular abschicken" ist ein ganz normaler HTTP-Request. Der Request kann sinnvollerweise erst abgeschickt werden, wenn die dadrunterliegende Verbindung steht. Bei HTTPS liegt SSL zwischen HTTP und TCP. Ziehe deine eigenen Schlüsse.

Ja, manchmal ist 1+1 tatsächlich 2. Wirklich.

[MatzeA]

Servus,

siehst du,
ich dachte http und https würden auf der gleichen ebene liegen.

Gruss Matze

[eeye]

Hallo

ich dachte http und https würden auf der gleichen ebene liegen.

Dachte ich eigentlich auch. Wenn ich das aus dem Studium noch richtig weiss:

HTTP / HTTPS -> OSI Schicht 4
SSL
TCP          -> OSI Schicht 3

Bei HTTPS liegt zwischen den beiden Schichten (quasi auf 3.5) eben noch zusätzliche SSL, wie Henryk schon geschrieben hat.

PS: Keine garantie auf die korrektheit der OSI Schichten ;-)

Grüsse, eeye

[Sven Rautenberg]

Moin!

Dachte ich eigentlich auch. Wenn ich das aus dem Studium noch richtig weiss:

HTTP / HTTPS -> OSI Schicht 4
SSL
TCP          -> OSI Schicht 3

Bei HTTPS liegt zwischen den beiden Schichten (quasi auf 3.5) eben noch zusätzliche SSL, wie Henryk schon geschrieben hat.

PS: Keine garantie auf die korrektheit der OSI Schichten ;-)

Die sind sowieso immer falsch, wenn man OSI und TCP/IP vergleicht. Bei TCP/IP sind einige OSI-Schichten zu einer zusammengefaßt. HTTP ist in der obersten Schicht - und das war IMHO OSI Nr. 7. Das IP-Protokoll liegt, wenn ich nicht ganz falsch bin, auf Schicht Nr. 3, und demnach muß TCP auf Schicht Nummer 4.

Dass SSL als Zwischenschicht zwischen HTTP und TCP eingefügt ist, ist aber richtig. :) Würde ich jedenfalls auch meinen.

- Sven Rautenberg

[eeye]

Hi

Die sind sowieso immer falsch, wenn man OSI und TCP/IP vergleicht. Bei TCP/IP sind einige OSI-Schichten zu einer zusammengefaßt. HTTP ist in der obersten Schicht - und das war IMHO OSI Nr. 7. Das IP-Protokoll liegt, wenn ich nicht ganz falsch bin, auf Schicht Nr. 3, und demnach muß TCP auf Schicht Nummer 4.

Hier mal das OSI-Referenzmodell: http://tiss.zdv.uni-tuebingen.de/webroot/vorlesungen/ha/sose2000/pp97html/Abschnitt1/sld003.htm

Hm. Ich muss dir (oder Dir?!) in sofern Recht geben, dass dieses 7-Schichten-Modell in der Realität nicht so richtig greift (insbesondere überhalb von Schicht 4). Aber HTTP gehört als Protokoll IMHO nicht in die Anwendungsschicht sondern doch eher in die Transportschicht (4).
Dann wäre TCP/IP auf 3 und laut dem link oben die MAC Adressierung auf 2. 1 ist dann die "Bitübertragungs" oder physikalische Ebene.

Naja, ist aber wirklich kein Thema dass ich breittreten will, da es kaum Praxisrelevanz hat.
Da vergrab ich mich doch lieber in irgendeiner w3c recommendation ;)

Fast schon feierabendliche Grüsse, eeye

[Sven Rautenberg]

Moin!

Hier mal das OSI-Referenzmodell: http://tiss.zdv.uni-tuebingen.de/webroot/vorlesungen/ha/sose2000/pp97html/Abschnitt1/sld003.htm

Eine Gegenüberstellung zu TCP/IP wäre hilfreicher gewesen. :)

Aber was nicht ist, kann ja noch werden:
<img src="http://www.neveprise.net/docbase/xhtml/systech/net/tcpip/osi.png" border="0" alt=""><img src="http://www.neveprise.net/docbase/xhtml/systech/net/tcpip/tcpip5.png" border="0" alt="">

Von http://www.neveprise.net/docbase/xhtml/systech/net/tcpip/#1.1

Hm. Ich muss dir (oder Dir?!) in sofern Recht geben, dass dieses 7-Schichten-Modell in der Realität nicht so richtig greift (insbesondere überhalb von Schicht 4). Aber HTTP gehört als Protokoll IMHO nicht in die Anwendungsschicht sondern doch eher in die Transportschicht (4).

Eben nicht. HTTP ist die höchste Protokollebene, die gesprochen wird, genauso wie FTP, SSH etc. Also kommt die in die oberste Schicht.

Dann wäre TCP/IP auf 3 und laut dem link oben die MAC Adressierung auf 2. 1 ist dann die "Bitübertragungs" oder physikalische Ebene.

TCP und IP sind zwei verschiedene Schichten. Das eine setzt auf dem anderen auf. IP ist die untere Schicht und sorgt für die logische Netzwerkverbindung (z.B. über Router hinweg), während TCP (und auch UDP) die eigentlichen Nutzdaten kapseln und übermitteln - und deren Transport sicherstellen, oder auch nicht.

Naja, ist aber wirklich kein Thema dass ich breittreten will, da es kaum Praxisrelevanz hat.

OSI zumindest hat keine Praxisrelevant - außer ständig bei allen Gelegenheiten als Referenzdesign zitiert zu werden. :)

- Sven Rautenberg

[eeye]

N'Abend

Moin!

Aus'm Norden?

Eine Gegenüberstellung zu TCP/IP wäre hilfreicher gewesen. :)

korrekt :)

[besseres bild als meins]

Eben nicht. HTTP ist die höchste Protokollebene, die gesprochen wird, genauso wie FTP, SSH etc. Also kommt die in die oberste Schicht.

Hm hm hm. Ich kann dir immer noch nicht so ganz recht geben. Ich glaub nämlich nicht dass man die beiden Stacks einfach so aufeinandermappen kann. Mit höchster Protokollebene erkläre ich mich einverstanden. Also die höchste Ebene im rechten Stack. Aber bei der Protokollebene (HTTP _ist_ ein Protokoll) sind wir IMHO in OSI-Ebene 4! Danach kommt eben noch der SessionLayer (Sessions mit HTTP?!), der  PresentationLayer (OS Abhängig) und der Anwenundgslayer, womit wir dann ganz oben, weit überhalb der Protokolle wären...

OSI zumindest hat keine Praxisrelevant - außer ständig bei allen Gelegenheiten als Referenzdesign zitiert zu werden. :)

hehe, full ACK.

Wie dem auch sei, bevor ich hier noch mehr halbwissen verbreite, geh ich jetzt in Feierabend + Wochenende und schlag mal in meinemNetzwerktechnik-Skript nach ;-)

Liebe Grüsse & ein tolles WE

eeye

[Andreas Korthaus]

Hi!

Eben nicht. HTTP ist die höchste Protokollebene, die gesprochen wird, genauso wie FTP, SSH etc. Also kommt die in die oberste Schicht.
Hm hm hm. Ich kann dir immer noch nicht so ganz recht geben. Ich glaub nämlich nicht dass man die beiden Stacks einfach so aufeinandermappen kann.

Nein, kann man nicht, da sich da einiges vermischt, oder auch komplett rausfällt, aber dass HTTP, FTP, Telnet... Anwendungs-Protokolle sind das steht vollkommen außer Frage.

Siehe z.B.
http://de.wikipedia.org/wiki/TCP/IP-Referenzmodell
http://www.incremental.de/talks/phpconf-2003-caching/http/

<img src="http://www.incremental.de/talks/phpconf-2003-caching/images/internet_protokolle.gif" border="0" alt="">

Mit höchster Protokollebene erkläre ich mich einverstanden. Also die höchste Ebene im rechten Stack. Aber bei der Protokollebene (HTTP _ist_ ein Protokoll) sind wir IMHO in OSI-Ebene 4!

Nein. Stellst Du HTTP und TCP auf eine Stufe? Oder wo würdest Du TCP hinpacken? HTTP und die anderen Anwendungs-Protokolle verwenden TCP oder UDP als Transportschicht, welches die Schicht 4 im OSI-Modell darstellt. Meinst Du nur weil über HTTP Daten transportiert werden ist es gehört es zur Transportschicht? Dann gehören ja alle Protokolle in diese Schicht, da auch über IP, Ethernet, WLAN und was weiß ich alles Daten transportiert werden. Nur eben auf verschiedenen Abstraktions-Ebenen. Ein Webserver ist eine Anwendung, genauso wie ein Browser, und die verwenden direkt HTTP als Protokoll der Anwendungsschicht. FTP-Server verwenden das FTP Protokoll usw. Diese beiden Protokolle verwenden z.B. TCP als Transportschicht. Diese Schicht weiß nicht für welche Anwendung sie Daten transportiert, ist hier auch vollkommen irrelevant, die Schicht bekommt nur Datenpakete von irgendeiner Anwendung (über das Betriebssystem), und schickt die dahin wo die Anwendung will. TCP verwendet dann wieder eine andere Schicht um ein einzelnes Datenpaket zu übertragen, z.B. ist es dann einem IP-Paket egal ob das jetzt TCP oder UDP ist, es guckt nur dass dieses eine Paket vom eigenen Rechner zum Zielrechner kommt, und auch IP verwendet irgendein Protokoll um das Paket über irgendeine Leitung zur nächst möglichen Gegenstelle zu transportieren...

Das Ziel der Transportschicht ist es lediglich die Daten irgendeines Aawenungs-Protokolls auf einen Zielrechner zu übertragen, TCP stellt dabei sicher dass es ankommt, UDP schickt die Daten einfach los ohne die Zustellung zu kontrollieren. Das hat aber noch nichts mit den eigentlichen Anwendungen wie Webserver/Browser zu tun, die können nur mit vollständigen HTTP-Paketen umgehen, womit HTTP wie gesagt ein Protokoll der Anwendungs-Ebene darstellt.

Danach kommt eben noch der SessionLayer (Sessions mit HTTP?!),

Wie gesagt, es gibt nicht überall Entsprechungen, mit anderen Protokollen der Anwendungs-Ebene gibt es durchaus Sessions, z.B. SSH, FTP...

der  PresentationLayer (OS Abhängig) und der Anwenundgslayer, womit wir dann ganz oben, weit überhalb der Protokolle wären...

Das sind alles Protokolle. Ethernet ist ein Protokoll, IP ist ein Protokoll, TCP ist ein Protokoll, und auch HTTP, nur eben auf verschiedenen Abstraktions-Ebenen. Die oberen Schichten des OSI-Modells werden halt mehr oder weniger vollständig von den Protokollen der Anwendungs-Ebene implementiert.

Viele Grüße
Andreas

[eeye]

Hi Andreas, Hi Sven

Vielen Dank für die ausführlichen Antworten! So langsam klärt sich das Schichten-Durcheinander in meinem Kopf.

Also nach erneuter Sortierung gehört dann TCP auf Layer 4 (Transport) und IP eher auf Layer 3 (Network) die unteren Layer werden zB von Ethernet oder PPP realisiert (DataLink + Physical) und alle darüberliegenden Schichten werden dann von den Anwendungsprotokollen (zB HTTP) umgesetzt...

Danach kommt eben noch der SessionLayer (Sessions mit HTTP?!),
Wie gesagt, es gibt nicht überall Entsprechungen, mit anderen Protokollen der Anwendungs-Ebene gibt es durchaus Sessions, z.B. SSH, FTP...

Auch das hab ich nun verstanden :) Klar kann man mit HTTP keine Sessions realisieren, wohl aber mit anderen Protokollen der gleichen OSI-Ebene. Denkfehler meinerseits...

Für den interesierten c't Leser ist in der c't 1/04 in dem Artikel über Netzwerkprozessoren (ich glaub ab S.160) auch nochmal ein schönes Diagramm mit der Gegenüberstellung von OSI, TCP/IP und Protokollen.
Das entspricht so etwa dem was auch hier im Thread zu lesen ist (also zumindest dem was die anderen geschrieben haben ;)

Liebe Grüsse, eeye

[Sven Rautenberg]

Moin!

Auf einer http://...
Seite befindet sich ein formular mit der aktion="https://....

beim absenden dieses Formulars.
Wie verhält sich der client?
Wird der Schlüssel vorher oder nachher ausgehandelt.
Sprich ist die Übertragung der Formular Daten sicher ja oder nein.

Obwohl der komplette Request verschlüsselt abgehandelt wird, würde ich so ein Formular nur äußerst ungern abschicken. Ich sehe ja die Action-Zieladresse nicht. Erst wenn ich mich entschieden habe, das Formular abzuschicken, informiert mich der Browser, dass ich jetzt sicher surfe. Genausogut könnten die Daten aber unverschlüsselt über die Leitung gehen - ich habe in diesem Moment nicht mehr die Möglichkeit, sie zurückzuhalten.

Deshalb macht es ziemlich viel Sinn, auch das Formular bereits per HTTPS zu übertragen. Dann weiß ich gleich, dass das Formular sicher ist, und werde vom Browser nur dann informiert, dass ich etwas unsicheres tue, wenn die Action-Zieladresse wieder auf HTTP lautet - und kann dann abbrechen.

- Sven Rautenberg

[Henryk Plötz]

Moin,

Deshalb macht es ziemlich viel Sinn, auch das Formular bereits per HTTPS zu übertragen. Dann weiß ich gleich, dass das Formular sicher ist, und werde vom Browser nur dann informiert, dass ich etwas unsicheres tue, wenn die Action-Zieladresse wieder auf HTTP lautet - und kann dann abbrechen.

Schlimmer noch: Wenn das Formular über HTTP kommt, könnte es zwischendurch manipuliert worden sein und jemand hätte aus dem eigentlich sicheren HTTPS-Ziel jedes beliebiges machen können.

[MatzeA]

Servus,

ich gebe dir da völlig recht.
Es war ja auch eher eine Theretische Frage, wie die Daten in einem solchen Fall übermittelt werden.

Im grossen Netzwerk kommt meine Fall leider öfters vor.

Gruss Matze