Umstellung auf https: Die http-Welt ist auf einmal verschlossen

[Linuchs]

Moin,

heute Nacht bin ich bei meinem problematischen one.com Vermieter ausgezogen. Er konnte meine PHP-Mails nicht versenden und verhindert, dass neue CSS-Dateien ausgeliefert werden. Wir haben das ausführlich diskutiert.

Der neue Vermieter ist cleverer, er hat zum Beispiel die bisherige Erreichbarkeit unter http: gelassen und zusätzlich https: eingerichtet, ohne Zwang.

Nun sehe ich, dass unter https: so einige Aufrufe für http: nicht funktionieren. Ich habe z.B. eine OSM-Landkarte eingebunden, sie erscheint nicht.

Verständnisfrage: Ist das die Diktatur des Firefox? Oder weigert sich http://OSM, Anfragen an https zu liefern?

Die Seite zu verlinken ist sinnlos, da ich die "Fehler" in den nächsten Stunden beheben werde.

Ich wundere mich nur, dass Abwärts-Kompatibilität offenbar ausgechlossen ist. So als ob ein USB3-Kabel USB2 nicht mehr überträgt.

Ist das wirklich so strikt?

Gruß, Linuchs

[dedlfix]

Tach!

Verständnisfrage: Ist das die Diktatur des Firefox? Oder weigert sich http://OSM, Anfragen an https zu liefern?

Alle Browser verhindern das. Und es ist ziemlich logisch. Wenn man eine Seite hat, die per HTTPS in einer gesicherten Übertragung zum Client gelangt, und dies auch so angezeigt wird, dann kann man da keine "unsicheren" Inhalte einfügen, weil das das Anliegen aushebelt. Das ist aber schon sehr lange bekannt.

Ich wundere mich nur, dass Abwärts-Kompatibilität offenbar ausgechlossen ist. So als ob ein USB3-Kabel USB2 nicht mehr überträgt.

Das hat nichts mit Kompatibilität zu tun. Auch ist HTTPS keine Verbesserung von HTTP. HTTPS ist dasselbe HTTP, nur über eine gesicherte Verbindung übertragen.

dedlfix.

[Der Martin]

Hallo,

Der neue Vermieter ist cleverer, er hat zum Beispiel die bisherige Erreichbarkeit unter http: gelassen und zusätzlich https: eingerichtet, ohne Zwang.

einen Zwang, https zu verwenden, würde ich auch ablehnen. Die Möglichkeit ist aber durchaus willkommen.

Nun sehe ich, dass unter https: so einige Aufrufe für http: nicht funktionieren. Ich habe z.B. eine OSM-Landkarte eingebunden, sie erscheint nicht.

Ja, das ist so gewollt (nicht von dir, aber von den Sicherheitspäpsten).

Verständnisfrage: Ist das die Diktatur des Firefox? Oder weigert sich http://OSM, Anfragen an https zu liefern?

Es ist eine Eigenheit aller Browser: Eine Seite, die per https übermittelt wurde, soll keine unsicheren (d.h. unverschlüsselten) Ressourcen enthalten bzw. nachladen.

Meines Wissens kann man diese Restriktion des Browsers in der individuellen Konfiguration lockern. Nur nützt dir das nichts: Dann könntest du selbst die "gemischten" Seiten zwar anzeigen, der Großteil deiner Besucher aber immer noch nicht.

Ich wundere mich nur, dass Abwärts-Kompatibilität offenbar ausgechlossen ist. So als ob ein USB3-Kabel USB2 nicht mehr überträgt.

Ist das wirklich so strikt?

Ja. Wenn die Verschlüsselung an einer Stelle aufgeweicht wird, könnte das übel ausgenutzt werden.

Ciao,
 Martin

[TS]

Hello,

Nun sehe ich, dass unter https: so einige Aufrufe für http: nicht funktionieren. Ich habe z.B. eine OSM-Landkarte eingebunden, sie erscheint nicht.

Verständnisfrage: Ist das die Diktatur des Firefox? Oder weigert sich http://OSM, Anfragen an https zu liefern?

Nee, das ist das allgemeine Konzept für TLS und darauf aufsetzend HTTP. Es sind zwei kombinierte Protokolle in zwei getrennten Schichten. Aus einem "sicheren" Hauptdokument heraus unsichere aufzurufen, ist zunächst einmal verboten.

