The user and all related content has been deleted.
Hi, guckst Du hier: Link Für die Shopseiten, bzw. Versandkostenmodalbox url controller ändern, {url controller=custom sCustom=6 forceSecure}. Ob da noch was in die DB muss weiß ich nicht. Viell. kann Dir das hier jemand beantworten.
The user and all related content has been deleted.
- es ist ja von SW so gedacht das nur wichtige seiten wie registrierung, bestellung usw. verschlüsselt werden. was soll es auch bringen wenn der kunde eine ständige ssl verbindung hat! 2. sollte das auch über server einstellungen gehen. da kannst du je nach hoster einstellen das er alle http anfragen nach https weiterleitet. dann brauchst du im sw nichts weiter zu machen.
na wie wäre htaccess? RewriteCond %{SERVER_PORT} !^443$ RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]
Hallo, ersteinmal vielen Dank für die überaus wertvollen und ansonsten schwer zugänglichen Infos in diesem Thread. Derzeit habe ich bei einem Plugin auf einem Kundenserver das Problem, dass es zu Problemen mit dem Url-Plugin kommt, wenn nicht forceSecure als Parameter verwendet wird, also die Aufrufe in der Form {url controller=‚myController‘ forceSecure} umgestrickt werden. So wie ich es sehe, muss dann ja zwangsweise der Parameter forceSecure für Template-Aufrufe des Url-Plugins verwendet werden, da die meisten Shops ja zumindest im Checkout SSL verwenden. Ist das so? Gilt das nur für Controller-Aufrufe oder auch für einfache actions ohne einen anderen Controller aufzurufen? Kann es bei Nicht-SSL-Servern zu Problemen führen, wenn forceSecure als Parameter verwendet wird? Weshalb sind in den Shopware-Templates im Checkout standardmäßig Aufrufe des Url-Plugins vorhanden, die nicht den forceSecure-Parameter benutzen und es führt offensichtlich nicht zu Problemen? Freundliche Grüße aus dem hohen Norden Philip
Hallo, wenn SSL im Shop aktiviert wird, so ist SSL nur in einigen Bereichen vorgesehen. Checkout, Mein Konto usw. Es ist nicht vorgesehen, dass der gesamte Shop auf SSL umgestellt wird. Bei uns wird auch nur mit der Standard SSL Funktion getestet. Sprich wenn der gesamte Shop auf SSL umgestellt wird, so kann das zu unbekannten Seiteneffekten führen. Wir empfehlen nicht den gesamten Shop auf SSL umzustellen, sondern die von uns implementierten Funktionen zu nutzen. Grüße aus dem Münsterland Patrick Schücker
Was spricht den nach Eurer Meinung grundsätzlich dagegen, den gesamten Shop auf https umzustellen? Zum Beispiel google, paypal, gls, otto, carrera, spotify und viele Andere haben das …und aus SEO-Sicht ist die Verwendung von https auch kein Problem, wie auch Matt Cutts vor Kurzem in seinem Video bestätigt hat. Die übliche Browser-Website-Kommunikation erfolgt über das ungeschützte http. Alle Daten werden im Plaintext übertragen, d.h. sie können praktisch von jedem abgefangen und gelesen werden, der dazu technisch in der Lage ist. Z.B. Passwörter und Cookies stehlen, Besuchersitzungen kapern usw.; in einem öffentlichen WLAN oder anderen, nicht vertrauenswürdigen Netzwerken kann so einiges passieren, wenn auf eine verschlüsselte Verbindung verzichtet wird. Ich persönlich finde sowas sehr gut und fühle mich direkt sicher in so einem Shop. Und deshalb habe ich auch komplett umgestellt auf https. 
EDIT: Backend ist auch verschlüsselt!
Sehe ich auch so, insbesondere wenn man in ein Extended Validation Zertifikat investieren kann/möchte und der Besucher bereits auf der Startseite mit einer grünen Adressleiste in seinem Browser „begrüßt“ wird. Das hat in der Regel einen positiven Einfluss auf das Vertrauen in den Onlineshop. Darüber hinaus ist vielleicht noch zu beachten, dass eine Ressource (z.B. ein Bild oder eine CSS oder Javascript Datei), die zuvor über http unverschlüsselt geladen wurde, dann im verschlüsselten Bereich der Seite noch einmal über https geladen werden muss. Der lokale Browsercache kann in diesem Falle nicht wiederverwendet werden (kein geteilter Cache zwischen http und https). Das ist sicher nicht für jeden relevant, mag aber dennoch für den einen oder anderen auch eine Rolle spielen, vielleicht insbesondere dann, wenn man mobile Geräte bedienen möchte, die nicht gerade ständig in einem potenten WLAN hängen.
Hallo, aktuell werden halt nur die sicherheitsrelevanten Sachen verschlüsselt. Die gesamte Webseite zu verschlüsseln macht eigentlich kein Sinn. Es bedeutet nur einen größeren Rechenaufwand am Server und natürlich auch am Client. Passwörter werden verschlüsselt übermittelt. Das was im verschlüsselten Bereich nicht aus dem Cache geladen werden kann ist nicht wirklich viel. Das sollte keine großen Performance Einbußen bringen. Ihr könnt diesen Featurewunsch aber gerne auf jira.shopware.de als Ticket einstellen. Das Ticket wird dann von unserer Entwicklung geprüft. Je mehr für ein Ticket voten, desto eher ist die Chance der Realisierung. Gruß Patrick Schücker
[quote=“Patrick Schücker”] aktuell werden halt nur die sicherheitsrelevanten Sachen verschlüsselt. Die gesamte Webseite zu verschlüsseln macht eigentlich kein Sinn. Es bedeutet nur einen größeren Rechenaufwand am Server und natürlich auch am Client.[/quote] Das stimmt leider nicht, Session Daten sind sehr relevant, da man die komplette Session übernehmen und Bestellungen auf jemand anderen durchführen kann, auch ohne das Passwort. Jeder Shop sollte die Möglichkeit bieten, den gesamten Traffic durch SSL zu leiten, Shopware hinkt hier eindeutig hinterher. Ein Umschreiben der URLs bringt hier auch nichts, da initial Requests mit der Session ohne SSL gesendet werden. Auch der Rechenaufwand ist heutzutage zu vernachlässigen, nur der Handshake erfordert etwas mehr Aufwand, tritt aber pro Session nur einmal auf. Meiner Meinung nach gibt es keinen Grund, heutzutage nicht alle Daten per SSL zu sichern.
Hallo, die Aussage, sicherheitsrelevante Bereiche seien immer verschlüsselt, ist auch aufgrund der unverschlüsselten Übertragung des Backends fragwürdig. Immerhin werden dort alle Kundendaten (Bestellungen, Kontodaten,…) verarbeitet. Diese personenbezogenen Daten sind jedoch besonders zu schützen. Ich freue mich , dass dies mittlerweile hier im Forum als kritisch beachtet wird. Vor ca. einem Jahr war die Resonanz noch ganz anders, als ich den Wunsch nach verschlüsselter Übertragung geäußert habe. Shopware geht aus meiner Sicht leider etwas fahrlässig mit dem Thema um.
The user and all related content has been deleted.
Freue mich, dass ich mit meiner Meinung nicht alleine da stehe! [quote=“hth”]Hallo, die Aussage, sicherheitsrelevante Bereiche seien immer verschlüsselt, ist auch aufgrund der unverschlüsselten Übertragung des Backends fragwürdig. Immerhin werden dort alle Kundendaten (Bestellungen, Kontodaten,…) verarbeitet. Diese personenbezogenen Daten sind jedoch besonders zu schützen. [/quote] Momentan ist nur das reine Backend verschlüsselt (Schloss auf grün), aber wenn man die einzelnen Tabs aufruft nicht mehr. Wie kann man das komplette Backend auf https einstellen um, wie Holger schreibt, auch die Kontodaten etc zu schützen? Wo müsste man da was einstellen?
So, jetzt sind alle Fenster auch im Backend verschlüsselt, dank Holger (hth) Thanks!! :thumbup: In die htaccess: RewriteCond %{HTTPS} !=on RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
2 „Gefällt mir“
Petra, ist durch Verwendung Deines Codes der gesamte Shop verschlüsselt ? Danke und LG, Annette
ich kann eure aufregung und beschwerde an SWag nicht nachvollziehen. wie ich paar post zuvor eine htaccess lösung gezeigt habe und artep nun auch, bleit es einem betreiber selbst überlassen ob er SSL verwendet oder nicht, und ob https erzwungen wird (htaccess). mir ist kein fehler aufgefallen, wenn alle seiten per https angezeigt werden. also hat SWag wohl ihre arbeit gemacht. wenn ihr also permanent SSL haben wollt, dann tragt den zusatz in eure htaccess ein.
Hallo, durch den htaccess-Eintrag, den Petra gepostet hat, sollte der gesamte Shop verschlüsselt sein. Notwendig wird aber wahrscheinlich eine Anpassung der url-Plugin-Aufrufe in Teilen des Templates mit forcesecure - wie das auch irgendwo am Anfang des Threads geschrieben wurde. Ein zweiter wichtiger Punkt ist, dass ein Redirect erzeugt wird. Dies kann sehr wohl unter bestimmten Konstellationen zu Problemen führen . Mir sind bislang zwar keine Probleme aufgefallen, aber sie können vorhanden sein. Ich kann Patrick (Shopware) daher verstehen, wenn diese auf die (evtl. theoretische) Möglichkeit von Fehlfunktionen hinweisen. Bei Problemen mit dem Shop sollte man zumindest testen, ob diese durch einen Wechsel auf http zu beheben sind. Wenn man die unverschlüsselte Übertragung der Session-Ids mit den daraus resultierenden Sicherheitsrisiken für vertretbar hält, kann man auch nur URLs mit /backend/ über einen redirect auf https setzen. Alternativ das Backend direkt mit https://domain.de/backend aufrufen. Wahrscheinlich werden dann zumindest alle sensitiven Backend-Daten verschlüsselr übertragen. Komplett getestet habe ich das aber nicht. Viele Grüße H. Thomas (info@mycetome.de)
[quote=“pino”]ich kann eure aufregung und beschwerde an SWag nicht nachvollziehen. wie ich paar post zuvor eine htaccess lösung gezeigt habe und artep nun auch, bleit es einem betreiber selbst überlassen ob er SSL verwendet oder nicht, und ob https erzwungen wird (htaccess).[/quote] Das Problem, wenn Anfragen per rewrite umgeschrieben werden ist, dass zuerst ein normaler HTTP Request angefragt wird, dann merkt der Webserver: “Oh, meine rewrite Regel trifft zu, bitte zu HTTPS umschreiben”, und erst dann ein gesicherter Requests ausgeführt wird. Wenn man sich also in einem Netzwerk befindet, in welchem auch andere Zugang haben, lässt sich dieser erste Request ohne SSL inklusive Session ID mitschneiden. Dann kann man sich die komplette Verschlüsselung auch sparen, denn ein Angreifer kann in meinem Namen und mit meinen Zahldaten mithilfe der Sessioninformationen eine Bestellungen durchführen. Shopware hilft dabei sogar noch, denn selbst wenn man sich selbst entscheidet, SSL zu nutzen, führen (fast) alle Links wieder auf eine ungesicherte Seite. Verstehst du nun, warum sich einige Leute hier beschweren? Das ist meiner Meinung nach einer der Hauptgründe, immer SSL zu nutzen; aus reinen Privacy Gesichtspunkten gibt es noch einige weitere Argumente, den kompletten Traffic mit SSL zu sichern. Keine der genannten .htaccess Regeln kann also den kompletten Traffic sichern, und es bleibt immer noch die Gefahr des Session hijacking (unerlaubt ins Backend einloggen, Bestellungen als jemand anderes durchführen), wenn man sich in öffentlichen Netzwerken befindet.
Dieses Thema war schon immer ein Anliegen von mir - die Antworten von Shopware leider immer die gleichen. Ich sehe es auch so, dass speziell das Backend verschlüsselt sein muss - es sei denn der Shopbetreiber schaltet das explizit ab. Das momentan das Backend quasi unverschlüsselt ist, und dort sehr sensible persönliche Daten enthalten und übertragen werden ist schon fast - ich würde sagen - fahrlässig. RewriteRules sind keine Lösung, da wie der Vorschreiber schon korrekt schreibt der erste Request unverschlüsselt ist, hier ist schon die Schwachstelle und sensible Daten sind mitunter hier schon übertragen worden. Für das Frontend sollte SSL optional auf jeden Fall auch möglich sein, eben unter dem Aspket „Extended Validation“ Zertifikate - haben wir auch. Der „Overhead“ ist zu vernachlässigen, die Server können so etwas leisten, die Clients auch locker und wenn man dann noch das SPDY Protokoll im Webserver unterstützt dann macht man nichts anderes was Google auch macht bei all seinen Produkten Ich hab ein Ticket gefunden das wir jetzt nur noch „hochvoten“ müssten: http://jira.shopware.de/?ticket=SW-7120 Einen ergänzenden Kommentar kann auch jeder dazu verfassen, falls der Kollege oder ich etwas vergessen haben sollten.