Hallo Onkel_wom,

ich schaue mir immer wieder gerne Ihre Bilder an. Zuletzt die historischen Aufnahmen aus Kassel.

Ich habe es bei meinem eigenen Postings schon festgestellt und nun auch bei Ihrem:
In Microsoft Edge und in Google Chrome, werden Ihre Bilder bei DS onlne leider im Beitrag nicht angezeigt. Es erscheint anstelle der Bilder nur ein Platzhalter mit dem Link zum Bild.

Aus dem Link ist ersichtlich, dass Sie die Bilder von einem Server aus verlinken, der mit http und nicht mit https beginnt. Da ich dasselbe Problem bei mir hatte, habe ich mich an den Systemadministration von DS online gewandt, der mich auf die http/https-Problematik aufmerksam gemacht hat. Aufgrund der Sicherheitsrichtlinien der beiden Browser, wird die Anzeige von Verlinkungen von http-Servern blockiert. Ich habe auch keine Möglichkeit gefunden, diese Blockade in den Browsern abzuschalten.

Zurzeit kann man Ihre Bilder nur mit Firefox direkt im Beitrag sehen.

Für mich besteht die Lösung des Problems darin, dass ich meine Fotos, die ich in DS online zeigen möchte, nicht mehr vom Webspace meines DSL-Anbieters aus verlinke, da hier ist eine Umstellung von http auf https leider nicht möglich ist. Ich habe mir daher bei Flickr einen kostenlosen Account eingerichtet, der Platz für ca. 1000 Bilder bietet und von dem aus ich nun meine Fotos verlinke. Somit sind sie auch wieder bei Edge und Google Chrome direkt im Beitrag sichtbar.

Vielleicht ist das ja für Sie ein kleiner Hinweis, sich über die http/https-Problematik ein paar Gedanken zu machen. Ansonsten freue ich mich immer über ihre Beiträge und nutze dann auch in diesen Fällen Firefox, den sonst nicht mein Standard-Browser ist.

Herzliche Grüße aus Bremen
Dietmar Krebs

Hallo,

bei mir ist das in Firefox auch so, daß die Bilder blockiert werden. Mag allerdings an der Version liegen, oder es gibt noch irgendwo tief in den Einstellungen ein Häkchen, wo man das Verhalten einstellen kann. Ich hab's allerdings gerade auf die Schnelle nicht gefunden.

Klaus

Edit: Typo



1-mal bearbeitet. Zuletzt am 19.03.21 23:49.

Hallo Klaus,

Zitat:

bei mir ist das in Firefox auch so, daß die Bilder blockiert werde. Mag allerdings an der Version liegen, oder es gibt noch irgendwo tief in den Einstellungen ein Häkchen, wo man das Verhalten einstellen kann. Ich hab's allerdings gerade auf die Schnelle nicht gefunden.

Bei meinem Firefox (Version 86.0.1 (64-Bit)) auf Windows 10 geht es wie folgt:

Menü rechts oben anklicken (drei Striche) -> Einstellungen (Zahnrad in etwa der Mitte des Menus) -> Datenschutz & Sicherheit (Schloss-Symbol) -> ganz nach unten scrollen und "Nur-HTTPS-Modus nicht aktivieren" aktivieren


Viele Grüße

Florian

Hallo,

gibt es sowas auch bei Miccrosoft Edge und Google Chrome?

Gruß
Dietmar

Hallo

Dass die Bilder nicht sichtbar sind, habe ich in letzter Zeit öfter lesen müssen. Das ist sehr ärgerlich.
Ich sehe aber nicht ein, dass ich mir für teuer Geld ein "s" kaufe. Da hat jemand eine Gelddruckmaschine erfunden.

Bei Winzigweich-Etsch kann man das umgehen:

- Auf das Schloss neben der Internetadresse
- Websiteberechtigungen
- Unsicherer Inhalt
- Zulassen

Viele Grüße
Onkel Wom!

Hallo Dietmar,

gibt es sowas auch bei Miccrosoft Edge und Google Chrome?

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.

Browser von Microsoft nutze ich als ITler nicht und habe es daher auf meinen Rechnern nicht installiert, daher kann ich da leider nicht weiterhelfen.
Edit: Onkel_wom hat direkt über diesem Beitrag geschrieben, wie es in Edge funktionieren kann.

Viele Grüße

Florian





1-mal bearbeitet. Zuletzt am 19.03.21 13:31.

Super Danke,

das habe ich gesucht. Vielen Dank für die Hilfe.

Und entschuldigt bitte, dass das im so im Forum gelandet ist. Eigentlich wollte ich das als Privatnachricht versenden. Irgendwie habe ich da wohl vorher eine falsche Abzweigung genommen.

Viele Grüße
Dietmar

Hallo Dietmar,