Wie man das dann trotzdem wieder erlauben könnte, wirst Du bestimmt noch von Anderen erfahren. (Ich kann mit meinen Tab 4 ja noch nicht wieder vernünftig arbeiten :-( )

Mit HSTS (strictes https) kannst Du die meisten Browser im Hauptdokument auch anweisen, diese Erlaubnis in Subrequests (z. B. iFrames) überhaupt nicht zuzulassen.

Glück Auf
Tom vom Berg

[Mitleser]

Mit HSTS (strictes https) kannst Du die meisten Browser im Hauptdokument auch anweisen, diese Erlaubnis in Subrequests (z. B. iFrames) überhaupt nicht zuzulassen.

Nein.

[TS]

Hello,

Mit HSTS (strictes https) kannst Du die meisten Browser im Hauptdokument auch anweisen, diese Erlaubnis in Subrequests (z. B. iFrames) überhaupt nicht zuzulassen.

Nein.

Doch!

Ein HSTS-Header sorgt in einer per TLS + HTTP (also https:) aufgerufenen Seite dafür, dass keine in der Seite befindlichen Links ohne TLS, also nuf http: , aufgerufen werden dürfen. Auch nicht die Initiale URL.

Dafür, dass die das in dem von Dir verlinkten Dokument etwas verschwurbelt darstellen, kann ich nichts ;-)

Glück Auf
Tom vom Berg

[Mitleser]

Ein HSTS-Header sorgt in einer per TLS + HTTP (also https:) aufgerufenen Seite dafür, dass keine in der Seite befindlichen Links ohne TLS, also nuf http: , aufgerufen werden dürfen. Auch nicht die Initiale URL.

Nein. Das, was Du beschreibst, ist seit einiger Zeit das Standardverhalten gängiger Clients. HSTS bewirkt etwas anderes. Nämlich das, was im Link beschrieben wird.

[TS]

Hello,

Ein HSTS-Header sorgt in einer per TLS + HTTP (also https:) aufgerufenen Seite dafür, dass keine in der Seite befindlichen Links ohne TLS, also nuf http: , aufgerufen werden dürfen. Auch nicht die Initiale URL.

Nein. Das, was Du beschreibst, ist seit einiger Zeit das Standardverhalten gängiger Clients. HSTS bewirkt etwas anderes. Nämlich das, was im Link beschrieben wird.

So, und was wird da anderes beschrieben, als ich auf Deutsch beschrieben habe?

Das Ganze erinnert mich an eine Person, die steif und fest behauptet hat, man könne aus zwei vorhandenen IPv4 nicht das kleinste gemeinam mögliche Netz bestimmen, wenn es eines gibt. ;-p

Glück Auf
Tom vom Berg

[Mitleser]

So, und was wird da anderes beschrieben, als ich auf Deutsch beschrieben habe?

Im Grunde, was pl umgangssprachlich und knapp formuliert hat.

[TS]

Hello,

So, und was wird da anderes beschrieben, als ich auf Deutsch beschrieben habe?

Im Grunde, was pl umgangssprachlich und knapp formuliert hat.

Nee, denn HSTS ist ein Response-Header.
Wird der per http (also ohne TLS) gesendet, soll der Browser ihn sogar ignorieren.

Glück Auf
Tom vom Berg

[JürgenB]

Hallo Tom,

der Strict Transport Security-Header bewirkt im Browser, das die Seite nach dem ersten Aufruf nur noch per https aufgerufen werden kann. Nur beim ersten Mal oder nach Ablauf der in max-age festgelegten Zeit kann er auch unter http ausgeliefert werden.

Gruß
Jürgen

[TS]

Hello,

Hallo Tom,

der Strict Transport Security-Header bewirkt im Browser, das die Seite nach dem ersten Aufruf nur noch per https aufgerufen werden kann. Nur beim ersten Mal oder nach Ablauf der in max-age festgelegten Zeit kann er auch unter http ausgeliefert werden.

... und damit auch alle darin enthaltenen Links.

Wo merkt sich der Browser diese HSTS-Anforderung nebst Gültigkeitsdauer?

Was ist mit komplexen HTTPS-Proxies? Wie kann man die als Client erkennen?

Glück Auf
Tom vom Berg

[JürgenB]

Hallo Tom,

der Strict Transport Security-Header bewirkt im Browser, das die Seite nach dem ersten Aufruf nur noch per https aufgerufen werden kann. Nur beim ersten Mal oder nach Ablauf der in max-age festgelegten Zeit kann er auch unter http ausgeliefert werden.

... und damit auch alle darin enthaltenen Links.

der Strict Transport Security-Header macht nur bei Seiten Sinn, die per https ausgeliefert werden. Darin enthaltene Links sollten auch auf https basieren. Aber wenn aus so einer Seite auf http verlinkt wird, wird die verlinkte Seite eben auch so aufgerufen und es gelten mögliche 301-Weiterleitungen auf https oder eben HSTS.

Wo merkt sich der Browser diese HSTS-Anforderung nebst Gültigkeitsdauer?

Ich vermute, im Benutzerprofil.

Was ist mit komplexen HTTPS-Proxies? Wie kann man die als Client erkennen?

Wenn die einen HSTS-Header senden, wird beim nächsten mal die Seite per https Aufgerufen.

