SSL Verschlüsselung

[PamA2013]

Hi,

mir ist schon länger aufgefallen, dass MTB-News bzw das Forum nicht so richtig auf SSL ausgerichtet ist. So kann ich mich zum Beispiel wenn ich mich bei https://www.mtb-news.de/ ins Forum einlogge, nicht in den Bikemarkt einloggen. Weder auf https noch auf http. Im Bikemarkt werden ja doch ein haufen sensibler Daten, wie Kontonummern und Adressen ausgetauscht. Scheinbar völlig unverschlüsselt. Das bedeutet dass zum Beispiel die beteiligten Internetprovider vollständig mitlesen können was geschrieben wird, oder auch betreiber von Hotspots wenn man sich darüber einloggt.
Ich weiß nicht ob das Problem in der Form bei anderen auch auftritt, aber ich kann eine Nutzung von SSL nicht forcieren, dann funktionieren teile der Seite bzw der Bikemarkt garnicht mehr.

Grüße

 

[ploerre]

bei mir geht da gar nichts (ERR_TOO_MANY_REDIRECTS)
EDIT: betrifft nur die Startseite. Rest scheint zu gehen.

Ich finde, 2017 und in Zeiten von Let's Encrypt Zertifikaten gibt es eigentlich keine Entschuldigung mehr, nicht SSL zu verwenden. (meiner Meinung gehört das sogar Serverseitig enforced, d.h. Weiterleitung von http auf https)

Wenn man z.B auf dem Forum über SSL ist und auf Bikemarkt klickt (oder umgekehrt) landet man wieder auf der unverschlüsselten Version.
Das mit den potentiellen Securityleaks betrifft ja nicht nur das eigene Userverhalten, sondern auch das des Gegenübers, mit dem man gerade Kontodaten usw. austauscht. Ohne SSL Enforcement kann ich da noch und nöcher aufpassen wie Luchs, ich hab da letztlich keine Kontrolle drüber.

 

[PamA2013]

Ich muss auch gestehen dass ich ein bisschen schockiert bin, dass hier niemand mal von offizieller Seite ein Statement zu abgibt. Ich hatte doch mit mehr resonanz gerechnet.

 

[Bener]

@rik was sagstn Du dazu??

 

[Marcus]

was sagstn Du dazu??

Wir sind dran. In den nächsten Tagen wird die erste Sub-Site von MTB-News.de auf HTTPS-only umgestellt.

Viele Grüße

rik

 

[Marcus]

Ich finde, 2017 und in Zeiten von Let's Encrypt Zertifikaten gibt es eigentlich keine Entschuldigung mehr, nicht SSL zu verwenden.

Das Vorhandensein von Zertifikaten war noch nie das Problem, die haben wir seit über 15 Jahren. Es gibt andere Constraints (die wir nicht unmittelbar beeinflussen können), die dafür sorgen, dass eine Umstellung nicht trivial ist. Wir sind dran.

 

[Schildbürger]

Scheitert es an der Werbung?
Die brauchen wir nicht, das vereinfacht die Sache doch!

 

[reo-fahrer]

Scheitert es an der Werbung?
Die brauchen wir nicht, das vereinfacht die Sache doch!

naja, je nachdem wo man das SSL terminiert, ob am loadbalancer oder webserver, cloudflare hängt da ja auch irgendwie mit drin, da ist man halt darauf angewiesen, was die Dienstleister können und wollen.

 

[franticz]

Ich krieg seit gestern immer schöne Server Identitäts Abfragen, weil das Zertifikat nicht vertrauenswürdig ist

 

[Marcus]

Ich krieg seit gestern immer schöne Server Identitäts Abfragen, weil das Zertifikat nicht vertrauenswürdig ist

Gib uns doch mal bitte ein paar mehr Details …

 

[franticz]

Repo Steps (auf 3 mobilen Geräten verifiziert):
Browser öffnen -> mtb-news.de laden -> Forenübersicht -> dann auf Fotos
danach kommt die Abfrage.

Es scheint eine auch abhängig zu sein, wie man auf die fotoseite geht. rufe ich direkt die foto übersicht auf funktioniert alles wie gehabt

falls nötig mach ich die reposteps auch nochmal mit bilder für euch.

 

[franticz]

Es ist übrigens egal ob apple gerät oder android

 

[Marcus]

falls nötig mach ich die reposteps auch nochmal mit bilder für euch.

Danke, nicht notwendig. Konnte es nachvollziehen. Problem ist jetzt behoben.

