nicht angemeldet
DSGV Bullshit
JürgenB
Rolf B
Auge
Gunnar BittersmannHab für einen Kunden ein Zertifikat eingerichtet. Nun hat er gemischte Inhalte weil er Ressourcen einbindet die nicht verschlüsselt sind. Der Browser blockert das. Hat jemand eine Idee was man hier tun kann!? Der Kunde ist stinksauer!
-
Hallo,
von wo kommen denn die unverschlüsselten Ressourcen? Eigene oder Fremddomain?
Gruß
Jürgen-
von wo kommen denn die unverschlüsselten Ressourcen? Eigene oder Fremddomain?
Das sind Seiten zum selben Thema die auf anderen Domänen liegen. Darauf hat mein Kunde keinen Einfluß. Mein Kunde hat übrigens bezahlt für das Zertifikat, ist aber nicht nur deswegen stinksauer.
-
Hallo Wallpappe,
Das sind Seiten zum selben Thema die auf anderen Domänen liegen. Darauf hat mein Kunde keinen Einfluß. Mein Kunde hat übrigens bezahlt für das Zertifikat, ist aber nicht nur deswegen stinksauer.
Wenn die Dritt-Seite keine HTTPS-Variante davon abietet: bad luck. HTTPS wieder abschalten bis die Dritt-Seite eine HTTPS-Variante anbietet. Und natürlich Druck machen, dass das auch passiert.
LG,
CK-
Das sind Seiten zum selben Thema die auf anderen Domänen liegen. Darauf hat mein Kunde keinen Einfluß. Mein Kunde hat übrigens bezahlt für das Zertifikat, ist aber nicht nur deswegen stinksauer.
Wenn die Dritt-Seite keine HTTPS-Variante davon abietet: bad luck. HTTPS wieder abschalten bis die Dritt-Seite eine HTTPS-Variante anbietet. Und natürlich Druck machen, dass das auch passiert.
Was soll das denn werden!? Witzbold!
-
Hallo Wallpappe,
Wenn die Dritt-Seite keine HTTPS-Variante davon abietet: bad luck. HTTPS wieder abschalten bis die Dritt-Seite eine HTTPS-Variante anbietet. Und natürlich Druck machen, dass das auch passiert.
Was soll das denn werden!? Witzbold!
Das war kein Witz. Das war die Antwort auf deine Frage. Hast du an der Antwort etwas nicht verstanden? Dann frag nach 😀
LG,
CK-
Das war kein Witz. Das war die Antwort auf deine Frage. Hast du an der Antwort etwas nicht verstanden? Dann frag nach 😀
Dann erkläre hier mal bitte was Du meinst mit Druck ausüben! So redet man nicht mit Kunden!
-
Hallo Wallpappe,
Das war kein Witz. Das war die Antwort auf deine Frage. Hast du an der Antwort etwas nicht verstanden? Dann frag nach 😀
Dann erkläre hier mal bitte was Du meinst mit Druck ausüben!
Du rufst beim Betreiber der Dritt-Seite an und sagst ihm „Alter, wir haben 2019, rüste mal schnellstens HTTPS nach!“
So redet man nicht mit Kunden!
Du sagtest in dem Posting, auf das ich geantwortet habe, der Kunde habe keinen Einfluss auf die Dritt-Seiten.
LG,
CK -
Hallo Wallpappe,
dein Kunde müsste auf die Dritt-Domains "Druck ausüben" - wie auch immer man das diplomatisch vermitteln kann -, dass sie ihre Ressourcen https-verschlüsselt anbieten.
Oder auf https ganz oder teilweise verzichten.
Warum will der Kunde https? Habt ihr die Möglichkeit, https auf die Seiten zu begrenzen, auf denen es unbedingt gebraucht wird (tyischerweise ein Kontaktformular oder der Warenkorb eines Webshop)? Sind die Drittressourcen statisch? Könntet ihr die auf den Kundenserver replizieren?
Die erwähnte Proxy-Technik solltest Du NICHT anbieten. Zum Einen ist das nicht so ganz trivial, weil Du die Ressourcen, die Du durch den Proxy jagst, auf weitere Referenzen auf http-Ressourcen parsen und diese Referenzen auf deinen Proxy verbiegen musst. Zum Anderen verkaufst Du damit - wie schon von anderen geschrieben - Schlangenöl.
Fazit: Der Kunde könnte Dir einen Beratungsfehler vorwerfen und Dich für die Zertifikatskosten in Regress nehmen. Vor Gericht könnte er damit sogar durchkommen. Angesichts deiner entrüsteten Fragen hier war Dir die mixed-content Problematik in aktuellen Browsern unbekannt, und wenn dein Kunde diesen Thread findet, hat er einen unangenehmen Beweis gegen Dich in der Hand.
Rolf
--
sumpsi - posui - clusi-
Hallo
dein Kunde müsste auf die Dritt-Domains "Druck ausüben" - wie auch immer man das diplomatisch vermitteln kann -, dass sie ihre Ressourcen https-verschlüsselt anbieten.
Kann es sein, dass wir hier zwei Szenarien vermischen?
- In eine über HTTPS aufgerufene Seite werden Ressourcen per HTTP eingebunden (Bilder, JS, CSS, you name it). Browser quittieren das mindestens mit einer Meldung oder verweigern das Laden gleich ganz. Das tun sie nicht überraschend seit heute sondern (zumindest bezüglich der Meldung) seit Jahren. Dass jemand davon überrascht wird, überrascht mich.
- In einer per HTTPS aufgerufene Seite werden fremde Inhalte mit dem Protokoll HTTP verlinkt. Das sollte überhaupt kein Problem sein, nicht zu Meldungen führen und auch keine Einflussnahme auf die Betreiber dieser Seiten erfordern.
Sind die Drittressourcen statisch? Könntet ihr die auf den Kundenserver replizieren?
Das dürfte Probleme mit dem Urheberrecht provozieren. Es verbietet einem aber niemand, die externen Ressourcen darauf zu prüfen, ob sie nicht auch per HTTPS erreichbar sind. Oft wurden externe Bilder oder WasAuchImmer ja vor Ewigkeiten eingebunden, als die allermeisten Seiten nur unverschlüsselt erreichbar waren und üblicherweise hat danach nie jemand geprüft, ob sich im Laufe der Jahre daran etwas geändert hat.
Tschö, Auge
--
Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
Hohle Köpfe von Terry Pratchett-
Hallo Auge,
da von Problemen im Mischbetrieb gesprochen wurde und Wallpappe auch im OP das Wort "eingebunden" nutzte, wird es wohl Szenario 1 sein.
Szenario 2 merkt man überhaupt nicht, es sei denn, ich hätte auf https://example.org einen Link drin mit href="//example.net". Aber (1) würde ich sagen, dass das bad practice ist und (2) könnte man das problemlos auf Kundenseite beheben.
Rolf
--
sumpsi - posui - clusi-
Nein so einfach ist das nicht. Die Partner, das sind größtenteils ehrenamtlich betriebene Server und das müssen wir schon denen selbst überlassen wann sie auf HTTPs umstellen. Falls das überhaupt möglich ist mit hardcodierten Webservern die auf Appliances laufen. Es ist einfach nur schade um dieses wundervolle Projekt!
-
Hallo
Nein so einfach ist das nicht. Die Partner, das sind größtenteils ehrenamtlich betriebene Server und das müssen wir schon denen selbst überlassen wann sie auf HTTPs umstellen.
Was wird denn überhaupt von fremden Domains wie in die Seite eingebunden, dass sie der Browser des Benutzers anfordern muss?
Tschö, Auge
--
Ein echtes Alchimistenlabor musste voll mit Glasgefäßen sein, die so aussahen, als wären sie beim öffentlichen Schluckaufwettbewerb der Glasbläsergilde entstanden.
Hohle Köpfe von Terry Pratchett -
Liebe(r) Wallpappe,
Nein so einfach ist das nicht.
kommt darauf an.
Die Partner, das sind größtenteils ehrenamtlich betriebene Server und das müssen wir schon denen selbst überlassen wann sie auf HTTPs umstellen.
Es mag deren Sache sein, ob und wann sie Zertifikate einsetzen. Es ist aber Deine Sache, ob so lange überhaupt Inhalte in die Seite Deines Kunden eingebunden werden.
Und was ist mit iframes? Wenn schon Scheiße, dann soll sie doch auch stinken, oder?
Falls das überhaupt möglich ist mit hardcodierten Webservern die auf Appliances laufen.
Was willst Du uns damit sagen?
Es ist einfach nur schade um dieses wundervolle Projekt!
Welches Projekt? Und was ist daran wundervoll?
Liebe Grüße,
Felix Riesterer.
-
-
-
Wäre ja noch schöner wenn ich mich jetzt mit meinem Kunden vor Gericht streiten würde!
-
-
-
-
-
-
Hallo,
von wo kommen denn die unverschlüsselten Ressourcen? Eigene oder Fremddomain?
Das sind Seiten zum selben Thema die auf anderen Domänen liegen. Darauf hat mein Kunde keinen Einfluß.
dann musst ihr, du und dein Kunde, der ja möglicherweise Kunde beim Betreiber der „anderen Domänen“ ist, diesen dazu bewegen, auch auf https umzustellen und bis dahin bei deinem Kunden die Verschlüsselung wieder abschalten.
Mein Kunde hat übrigens bezahlt für das Zertifikat, ist aber nicht nur deswegen stinksauer.
Dann sieh zu, dass du das wieder gerade biegst.
Gruß
Jürgen
-
-
-
@@Wallpappe
Hab für einen Kunden ein Zertifikat eingerichtet. Nun hat er gemischte Inhalte weil er Ressourcen einbindet die nicht verschlüsselt sind.
Und der Anbieter stellt diese Ressourcen nicht wie inzwischen allgemein üblich über HTTPS zur Verfügung?
Hat jemand eine Idee was man hier tun kann!?
Einfach
http://…inhttps://…ändern?Und was genau hat deine Frage mit DSGV [sic!] zu tun?
LLAP 🖖
--
„Wer durch Wissen und Erfahrung der Klügere ist, der sollte nicht nachgeben. Und nicht aufgeben.“ —Kurt Weidemann -
Tach!
Hab für einen Kunden ein Zertifikat eingerichtet. Nun hat er gemischte Inhalte weil er Ressourcen einbindet die nicht verschlüsselt sind. Der Browser blockert das. Hat jemand eine Idee was man hier tun kann!? Der Kunde ist stinksauer!
Auf so einen Dienstleister wäre ich sicher auch sauer, aber der Gemütszustand des Kunden bringt das Problem nicht weiter.
Die sauberste Lösung wäre, wie schon genannt, keine unsicheren Quellen in eine gesicherte Datenübertragung aufnehmen. Das wird bereits seit langen von den Browsern so gehandhabt, denn Sicherheit bringt nicht viel, wenn da das Scheunentor offensteht.
In der Praxis ist es aber oft nicht so einfach möglich, die Datenquellen zu beeinflussen oder sie zu vermeiden. Es gibt auch keinen Schalter, den man einfach so im Browser der Besucher umlegen könnte, um die unsichere Kommunikation zu ermöglichen. Außer man steigt wieder zurück auf generell unsichere Webseiten, denn die können problemlos sichere Quellen einbinden. Aber auch das wird keine Option in dem Fall sein.
Der einzige Ausweg wäre, dass der Server des Kunden sich als Proxy betätigt und die unsicheren Daten abfragt und über die gesicherte Verbindung ausliefert. Aber damit reißt man genau das Loch auf, das die Browser zu vermeiden versuchen, und klebt noch ein Gütesiegel drauf. Solch ein Vorgehen dürfte keiner ernsthaften Sicherheitsprüfung standhalten.
Übrigens, wenn ich hier von sicher und unsicher gesprochen habe, handelt es sich lediglich um die Absicherung des Übertragungswegs. Wie Server und Client selbst oder die angefragten Datenquellen inklusive Verarbeitung gesichert sind oder nicht, steht auf einem anderen Blatt. Zu einem umfassenden Konzept gehört also nicht nur ein Zertifikat zu kaufen (die einfachen Formen gäbe es bei Let's Encrypt auch kostenlos) und ein s anzuhängen.
dedlfix.
-
Hallo dedlfix,
Der einzige Ausweg wäre, dass der Server des Kunden sich als Proxy betätigt und die unsicheren Daten abfragt und über die gesicherte Verbindung ausliefert. Aber damit reißt man genau das Loch auf, das die Browser zu vermeiden versuchen, und klebt noch ein Gütesiegel drauf. Solch ein Vorgehen dürfte keiner ernsthaften Sicherheitsprüfung standhalten.
Nein, das ist kein Ausweg. Das ist ein übler Hack, der eine Menge anderer Probleme mit sich bringt. Don't do that!
LG,
CK-
Tach!
Der einzige Ausweg wäre, dass der Server des Kunden sich als Proxy betätigt und die unsicheren Daten abfragt und über die gesicherte Verbindung ausliefert. Aber damit reißt man genau das Loch auf, das die Browser zu vermeiden versuchen, und klebt noch ein Gütesiegel drauf. Solch ein Vorgehen dürfte keiner ernsthaften Sicherheitsprüfung standhalten.
Nein, das ist kein Ausweg. Das ist ein übler Hack, der eine Menge anderer Probleme mit sich bringt. Don't do that!
Hab ich ja gesagt, dass das keine gute Lösung ist. Aber erzähl mal bitte was Näheres zu den möglichen Problemen.
dedlfix.
-
Hallo dedlfix,
Aber erzähl mal bitte was Näheres zu den möglichen Problemen.
Die kennst du doch selber. 😉
Angefangen beim Caching, um das man sich jetzt selber kümmern muss („ist der Cache ausgelaufen? Frage ich die Ressource jetzt nochmal an?“) damit man nicht den HTTP-Cache vollständig aushebelt, bis hin zu potentiellen Sicherheitsproblemen (ich muss sicherstellen, dass niemand Code einschleusen kann oder mich dazu verführt, Dateien zu überschreiben), ggfls Cookie-Handling. Man lädt sich ggfls fremden Code mit den Rechten der eigenen Origin in den Browser. Man muss jetzt aufpassen, dass die Festplatte nicht voll läuft. Usw, pp.
LG,
CK-
Tach!
Die kennst du doch selber. 😉
Eigentlich ja, obwohl ich sie nicht hätte aus dem Steggreif aufzählen können. Aber es geht mir da nicht um mich, sondern darum, dass auch der OP wissen muss, warum man einen bestimmten Weg nicht oder nur ungern geht. Ein "mach es nicht" hilft wenig beim Verständnis. Deswegen danke, dass du das noch konkretisiert hast.
dedlfix.
-
-
-
-
-
Liebe(r) Wallpappe,
Der Kunde ist stinksauer!
er hat ja auch recht!
Liebe Grüße,
Felix Riesterer.