Du hast alles richtig gemacht, haben sich doch dadurch Erkenntnisse ergeben, die für die gesamte Forengemeinschaft nützlich sind.

Gerade solche für die Gemeinschaft wichtigen technischen Sachen müssen nämlich m.M.n. eben nicht im stillen Kämmerlein behandelt werden.

Danke also natürlich auch @ „0nkel_wom“:

.

>Ich sehe aber nicht ein, dass ich mir für teuer Geld ein "s" kaufe.
Hallo Onkel WOM,

muss nicht unbedingt sein...
Bei meiner Domain bei 1&1 kann man in den Einstellungen ein kostenloses Zertifikat mit einem Klick aktivieren.
Ist halt unschön, dass das nicht automatisch gemacht wird. Vermutlich geht das inzwischen auch bei vielen anderen Anbietern.
Man muss nach der Aktivierung nur die Links auf https ändern.

Gruß Jürgen

Jürgen Utecht schrieb:Zitat:

>Ich sehe aber nicht ein, dass ich mir für teuer Geld ein "s" kaufe.
Hallo Onkel WOM,

muss nicht unbedingt sein...
Bei meiner Domain bei 1&1 kann man in den Einstellungen ein kostenloses Zertifikat mit einem Klick aktivieren.
Ist halt unschön, dass das nicht automatisch gemacht wird. Vermutlich geht das inzwischen auch bei vielen anderen Anbietern.
Man muss nach der Aktivierung nur die Links auf https ändern.

Ja, ich hoste meine Homepage auch bei 1&1 (IONOS) und die ssl-Aktivierung kostet dort keinen einzigen Cent. Wer einen Hoster hat, der heutzutage für ein ssl-Zertifikat extra Geld verlangt, sollte sich vielleicht einen Wechsel überlegen. Webspace ist mittlerweile so billig, da kann sich ein neuer Vertrag lohnen. Ist mit ssl-Zertifikat dann vielleicht sogar billiger wie der alte Vertrag ohne. Die meisten Hoster bieten einen Umzugsservice für die Domain an. Es ist davon auszugehen, dass früher oder später praktisch alle Browser voll auf den https-Standard wechseln und http-Verbindungen grundsätzlich nicht mehr zulassen.


Viele Grüße

Florian

0nkel_wom schrieb:

Hallo

Dass die Bilder nicht sichtbar sind, habe ich in letzter Zeit öfter lesen müssen. Das ist sehr ärgerlich.
Ich sehe aber nicht ein, dass ich mir für teuer Geld ein "s" kaufe. Da hat jemand eine Gelddruckmaschine erfunden.

Bei Winzigweich-Etsch kann man das umgehen:

- Auf das Schloss neben der Internetadresse
- Websiteberechtigungen
- Unsicherer Inhalt
- Zulassen

Viele Grüße
Onkel Wom!

Das funktioniert bei Chrome ganz genau so.
War hier auch schon mehrmals Thema - ich habe diese Nachhilfe auch gebraucht.

Gruß
Jörn.

Jürgen Utecht schrieb:

Bei meiner Domain … kann man in den Einstellungen ein kostenloses Zertifikat mit einem Klick aktivieren. […]
Vermutlich geht das inzwischen auch bei vielen anderen Anbietern.
Man muss nach der Aktivierung nur die Links auf https ändern.

Hallo Jürgen,

nach meiner Kenntnis ist das leider nicht bei allen Anbietern so, es gibt wohl tatsächlich welche, bei denen sich die monatlichen Kosten für den Webspace/ - die Homepage für solch ein Zertifikat danach erhöht haben sollen.

Aber wie ist denn Deine Aussage »Man muss nach der Aktivierung nur die Links auf https ändern« gemeint? (Ich meine natürlich nicht die Links zu Deinem Speicherplatz, die Du bereits vorher irgendwo anders hinterlassen hattest).

Dazu nämlich habe ich von anderen Usern die Information erhalten, dass neue Verlinkungen danach selbstverständlich auch den Vorsatz https erhalten.



Walter
__________
PS: bitte vermeide es, hier noch mit der Usenet-Zitatkennzeichnung „>“ herumzufuhrwerken; die kennen heute nicht mehr viele (erst recht nicht mehr, was deren Verdopplung „>>“ bedeutet).

Mindestens aber schreibe dann doch aber wenigstens den Zitatgeber hinzu!


Warum?

Weil Dritte User sonst unbewusst dazu verleitet werden können, Dir Worte in den Mund zu legen, die gar nicht von Dir stammen! ☹



1-mal bearbeitet. Zuletzt am 19.03.21 21:52.

Moin,

dieses "s" ist keine Gelddruckmaschine sondern dient der Sicherheit!
[www.globalsign.com]
Bitte erst informieren um dann diesen Unsinn nicht zu schreiben