Ich habe Strict Transport Security so verstanden, das dem Browser mitgeteilt wird, die Seite in Zukunft nur noch per https aufzurufem, egal was der User ins Adressfeld tippt oder was im href von Links steht.

Gruß
Jürgen

[Mitleser]

Ich habe Strict Transport Security so verstanden, das dem Browser mitgeteilt wird, die Seite in Zukunft nur noch per https aufzurufem, egal was der User ins Adressfeld tippt oder was im href von Links steht.

So kann man es IMHO formulieren, auch wenn es analog RolfPlHotteHorsts Ausführungen nicht ganz sauber dargelegt ist, zusammenfassen.

Aber ja, das ist letztlich die Idee hinter der Nummer, auch wenn TS das anders sieht und irgendwie versucht, sein Geschwurbel noch als fachlich fundiert hinzubiegen.

Aber klar, MDN hat es verschwurbelt formuliert. LOL

Fun fact dabei ist, dass es der Google Chrome dann sogar als internen HTTP 307 im Netzwerkpanel protokolliert. Erscheint mir stimmig.

[Rolf B]

Hallo Linuchs,

als Ergänzung zu den Hinweisen von dedlfix und Martin: Wenn Du Ressourcen einbinden willst, die nur per HTTP zugänglich sind und Du auch nicht im Stande bist, den Ressourcenanbieter zu einer Umstellung auf HTTPS zu überreden, dann musst Du auf deinem Server einen Proxy dafür einrichten.

Das wird eher nicht funktionieren, wenn die Ressource eigenes Script mit eigenen Ajax Calls hat. Oder es macht viel Arbeit, weil Du jeden Ajax-Request dann über deinen Server laufen lassen und an den eigentlichen Ressourcenanbieter durchreichen musst. Aber für statische Ressourcen sollte es gehen.

Bei OSM würde ich aber annehmen, dass das auch über https erreichbar ist. Im Gegenteil sogar, wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Rolf

[Linuchs]

Hallo Rolf,

wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Interessant, also zensiert schon der Browser die Zugriffe http, obwohl die Antwort unter https sicher sein könnte?

Linuchs

[dedlfix]

Tach!

wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Interessant, also zensiert schon der Browser die Zugriffe http, obwohl die Antwort unter https sicher sein könnte?

Er weiß das ja nicht, ob er nach HTTPS umgeleitet werden wird oder nicht.

dedlfix.

[JürgenB]

Hallo,

wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Interessant, also zensiert schon der Browser die Zugriffe http, obwohl die Antwort unter https sicher sein könnte?

da zensiert niemand etwas. Der Server leitet einfach von http auf https um.

Gruß
Jürgen

[TS]

Hello,

Hallo,

wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Interessant, also zensiert schon der Browser die Zugriffe http, obwohl die Antwort unter https sicher sein könnte?

da zensiert niemand etwas. Der Server leitet einfach von http auf https um.

Könnten wir uns auf eine andere Formulierung einigen?

Der Server sendet dem Browser eine Umleitungsanforderung. Die Umleitung findet also nicht serverintern statt, sondern über einen Roundturn mif dem Client.

Glück Auf
Tom vom Berg

[JürgenB]

Hallo Tom,

stimmt. Ich habe folgendes in meiner .htaccess stehen:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Da wird dann ein Zugriff auf http://… mit einem Moved Permanent auf https weitergeleitet.

Gibt es eigentlich eine Möglichkeit, per .htaccess die Weiterleitung direkt im Server ablaufen zu lassen?

Gruß
Jürgen

[TS]

Hello,

Hallo Tom,

stimmt. Ich habe folgendes in meiner .htaccess stehen:

RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Da wird dann ein Zugriff auf http://… mit einem Moved Permanent auf https weitergeleitet.

Gibt es eigentlich eine Möglichkeit, per .htaccess die Weiterleitung direkt im Server ablaufen zu lassen?

Mhh, technisch machbar, aber:

Ja mit einem komplexen Proxy. Damit kann man per HTTP über diesen Proxy auf HTTPS-Seiten (i. d. R. fremde) zugreifen.

Was würde Dir das serverintern nützten, wenn die Client-Server-Verbindung ohne TLS läuft?

Glück Auf
Tom vom Berg

[Mitleser]

Gibt es eigentlich eine Möglichkeit, per .htaccess die Weiterleitung direkt im Server ablaufen zu lassen?

Nein.

[dedlfix]

Tach!

Gibt es eigentlich eine Möglichkeit, per .htaccess die Weiterleitung direkt im Server ablaufen zu lassen?

Nein, weil der Client den Request starten muss.

dedlfix.

[JürgenB]

Hallo,

Gibt es eigentlich eine Möglichkeit, per .htaccess die Weiterleitung direkt im Server ablaufen zu lassen?