Hintergrund: es war eine falsche Weiterleitungs-URI für die mobile Website hinterlegt. Die hat aktuell nicht nur eine 3rd-Level-Domain (fotos.mtb-news.de), sondern eine 4th-Level-Domain (m.fotos.mtb-news.de). 4th-Level-Domains sind aber mit einem Wildcard-SSL-Zertifikat (*.mtb-news.de) nicht enthalten und so zeigte der Browser - zu recht - eine Fehlermeldung an.

Viele Grüße

rik

 

[franticz]

Gerne.

 

[Nordschleifeb1]

Das Vorhandensein von Zertifikaten war noch nie das Problem, die haben wir seit über 15 Jahren. Es gibt andere Constraints (die wir nicht unmittelbar beeinflussen können), die dafür sorgen, dass eine Umstellung nicht trivial ist. Wir sind dran.

Hallo,
gibt es eigentlich einen Grund, warum nicht mtb-news.de als erster Wert für die Gültigkeit des Zertifikats hinterlegt ist? Zudem weiß ich nicht was daran so schwierig ist, einen https redirect einzubauen. Funktionieren die Tracker dann nicht mehr oder was genau hindert auch daran?

Gibt mittlerweile 1000 Tutorials dazu. Zudem störe ich mich etwas am Tracker der InfoOnline, welches vom Forum genutzt wird. Ein Optout ist bei denen wohl nur über das aufrufen der Seite: https://optout.ioam.de/ möglich. Sobald ich mein Browser aber schließe und das Cookie gelöscht wird, ist wieder der Tracker aktiv.

PS: Falls ihr Hilfe bei konfigurieren braucht, bitte eine PN.

Gruß
Michael

 

[Marcus]

Hallo,

gibt es eigentlich einen Grund, warum nicht mtb-news.de als erster Wert für die Gültigkeit des Zertifikats hinterlegt ist?

was genau meinst du damit?

Zudem weiß ich nicht was daran so schwierig ist, einen https redirect einzubauen.

Das ist nicht schwierig.

Funktionieren die Tracker dann nicht mehr oder was genau hindert auch daran?

Wir können aktuell noch nicht sicher stellen, dass _alle_ eingebundenen externen* Ressourcen HTTPS unterstützen, arbeiten aber daran.

Sobald ich mein Browser aber schließe und das Cookie gelöscht wird, ist wieder der Tracker aktiv.

Das stimmt so nicht: das Cookie wird mit einer Lebensdauer von 10 Jahren gespeichert, was Browser in Standardkonfiguration auch berücksichtigen.

Viele Grüße

rik


* extern bedeutet, dass wir die Konfiguration dieser nicht unmittelbar beeinflussen können.

 

[Nordschleifeb1]

Hallo,
was genau meinst du damit?

Siehe Screenshot. Auf den ersten Blick ist für mich nicht ersichtlich, dass das Zertifikat zu mtb-news.de gehört, sondern ich sehe nur eine cloudflare-Adresse. Dies steht erst in den alternativen Werten des Zertifikates.

Wir können aktuell noch nicht sicher stellen, dass _alle_ eingebundenen externen* Ressourcen HTTPS unterstützen, arbeiten aber daran.

Mail an Support bzw Vertrieb und nachfragen. Wenn nicht unterstützt -> Feature Request oder Produkt wechseln.

Das stimmt so nicht: das Cookie wird mit einer Lebensdauer von 10 Jahren gespeichert, was Browser in Standardkonfiguration auch berücksichtigen.

Prinzipiell richtig, gibt aber in der Praxis Probleme damit:
- Ich möchte meine Cookies nicht 10 Jahre aufbewahren, dann kann ich direkt auch ein Buch auslegen auf welchen Seiten ich war
- Cookies werden bei mir bspw automatisch gelöscht, wenn der Browser geschlossen wird -> Ich müsste jedes Mal auf die Seite gehen um das Cookie wieder zu setzen
- Privater Modus von Chrome, Firefox etc "effektiv" nicht nutzbar
- Es ist für mich als Benutzer dieser Seite nicht erkennbar, ob evtl auch des Senden des Do not Track-headers ausreichen würde

Viele Grüße

rik

* extern bedeutet, dass wir die Konfiguration dieser nicht unmittelbar beeinflussen können.

Gruß,
Michael

 

[Marcus]

Siehe Screenshot. Auf den ersten Blick ist für mich nicht ersichtlich, dass das Zertifikat zu mtb-news.de gehört, sondern ich sehe nur eine cloudflare-Adresse. Dies steht erst in den alternativen Werten des Zertifikates.

Das macht dein Browser ja für dich. Sobald der CN oder ein „DNS Name” nicht mit dem aktuellen Host der URI übereinstimmen, bekommst du eine auffällige Warnung. Für das Webbrowsen ist es technisch egal, in welchem Feld des Certs der Hostname steht, solange er nur übereinstimmt.

