JTL-Shop und SSL - Eure Meinung

  • Wenn Ihr uns das erste Mal besucht, lest euch bitte zuerst die Foren-Regeln durch.

die-andis

Gut bekanntes Mitglied
26. März 2010
506
2
#1
Hallo Leute,

wir möchten unseren JTL- Shop (also den Transport der Kundendaten) gerne per SSL absichern.

Habt ihr Erfahrung diesbezüglich? Welche Anbieter sind zu empfehlen oder auch nicht zu empfehlen? (Preis-/Leistungverhältnis, Akzeptanz im Browser, Zert. mit Validierung,...) Was gibt es für Probleme?

Wie wichtig ist das Thema überhaupt?

Gruß
Andreas
 

dixeno-bhesse

Aktives Mitglied
30. August 2014
92
5
#2
AW: JTL-Shop und SSL - Eure Meinung

Meiner Meinung nach ist es schon einfach nicht mehr zeitgemäß keine Verschlüsselung im Shop einzusetzen, zumal die laufenden Kosten dafür heutzutage eigentlich ziemlich gering sind.
Interessant ist ggf. auch: IT-Sicherheitsgesetz: SSL-Verschlüsselung und technischer Zugriffsschutz in Online-Shops jetzt Pflicht?
Auch google interessiert sich dafür: https://www.internetx.com/news/ssl-erste-vorteile-im-google-ranking-ersichtlich/

Ich persönlich würde grundsätzlich die gesamte Seite per SSL absichern und Aufrufe per http:// immer direkt auf https:// weiterleiten, damit auch sämtliche Cookie-Daten über eine verschlüsselte Verbindung laufen.

Sofern das Zertiifkat nicht über den eigenen Hoster erworben werden muss (was häufig aber wesentlich einfacher und stressfreier ist), ist dieser Anbieter zu empfehlen:
https://www.psw-group.de/ssl-zertifikate/
Hier sieht man die Browser-Abdeckungen jeweils auch ganz gut: https://www.psw.net/ssl-zertifikate.cfm

Der grobe Unterschied zwischen den verschiedenen Typen:
  • Domainvalidierte SSL-Zertifikate: Es wird geprüft, ob einem die Domain tatsächlich gehört.
    (meist automatisiert z.B. via whois-Einträge zur Domain)
  • Organisationsvalidierte SSL-Zertifikate: Hier wird zusätzlich auch das Unternehmen an sich geprüft
    (d.h. in der Regel wird die Zertifizierungsstelle den Gewerbeschein und/oder Handelsregisterauszug prüfen)
  • Erweitert validierte SSL-Zertifikate: Hier wird wohl noch genauer geprüft.
    Das interessante an diesen Zertifikaten: Die Browser zeigen in der Regel den Firmennamen in der Adresszeile mit an, wie beispielsweise bei https://www.paypal.com zu sehen.
...der Unterschied ist hier also dass der Besucher je nach Zertifikats-Typ mehr Informationen über die Firma die hinter der Domain steckt sehen kann.
Für den Zweck die Kundendaten zu schützen reicht theoretisch schon das billigste SSL-Zertifikat aus.

SSL-Zertifikate sind standardmässig an eine bestimmte Domain gebunden (also z.B. "www.example.org") - und nicht wie häufig falsch angenommen an eine bestimmte IP.
Falls auch Subdomains mit abgedeckt werden sollen, wird ein Wildcard-Zertifikat benötigt (d.h. dann ist auch "www.example.org", "shop.example.org", "cdn.example.org", etc. möglich)
Es können über Multidomain-Zertifikate auch mehrere Domains mit dem gleichen SSL-Zertifikat abgedeckt werden (d.h. z.B. "www.example.org" und "www.example-shop.org")
Achtung: Je nach Anbieter/Paket werden teils auch Wildcard-Zertifikate als Multidomain-Zertifikat bezeichnet oder auch umgekehrt.
Bzgl. Limiterungen unbedingt jeweils die Beschreibungen der Angebote durchlesen.

"Früher" musste man pro SSL-Zertifikat eine eigene Server-IP verwenden.
Dank SNI ("Server Name Indication") ist dies nicht mehr zwingend notwendig: https://de.wikipedia.org/wiki/Server_Name_Indication#Unterst.C3.BCtzte_Software
(Bei SNI sendet der Browser schon beim Aufbau der SSL-Verbindung die gewünschte Domain mit und der Webserver kann das dazu passende SSL-Zertifikat auswählen und verwenden)

