https

Moin moin,
kurze Frage in den Raum gestellt ...
Macht es Sinn, oder Unsinn einen Online Shop generell auf https laufen zu lassen ?

Ich habe wie hier im Forum eine permanente Login eingabemaske (2 input + button) und möchte die Anmeldung via https laufen lassen. Mein Problem ist nur das ich vorher (serverseitig) schon festlegen muss ob ich https verwende, oder nicht (MVC - Zend).

Begründung: Bevor die View und das Layout zusammengeführt und gerendert, sowie an den Client gesendet werden, habe ich die Möglichkeit den Schalter umzulegen.

Nun nochmal die Frage, habe ich einen nennenswerten Nachteil, wenn ich generell https verwende ?
 
Wenn ich mir solch großen Online-Händler anschaue wie Amazon, läuft die Seite nur bei der Anmeldung und (glaube ich) der Zahlungsabwicklung über HTTPS.

Also die Dinge, welche relevante Daten an Server sendet, werden verschlüsselt. M.E.n. macht dieses auch hauptsächlich Sinn für HTTPS.

Nachteile sind sicherlich der erhöhte Aufwand für HTTPS, wie die Zertifikate + Verlängerung, erhöhter Rechteaufwand usw. usf.

Ansonsten, kannst Dir ja mal die Vor- und Nachtteile von HTTPS durchlesen:
http://www.fmi.uni-jena.de/minet_mu...ilung+für+Didaktik/GDI/Erlaeuterung_HTTPS.pdf

Edit: Noch ein Link: http://de.onpage.org/wiki/HTTPS
 
Nun nochmal die Frage, habe ich einen nennenswerten Nachteil, wenn ich generell https verwende ?

Hi ByteSurfer,

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.

mfg
justj
 
Wenn man es geschickt macht, kann man nur für sicherheitskritische Funktionen (Login, Usereinstellungen etc.) beispielsweise das rechenintensivere ecdhe_ecdsa_aes_256_sha (oder ähnlich) aushandeln und für unwichtige Dinge (Bilder, öffentliche Textelemente usw.) z.B. das nicht so rechenaufwändige rsa_rc4_128_sha (oder ähnlich).

Letztens bin ich darüber gestolpert, dass ich keine Videos mehr auf youtube anschauen konnte, weil ich alle RC4 stromverschlüsselten Verbindungen (RC4 sollte man mittlerweile als unsicher betrachten) im Browser verboten habe. Dabei benutzte youtube das zur nicht so rechenintensiven Übertragung von Videos, was eigentlich schon sinnvoll ist.
Ich sah dann ewig den bekannten drehenden Kreisel und fragte mich, was da schiefläuft. Dann habe ich nach ein wenig debuggen gesehen, dass die Aushandlung fehlschlägt und Youtube Videos nur über RC4 und mit nicht so sicherem Schlüsseltausch überträgt.

Der Rest von Youtube samt Login hatte einen viel sichereren Schlüsseltausch und forward secrecy (ECDHE-ECDSA) und einen stärkeren Verschlüsselungsalgorithmus (AES).

Ist meiner Meinung nach schon ein fairer Kompromiss. Öffentliche Videos müssen jetzt nicht unbedingt so sicher und rechenintensiv übertragen werden wie Logins, aber wäre allgemein schon gut, wenn man konsequent bleibt und trotzdem die ganze Seite verschlüsselt übertragen lässt.
 
Letztens bin ich darüber gestolpert, dass ich keine Videos mehr auf youtube anschauen konnte, weil ich alle RC4 stromverschlüsselten Verbindungen (RC4 sollte man mittlerweile als unsicher betrachten) im Browser verboten habe. Dabei benutzte youtube das zur nicht so rechenintensiven Übertragung von Videos, was eigentlich schon sinnvoll ist.

Der Rest von Youtube samt Login hatte einen viel sichereren Schlüsseltausch und forward secrecy (ECDHE-ECDSA) und einen stärkeren Verschlüsselungsalgorithmus (AES).

Ist meiner Meinung nach schon ein fairer Kompromiss.

Ging mir genauso.
Sinnvoll kann das schon sein, jedoch muss ich jetzt wegen den Videos RC4 wieder unfreiwillig in meinem Browser erlauben. Damit bin ich aber wieder darauf angewiesen, dass andere Anbieter eben nicht RC4 als einzige oder primäre Verschlüsselungsmethoden nutzen.

Praktisch wäre es, wenn man pro Domain festlegen könnte.
Einige Banken haben auch vor kurzem noch RC4 als erste (oder einzige) mögliche Verschlüsselungsoption angeboten.
Wenn man RC4 im Browser jedoch deaktiviert, wäre eine andere Verschlüsselungsmethode aufgerufen.

Von daher sehe ich es schon als Sinnvoll von YT an, Videostreams nicht mit rechenintensiven Algorithmen zu verschlüsseln, jedoch ist man dann weiterhin auf anderen Webseiten mit RC4 eingeschränkt.

PS: Anscheinend verschlüsselt YT den Stream aber nur mit RC4 wenn man eingeloggt ist.
Bis ich herausgefunden hatte, dass es an RC4 lag, war nämlich meine Notlösung, das Video eingeloggt in meinen Abos zu suchen und dann in einem neuen privaten Fenster, in dem eben kein Login vorhanden war, den Videolink einzufügen. Da konnte ich seltsamerweiße den Stream anschauen, obwohl RC4 eben in meinem Browser nicht erlaubt war.
 
