KlausM schrieb (sinnwahrend gekürzt):

[…]
Funktioniert im Fall des Thread-Öffners aber dennoch nicht. Das Problem liegt nämlich auch bei der Website "onkel-wom.de", auf dem die Bilder gehostet sind.
Die Seite kann zwar https, aber sie hat einerseits ein falsches Zertifikat und andererseits sind die Bilder aus welchen Gründen auch immer über https nicht abrufbar (404).

Hallo Klaus,

das Ganze ist in der Tat etwas jetzt etwas seltsam. Ich habe mir mal nach dem Zufallsprinzip irgend einen X-beliebigen Eintrag Wolfgangs herausgesucht und unter Firefox und MS Edge*) dabei folgendes festgestellt:

────────────────────
_{*) ich könnte das zwar auch noch auf meinem Android-Smartphone testen, erwarte davon aber keine neuen Erkenntnisse, weil ich das bereits früher schon mal ausprobiert hatte}

Firefox 86.0.1 (64-Bit) zeigt die Bilder an:

MS Edge, Version 89.0.774.57 (64-Bit) zeigt die Bilder (welch Überraschung! 😉) nicht an: 

die Bilder lassen sich in einem neuen TAB - oder Fenster einzeln jedoch öffnen, sprich anzeigen: 

reduziert man eine Bildadresse, hier [www.onkel-wom.de], auf [www.onkel-wom.de], erscheint eine Meldung, dass sich diese Seite „im Aufbau“ befände – gleichgültig, welcher der beiden Browser dabei zum Einsatz kommt: 

Irgend etwas an Wolfgangs Seite scheint demnach also in der Tat „irgendwie anders“ zu sein …‽

ruft man jedoch eine andere beliebige andere Seite „im Retrolook“ (Zitat) auf, wird durchaus alles angezeigt – auch beim MS Edge: 

Walter



1-mal bearbeitet. Zuletzt am 2021:03:20:13:24:26.

Hallo zusammen,

vielen Lesern wird nicht so genau klar sein, was es mit http und https auf sich hat. Daher folgend mal der Versuch einer abstrahierenden Erklärung:

Ein DSO-Leser (Kunde) klickt einen Beitrag auf DSO an (Prospekt eines Händlers z.B. über die Straßenbahnen Kassels). Der DSO-Beitrag enthält Links zu Bildern, die nicht auf dem DSO-Server, sondern einem anderen Server abgelegt sind (der Prospekt enthält keine Bilder, die Bilder können jedoch direkt beim Händler bestellt werden). Der Browser des DSO-Lesers fragt daraufhin die Bilder bei dem anderen Server ab (Kunde bestellt die Bilder beim Händler). Der Server liefert die Bilder und der Leser kann den Beitrag mit Bildern lesen (Kunde bekommt Paket vom Händler, das die Bilder enthält und kann sie zusammen mit dem Prospekt anschauen). Für den DSO-Leser sieht es zwar am Browser so aus, als würde er nur eine Anfrage stellen und daraufhin den Beitrag samt Bildern angezeigt zu bekommen. Tatsächlich läuft aber im Hintergrund diese Kaskade ab.

Was hat das jetzt mit http und https zu tun? Ich versuche das mal an dem abstrahierenden Beispiel mit Kunde und Händler zu erläutern. Bei http bestellt der Kunde die Bilder so, dass jeder auf dem Transportweg vom Kunden zum Händler die Bestellung sehen und ggf. manipulieren kann. Das wäre in etwas so, als ob der Kunde per Postkarte bestellt und jeder Postangestellte oder Briefträger die Bestellung lesen und sie ggf. manipulieren kann. Deshalb sollte man auch niemals persönliche Daten, Konto- oder Kreditkarteninformationen und Passwörter über http-Verbindungen verschicken, denn jeder auf dem Transportweg kann sie lesen. Bezogen auf das obige Beispiel ist das nicht so schlimm, da die Bilderbestellung ja keine persönlichen Daten enthält. Es kann halt jeder auf dem Transportweg erfahren, dass sich der Kunde für Straßenbahnen in Kassel interessiert. Der Händler packt nun die Bilder in ein Paket und schickt sie ungesichert dem Kunden zu. Hier kann wiederum auch jeder auf dem Transportweg das Paket öffnen und ggf. den Inhalt gegen eine sagen wir mal Paketbombe austauschen (sogenannte "man-in-the-middle-attack"). Der Kunde merkt wegen dem ungesicherten Versand nicht, dass das Paket unterwegs geöffnet und der Inhalt ausgetauscht wurde. Er öffnet das Paket und es macht bumm!

