Sry, das ich mich jetzt erst wieder melde ...
Danke für die bisherigen Antworten ...
Bei der Frage sollte man nicht nur die technischen Aspekte betrachten sondern auch Aspekte des Marketings. Heutzutage vertrauen Leute einem Online-Shop weniger, wenn er nicht verschlüsselt läuft. Das liegt vor allem daran, dass ein normaler Anwender nicht unterscheiden kann ob nun der Bezahlvorgang und die Eingabe der persönlichen Daten wirklich gesichert wird oder nicht. Amazon da als Vergleich anzuführen, ist ein schlechtes Beispiel, denn Amazon hat bereits einen Namen, so dass bereits ein Vorschuss-Vertrauen bei den Usern vorhanden ist. Bei einem neuen Shop ist das eher nicht der Fall.
Eine Ansicht die ich so noch nicht betrachtet habe ...
Aber auch technisch gesehen macht es durchaus Sinn zumindest eingeloggte User komplett über HTTPS laufen zu lassen. Dadurch werden die Session-Daten nochmal zusätzlich geschützt, so dass über ein MITM (z.B. auf dem Router des Users) keine Cookies u.ä. abgefangen werden können.
Als eher ein Punkt für generelle https Verwendung
Zu beachten ist allerdings, dass Caching-Mechanismen nur noch begrenzt greifen, wenn HTTPS im Einsatz ist. Die Anzahl der Requests auf dem Webserver steigt dadurch also an und natürlich entsteht auch eine etwas höhere Last auf dem Server, da ja sämtliche Daten ver- und entschlüsselt werden müssen.
Da ich meine Daten intern selber Cache und somit eine Anfrage an die DB, wenn sie schon einmal gestellt wurde, direkt von der Application (Cache), zurückgegeben wird habe ich hier schon ein Zeitersparniss.
Ich denke aber du Beziehst Dich hier auf den Brwoser Cache usw, oder?
Als Beispiel zu meinem Cache: Artikeldaten ändern sich nur, wenn ich diese editiere oder verändert habe.
Und solange das nicht der Fall ist kann ich die bereits erzeugte Ansicht wieder darstellen (serialize,unserialze), ohne das System, bzw. die Datenbank wieder mit einer Anfragen zu belasten.
Spart mir Zeit und erhöht die Performance enorm, sowie auch die "Sicherheit", da die DB nicht zu 100% einbezogen ist ...
Natürlich hoch gerechnet auf x² Users...
Im übrigen kann man auch beim Zend-Framework alternativ die Umlenkung auf HTTPS via Rewrite-Regeln in der htaccess machen oder die SSL-Terminierung in einem vorgeschalteten Loadbalancer oder Caching-Layer durchführen. Dadurch ist man etwas unabhängiger vom Framework.
Hier kann ich dir nicht ganz folgen ...
htaccess ist klar. Ok, wäre eine alternative.
Aber hier wäre das gleiche Probelm.
Es muss vorher entschieden werden ob https, oder nicht Verwendung findet.
Sprich wenn der Nutzer sich auf der Seite "Zubehoer/Gruppe/Artikelansicht" befindet und sich spontan da zu entscheidet sich einzuloggen, werden die Daten (user/pw) eingegeben und der POST abgesendet ... es wird die loginmaske aber wie hier im Forum, permant angezeigt und die URL ist auch immer noch die gleiche "Zubehoer/Gruppe/Artikelansicht" .
Somit muss ich ja bevor die Seite "Zubehoer/Gruppe/Artikelansicht" an den Client gesendet wird entscheiden welche Übertragungsart Verwendung findet.
Auf jeden Fall würde ich bei einer teilweisen SSL-Verschlüsselung irgendwo auf der Website einen Hinweis anbringen, dass die Daten beim (und nach dem) Login verschlüsselt werden, so dass der User gleich sieht, dass es nicht komplett ohne SSL läuft. Und seine Daten sicher sind. Das schafft Vertrauen und zeigt, dass dem Betreiber der Datenschutz wichtig ist. So könnte man z.B. den Login-Link mit "Login über unseren sicheren Server" kennzeichnen und beim Klick darauf auf SSL umschwenken. Dann sieht der User, dass es beim und nach dem Login verschlüsselt weiter geht.
Diese Variante, habe ich noch gar nicht betrachtet ...
Eigentlich eine gängige Praxis ....
Hier wäre ein Lösungsansatz ...
Der Nutzer kann entscheiden, ob er verschlüsselt, oder nicht.
Einen Button für "verschlüsselte Anmeldung" einbinden und nach Bestätigung direkt auf https umschalten Auth/Index/Login umleiten und an den Client die Eingabemaske senden ...
Und solange der Nutzer dann angemeldet ist bleibt auch https aktiv ....
meiner Meinung nach hast du keine Nennenswerten Nachteile durch die permantente Verwendung von verschlüsselten Verbindungen. Jeder Nutzer der Seite erzeugt allerdings bei dir ein bisschen mehr Rechenlast. Wenn das für dich kein Problem darstellt, dann stelle alles auf https um. Ich finde, dass es durchaus ein sinnvolles Ziel ist, seinen gesamten Webtraffic nur noch über verschlüsselte Verbindungen zu leiten.
Mmmh ....
Wenn man abwägt, unter der Argumentation von Bitmuncher (vertrauen des user) und justj , könnte man es wirklich auf https stehen lassen...