Diesen Nachteil würde ich clientseitig lösen mit einem Browser-Plugin. Also domainbezogene TLS-Richtlinien.
 
Macht es Sinn, oder Unsinn einen Online Shop generell auf https laufen zu lassen ?

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.

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. 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.

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.

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.
 
Letztens bin ich darüber gestolpert, dass ich keine Videos mehr auf youtube anschauen konnte, weil ich alle RC4 stromverschlüsselten Verbindungen (RC4 sollte man mittlerweile als unsicher betrachten) im Browser verboten habe. Dabei benutzte youtube das zur nicht so rechenintensiven Übertragung von Videos, was eigentlich schon sinnvoll ist.

ENDLICH weiß ich warum Youtube Videos bei mir über SSL nicht funktionieren. Ich finde das überhaupt nicht sinnvoll, RC4 ist praktisch gebrochen und deshalb sollte man auch die Unterstützung nach und nach dafür entfernen. Vor allem ist es schon fragwürdig keine Alternativen anzubieten, für den Fall das RC4 vom Client nicht unterstützt wird. AES ist schnell genug und wird mit modernen CPUs sogar von der Hardware unterstützt.

Davon abgesehen kann ich nur dazu raten Perfect Forward Secrecy zu nutzen, vor allem wenn über die gesicherte Verbindung auch Passwörter überragen werden. Ansonsten können mit dem privaten Schlüssel nachträglich alle Verbindungen wieder entschlüsselt werden. Wird PFS eingesetzt, dann haben passive Angreifer keine Chance selbst wenn sie den privaten Schlüssel schon kennen, sondern müssen einen Man in the Middle Angriff durchführen.
Das sind alle Ciphern mit DHE oder ECDHE in der Bezeichnung. Falls man noch den Internet Explorer 6 unterstützen möchte (der kann die modernen Ciphern nicht), dann kann man noch DES-CBC3-SHA aktivieren. 3DES ist zwar langsam aber trotzdem noch sicher im Vergleich zu RC4.
 
Ich finde das überhaupt nicht sinnvoll, RC4 ist praktisch gebrochen und deshalb sollte man auch die Unterstützung nach und nach dafür entfernen.

In sicherheitsrelevanten Bereichen sowieso.
Warum ist es bei öffentlichen Videos schlimm?

Vor allem ist es schon fragwürdig keine Alternativen anzubieten, für den Fall das RC4 vom Client nicht unterstützt wird. AES ist schnell genug und wird mit modernen CPUs sogar von der Hardware unterstützt.

Bist du YouTube-Entwickler und hast mal Benchmarks auf dem Produktiv-System mit TBit-Upstreams gemacht?

Ich glaube nicht, dass das völlig unabsichtlich so gemacht worden ist.

Davon abgesehen kann ich nur dazu raten Perfect Forward Secrecy zu nutzen, vor allem wenn über die gesicherte Verbindung auch Passwörter überragen werden. Ansonsten können mit dem privaten Schlüssel nachträglich alle Verbindungen wieder entschlüsselt werden. Wird PFS eingesetzt, dann haben passive Angreifer keine Chance selbst wenn sie den privaten Schlüssel schon kennen, sondern müssen einen Man in the Middle Angriff durchführen.

Ja. Ich habe doch gesagt, dass YouTube dies überall, nur nicht bei öffentlichen Videodaten macht.
Was wäre so schlimm, wenn ein Angreifer z.B. nun das übertragene Video Gangnam-Style mit einem alten geklauten privaten Schlüssel entschlüsselt?
Der Rest (Login, Usercenter, etc.) ging mit ECDHE-ECDSA und AES, also PFS, sicherer Schlüsseltausch und sicherer Verschlüsselungsalgo.
 
In sicherheitsrelevanten Bereichen sowieso.
Warum ist es bei öffentlichen Videos schlimm?

Weil man es dann im Browser nicht deaktivieren kann. Ich möchte gerne verhindern, dass beispielsweise bei Online Banking RC4 zur Verschlüsselung benutzt wird. Und das passiert wirklich, z.B. hier bei Barclaycard Online Banking https://www.ssllabs.com/ssltest/analyze.html?d=banking.barclaycard.de
Der Browser zeigt trotzdem eine tolles grünes Schloss dank Extended Validation Zertifikat an, na dann ist ja alles "sicher" ... NSA entschlüsselt Webserver-Daten angeblich in Echtzeit | heise Security

Bist du YouTube-Entwickler und hast mal Benchmarks auf dem Produktiv-System mit TBit-Upstreams gemacht?

Ich glaube nicht, dass das völlig unabsichtlich so gemacht worden ist.
Mag sein, dass RC4 in ihrem Fall einen Performance Vorteil bringt - das macht die Entscheidung es (ausschließlich) zu unterstützen aber nicht weniger falsch. Auch Youtube an sich handelt bei aktuellen Systemen (z.B. Android 4.3) noch eine RC4 Cipher aus. Dann sollen sie es lieber ganz bleiben lassen.

Ja. Ich habe doch gesagt, dass YouTube dies überall, nur nicht bei öffentlichen Videodaten macht.
Was wäre so schlimm, wenn ein Angreifer z.B. nun das übertragene Video Gangnam-Style mit einem alten geklauten privaten Schlüssel entschlüsselt?
Der Rest (Login, Usercenter, etc.) ging mit ECDHE-ECDSA und AES, also PFS, sicherer Schlüsseltausch und sicherer Verschlüsselungsalgo.
Man möchte vermutlich eine Fehlermeldung wegen Nachladen von ungesicherten Inhalten vermeiden ... aber diese Idee an sich ist schon fragwürdig, da so ein falscher Sicherheitseindruck vermittelt wird.
 
