Hi h-h-h
Das ist eigentlich nicht nötig. Wenn der Shop insgesamt unter SSL läuft. Denn dann wird die initiale SID ja schon innerhalb des verschlüsselten Kontext vergeben.
Die Krücke (bleiben wir mal bei dem Arbeitstitel) ansich funktioniert ja (mein Apache, der nur auf 443 horcht, fühlt sich für jeden Request zuständig, soweit ich das jetzt überblicken kann und ich bei den Anpassungen alle Funktionen mal aufgerufen habe).
Das heisst, dass die notwendigen Eingriffe in den Core durchaus überschaubar wären. Ob jetzt auch das Cookie nur innerhalb des SSL-Kontext funktionieren soll oder darf, müsste man dann ausdiskutieren. Sauber umgesetzt würde es das, wenn der Nutzer die Verschlüsselung via Konstante aktiviert, ganz klar.
Allerdings weis ich mangels Erfahrung nun nicht, wie sich das dann mit mobile devices verhält .... können die dann auch SSL-Cookies oder würde es dort eines fallbacks bedurfen?
Mir ist aber ansich nicht klar, warum nun ausgerechnet die Cookieproblematik nicht zuende entwickelt wurde. Die Ansätze sind ja da. Wenn es an anderer Stelle dann hakt ... dazu müsste mal einer vom Team was sagen.
Ich bin gern bereit, da unterstützend tätig zu werden, habe aber schlicht die Zeit nicht, mich durch den gesamten Code zu wühlen und betroffene Stellen zu suchen.
Die Fragen, die man ausdiskutieren sollte, lauten:
1. Macht es überhaupt Sinn, nur Teilkommunikation zu verschlüsseln?
2. Wenn ja, welchen Vorteil sollte dieses Vorgehen haben?
3. Welche Nachteile hätte eine komplette Verschlüsselung?
Mal meine Meinung dazu:
Eine Teilverschlüsselung stammt aus den Anfängen der Verschlüsselung überhaupt. SSL-Connections waren einfach langsamer (und sind es auch heute noch) - handshaking usw. erzeugt Overhead - und man wollte das reduzieren.
Das muss man aber heute nicht mehr
Den Unterschied kann man allenfalls messen - subjektiv wird den keiner feststellen können. Und der Zugewinn an Sicherheit sollte die eine oder andere Millisekunde deutlich aufwiegen.
Programmiertechnisch würde ein komplettes Verschlüsseln sogar einige Vereinfachungen bedeuten. Nämlich spätestens da, wo bisher entschieden werden musste, ob der Parameter "SSL" übergeben werden muss oder nicht, da dieser bei meiner oben vorgeschlagenen Änderung schlichtweg ignoriert wird, da ENABLE_SSL dann als Masterkonstante fungiert. Über diese Konstante kann dann entschieden werden, ob eine traditionelle Kommunikation (also Protokollpingpong^^) genutzt werden soll oder eine moderne (alles SSL und gut isses).
Ich sags mal so: nutzt man die Konstante so, wie von mir vorgeschlagen, kann man ruhig mal einen falschen Parameter übergeben (oder ihn gar weglassen, wie es an einigen Stellen im Core ja auch geschieht) und läuft trotzdem nicht Gefahr, sich damit ein Loch aufzureissen.
Einen eventuellen Error-handler (HTTPS_SERVER ist nicht entsprechend konfiguriert) kann man vorsehen ... den bedarf es aber meiner Meinung nach in der ersten Ausbaustufe nicht. Man kann einem Admin soviel zutrauen, dass er die Konfiguration nach Anleitung wohl richtig machen dürfte an der Stelle
Für die Cookieproblematik müsste man eventuell eine neue Configvar einfügen, die den Switch zwischen unsecured und secured Cookie realisiert. Sauber wäre innerhalb einer ansonsten durchgezogenen SSL-Verschlüsselung auch das Cookie entsprechend zu behandeln. Hier sollte man aber - unabhängig vom restlichen Shop ... deswegen die neue var - einen fallback auf ungesicherte Cookies vorsehen.
