Hi,

hab mal ne dumme Frage zu HTTPS/SSL. Wenn ich bei der Google login Seite bin..

https://www.google.com/accounts/Login?continue=http://www.google.de/&hl=de

...mich einlogge und dann in meinem HTTP Sniffer (z.B Live HTTP Headers für Firefox) schaue dann sehe ich meine Passwort im Klartext??? Ich dachte das sollte bei SSL grad nicht passieren!? Oder hab ich da jetzt nen Denkfehler.

Gefunden hab ich das ganze im Live HTTP Header unter dem ersten Request den Google macht beim einloggen...

https://www.google.com/accounts/LoginAuth?continue=http%3A%2F%2Fwww.google.de%2F&hl=de

Untere "Content-Length: 160" werden die Parameter aufgezählt und da steht mein Passwort im Klartext.

Vielen Dank

Jens

ist IMO dein denkfehler. der HTTP POST geht an www.google.com und ist schon verschlüsselt.

livehttpheaders zeigt nachfolgende HTTP GET auch mit https:// an. verschlüsselt wird erst eine (OSI-)schicht tiefer.

IMO ist da alles in ordnung.

edit: arghs, "Links automatisch umwandeln" ist manchmal doof.

s'Amstel

Vielen Dank für die Antwort, hab's verstanden...hätte aber gleich die nächste Frage.

Ich möchte von einer HTTP Seite ein Formular per POST an eine HTTPS Adresse schicken. Meine Frage ist...

Werden die Formulardaten veschlüsselt verschickt oder muss die Seite auf der das Formular ist schon HTTPS sein?

Danke

Jens

auch wenn der ursprungs-URL nur http:// war, werden die daten im POST bereits SSL-verschlüsselt übertragen.

meiner erfahrung nach simuliert es bei unbedarften usern allerdings etwas mehr sicherheit, wenn die ursprungsseite auch SSL-gesichert ist

edit: übrigens bestätigt sich ersteres auch dadurch, dass HTTP (vielerorts unbekanntermassen) verbindungslos ist.

s'Amstel

edit: übrigens bestätigt sich ersteres auch dadurch, dass HTTP (vielerorts unbekanntermassen) verbindungslos ist.

Mit HTTP kann man also Daten ohne eine Verbindung übertragen? Wow.

Ich denke du meinst zustandslos (stateless) , also eine Verbindung kennt keine früheren Verbindungen o.ä., sonsern ist immer eine eigene, abgeschlossene Übertragung. (Aus dem Grund wurden ja Cookies und danach dann die Session erfunden, um diesen Zustand der Zustandslosigkeit zu umgehen)

statuslos, ja, das meinte ich, danke

cookies und/oder sessions habe ich hier nicht explizit erwähnt, aber du meinst damit genau das richtige.

s'Amstel

auch wenn der ursprungs-URL nur http:// war, werden die daten im POST bereits SSL-verschlüsselt übertragen.

meiner erfahrung nach simuliert es bei unbedarften usern allerdings etwas mehr sicherheit, wenn die ursprungsseite auch SSL-gesichert ist

edit: übrigens bestätigt sich ersteres auch dadurch, dass HTTP (vielerorts unbekanntermassen) verbindungslos ist.

s'Amstel

Das heist also der Browser macht den SSL Handshake bevor er die Post Daten verschickt? Hier in der Abteilung sind wir uns grad uneinig. Die meissten sagen das die Form von einer https Seite los geschickt werden muss damit es funktioniert.

Danke

Jens

Das heist also der Browser macht den SSL Handshake bevor er die Post Daten verschickt? Hier in der Abteilung sind wir uns grad uneinig. Die meissten sagen das die Form von einer https Seite los geschickt werden muss damit es funktioniert.

Nein, denn es ist doch vollkommen egal was dein Browser an Daten hat oder wie er die bekommen hat. Er hat sie einfach und mehr weiß die Verbindung ja nicht. Selbst wenn die Daten über HTTPS gekommen sind, spielt das für jede weitere Verbindung keine Rolle mehr. Einzig der Browser kann dir eine Meldung anzeigen, dass du dich wieder auf eine ungeschützte Seite bewegst wenn du auf einer geschützten bist. Das tut aber der Browser weil er das weiß.

Der SSL-Handshake wird immer für jede Verbindung gemacht, da sie ja nur einmalig ist. Jede weitere Verbindung ist wieder wie wenn nie eine davor gewesen wäre.

Es reicht also vollkommen, wenn nur die Action eine HTTPS-URL hat. Es geht ja auch nur um die Daten, die in diesem Moment übertragen werden.

Nachtrag:

Probier es doch einfach aus:

Schreib ein Skript auf dem Server, welches ein Form per Get annimmt. Dazu ein Form das per https gesendet wird. Das rufst du auf und schickst es ab, und nimmst dabei mit einem entsprechenden Tool den Datenverkehr auf (nicht HTTP-Headers, das hat die ent bzw noch nicht verschlüsselten Daten, weil es ja im Browser arbeitet).

Dann rufst du einfache die Action-URL im Browser auf, und gibst ihr andere Daten per GET mit (also ohne das Form angefragt zu haben). Diese Daten zeichnest du auch auf und schaust was beim Skript ankommt. Du wirst sehen, dass beim Skript beides korrekt ankommt und dass der Verkehr dennoch unlesbar ist.

ich erweitere die begründung von JesterDay um die theoretische möglichkeit des tests:

eine lokal abgelegte HTML-datei mit einem <form>, das mittels method POST und einem https:// in der action ein HTTP POST macht. und das klappt genauso, wie wenn die datei von einem webserver in eine URL gemapped wird.

s'Amstel