Der Ablauf einer manuellen SSL-Einrichtung sieht meist etwa so aus:
1) Auf dem Webserver wird ein Private-Key und ein Public-Key erstellt
2) Auf dem Webserver wird ein CSR ("Certificate Signing Request") erstellt und mit dem Private-Key signiert. Im CSR stehen allgemeine Firmendaten sowie im "Common-Name" in der Regel die Domain für die das Zertifikat erstellt wird.
3) Der CSR wird zum Anbieter des SSL-Zertifikats gesendet (ggf. mit weiteren Dokumenten)
4) Von dort bekommt man einen CRT zurück (das ist mehr oder weniger einfach der CSR, der aber nun vom SSL-Anbieter signiert wurde)
5) Der CRT und der in Schritt 1 generierte Private-Key werden im Webserver eingerichtet. Zusätzlich müssen ggf. noch Zwischenzertifikate im Webserver eingerichtet werden.
(Schritt 1+2 müssen nicht zwingend auf dem Webserver gemacht werden, dort sind die dazu nötigen Tools in der Regel aber bereits vorhanden)
...davon werden je nach Hoster einige Teile von den Weboberflächen oder den Support des Hosters teils oder gar ganz abgenommen.

Nach der Einrichtung:
1) Am Besten direkt z.B. via https://www.ssllabs.com/ssltest/ testen, ob auch alles richtig eingerichtet wurde.
Zum Beispiel ein häufiger Fehler: Es werden Zwischenzertifikate vergessen einzurichten => Einige Browser halten das eigentlich gültige Zertifikat dann nicht für gültig.
2) Die üblichen Shop-Abläufe z.B. in google Chrome mit geöffneter Debug-Konsole durchtesten und dabei speziell auf "Mixed-Content"-Fehler in der Konsole achten.
Mixed Content = Trotz SSL-Verschlüsselung werden einige Elemente nicht über SSL geladen.
Da der Besucher dann nicht mehr direkt wissen kann welche Teile nun verschlüsselt oder unverschlüsselt übertragen werden, zeigen Browser dann in der Regel das https durchgestrichen an oder ähnliches.
Der IE gibt dann gerne ganz schlimme Warnmeldungs-Popups aus (die der Nutzer aber meist aufgrund des Fehlers auf einer anderen Seite schon dauerhaft ausgeschaltet hat)
Besucher kriegen dann teils mehr Panik, als hätte der Shop gar keine Verschlüsselung ;D
=> Wenn SSL aktiv ist, sollten auch ALLE Elemente in der Seite über https:// statt http:// geladen werden.
Alle falsch eingebundenen URLs (und häufig auch von externen eingebundene Skripte) zu finden und entsprechend zu korrigieren macht häufig den Großteil des Aufwands der SSL-Einrichtung aus!

Tipp: URLs über protocol-relative URLs angeben, d.h. "//www.example.org/bild.jpg" statt "https://www.example.org/bild.jpg" verwenden.
Alle einigermaßen aktuellen Browser setzen dann automatisch https oder http davor - je nachdem ob die aktuelle Seite über https oder http geladen wurde.

Noch ein Tipp: Ablaufdatum der Zertifikate im Kalender notieren und rechtzeitig um Erneuerung kümmern.
Oder falls es der Hoster übernimmt: In der Regel wird ein Zertifikat schon ein paar Tage vor Ablauftag ausgetauscht - Besser prüfen, dass der Hoster es nicht verschläft.
Abgelaufenes SSL-Zertifikat wird definitiv für Kauf-Abbrüche sorgen.

Je nach SSL-Zertifikat gibt es häufig noch die Möglichkeit eine Art Siegel einzubinden (z.B. "Secured by thawthe - (Aktuelles Datum)".
Diese Siegel werden leider häufig via synchronem JS eingebunden und verlangsamen teils die Seitenladezeit deutlich! Wenn man die nutzen will: Besser in einen iframe packen, damit es asynchron laden kann.
 

dixeno-bhesse

Aktives Mitglied
30. August 2014
92
5
#3
Da passend zum Thema, hole ich den Thread mal von den Toten hervor:
aus: https://www.heise.de/security/meldu...8-mag-HTTP-ueberhaupt-nicht-mehr-4104569.html
Am 23. Juli will Google mit der Version 68 des Webbrowsers Chrome einen weiteren Schritt hin zum verschlüsselten Internet machen: Ab diesem Datum kennzeichnet der Browser unverschlüsselte Seiten ohne TLS-Zertifikat als nicht sicher. Diese Warnung soll bei allen HTTP-Webseiten in der Adressleiste auftauchen.
...schon wegen DSGVO und Zahlungsmodulen sollte das aber mittlerweile hoffentlich wohl ohnehin jeder längst aktiv haben ;)