Wie sieht das jetzt bei https aus? Hier vereinbaren Kunde und Händler vorab einen gesicherten Transport, bei dem praktisch so gut wie ausgeschlossen ist, dass der Brief mit der Bestellung bzw. das Paket mit den Bildern unterwegs geöffnet werden kann bzw. der Händler erkennt anhand vereinbarter Sicherheitsmerkmale, dass der Brief mit der Bestellung auf dem Transportweg geöffnet wurde oder der Kunde erkennt , dass das Paket auf dem Transportweg geöffnet wurde und macht es dann erst gar nicht auf. D.h. Kunde und Händler schützen sich mit https davor, dass jemand auf dem Transport Einblick in die Bestellung/Ware hat und diese ggf. manipulieren kann. Allerdings schützt mich https nicht davor, dass der Händler anstatt der Bilder gleich eine Paketbombe in das Paket steckt!

Eine https-Verbindung stellt also mit sehr hoher Wahrscheinlichkeit sicher, dass niemand auf dem Transportweg die Daten lesen bzw. manipulieren kann (z.B. Einschleusen von "bösem Code"). Die Verschlüsselung per https sollte also sowohl im Interesse des Lesers (Kunde) als auch des Hosters (Händler) sein. Schließlich möchte ja auch der Händler nicht, dass seine Ware auf dem Transportweg durch eine Paketbombe ersetzt wird. Wie hoch jetzt die Wahrscheinlichkeit ist, dass auf dem Transportweg mit http ein unbefugter Dritter die Ware gegen eine Paketbombe austauscht, muss jeder selbst entscheiden. Und wie gesagt, https stellt nicht sicher, dass der Händler nicht direkt eine Paketbombe in das Paket packt. Da muss jeder selbst entscheiden, wie er dem Händler (vulgo der Webadresse) vertraut. Auch eine mit https verschlüsselte Webpage kann fehlerhaften Code enthalten. Ich habe schon öfters von Nutzern gehört: "Ich habe mir das Dokument doch über eine verschlüsselte Verbindung runtergeladen. Das kann doch nichts passieren!". Leider eine komplette Fehleinschätzung!

Ich hoffe, dass ich damit ein bisschen zur Aufhellung beigetragen habe.


Viele Grüße

Florian





1-mal bearbeitet. Zuletzt am 2021:03:20:14:58:37.

Hallo Walter,

seltsam ist das nicht. Es lässt sich ganz gut erklären. Der Hosting-Provider von Onkel_Wom bietet grundsätzlich schon Verschlüsselungen an (erkennbar an dem Zertifikat, dass aber nicht auf die Domain von Onkel_Wom ausgestellt ist). Allerdings verzichtet Onkel_Wom aus Kostengründen auf das Zertifikat und folglich lehnt der Hosting-Provider auch Anfragen über https mit einem Fehler 404 ab. Sobald Onkel_Wom das Zertifikat aktivieren würde (d.h. das Zertifikat wird auf die Domain von Onkel_Wom ausgestellt), würde der Provider auch die https-Verbindung zulassen. Aber das scheint bei Onkel_Wom's Provider eben extra zu kosten.

Dass Firefox die Bilder anzeigt, Edge aber nicht, liegt wie gesagt daran, dass Edge und Chrome grundsätzlich das Laden von Bildern über http zunächst unterbinden. Firefox lässt das (noch) zu, sofern man die Einstellungen entsprechend wählt (siehe oben).