Weil man es dann im Browser nicht deaktivieren kann.

Aber das hat ja damit nichts zu tun?!
Die Lösung dafür ist eben erstens Sensibilisierung der Server-Betreiber und zweitens eine clientbasierte Software-Lösung.

Ich sagte ja bereits:
+++ATH0 hat gesagt.:
Diesen Nachteil würde ich clientseitig lösen mit einem Browser-Plugin. Also domainbezogene TLS-Richtlinien.

Wichtiger ist aber die Sensibilisierung von Server-Betreibern, weil Laien kann man so eine Sicherheitsaufgabe nicht in die Hand geben. Darum muss sich der Anbieter kümmern.

Und wer als Hacker vor diesem Problem steht, der macht sich seine Lösung selbst. :wink:

Also anstatt YouTube anzumaulen, dass sie für unwichtige Videos nicht so sichere TLS Verbindungen nutzen, müsstest du doch viel eher die Banken, die für sicherheitsrelevante Logins unsicheres TLS benutzen anschnauzen oder? *lol*

Mag sein, dass RC4 in ihrem Fall einen Performance Vorteil bringt - das macht die Entscheidung es (ausschließlich) zu unterstützen aber nicht weniger falsch. Auch Youtube an sich handelt bei aktuellen Systemen (z.B. Android 4.3) noch eine RC4 Cipher aus. Dann sollen sie es lieber ganz bleiben lassen.

Man möchte vermutlich eine Fehlermeldung wegen Nachladen von ungesicherten Inhalten vermeiden ... aber diese Idee an sich ist schon fragwürdig, da so ein falscher Sicherheitseindruck vermittelt wird.

Warum bist du eigentlich komplett nicht auf den wichtigen Punkt eingegangen, dass es sich nur um öffentliche für jeden anschaubare Videos handelt, die eben nur unsicherer übertragen werden?
Hättest du auch ein Problem damit, wenn Verzierungs- und Design-Bilder einer Homepage unsicherer übertragen werden?

Ich finde schon, dass man Sicherheit an Kriterien skalieren sollte. Wenn etwas besonders schützenswert und sicher sein muss, dann hohe Standards mit hohen Kosten, ansonsten reichen niedrigere Standards.
Das macht man quasi überall so. Zum Beispiel muss der Gartenschuppen kein so gutes Schloss haben wie die Haustür oder wie der Safe im Büro.

Keiner wird sich die Mühe machen deinen RC4-Datenstrom zu entschlüsseln nur um zu sehen, welches Video du dir angeguckt hast. Er hat dadurch hohe Kosten und wenig Nutzen. Er hat weder Passwort noch sonstwas von dir ... nur das Video. Welches Attack-Model hast du denn im Blick?
 
Aber das hat ja damit nichts zu tun?!
Die Lösung dafür ist eben erstens Sensibilisierung der Server-Betreiber und zweitens eine clientbasierte Software-Lösung.

Ich sagte ja bereits:


Wichtiger ist aber die Sensibilisierung von Server-Betreibern, weil Laien kann man so eine Sicherheitsaufgabe nicht in die Hand geben. Darum muss sich der Anbieter kümmern.

Und wer als Hacker vor diesem Problem steht, der macht sich seine Lösung selbst. :wink:

Also anstatt YouTube anzumaulen, dass sie für unwichtige Videos nicht so sichere TLS Verbindungen nutzen, müsstest du doch viel eher die Banken, die für sicherheitsrelevante Logins unsicheres TLS benutzen anschnauzen oder? *lol*

Aus meiner Sicht ist RC4 eine gewaltige Sicherheitslücke, deshalb sollte man die Unterstützung dafür eigentlich so schnell wie möglich aus allen im Einsatz befindlichen Softwareprodukten entfernen oder zumindest bei Benutzung warnen (wie bspw. bei ungültigen Zertifikaten). Einem Laien kann man es eben nicht zumuten, sich mit TLS zu beschäftigen geschweige denn individuelle TLS Profile mittels Browserplugin zu erstellen. Ich ärgere mich eben über Youtube, dass sie ihren Dienst so bauen, dass er nicht mehr funktioniert wenn man restriktive Sicherheitseinstellungen festlegt ... damit verhindern sie aktiv, dass sich diese durchsetzen. Das Onlinebanking funktioniert eben trotzdem noch, wenn ich RC4 deaktiviere, nur halt mit einer sicheren Cipher.

Warum bist du eigentlich komplett nicht auf den wichtigen Punkt eingegangen, dass es sich nur um öffentliche für jeden anschaubare Videos handelt, die eben nur unsicherer übertragen werden?
Hättest du auch ein Problem damit, wenn Verzierungs- und Design-Bilder einer Homepage unsicherer übertragen werden?

Ich finde schon, dass man Sicherheit an Kriterien skalieren sollte. Wenn etwas besonders schützenswert und sicher sein muss, dann hohe Standards mit hohen Kosten, ansonsten reichen niedrigere Standards.
Das macht man quasi überall so. Zum Beispiel muss der Gartenschuppen kein so gutes Schloss haben wie die Haustür oder wie der Safe im Büro.