Nein, weil der Client den Request starten muss.

Danke.

Gruß
Jürgen

[Linuchs]

Hallo Jürgen,

habe ich in meine .htaccess übernommen:

DirectoryIndex index.php index.htm index.html
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Wenn ich dem FF shanty-fsd.de eingebe, kommt http://shanty-fsd.de/

Was ist falsch?

Gruß, Linuchs

[JürgenB]

Hallo,

habe ich in meine .htaccess übernommen:

DirectoryIndex index.php index.htm index.html
RewriteEngine on
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}/$1 [R=301,L]

Wenn ich dem FF shanty-fsd.de eingebe, kommt http://shanty-fsd.de/

Was ist falsch?

ich habe vom Servergeschäft zu wenig Ahnung, da müssen andere ran. Ich kann nur sagen "Bei mir funktionierts.", aber das hilft dir nicht wirklich.

Gruß
Jürgen

[TS]

Hello,

Hallo Rolf,

wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

Interessant, also zensiert schon der Browser die Zugriffe http, obwohl die Antwort unter https sicher sein könnte?

Jein.

Der Browser erkennt aus dem Scheme https:, dass er zunächst eine sichere Verbindung über TLS bei der Gegenstelle anfordern lassen soll, um dann darauf das zustandslosose HTTP zu sprechen.

Deinem Gedanken folgend würde er zunächst eine unverschlüsselte Verbindung anfordern, darauf auch HTTP sprechen, aber nun von der Gegenstelle über diesen unsicheren Kanal eine Umleitungsanforderung (Location: https://~) zu erhalten. Erst damit würde er, wie oben beschrieben, von vorne anfangen.

Glück Auf
Tom vom Berg

[pl]

Wird ein HSTS'Header gesendet, holt sich der Browser spontan die HTTPS'Seite ohne daß da serverseitig eine Umleitung geschaltet ist.

MFG

[TS]

Hello,

Wird ein HSTS'Header gesendet, holt sich der Browser spontan die HTTPS'Seite ohne daß da serverseitig eine Umleitung geschaltet ist.

Nee, denn HSTS ist ein ResponseHeader.

Glück Auf
Tom vom Berg

[JürgenB]

Hallo Rolf,

Bei OSM würde ich aber annehmen, dass das auch über https erreichbar ist. Im Gegenteil sogar, wenn ich http://openstreetmap.de aufrufe, werde ich automatisch auf den https-Anschluss umgeleitet.

seit ca. 3 Jahren. Mitte 2017 habe ich in meinen Kartenskripten die letzten http-Aufrufe auf https umgestellt.

Gruß
Jürgen

[JürgenB]

Hallo,

Nun sehe ich, dass unter https: so einige Aufrufe für http: nicht funktionieren. Ich habe z.B. eine OSM-Landkarte eingebunden, sie erscheint nicht.

willkommen in der Gegenwart 😀.

Gruß
Jürgen

[Linuchs]

Jetzt muss ich doch zur problematischen Seite verlinken:

http://shanty-fsd.de | https://shanty-fsd.de

Mit dem Einfügen eines s ist es nicht getan:

L.tileLayer('https://{s}.tile.osm.org/{z}/{x}/{y}.png',
{attribution: '<a class="ls2" href="https://shanty-fsd.de">shanty-fsd.de</a> | Map data &copy; <a href="https://openstreetmap.org">OpenStreetMap</a> contributors, <a href="https://creativecommons.org/licenses/by-sa/2.0/">CC-BY-SA</a>'}
).addTo(mitglieder_map);

L.marker([ 51.451, 11.9486 ], {icon: kreis_gruen}).addTo(mitglieder_map);

Jetzt wird die Karte auch unter http://shanty-fsd.de nicht gezeigt.

[dedlfix]

Tach!

Jetzt wird die Karte auch unter http://shanty-fsd.de nicht gezeigt.

Liegt aber an einem Programmierfehler deinerseits. Das Javascript steigt mit einer Fehlermeldung aus. Hättest du auch selbst in der Konsole sehen können.

dedlfix.

[Linuchs]

Liegt aber an einem Programmierfehler deinerseits.

Oh ja, danke für den Hinweis.

[JürgenB]

Hallo,

beide Varianten liefern

Laden fehlgeschlagen für das <script> mit der Quelle "http://shanty-fsd.de/css/leaflet.js". shanty-fsd.de:187:1

bzw.

Laden fehlgeschlagen für das <script> mit der Quelle "https://shanty-fsd.de/css/leaflet.js". shanty-fsd.de:187:1

Gruß
Jürgen

[Linuchs]

Der Codierungs-Wahn treibt seltsame Blüten. Jetzt ist sogar die Buchstaben-Suppe verschlüsselt:

Habe ich bisher nicht drauf geachtet, aber nun bin ich sensibilisiert.

Linuchs