Mail an Support bzw Vertrieb und nachfragen. Wenn nicht unterstützt -> Feature Request oder Produkt wechseln.

Ja, in einer einfachen Welt wäre das vermutlich eine gangbare Option ;-)

Prinzipiell richtig, gibt aber in der Praxis Probleme damit:

Ich schrieb ja, dass das für ein Browser in der Standard-Einstellung gut funktioniert. Du bringst jetzt zumindest drei Punkte, bei denen du explizit vom normalen™ Einsatz abweichst. Die IVW schreibt auch direkt auf der von dir verlinkten Seite:

Falls Sie dieses Cookie löschen, müssen Sie erneut die Opt-Out-Funktion aktivieren, wenn Sie der Messung von Seitenaufrufen widersprechen möchten.

Schlussendlich bleibt es jetzt deine Entscheidung, ob du vor jedem Seitenbesuch das Opt-out triggerst, 3rd-Party-Cookies generell (oder speziell für IVW) gar nicht erst annimmst, den Browser mit unveränderten Einstellungen benutzt oder sogar das Browsen ganz sein lässt.

Viele Grüße

rik

 

[Nordschleifeb1]

Das macht dein Browser ja für dich. Sobald der CN oder ein „DNS Name” nicht mit dem aktuellen Host der URI übereinstimmen, bekommst du eine auffällige Warnung. Für das Webbrowsen ist es technisch egal, in welchem Feld des Certs der Hostname steht, solange er nur übereinstimmt.

Das stimmt wohl. Trotzdem prüfe ich als erstes den 1. Wert vom Zertifkat, neben der Gültigkeit. Technisch ist es egal, wenn ich aber die Nutzer schule wie sie ein Zertifikat prüfen, werden sie vermutlich den alternativen Wert nicht prüfen, da sie es bei 99% der normalen Seiten auch nicht machen müssen, da diese bereits als 1. Wert die richtige URL enthalten. In dem Falle hier würden sie es halt vergessen. Und da würde ich erstmal daraus schließen, dass jemand die Seite nachgebaut hat und versucht meine Daten abzugreifen...

Ja, in einer einfachen Welt wäre das vermutlich eine gangbare Option ;-)

Zumindest in der IT-Welt läuft das so. Produkt erfüllt nicht die Anforderungen -> Kunde kauft es nicht mehr und wechselt.

Ich schrieb ja, dass das für ein Browser in der Standard-Einstellung gut funktioniert. Du bringst jetzt zumindest drei Punkte, bei denen du explizit vom normalen™ Einsatz abweichst. Die IVW schreibt auch direkt auf der von dir verlinkten Seite:

Was wird den bitte als normaler Einsatz definiert? Das Optout über Cookie ist ja ok, allerdings würde ich als Anbieter auch mich drauf vorbereiten, dass es diese Option bei einen Teil der Nutzer nicht gibt. Eigentlich sollte das im Interesse von jedem sein. Und bisher kann ich auch nicht sehen dass es von denen ein Addon geben würde, was mir diese Arbeit automatisch abnehmen würde...

Schlussendlich bleibt es jetzt deine Entscheidung, ob du vor jedem Seitenbesuch das Opt-out triggerst, 3rd-Party-Cookies generell (oder speziell für IVW) gar nicht erst annimmst, den Browser mit unveränderten Einstellungen benutzt oder sogar das Browsen ganz sein lässt.

Viele Grüße

rik

Das stimmt wohl, wollte halt mal so paar Anregungen geben.

 

[PamA2013]

Ich finde den Umgang hier extrem fahrlässig, auch dass ihr so locker damit umgeht. Die Daten die man hier abgreifen kann sind brand gefährlich und offensichtlich ist euch der Mangel ja auch bekannt. Das Missbrauchspotential ist quasi unmöglich.
Hier werden völlig unverschlüsselt sämtliche Persönliche Daten ausgetauscht. Jemand der diese Daten abgreift, hat Adresse Kontodaten und vermutlich sogar eine Liste mit Hochwertigen Gegenständen die er abgreifen muss wenn er einsteigt. Wenn mich jemand auf solch massive Sicherheitsmängel hinweisen würde, würde ich meine Platform abschalten is das behoben ist.

 

[Marcus]

Technisch ist es egal, wenn ich aber die Nutzer schule wie sie ein Zertifikat prüfen, werden sie vermutlich den alternativen Wert nicht prüfen, da sie es bei 99% der normalen Seiten auch nicht machen müssen, da diese bereits als 1. Wert die richtige URL enthalten.