Keiner wird sich die Mühe machen deinen RC4-Datenstrom zu entschlüsseln nur um zu sehen, welches Video du dir angeguckt hast. Er hat dadurch hohe Kosten und wenig Nutzen. Er hat weder Passwort noch sonstwas von dir ... nur das Video. Welches Attack-Model hast du denn im Blick?
Weil das gar nicht mein Kritikpunkt ist, dass die Videos nicht ausreichend gesichert sind, auch wenn man sicher einen Fall konstruieren könnte in dem man eben vermeiden will dass gegenüber dritten bekannt wird *welches* Video man anschaut, auch wenn das Video selbst öffentlich ist. In diesem speziellen Fall mag es vielleicht egal sein, aber es lässt sich halt nicht isoliert betrachten. Das Prinzip hinter TLS in Browsern ist Schlosssymbol => Sicher, eine differenziertere Betrachtung gibt es da für Laien nicht und auch mit Fachwissen hab ich keine Lust alles manuell zu prüfen.

Und ja es ist imho ein Problem, dass Designelemente ungesichert übertragen werden *können*. Zumindest Skripte werden von Firefox blockiert wenn sie von einer ungesicherten Quelle geladen werden sollen. Ein Browser kann nämlich nicht selbst entscheiden welche Daten schutzbedürftig sind, und wenn dann auf einmal auch private Fotos unverschlüsselt übertragen werden (man denkt aber die Verbindung wäre TLS gesichert), dann ist das ein ziemliches Problem. Außerdem fallen Metainformationen an, welche evtl. wieder Rückschlüsse auf den eigentlich gesicherten Inhalt zulassen.
 
Aber jetzt widersprichst du dir doch?!

Einem Laien kann man es eben nicht zumuten, sich mit TLS zu beschäftigen geschweige denn individuelle TLS Profile mittels Browserplugin zu erstellen

Aber dann sagst du:

Das Onlinebanking funktioniert eben trotzdem noch, wenn ich RC4 deaktiviere, nur halt mit einer sicheren Cipher.

RC4 deaktivieren ist eben keine Laien-Angelegenheit.

Es wäre kein Problem eine unsichere Cipher-Suite zu behalten, wenn die Betreiber dies dann einfach auch nur für unwichtige Komponenten der Webseite benutzen würden. Zum Beispiel hochauflösende Videos. Man sollte sich freuen, dass bei TBit/s an Upstream youtube ÜBERHAUPT noch öffentlich zugängliche Videos verschlüsselt.

Das Prinzip hinter TLS in Browsern ist Schlosssymbol => Sicher, eine differenziertere Betrachtung gibt es da für Laien nicht und auch mit Fachwissen hab ich keine Lust alles manuell zu prüfen.

Eben. Der Laie soll eben nicht dazu genötigt werden selber Ciphersuites auszuwählen.

In die Pflicht genommen werden sollten die Betreiber der Webseiten und Browser-Entwickler.

Die Betreiber für eine sinnvolle Auswahl an Ciphersuites für die Komponenten ihrer Webseite und Transparenz gegenüber dem Nutzer, welche Sicherheit der Nutzer erwarten kann.

Zusätzlich könnte man sich als Browser-Entwickler überlegen wie man bei Webseiten mit verschieden-verschlüsselten Inhalten dies sinnvoll dem User anzeigt.

Und ja es ist imho ein Problem, dass Designelemente ungesichert übertragen werden *können*. Zumindest Skripte werden von Firefox blockiert wenn sie von einer ungesicherten Quelle geladen werden sollen.

Skripte != Designelemente?!
Du hast mich da vielleicht falsch verstanden.

Ein Browser kann nämlich nicht selbst entscheiden welche Daten schutzbedürftig sind, und wenn dann auf einmal auch private Fotos unverschlüsselt übertragen werden (man denkt aber die Verbindung wäre TLS gesichert), dann ist das ein ziemliches Problem. Außerdem fallen Metainformationen an, welche evtl. wieder Rückschlüsse auf den eigentlich gesicherten Inhalt zulassen.

Ja, da stimme ich dir überall zu.
Aber nirgends widerspricht es irgendwie der Entscheidung YouTubes für Videos eine nicht so sichere Ciphersuite zu benutzen.
Private Fotos, Gesicherte/Private Inhalte... darum geht es doch nirgends.

Der Aufwand in dem Fall in dem man herausfinden möchte, was für Videos du guckst (wer? google weiß das sowieso alles) steht halt überhaupt nicht im Verhältnis zu dem Nutzen.
RC4 mag man als unsicher betrachten - aber der operative Aufwand ist trotzdem nicht zu unterschätzen.
 
RC4 mag man als unsicher betrachten - aber der operative Aufwand ist trotzdem nicht zu unterschätzen.

Es ist ja nicht nur der Aufwand, es sind vielmehr die Kosten für etwas, das faktisch keinen Nutzen bringt, denn letzten Endes geht es hierbei nur um die Einhaltung der Best Practice, jeden Teil einer Seite per HTTPS zu übertragen. In diesem Sinne darf RC4 nicht als Sicherheitsmechanismus gesehen werden, sondern nur als Maßnahme zur Einhaltung einer Best Practice, welche durch Browserhersteller erzwungen werden.

