[Deleted User][Deleted User] MemberComments: 0 Received thanks: 3 Member since: November 2010 edited September 2014
The user and all related content has been deleted.

Comments

  • artepartep MemberComments: 3601 Received thanks: 594 Member since: July 2010
    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.
  • [Deleted User][Deleted User] MemberComments: 0 Received thanks: 3 Member since: November 2010
    The user and all related content has been deleted.
  • ratzingerratzinger MemberComments: 190 Received thanks: 29 Member since: August 2012
    1. 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.
  • pinopino MemberComments: 248 Received thanks: 39 Member since: July 2011
    na wie wäre htaccess?

    RewriteCond %{SERVER_PORT} !^443$
    RewriteRule (.*) https://%{HTTP_HOST}/$1 [L]
  • stoertebeckerstoertebecker MemberComments: 8 Received thanks: 0 Member since: November 2012
    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
  • Patrick SchückerPatrick Schücker AdministratorsComments: 947 Received thanks: 171 Member since: April 2012
    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
  • artepartep MemberComments: 3601 Received thanks: 594 Member since: July 2010
    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!
  • oviovi MemberComments: 129 Received thanks: 24 Member since: August 2011
    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.
  • Patrick SchückerPatrick Schücker AdministratorsComments: 947 Received thanks: 171 Member since: April 2012
    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
  • PickwarePickware MemberComments: 383 Received thanks: 131 Member since: August 2012
    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.
    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.
  • hthhth MemberComments: 1451 Received thanks: 324 Member since: October 2012
    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.
  • [Deleted User][Deleted User] MemberComments: 0 Received thanks: 3 Member since: November 2010
    The user and all related content has been deleted.
  • artepartep MemberComments: 3601 Received thanks: 594 Member since: July 2010
    Freue mich, dass ich mit meiner Meinung nicht alleine da stehe! ;)
    hth wrote:
    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.
    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?
  • artepartep MemberComments: 3601 Received thanks: 594 Member since: July 2010
    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]
    Thanked by 2metamind handssw5
  • metamindmetamind MemberComments: 192 Received thanks: 8 Member since: February 2011
    Petra,

    ist durch Verwendung Deines Codes der gesamte Shop verschlüsselt ?

    Danke und LG,
    Annette
  • pinopino MemberComments: 248 Received thanks: 39 Member since: July 2011
    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.
  • hthhth MemberComments: 1451 Received thanks: 324 Member since: October 2012
    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)
  • PickwarePickware MemberComments: 383 Received thanks: 131 Member since: August 2012
    pino wrote:
    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).
    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.
  • shopoholicshopoholic MemberComments: 47 Received thanks: 11 Member since: May 2012
    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.
  • Patrick SchückerPatrick Schücker AdministratorsComments: 947 Received thanks: 171 Member since: April 2012
    Hallo Community,

    ich habe eine gute Nachricht für euch.
    Wir haben die Entwickler über Nacht eingesperrt und für euch eine Lösung erarbeiten lassen.

    In kürze wird hier im Thread ein Beispiel Code gepostet, mit dem ihr euren Shop komplett auf HTTPS laufen lassen könnt. Das ist natürlich eine "ungetestete" Lösung. Also wirklich experimentell. Bitte nur nutzen, wenn ihr wisst was ihr macht.

    Eine offizielle Lösung wird es auf Dauer auch geben. Dies wird voraussichtlich in einen der nächsten Updates realisiert werden.
    Ich denke ihr versteht, dass wir nicht auf die schnelle eine offizielle Version bringen können. Es ist ein Teil, die Lösung zu programmieren, aber noch ein anderer die Lösung auch zu Testen. Da dies eine Sache ist, die sich auf den gesamten Shop auswirkt, ist die notwendige QA dementsprechend umfangreich.

    Ich denke so haben wir aber eine Lösung die für jeden passend ist. Wer sich auskennt bekommt in kürze eine experimentelle Lösung (dies können wir nicht über den offiziellen Weg supporten). Für alle die eine offizielle Lösung wollen, wird es voraussichtlich in den kommenden Versionen eine Lösung geben.


    Viele Grüße aus dem Münsterland
    Patrick Schücker
  • artelierartelier MemberComments: 586 Received thanks: 89 Member since: July 2013
    Sehr löblich! Danke Patrick.
  • Benjamin CremerBenjamin Cremer EmployeeComments: 206 Received thanks: 100 Member since: April 2012
    Hallo Zusammen,
    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.
    Das ist richtig.
    Es ist eine Anpassung am Shopware-Router nötig, damit die HTTPS-Links immer generiert werden:
    https://github.com/bcremer/shopware-4/c ... 8fe3ce1c76

    Zusammen mit der Anpassung der .htaccess sollte der Shop komplett (Storefront/Backend) über HTTPS ausgeliefert werden.
    RewriteCond %{HTTPS} !=on
    RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
    Viele Grüße,
    Benjamin Cremer :shopware:
    Thanked by 1backtraum
  • PickwarePickware MemberComments: 383 Received thanks: 131 Member since: August 2012
    Hallo Benjamin,

    ich habe die Änderung auf unserem Testsystem eingespielt und konnte soweit keine Probleme feststellen. Alle soweit gefundenen Links werden korrekt mit https ausgeliefert, vielen Dank.

    Zur Info, das gilt natürlich auch für die Anfragen, die vom/ans Backend gesendet werden.
  • artepartep MemberComments: 3601 Received thanks: 594 Member since: July 2010
    Hi,
    haben auch gerade die Änderung gemacht und funktioniert soweit man das überblicken kann! Prima!! :thumbup:
    Eins habe ich allerdings entdeckt: im Backend kleines Problem mit den Shopseiten.
    Klickt man diese an, alles ok. Klickt man die einzelnen Seiten an, nicht ok, kein https.
  • dewibdewib MemberComments: 201 Received thanks: 10 Member since: November 2013
    Hallo,

    ich habe folgendes Problem/Phönomen festgestellt: Rufe ich den Shop über https auf, wird der Facebook-Like-Button auf der Artikel-Detailseite nicht mehr angezeigt. Ruche ich das identische Produkt über http (ohne SSL) auf, ist der Button sofort wieder da.

    Ich würde gern den Shop komplett auf https laufen lassen, aber nur ungern auf Social-Buttons verzichten. Wie kann ich das lösen?

    Danke für Tipps und Hinweise.
  • dewibdewib MemberComments: 201 Received thanks: 10 Member since: November 2013
    Kann mir bitte jemand mit folgendem Problem weiterhelfen.

    Wir haben eine 4.2.3 und im Backend alle Häkchen bzgl. SSL für den Shop gesetzt.

    Ruft man die Domain auf, landet man aber auf http (ohne SSL). Im Hauptmenü werden fast alle Links mit https aufgerufen, bis auf einen: "MOTIVE" (siehe hier: www.oberland.la)

    Nutze ich zusätzlich zu den Backend-Einstellungen eine RewriteRule um auf https umzuschreiben, bekommen (vorrangig Firefox-Nutzer) in bestimmten Konstellationen eine Zertifikat-Warnung.

    Szenario: wir nutzen den Host grundsätzlich ohne "www.", und haben dafür eine RewriteRule, die alle [url=http://www.-Anfragen]www.-Anfragen[/url] auf den Host ohne www umleitet. (Auch wegen SEO: Duplicate Content vermeiden).

    Unser Zertifikat ist auch so ausgestellt (Host ohne www).

    So, erweiter ich nun die htaccess um die RewriteRule für https gibt das irgendeinen Konflikt, der bei Anfragen mit "www." eine Warnung im Browser auswirft die Domain "www.oberland.la" wäre nicht sicher (was ja uch richtig ist, weil unser Zertifikat nur für ohne www gilt).

    Da eine Zertifikatwarnung für Nutzer weitaus schlimmer wirkt als eine von Haus aus ungesicherte http-Verbindung, hab ich den https-Rewrite aus der htaccess erst mal wieder rausgeschmissen.

    Aber wie löse ich es, dass ALLE Anfragen auf dem SSL-gesicherten https-Host ohne "www." landen und ohne Zertifikatwarnung?
  • TamiraTamira MemberComments: 71 Received thanks: 2 Member since: July 2014
    Ich habe zu Testzwecken die ssl Verschlüsselung des Backend in der .htacces auskommentiert, aber leider wird mir immer noch beim Aufruf des Backend eine Seite mit ssl Verschlüsselung angezeigt, bzw. versucht anzuzeigen.

    Hier die htaccess Daten:

    # Https config for the backend
    #RewriteCond %{HTTPS} !=on
    #RewriteRule backend/(.*) https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

    Warum kann ich das Backend zur Probe, weil ich keine SSL Zertifikat bei 1und1 habe, nicht normal erreichen?
    LG Tamira
  • handssw5handssw5 MemberComments: 111 Received thanks: 8 Member since: October 2015
    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]

    Das hier hat auch mit 1und1 geklappt! 

Sign In or Register to comment.