Hallo,

ich habe seit Jahren den günstigsten Tarif P bei all-inkl.com (50GB Speicherplatz, 3 Domains) für knapp 5 EUR/Monat. Für ssl kommt ein Aufpreis von 1 EUR/Monat hinzu. Bei den weiteren teuren Tarifen wird kein Aufpreis verlangt.

Die Umstellung ging innerhalb weniger Minuten vonstatten. siehe hier: [www.drehscheibe-online.de]

Und in keinem meiner seit 2005 in DSO hinterlegten Links zu Bildern musste http in https geändert werden.

siehe dazu: [www.drehscheibe-online.de]

Hier habe ich nur noch die .htaccess hinzugfügt bzw. ergänzt.

hkl

Flo1979 schrieb:

Bei meinem Firefox (Version 86.0.1 (64-Bit)) auf Windows 10 geht es wie folgt:

Menü rechts oben anklicken (drei Striche) -> Einstellungen (Zahnrad in etwa der Mitte des Menus) -> Datenschutz & Sicherheit (Schloss-Symbol) -> ganz nach unten scrollen und "Nur-HTTPS-Modus nicht aktivieren" aktivieren


Viele Grüße

Florian

Hallo Florian,

bei mir ist das so eingestellt, aber es funktioniert dennoch nicht. Nachdem mir das richtige Stichwort eingefallen war, habe ich beim Suchen auch herausgefunden, wie man das tatsächlich abschalten kann. Das geht über about:config und dem Eintrag "security.mixed_content.block_active_content", den man auf "false" stellen muß. Ich habe mich aber entschieden, es so zu lassen, wie's ist, also auf "true". Funktioniert in dem 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). Ist für mich jetzt in diesem Fall nicht so wichtig, daß ich weiterforschen möchte.

Klaus

Hallo Onkel Wom,

wie ich zu einem Beitrag weiter oben schon gerade schrieb, ist das verwendete Zertifikat auf Deiner Seite auf den falschen Namen ausgestellt (*.your-server.de). Außerdem tauchen die Bilder unter https irgendwie nicht auf. Wie die Vorredner schon schrieben, gibt es heutzutage einfache Zertifikate zum Nulltarif von Let's Encrypt und wohl auch ein paar anderen, alles automatisierbar. Sollte ein Webseiten-Hoster in sein System integrieren können.

Klaus

Flo1979 schrieb:

Hallo Dietmar,

gibt es sowas auch bei Miccrosoft Edge und Google Chrome?

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.

Vivaldi verhält sich genauso, ist ja auch ein Abkömmling von Chrome. Versuchs mal so bei Chrome: Den Bildlink mit der rechten Maustaste anklicken, dann wählen, ob in neuem Tab, Fenster oder Hintergrundtab geöffnet werden soll. Darin kann man dann das Bild sehen. Zumindest geht es so bei Vivaldi. Ob es bei Chrome auch klappt, weiß ich nicht, ich habe kein Chrome. Der IE zeigt die Bilder auch an.

LaNgsambahNer schrieb:

Moin,

dieses "s" ist keine Gelddruckmaschine sondern dient der Sicherheit!
[www.globalsign.com]
Bitte erst informieren um dann diesen Unsinn nicht zu schreiben

Mal sehen wann auch das s unsicher ist, oder installieren verlinkte Bilder reihenweise einen Virus? Genauso einen Unfug wie viele Cookie-Banner, vielleicht muss man für jedes jpeg demnächst auch Cookies akzeptieren, weil die EU es so vorschreibt?

Hallo,

es wäre nicht das erste Mal, daß der Teil der Software im Browser, die sich um das Dekodieren der Bilddaten kümmert, fehlerhaft ist und einen Mißbrauch zuläßt. Ein anderes Problem ist, daß die URL des Bildes nicht unbedingt fest sein muß. Eine Webseite könnte die URLs auch dynamisch generieren und dort könnten private/geheime Daten enthalten sein, die dann durch Nutzung von http nicht mehr gesichert wären und mitgelesen werden könnten. Das ist nicht weit hergeholt. Zum Beispiel QR-Codes können server-seitig generiert werden und so im Browser dargestellt werden. Insofern ist diese Einschränkung nicht politisch, sondern wirklich sicherheitstechnisch begründet.

Klaus

Mahlzeit,

Da hast Du Recht, das sehe ich auch so. Gerade Cookies und Hintergrundaktivitäten der Software sind ein weit grösseres Sicherheitsrisiko als http.





2-mal bearbeitet. Zuletzt am 20.03.21 12:02.

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 20.03.21 13:24.

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 20.03.21 14:58.

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 20.03.21 15:34.

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 20.03.21 18:24.

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 20.03.21 19:03.

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.