Ich kann auch das Problem verstehen, dass Browserhersteller (und damit auch die Benutzer) dazu gezwungen sind, RC4 weiterhin zu integrieren (aktivieren), weil Websites wie YT diesen Algorithmus voraussetzen und bei hartem Durchgreifen schlichtweg nicht mehr funktionieren würden. Dies ist aber letzten Endes garnicht die Sache der Browserhersteller, sondern die des Serverbetreibers, denn nur er ist in der Lage Schutzziele für die zu übertragenden Daten zu bestimmen und dementsprechende Maßnahmen zu ergreifen. Daher macht es meiner Ansicht auch kein Sinn, RC4 zu deaktivieren, da man einem Websitebetreiber, der es nicht schafft RC4 zu deaktivieren, auch nicht vertrauen sollte - zumindest, wenn man es wirklich so genau nehmen möchte ;)

Darüber gibt es für das Problem, dass viele Websites unsichere Algorithmen oder kurze Schlüssellängen verwenden, bereits mögliche Ansätze, beispielsweise die Crossbear-Notary der TU München. Diese Ansätze besitzen allerdings Schwächen, beispielsweise wenn es um Zertifikate geht, die in kurzen Intervallen getauscht werden, wie das beispielsweise bei Google (Gültigkeit eines SSL-Zertifikats: 3 Monate) der Fall ist.
 
Zuletzt bearbeitet:
Aber jetzt widersprichst du dir doch?!



Aber dann sagst du:



RC4 deaktivieren ist eben keine Laien-Angelegenheit.

Es wäre kein Problem eine unsichere Cipher-Suite zu behalten, wenn die Betreiber dies dann einfach auch nur für unwichtige Komponenten der Webseite benutzen würden. Zum Beispiel hochauflösende Videos. Man sollte sich freuen, dass bei TBit/s an Upstream youtube ÜBERHAUPT noch öffentlich zugängliche Videos verschlüsselt.



Eben. Der Laie soll eben nicht dazu genötigt werden selber Ciphersuites auszuwählen.

In die Pflicht genommen werden sollten die Betreiber der Webseiten und Browser-Entwickler.

Die Betreiber für eine sinnvolle Auswahl an Ciphersuites für die Komponenten ihrer Webseite und Transparenz gegenüber dem Nutzer, welche Sicherheit der Nutzer erwarten kann.

Aber es ist doch wie man sieht Wunschdenken, dass Betreiber von sich aus sichere Ciphersuites wählen.
Mit Fachwissen kann ich mir das individuell zurecht frickeln, aber als Browserentwickler oder Administrator würde man evtl. gerne RC4 komplett deaktivieren, was im Endeffekt durch Dienste wie Youtube erfolgreich verhindert wird. Nur so könnte man auch Laien schützen.

Ich gehe immer von Secure By Design als wünschenswertes Prinzip aus, nicht nur aus Betreibersicht, sondern auch aus Sicht des Clients. Dazu gehört eben auch, dass man in der Grundeinstellung restriktiv ist, und Ausnahmen individuell geschaffen werden müssen, nicht andersherum.

Zusätzlich könnte man sich als Browser-Entwickler überlegen wie man bei Webseiten mit verschieden-verschlüsselten Inhalten dies sinnvoll dem User anzeigt.
Das wäre in der Tat toll, nur bezweifle ich, dass das passieren wird. Nicht mal das Revocation Checking ist vernünftig Implementiert. Wenn die CRL nicht geladen werden kann passiert ... nichts: https://www.imperialviolet.org/2014/04/19/revchecking.html

Skripte != Designelemente?!
Du hast mich da vielleicht falsch verstanden.



Ja, da stimme ich dir überall zu.
Aber nirgends widerspricht es irgendwie der Entscheidung YouTubes für Videos eine nicht so sichere Ciphersuite zu benutzen.
Private Fotos, Gesicherte/Private Inhalte... darum geht es doch nirgends. Der Aufwand in dem Fall in dem man herausfinden möchte, was für Videos du guckst (wer? google weiß das sowieso alles) steht halt überhaupt nicht im Verhältnis zu dem Nutzen.
RC4 mag man als unsicher betrachten - aber der operative Aufwand ist trotzdem nicht zu unterschätzen.
Es geht eben ums Prinzip. Wenn ich von vornherein Ausnahmen bei der Sicherheit zulasse kann ich nicht verhindern, dass diese Möglichkeiten auch für tatsächlich schutzbedürftige Daten missbraucht werden.

Im Endeffekt muss man natürlich sagen, dass SSL (speziell Openssl) mehr Probleme hat als nur RC4. Wer was über den Programmierstil von Openssl lernen möchte sollte das hier mal anschauen ... http://www.openbsd.org/papers/bsdcan14-libressl/mgp00001.html
 
Aber es ist doch wie man sieht Wunschdenken, dass Betreiber von sich aus sichere Ciphersuites wählen.
Mit Fachwissen kann ich mir das individuell zurecht frickeln, aber als Browserentwickler oder Administrator würde man evtl. gerne RC4 komplett deaktivieren, was im Endeffekt durch Dienste wie Youtube erfolgreich verhindert wird. Nur so könnte man auch Laien schützen.

Im selben Maße ist es doch auch von deiner Seite aus Wunschdenken, dass alle Anbieter eben RC4 deaktivieren?! o_O
Also irgendwie kein Argument.

Wie du siehst liegen also die Verantwortungen komplett bei Anbietern und Browser-Entwicklern hier Transparenz und eine sinnvolle Auswahl an Ciphersuites zu schaffen, skaliert nach der Schutzbedürftigkeit der Daten.