Gibt man eine Domain ohne Verzeichniseingabe ein (z.B. [www.onkel-wom.de], dann gibt der Webserver automatisch die Datei index.html im Stammverzeichnis aus (also z.B. [www.onkel-wom.de]. Da diese nicht existiert (vermutlich hat Onkel_Wom auf seinem Webspace nur Bilder, aber keine html-Dateien abgelegt), wird eine vom Hostprovider standardmäßig generierte Seite mit "ist in Kürze erreichbar" zurückgegeben.

Nun zur Domain [www.gothawagen.de]. Hier ist eine ssl-Verschlüsselung aktiviert, wie man leicht feststellen kann:

https://www.gothawagen.de

Auch Bilder von dieser Domain lassen sich per https laden:

https://www.gothawagen.de/prospekt.JPG


Allerdings hat der Webseitenersteller wohl keine generelle Umleitung von http auf https eingerichtet (z.B. duch die Ablage einer .htacces Datei). Wenn man also die Seite per http aufruft, bekommt man auch eine Antwort über http und nicht automatisch über https. Wenn man also nun die Seite mit Edge oder Chrome aufruft, wird das HTML-Gerüst der Seite geladen. Beim Laden der Bilder versucht der Browser, dieser über eine https-Verbindung zu laden. Da diese bei dieser Domain eingerichtet ist, funktioniert der Bilderdownload über https und die Bilder werden angezeigt. Das "nicht sicher" in der oberen Leiste bezieht sich also auf das HTML-Grundgerüst, nicht aber die Bilder.

Zusammengefasst gibt es also drei Stufen:
- Die Domain bzw. der Provider, auf dem die Domain liegt, unterstützt kein https, z.B. [www.onkel-wom.de]
- Die Domain bzw. der Provider, auf dem die Domain liegt, unterstützt https. Allerdings ist keine generelle Umleitung von http auf https eingerichtet, z.B. [www.gothawagen.de]
- Die Domain bzw. der Provider, auf dem die Domain liegt, unterstützt https und es ist eine generelle Umleitung von http auf https eingerichtet, z.B. [www.drehscheibe-online.de]

Im Prinzip lässt sich das bei jeder Domain einfach durch Eingabe der URL testen:
- Eingabe "https://" + Domain ergibt Fehler 404 -> Domain bzw. deren Provider unterstützt kein https
- Eingabe "http://" + Domain zeigt Seite mit http:// an und Eingabe "https://" + Domain zeigt Seite mit https:// an -> Domain bzw. deren Provider unterstützt https, es ist aber keine generelle Umleitung von http auf https eingerichtet
- Eingabe "http://" + Domain zeigt Seite mit https:// an-> Domain bzw. deren Provider unterstützt https und es ist eine generelle Umleitung von http auf https eingerichtet


Viele Grüße

Florian





1-mal bearbeitet. Zuletzt am 2021:03:20:15:34:05.

Hallo,

Sehr viel, aber nichts konkret Verständliches geschrieben. Mal aus meiner Sicht - was nutzt das neue Sicherheitszertifikat unter https gegenüber http, wenn dieses Sicherheitszertifikat durch Cookies und andere Hintergrundaktivitäten oder auch bestimmte Aktivitäten auf einer Internetseite gleich wieder unterwandert werden kann ? Das was hier im letzten Absatz geschrieben wurde konnte auch http schon, es musste nur in den Voreinstellungen des Browsers eingestellt werden, sprich die Sicherheitsstufen niedrig, mittel oder hoch.
Was die Sicherheit angeht, sollte hier mehr von den Usern darauf geachtet werden, die Vollkaskomentalität ist hier fehl am Platz ...

... hier sollten es sich unsere IT-Experten vielleicht einmal wieder etwas abgewöhnen, den Endanwender stets und ständig bevormunden zu wollen.

@ Walter, ich habe mir die Seite von Onkel_wom einmal im Samsung Internet auf meinem Android angesehen, es gab keine Probleme.

Hallo,

wie ich Dir schon via PM geschrieben hatte, ist zwischen der Transport-Sicherheit und Cookies zu trennen. Das sind zwei völlig verschiedene, nicht zusammenhängede Problemkreise. Bei https geht es einzig und allein darum, daß fremde Dritte, zum Beispiel Geheimdienste oder Internet-Dienstleister, einschließlich Deinem DSL-Provider, zwischen Dir und dem Server nicht mitlesen können. Das schließt nicht aus, daß der Dienst selber Cookies und Tracking mißbräuchlich verwendet. Das betrifft aber dann eben das "Innenverhältnis" zwischen Besucher (Du) und der Website bzw. dem Server-Betreiber bzw. den Firmen, mit denen der Server-Betreiber zusammenarbeitet und deren Links der Server-Betreiber in seine Webseite mit einbaut. Fremde Dritte sind bei dieser Angelegenheit nicht im Spiel. Wenn man damit ein Problem hat, dann darf man halt die Seite nicht besuchen oder muß sich mit technischen Maßnahmen schützen (z.B. Cookies ganz abschalten oder auf die Session beschränken, Ghostery + zig andere Plugins).

Klaus

Hallo,

Du kannst softwaretechnische Prozesse und das Internet nicht voneinander trennen, das geht nach hinten los. Erlebe ich gerade in meiner beruflichen Tätigkeit, das es nicht in Deinem Sinne funktioniert, schon auf Grund immer wieder auftretender softwaretechnischer Probleme. Alles Weitere hatte ich ja heute Nachmittag schon geschrieben.
Warum sollte der Endanwender Cookies abschalten, diese Unsitte mit den Cookies sollte ganz schnell, aber ganz schnell wieder abgeschafft werden.

Alles in Allem wurde in dieser Diskussion kein definitiver Grund für eine notwendige Umstellung von http auf https erbracht.



1-mal bearbeitet. Zuletzt am 2021:03:20:18:24:44.

In der Informatik, aber nicht nur dort, gibt es das Prinzip von "Divide & Conquer" – teile und herrsche. Es stammt aus dem Altertum. Wenn ein Problem zu groß ist, teile es in kleinere auf und veruche die einzeln zu lösen. Das Problem der Sicherheit von Computersystemen ist derart komplex, daß es sich nicht im Ganzen lösen läßt. HTTPS, bzw. der HTTP over SSL (oder dessen Nachfolger TLS), was es eigentlich ist, befaßt sich mit einem kleinen Teilproblem, nämlich der verschlüsselten Übertragung von Daten zwischen zwei Systemen und der Identifikation des Servers (optional des Clients) über ein Chain-of-Trust-Zertifikatssystem auf Basis des X.509-Standards. Zwar ist SSL/TLS im Rahmen von HTTP entstanden, ist aber tatsächlich technisch unabhängig davon und wird in Dutzenden anderen Protokollen im Internet verwendet. Von daher kann es Probleme, die durch HTTP, HTML und Javascript entstanden sind, nicht lösen. Und Cookies sind ein Bestandteil von HTTP.

Klaus



3-mal bearbeitet. Zuletzt am 2021:03:20:19:03:24.

Belassen wir es dabei, da auch keine Wissenschaft daraus gemacht werden muss. Die ganze Diskussion bekommt auch meinem Blutdruck nicht ...

gerdboehmer schrieb u.a. (Ergänzung in eckigen Klammern von mir):

[…] ich habe mir die Seite von Onkel_wom einmal im [Browser] „Samsung Internet“ auf meinem Android angesehen, es gab keine Probleme.

Hallo Gerd,

Dein Tipp, mir den Browser „Samsung Internet“ aus dem Google-Playstore herunterzuladen, damit ich es mir dann selbst anschauen kann, der ist für mich solange noch genau vom Wert Null, wie Du mir mein zweimaliges Nachfragen nach dem funktionierenden Link, den Du angeblich angeklickt haben willst, etweder nicht beantworten willst, oder nicht in der Lage bist, mir zu beantworten.

Falls denn nun einfach nur letzteres der Fall sein sollte, so will ich gerne helfen. Auf der Download-Seite lese ich dazu (sic; Fettmarkierung von mir):

• Neue Funktionen für Sie:

Verbesserte Smart Protect-Funktion: die Funktion ‚URL kopieren‘ wurde zur oberen URL-Leiste hinzugefügt
Sie können eine URL auf einfache Weise kopieren, indem Sie auf das Symbol ‚Kopieren‘ rechts in der URL-Leiste klicken.
Dem Nutzer wird eine Warnnachricht angezeigt, wenn das Ziel zwangsweise auf eine Seite weitergeleitet wird, die mutmaßlich schädlich ist.

[…]

Walter

Doch, das ist eben eine Wissenschaft. Aber mach doch, was Du willst. Nur bitte hinterher nicht jammern, wenn der Rechner durch ein Erpresser-Virus verschlüsselt, die Daten im Netz oder die Bankkonten leergeräumt sind.

Klaus

...aber Erfahrungswerte teilen mir mit, dass es bei hppts in der großen Unterscheidung zu http darum geht, dass ab dann nur noch ganz bestimmte Dritte mitlesen können.

schon garnet das Schlitzauge!

Flo1979 schrieb:

Google Chrome lädt seit Version 81 grundsätzlich keine Bilder mehr über http bzw. versucht diese Bilder über https zu laden. Wenn das nicht funktioniert, werden keine Bilder angezeigt. Dieses Verhalten kann man auch nicht ändern.

Ich nutze hier neben einem Waterfox Classic für bestimmte damit nicht laufende Webseiten Chrome Portable, derzeit Version 88.0.4324.182 (32 Bit). Damit funktioniert nach wie vor diese Methode: [www.drehscheibe-online.de]

Und das funktioniert immer noch - auch mit den Fotos von 0nkel_wom.

Chrome und Edge (auf Desktop) zeigen offensichtlich keine HTTPS-Seiten mehr an, die Bilder per HTTP einbinden. Firefox ist wohl der einzige, der dies (mit Warnhinweis) noch macht. Daher lassen viele Foren (z. B. [bimmelbahn-forum.de] ) die Einbindung von HTTP-Bildern nicht mehr zu und zeigen alte Beiträge mit HTTP-Bildern über einen Proxy an. Damit kann man alle aktuellen Browser verwenden. Aber ich fürchte, das kann die hier verwendete Forensoftware nicht. Hat DSO eigentlich kein Hilfe-Forum?

So langsam kommt einem dieses Thema zu den Ohren wieder heraus.
Mir ging es anfangs auch so, nachdem es diese Änderung gab.
Aber ich habe dann einfach den Tipp gelesen, den mir ein freundlicher Mitforist gab. Und befolgt. Funktioniert!
Von diesen Tipps findet man inzwischen sicher hunderte in diesem Forum, auch wieder in diesem Faden.

Vielleicht wäre es wirklich nützlich, wenn einer der Moderatoren am Anfang dieses Forums einmal eine Anleitung einstellen würde.
In der Hoffnung, dass dann auch jemand liest...

Gruß
Jörn.