Naja, das würde ich so nicht sagen. Um beim aktuellen Beispiel zu bleiben: Cloudflare dürfte mittlerweile Proxy vor einer zweistelligen Prozentzahl des gesamten Webs sein, was das Aufkommen derartiger Zertifikate in eine ebensolche Größenordnung bringt. Ich denke, hier solltest du deine Nutzer schulen, nicht nur auf den CN zu schauen, sondern ebenfalls auf die anderen validen Felder.

Zumindest in der IT-Welt läuft das so. Produkt erfüllt nicht die Anforderungen -> Kunde kauft es nicht mehr und wechselt.

Wenn du in der IT-Welt unterwegs bist, weißt du, dass "wechseln" einen Prozess beschreibt, welcher mitunter von so vielen Randbedingungen abhängig ist, dass er entweder wirtschaftlich nicht sinnvoll ist oder einen sehr langen Zeitraum in Anspruch nehmen kann.

Was wird den bitte als normaler Einsatz definiert?

Browser out of the box, würde ich sagen. Das sieht natürlich jeder anders (mich eingeschlossen), aber ein Großteil der Nutzer kümmert sich nicht um Cookie-Settings usw.

Und bisher kann ich auch nicht sehen dass es von denen ein Addon geben würde, was mir diese Arbeit automatisch abnehmen würde...

Business Opportunity ;-)

Viele Grüße

rik

 

[Nordschleifeb1]

Naja, das würde ich so nicht sagen. Um beim aktuellen Beispiel zu bleiben: Cloudflare dürfte mittlerweile Proxy vor einer zweistelligen Prozentzahl des gesamten Webs sein, was das Aufkommen derartiger Zertifikate in eine ebensolche Größenordnung bringt. Ich denke, hier solltest du deine Nutzer schulen, nicht nur auf den CN zu schauen, sondern ebenfalls auf die anderen validen Felder.

Wie ich bereits schrieb, ist die Prüfung des CN nur ein Teil. Sofern aber der FQDN als 1. Wert des Zertifkates hinterlegt ist, kann ich auf einen Blick zumindest eine Aussage treffen, ob irgendwas verdächtig ist und muss nicht erst mit openssl s_client oder über die erweiterte Ansicht das passende Feld suchen ;-)

Wenn du in der IT-Welt unterwegs bist, weißt du, dass "wechseln" einen Prozess beschreibt, welcher mitunter von so vielen Randbedingungen abhängig ist, dass er entweder wirtschaftlich nicht sinnvoll ist oder einen sehr langen Zeitraum in Anspruch nehmen kann.

Wäre es denn zumidnest möglich, dass wenn ich mit HTTPS einsteige auch dauerhaft bei euch auf https bleibe und nicht beim Wechsel in den Bikemarkt über den Klick des Links wieder auf http lande und wieder manuell zu HTTPS wechseln muss?

Browser out of the box, würde ich sagen.

Vereinfacht ja, trifft aber wohl nur auf Heimanwender zu.

Business Opportunity ;-)

Umatrix, uBlock, Disconnect nur um paar zu nennen ;-)

Viele Grüße

rik

Gruß

 

[Bike_Ride]

Mir ist es im Endeffekt fast egal, was MTB-News mit Trackern und deren Cookies macht. Gleiches gilt für die Namensgebung der SSL Zertifikate. Oftmals lässt einem der angemietet Service wirtschaftlich ja keine andere Möglichkeit. Davon mal abgesehen, dass man eh bei jeder Gelegenheit von anderer Stelle überwacht und kontrolliert werden kann.

Als User mit entsprechendem Fachhintergrund würde ich das Forum-Team, welches für die technische Administration des Portals zuständig ist, dennoch darum bitten, HTTPS bei allen Anmeldungsmöglichkeiten und im BikeMarkt bei der Übertragung sensibler Daten zu forcieren. Natürlich auch bei einem Wechsel vom Forum in den BikeMarkt und zurück.

Eine grundsätzliche Sicherung mit HTTPS ist ja bei manueller Eingabe möglich.
Der Standarduser ohne IT-Hintergrund weis das aber vielleicht nicht, sofern er überhaupt drauf achtet. Dann kann ich mich mit SSL/TLS manuell so gut schützen wie ich möchte, habe aber nichts davon, wenn meine Daten auf der anderen Seite unverschlüsselt abgerufen werden.
Mir würde es also schon reichen, wenn das entsprechend eingetragen würde.

 

[ploerre]

Könnte man vllt wenigstens die Links oben in der Leiste (Bikemarkt, Forum) auf https setzen?
Ich lande jedesmal beim Klick rüber wieder auf den unverschlüsselten Seiten, auch wenn ich via SSL eingestiegen bin.

 

[Nordschleifeb1]

https://www.heise.de/security/meldu...t-sich-bei-Firefox-ueber-Warnung-3660544.html