Aber was total von "hinten durch die Brust ins Auge" ist: YouTube dazu zwingen RC4 auszuschalten, damit man die ciphersuite im Browser verbieten kann und gleichzeitig youtube noch geht um der Bank XY eins auszuwischen deren Server standardmäßig RC4 aushandeln, aber nun gezwungen sind etwas besseres zu nehmen...

Das ist irgendwie der merkwürdigste Weg.

Dazu gehört eben auch, dass man in der Grundeinstellung restriktiv ist, und Ausnahmen individuell geschaffen werden müssen, nicht andersherum.

Das war ja meine ursprüngliche Idee. Die Grundeinstellung ist restriktiv und dann sind die Ausnahmen Domains-Whitelists wo man auch unsichere Ciphersuites erlaubt?!

Also jetzt eben als Zielgruppe für einen Hacker wie speziell dich.

Es geht sogar noch einfacher mit mehreren Firefox-Profilen zum Beispiel. Dann macht man sich ein extra Youtube-Profil.

Es geht eben ums Prinzip. Wenn ich von vornherein Ausnahmen bei der Sicherheit zulasse kann ich nicht verhindern, dass diese Möglichkeiten auch für tatsächlich schutzbedürftige Daten missbraucht werden.

Doch das könntest du ja verhindern mit ein wenig Bastelei.
Ein Laie kann keins von beidem und er muss Browser und Anbieter vertrauen.

Ich finde irgendwie deine spezielle Zielgruppe nicht, wo es bloß sinnvoll ist, dass jetzt YouTube aufhört mit RC4 und die Welt ist wieder in Ordnung.
Bisher hört es sich eher nach einem Bequemlichkeits-Ärgernis an.

Im Endeffekt muss man natürlich sagen, dass SSL (speziell Openssl) mehr Probleme hat als nur RC4. Wer was über den Programmierstil von Openssl lernen möchte sollte das hier mal anschauen ... MagicPoint presentation foils

Ist mir bekannt. It's a mess. Da hatte Ted Unangst direkt nach Heartbleed beim Review des Codes ja fast eine Herzattacke. :D
(Habe übrigens für LibreSSL gespendet, wer noch?)
 
So langsam verrennen wir uns in der Diskussion ;)
Mir ging es nur darum, dass man RC4 nicht mehr voraussetzen sollte, selbst wenn die Daten nicht wirklich schützenswert sind. Denn damit verhindert man, dass der Support irgendwann entfernt werden kann. Von Google erwarte ich da einfach etwas mehr Weitsicht. Solange es nur optional ist, ist es mir relativ egal. Wenn man mal danach googelt bin ich auch bei weitem nicht der einzige den es stört.

Ist mir bekannt. It's a mess. Da hatte Ted Unangst direkt nach Heartbleed beim Review des Codes ja fast eine Herzattacke. :D
(Habe übrigens für LibreSSL gespendet, wer noch?)

Wär mal ne Überlegung wert. Ich bin gespannt ob es sich durchsetzen wird.
 
Aber es ist doch wie man sieht Wunschdenken, dass Betreiber von sich aus sichere Ciphersuites wählen.
Ich wiederhole gerne meine Frage: Wieso vertraust du einem Anbieter, der trotz seiner Verwantwortung diesbezüglich schlechte Algorithmen anbietet? Oder genereller gefragt: Ist denn ein Anbieter überhaupt vertrauenswürdig, wenn er es nichtmal schafft, seine Sicherheitspolicy nach seinen Sicherheitsanforderungen auszurichten?

Mit Fachwissen kann ich mir das individuell zurecht frickeln, aber als Browserentwickler oder Administrator würde man evtl. gerne RC4 komplett deaktivieren, was im Endeffekt durch Dienste wie Youtube erfolgreich verhindert wird. Nur so könnte man auch Laien schützen.
"Sicherheit" ist mehr, als nur eine Auswahl sicherer Algorithmen. Es umfasst - aus praktischer Sicher - vielmehr alle Maßnahmen, mit denen bestimmte Schutzziele erreicht werden müssen, die in ihrer Gesamtheit ein bestimmtes Sicherheitsniveau bilden. RC4 hat dann seine Daseinsberechtigung, wenn zwar SSL/TLS angeboten werden soll - Marketing *hust* -, aber das Sicherheitsniveau allgemein relativ niedrig gehalten werden kann, da die übertragenen Daten als nicht besonders kritisch bewertet werden. Das bedeutet aber auch, dass sowohl der Experte, als auch der Laie mit RC4 ausreichend geschützt sind - zumindest aus Sicht des Dienstanbieters. Das Sicherheitsbedürfnis spielt in diesem Modell keine Rolle, das ist korrekt. Ich sehe allerdings auch nicht, warum das Sicherheitsbedürfnis größer sein sollte, als das Sicherheitsniveau des Anbieters.

Ich gehe immer von Secure By Design als wünschenswertes Prinzip aus, nicht nur aus Betreibersicht, sondern auch aus Sicht des Clients.
Dann deaktiviere SSL unterhalb und inklusive Version 3.0 und TLS oberhalb Version 1.0. Das System besitzt derart viele Probleme, für die es heute schlicht noch keine Lösung gibt.
Dazu lässt sich leicht sagen, dass Algorithmen hierbei nicht zu diesem Problemen zählen, denn die kannst du einfach an- oder ausschalten.

Dazu gehört eben auch, dass man in der Grundeinstellung restriktiv ist, und Ausnahmen individuell geschaffen werden müssen, nicht andersherum. Das wäre in der Tat toll, nur bezweifle ich, dass das passieren wird.
Secure by Design bedeutet weder, dass es in seiner Grundeinstellung sicher ist, noch, dass du Einstellungen vornehmen kannst, die die Sicherheit des Systems gefährden. Es bedeutet lediglich, dass es von Grund auf Sicherheitsprinzipien basiert und daher zu jedem Zeitpunkt bestimmte Sicherheitsziele erfüllt.
Was du meinst ist "secure by default" - und das ist meiner Ansicht nach im Internet nur sehr schwer zu realisieren, da das Internet eine seit 40 Jahren wachsende Infrastruktur ohne ordnungsgebende Macht ist. Der Anspruch im Internet lag niemals darin sicher zu sein, sondern einen einfachen Informationsaustausch zu ermöglichen. Und dafür braucht es aktuell nunmal noch großzügige Sicherheitseinstellungen im Browser im Gleichgewicht zwischen unsicher und sicher.

Nicht mal das Revocation Checking ist vernünftig Implementiert. Wenn die CRL nicht geladen werden kann passiert ... nichts: https://www.imperialviolet.org/2014/04/19/revchecking.html
Who cares? Die CAs geben eh keine vollständigen CRLs raus, da sie schlichtweg keine Anreize dafür besitzen und nur drauf zahlen. Wenn es auf die Kunden umgelegt wird, dann wird eben der Kunde dafür nicht zahlen - sondern sich einfach ein neues Zertifikat ausstellen. CRLs sind damit nutzlos, sodass es garnicht so schlecht ist, dass es in den gängigen Browsern nicht aktiviert ist.

Und damit dieser Post nicht ganz umsonst ist:
Code:
OpenSSL 1.0.1g 7 Apr 2014
built on: Mon Apr  7 15:05:00 PDT 2014
options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: /usr/bin/clang -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4             268781.28k   287708.17k   303200.83k   308636.67k   307758.92k
des cbc          55235.47k    57313.09k    57318.40k    57435.78k    57045.36k
des ede3         21055.59k    21351.38k    21037.81k    21437.56k    21414.27k
blowfish cbc     83739.48k    88314.91k    90044.02k    91182.23k    89901.59k
aes-128 cbc      92383.57k   100077.23k   103173.48k   103595.69k   103937.03k
aes-192 cbc      79156.87k    82054.79k    84484.05k    86009.86k    87416.04k
aes-256 cbc      69129.81k    75184.91k    75511.98k    74723.92k    74021.16k
camellia-128 cbc    73237.89k   110834.07k   125280.02k   126558.38k   129129.24k
camellia-192 cbc    62640.51k    86547.31k    95116.59k    97104.31k    97577.64k
camellia-256 cbc    63104.46k    85653.43k    94353.12k    97119.38k    98769.77k

Das beweist glaube ich, warum RC4 trotz *theoretischer* Sicherheitsmängel durchaus eine Daseinsberechtigung besitzt ;)

xblax hat gesagt.:
Denn damit verhindert man, dass der Support irgendwann entfernt werden kann.
Quark. Üblicherweise issued man eine neue TLS Version, in der RC4 nicht mehr drin ist, und wartet einige Jahre. Google hält sich hier an den Standard, das hat also nichts mit Google zu tun. Dass RC4 in den nächsten 5-10 Jahren verschwindet, ist eh sehr unwahrscheinlich.
 
Zuletzt bearbeitet:
Ich wiederhole gerne meine Frage: Wieso vertraust du einem Anbieter, der trotz seiner Verwantwortung diesbezüglich schlechte Algorithmen anbietet? Oder genereller gefragt: Ist denn ein Anbieter überhaupt vertrauenswürdig, wenn er es nichtmal schafft, seine Sicherheitspolicy nach seinen Sicherheitsanforderungen auszurichten?

"Sicherheit" ist mehr, als nur eine Auswahl sicherer Algorithmen. Es umfasst - aus praktischer Sicher - vielmehr alle Maßnahmen, mit denen bestimmte Schutzziele erreicht werden müssen, die in ihrer Gesamtheit ein bestimmtes Sicherheitsniveau bilden. RC4 hat dann seine Daseinsberechtigung, wenn zwar SSL/TLS angeboten werden soll - Marketing *hust* -, aber das Sicherheitsniveau allgemein relativ niedrig gehalten werden kann, da die übertragenen Daten als nicht besonders kritisch bewertet werden. Das bedeutet aber auch, dass sowohl der Experte, als auch der Laie mit RC4 ausreichend geschützt sind - zumindest aus Sicht des Dienstanbieters. Das Sicherheitsbedürfnis spielt in diesem Modell keine Rolle, das ist korrekt. Ich sehe allerdings auch nicht, warum das Sicherheitsbedürfnis größer sein sollte, als das Sicherheitsniveau des Anbieters.

Natürlich akzeptiere ich das Sicherheitsniveau des Anbieters nicht, denn ich habe RC4 deaktiviert. Algorithmen deren Sicherheit nicht mehr gewährleistet ist, sollten nicht mehr benutzt werden ... da kann man wirklich keine Rücksicht auf Marketing nehmen.

Dann deaktiviere SSL unterhalb und inklusive Version 3.0 und TLS oberhalb Version 1.0. Das System besitzt derart viele Probleme, für die es heute schlicht noch keine Lösung gibt.
Dazu lässt sich leicht sagen, dass Algorithmen hierbei nicht zu diesem Problemen zählen, denn die kannst du einfach an- oder ausschalten.
Das ist Richtig, aber für RC4 besitzt man viele Lösungen die funktionieren und einsatzbereit sind.

Secure by Design bedeutet weder, dass es in seiner Grundeinstellung sicher ist, noch, dass du Einstellungen vornehmen kannst, die die Sicherheit des Systems gefährden. Es bedeutet lediglich, dass es von Grund auf Sicherheitsprinzipien basiert und daher zu jedem Zeitpunkt bestimmte Sicherheitsziele erfüllt.
Was du meinst ist "secure by default" - und das ist meiner Ansicht nach im Internet nur sehr schwer zu realisieren, da das Internet eine seit 40 Jahren wachsende Infrastruktur ohne ordnungsgebende Macht ist. Der Anspruch im Internet lag niemals darin sicher zu sein, sondern einen einfachen Informationsaustausch zu ermöglichen. Und dafür braucht es aktuell nunmal noch großzügige Sicherheitseinstellungen im Browser im Gleichgewicht zwischen unsicher und sicher.
Ja ich meine "secure by default", das könnte man aber auch als Voraussetzung für "secure by design" sehen. Den Anspruch hatte das Internet nie, da man in den Anfängen einfach nicht daran gedacht hat, dass es mal notwendig wird. Trotzdem sollte man daran arbeiten, auch wenn man mal legacy support aufgeben muss.

Who cares? Die CAs geben eh keine vollständigen CRLs raus, da sie schlichtweg keine Anreize dafür besitzen und nur drauf zahlen. Wenn es auf die Kunden umgelegt wird, dann wird eben der Kunde dafür nicht zahlen - sondern sich einfach ein neues Zertifikat ausstellen. CRLs sind damit nutzlos, sodass es garnicht so schlecht ist, dass es in den gängigen Browsern nicht aktiviert ist.
Es gibt auch noch nicht öffentliche CAs. Haben die CAs keine CRLs weil es die Browser eh nicht interessiert oder andersrum, ist die Frage ... ändern kann man da momentan nichts, trotzdem ist das ärgerlich. Zumal das bereitstellen einer CRL ja eh optional ist ...

Und damit dieser Post nicht ganz umsonst ist:
Code:
OpenSSL 1.0.1g 7 Apr 2014
built on: Mon Apr  7 15:05:00 PDT 2014
options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) idea(int) blowfish(idx) 
compiler: /usr/bin/clang -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
rc4             268781.28k   287708.17k   303200.83k   308636.67k   307758.92k
des cbc          55235.47k    57313.09k    57318.40k    57435.78k    57045.36k
des ede3         21055.59k    21351.38k    21037.81k    21437.56k    21414.27k
blowfish cbc     83739.48k    88314.91k    90044.02k    91182.23k    89901.59k
aes-128 cbc      92383.57k   100077.23k   103173.48k   103595.69k   103937.03k
aes-192 cbc      79156.87k    82054.79k    84484.05k    86009.86k    87416.04k
aes-256 cbc      69129.81k    75184.91k    75511.98k    74723.92k    74021.16k
camellia-128 cbc    73237.89k   110834.07k   125280.02k   126558.38k   129129.24k
camellia-192 cbc    62640.51k    86547.31k    95116.59k    97104.31k    97577.64k
camellia-256 cbc    63104.46k    85653.43k    94353.12k    97119.38k    98769.77k
Das beweist glaube ich, warum RC4 trotz *theoretischer* Sicherheitsmängel durchaus eine Daseinsberechtigung besitzt ;)
Aber nur, wenn man es als nicht gesicherte Verbindung betrachtet ;)

Quark. Üblicherweise issued man eine neue TLS Version, in der RC4 nicht mehr drin ist, und wartet einige Jahre. Google hält sich hier an den Standard, das hat also nichts mit Google zu tun. Dass RC4 in den nächsten 5-10 Jahren verschwindet, ist eh sehr unwahrscheinlich.
Nur weil es standardisiert ist muss man es nicht verwenden. Google hält sich nicht an die Standards, denn das TLS RFC sieht vor:

Code:
https://www.ietf.org/rfc/rfc2246.txt TLS 1.0:

9. Mandatory Cipher Suites
    In the absence of an application profile standard specifying
    otherwise, a TLS compliant application MUST implement the cipher
    suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
Ab TLS 1.2 ist dann TLS_RSA_WITH_AES_128_CBC_SHA Voraussetzung. Es gibt sogar schon einen Draft, der RC4 als gültige Cipher Suite untersagen möchte: draft-popov-tls-prohibiting-rc4-02

Edit:
Noch etwas Recherche hat ergeben: Microsoft ist erstaunlich innovativ und deaktiviert ab IE11 RC4 im initialen TLS Handshake. Nur wenn der Handshake nicht erfolgreich war, folgt ein zweiter Versuch mit RC4. Für fast 39% aller Webseiten wird dadurch eine bessere Cipher Suite gewählt. Quelle: http://blogs.msdn.com/b/ie/archive/...while-making-sure-sites-continue-to-work.aspx
 
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 ... :rolleyes:

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...
 
Zuletzt bearbeitet:
Zurück
Oben