Re: http-Seiten

22 views
Skip to first unread message

Axel Berger

unread,
Aug 25, 2022, 6:52:35 AM8/25/22
to
"Christian @Soemtron" wrote:
> erschwert FF den Aufruf von http-Seiten

Ein verwandtes Problem ist das Verweigern von Downloads. Es gibt dabei
*keinen* Hinweis und *keine* Warnung. Erst wenn man in der "Library" auf
die Datei klickt kommt eine Meldung mit der Frage "wollen Sie etwa
wirklich?". Wer das übersieht oder vergißt, steht mit leeren Händen da.


--
/¯\ No | Dipl.-Ing. F. Axel Berger Tel: +49/ 221/ 7771 8067
\ / HTML | Roald-Amundsen-Straße 2a Fax: +49/ 221/ 7771 8069
 X in | D-50829 Köln-Ossendorf http://berger-odenthal.de
/ \ Mail | -- No unannounced, large, binary attachments, please! --

Arno Welzel

unread,
Aug 25, 2022, 6:58:16 AM8/25/22
to
Christian @Soemtron, 2022-08-25 12:28:

> Hi,
>
> seit einiger Zeit erschwert FF den Aufruf von http-Seiten und versucht
> erst $ewig, die Adresse per https aufzurufen.
> Das nervt, auch wenn es sicherlich gut gedacht ist. Kann man die
> Wartezeit evtl. sinnvoll beschränken, z.B. 1-2 Sekunden oder gibt es eine
> Möglichkeit, Ausnahmen zu hinterlegen?

Evtl. hilft das:

browser.fixup.fallback-to-https = false
dom.security.https_first = false
dom.security.https_first_pbm = false


--
Arno Welzel
https://arnowelzel.de

Ruediger Lahl

unread,
Aug 25, 2022, 7:41:07 AM8/25/22
to
*Christian @Soemtron* schrieb:

> seit einiger Zeit erschwert FF den Aufruf von http-Seiten und versucht
> erst $ewig, die Adresse per https aufzurufen.
> Das nervt, auch wenn es sicherlich gut gedacht ist. Kann man die
> Wartezeit evtl. sinnvoll beschränken, z.B. 1-2 Sekunden oder gibt es eine
> Möglichkeit, Ausnahmen zu hinterlegen?

about:preferences#privacy -> Security -> HTTPS-Only Mode
O Don't enable HTTPS-Only Mode
--
bis denne

Joerg Lorenz

unread,
Aug 25, 2022, 2:16:55 PM8/25/22
to
Am 25.08.22 um 12:28 schrieb Christian @Soemtron:
> Hi,
>
> seit einiger Zeit erschwert FF den Aufruf von http-Seiten und versucht
> erst $ewig, die Adresse per https aufzurufen.
> Das nervt, auch wenn es sicherlich gut gedacht ist. Kann man die
> Wartezeit evtl. sinnvoll beschränken, z.B. 1-2 Sekunden oder gibt es eine
> Möglichkeit, Ausnahmen zu hinterlegen?
>
> cu,
> Christian
>
> PGP Key available.

Oder ganz einfach im GUI unter Datenschutz & Sicherheit:

Nur-HTTPS-Modus
HTTPS bietet eine sichere, verschlüsselte Verbindung zwischen Firefox
und den von Ihnen besuchten Websites. Die meisten Websites unterstützen
HTTPS und wenn der Nur-HTTPS-Modus aktiviert ist, wird Firefox alle
Verbindungen zu HTTPS aufrüsten.Weitere Informationen

Nur-HTTPS-Modus in allen Fenstern aktivieren

Nur-HTTPS-Modus nur in privaten Fenstern aktivieren

Nur-HTTPS-Modus nicht aktivieren

Letzteres anklicken.


--
De gustibus non est disputandum


Axel Berger

unread,
Aug 25, 2022, 3:07:27 PM8/25/22
to
Joerg Lorenz wrote:
> Nur-HTTPS-Modus nicht aktivieren
> Letzteres anklicken.

Sicher? "Nur" würde ich als "nur" interpretieren. Der OP klagte aber
über eine unangenehm lange Verzögerung, kein komplettes Ablehnen.

Markus Ammann

unread,
Aug 25, 2022, 3:42:48 PM8/25/22
to
Axel Berger wrote:
> Joerg Lorenz wrote:
>> Nur-HTTPS-Modus nicht aktivieren
>> Letzteres anklicken.
>
> Sicher? "Nur" würde ich als "nur" interpretieren. Der OP klagte aber
> über eine unangenehm lange Verzögerung, kein komplettes Ablehnen.

Wie verhält sich Firefox auf den folgenden Websites?

<http://www.geektools.com/> <- keine https-Version vorhanden
Seamonkey geht ohne weiteres drauf - andere Brauser meinen dazu lediglich
"nicht sicher".

<https://tatort-fundus.de/> <- Zertifikat für https abgelaufen
Die Brauser benötigen zum Bestätigen der unsicheren Verbindung trotz https
zwei Extra-Klicks.

Gruss Markus

--
Dieser Beitrag entstand durch hirnloses Herumtippen auf der Tastatur.
Jeglicher Sinn und Zusammenhang darin waere rein zufaellig und nicht
beabsichtigt.
DVD-Sammlung: http://www.howalgonium.ch/dvdsammlung.html

Thomas Hochstein

unread,
Aug 25, 2022, 4:45:02 PM8/25/22
to
Markus Ammann schrieb:

> Wie verhält sich Firefox auf den folgenden Websites?
>
> <http://www.geektools.com/> <- keine https-Version vorhanden

Problemlos.

> <https://tatort-fundus.de/> <- Zertifikat für https abgelaufen
> Die Brauser benötigen zum Bestätigen der unsicheren Verbindung trotz https
> zwei Extra-Klicks.

Richtigerweise.

-thh

Axel Berger

unread,
Aug 25, 2022, 4:48:55 PM8/25/22
to
Markus Ammann wrote:
> Wie verhält sich Firefox auf den folgenden Websites?

Vanilla? Keine Ahnung.

Meiner öffnet den ersten problemlos und ohne jede Verzögerung und
schmeißt beim zweiten die von Dir genannten Warnungen mit Klick erst auf
"advanced" dann auf "proceed".

Beides so wie ich gern möchte.

Joerg Lorenz

unread,
Aug 25, 2022, 4:54:06 PM8/25/22
to
Am 25.08.22 um 21:42 schrieb Markus Ammann:
> Axel Berger wrote:
>> Joerg Lorenz wrote:
>>> Nur-HTTPS-Modus nicht aktivieren
>>> Letzteres anklicken.
>>
>> Sicher? "Nur" würde ich als "nur" interpretieren. Der OP klagte aber
>> über eine unangenehm lange Verzögerung, kein komplettes Ablehnen.
>
> Wie verhält sich Firefox auf den folgenden Websites?
>
> <http://www.geektools.com/> <- keine https-Version vorhanden
> Seamonkey geht ohne weiteres drauf - andere Brauser meinen dazu lediglich
> "nicht sicher".

Drei Sekunden rödeln dann kommt bei meiner Einstellung:


Nur-HTTPS-Modus-Warnung
Sichere Website nicht verfügbar

Sie haben den Nur-HTTPS-Modus für erhöhte Sicherheit aktiviert und es
ist keine HTTPS-Version von www.geektools.com verfügbar.

Weitere Informationen…
Was könnte die Ursache sein?

Höchstwahrscheinlich unterstützt die Website HTTPS einfach nicht.
Es ist auch möglich, dass ein Angreifer beteiligt ist. Falls Sie
sich dafür entscheiden, die Website aufzurufen, sollten Sie nicht
sensible Informationen wie Passwörter, E-Mail-Adressen oder
Kreditkartendaten in diese eingeben.

Wenn Sie fortfahren, wird der Nur-HTTPS-Modus für diese Website
vorübergehend deaktiviert.

> <https://tatort-fundus.de/> <- Zertifikat für https abgelaufen
> Die Brauser benötigen zum Bestätigen der unsicheren Verbindung trotz https
> zwei Extra-Klicks.

und bei dieser Site diese Meldung. Die sagt aber etwas wesentlich
"Gefährlicheres":

Warnung: Mögliches Sicherheitsrisiko erkannt

Firefox hat ein Problem erkannt und tatort-fundus.de nicht aufgerufen.
Entweder ist die Website falsch eingerichtet oder Datum und/oder Uhrzeit
auf diesem Computer sind nicht korrekt.

Das Zertifikat der Website ist wahrscheinlich abgelaufen, weshalb
Firefox keine verschlüsselte Verbindung aufbauen kann. Falls Sie die
Website besuchen, könnten Angreifer versuchen, Passwörter, E-Mails oder
Kreditkartendaten zu stehlen.

Was können Sie dagegen tun?

Am wahrscheinlichsten wird das Problem durch die Website verursacht und
Sie können nichts dagegen tun. Sie können den Website-Administrator über
das Problem benachrichtigen.

>
> Gruss Markus

Arno Welzel

unread,
Aug 26, 2022, 4:28:00 AM8/26/22
to
Joerg Lorenz, 2022-08-25 22:54:

> Am 25.08.22 um 21:42 schrieb Markus Ammann:
[...]
>> <http://www.geektools.com/> <- keine https-Version vorhanden
>> Seamonkey geht ohne weiteres drauf - andere Brauser meinen dazu lediglich
>> "nicht sicher".
>
> Drei Sekunden rödeln dann kommt bei meiner Einstellung:
>
>
> Nur-HTTPS-Modus-Warnung
> Sichere Website nicht verfügbar

Ja, weil "Nur-HTTPS-Modus" bedeutet, dass Firefox generell keine
HTTP-Verbindung aufbaut.

Wenn Websites HTTPS anbieten, sollten sie *selber* darauf umleiten und
es nicht vom Browser abhängig machen, ob er das selber findet oder nicht.

Joerg Lorenz

unread,
Aug 26, 2022, 5:59:59 AM8/26/22
to
Am 26.08.22 um 10:27 schrieb Arno Welzel:
> Joerg Lorenz, 2022-08-25 22:54:
>
>> Am 25.08.22 um 21:42 schrieb Markus Ammann:
> [...]
>>> <http://www.geektools.com/> <- keine https-Version vorhanden
>>> Seamonkey geht ohne weiteres drauf - andere Brauser meinen dazu lediglich
>>> "nicht sicher".
>>
>> Drei Sekunden rödeln dann kommt bei meiner Einstellung:
>>
>>
>> Nur-HTTPS-Modus-Warnung
>> Sichere Website nicht verfügbar
>
> Ja, weil "Nur-HTTPS-Modus" bedeutet, dass Firefox generell keine
> HTTP-Verbindung aufbaut.

Habe ich je etwas Anderes gesagt?

Arno Welzel

unread,
Aug 26, 2022, 10:52:24 AM8/26/22
to
Joerg Lorenz, 2022-08-26 11:59:
Nein, aber dass so ausführlich beschreibst, was passiert, wirkt so, als
ob Du Dich darüber gewundert hast, was da passiert.

Zu erwähnen, dass mit "Nur HTTPS"-Modus die Seite
http://www.geektools.com/ nicht mehr geht, weil
https://www.geektools.com/ nicht funktioniert, wäre zielführender gewesen.

Joerg Lorenz

unread,
Aug 26, 2022, 12:47:36 PM8/26/22
to
Am 26.08.22 um 16:52 schrieb Arno Welzel:
> Joerg Lorenz, 2022-08-26 11:59:
>> Habe ich je etwas Anderes gesagt?
>
> Nein, aber dass so ausführlich beschreibst, was passiert, wirkt so, als
> ob Du Dich darüber gewundert hast, was da passiert.
>
> Zu erwähnen, dass mit "Nur HTTPS"-Modus die Seite
> http://www.geektools.com/ nicht mehr geht, weil
> https://www.geektools.com/ nicht funktioniert, wäre zielführender gewesen.

None of your business.

Arno Welzel

unread,
Aug 27, 2022, 1:02:38 PM8/27/22
to
Joerg Lorenz, 2022-08-26 18:47:
Da Du öffentlich postest - doch, ist es. Wenn Du nur bestimmte Leute
ansprechen willst - E-Mail existiert.

Joerg Lorenz

unread,
Aug 27, 2022, 4:56:59 PM8/27/22
to
Am 27.08.22 um 19:02 schrieb Arno Welzel:
> Joerg Lorenz, 2022-08-26 18:47:
>
>> Am 26.08.22 um 16:52 schrieb Arno Welzel:
>>> Zu erwähnen, dass mit "Nur HTTPS"-Modus die Seite
>>> http://www.geektools.com/ nicht mehr geht, weil
>>> https://www.geektools.com/ nicht funktioniert, wäre zielführender gewesen.
>>
>> None of your business.
>
> Da Du öffentlich postest - doch, ist es. Wenn Du nur bestimmte Leute
> ansprechen willst - E-Mail existiert.

Wie so oft, verstehst Du nicht mal ansatzweise, worum es geht. EOD.

Detlef Meißner

unread,
Aug 27, 2022, 5:32:33 PM8/27/22
to
Das ist einer seiner leichtesten Übungen.

Detlef

Helmut Waitzmann

unread,
Aug 31, 2022, 3:24:38 PM8/31/22
to
Arno Welzel <use...@arnowelzel.de>:

> browser.fixup.fallback-to-https = false
> dom.security.https_first = false
> dom.security.https_first_pbm = false

Was bewirken diese Einstellungen jeweils, wenn sie auf true oder
false gestellt werden?

Arno Welzel

unread,
Aug 31, 2022, 5:00:18 PM8/31/22
to
Helmut Waitzmann, 2022-08-31 21:01:
Siehe auch:

<https://www.privacy-handbuch.de/handbuch_21l.htm>

Helmut Waitzmann

unread,
Sep 3, 2022, 12:02:11 PM9/3/22
to
Arno Welzel <use...@arnowelzel.de>:
Danke.  «dom.security.https_first» und
«dom.security.https_first_pbm» werden dort erklärt; zu
«browser.fixup.fallback-to-https» habe ich da nichts gefunden.

Arno Welzel

unread,
Sep 3, 2022, 12:37:14 PM9/3/22
to
Helmut Waitzmann, 2022-09-03 17:22:
<https://www.netzware.net/post/firefox-leitet-immer-auf-https-deaktivieren>

"Mit Einführung der Firefox Version 100 gibt es die Option
browser.fixup.fallback-to-https. Solange der Wert auf true steht, wird
immer versucht die angegebene Andresse auch über das https-Protokoll
aufzurufen."

Helmut Waitzmann

unread,
Sep 7, 2022, 4:10:19 PM9/7/22
to
Arno Welzel <use...@arnowelzel.de>:
> Helmut Waitzmann, 2022-09-03 17:22:

>> zu «browser.fixup.fallback-to-https» habe ich da nichts
>> gefunden.
>
> <https://www.netzware.net/post/firefox-leitet-immer-auf-https-deaktivieren>
>
> "Mit Einführung der Firefox Version 100 gibt es die Option
> browser.fixup.fallback-to-https. Solange der Wert auf true
> steht, wird immer versucht die angegebene Andresse auch über das
> https-Protokoll aufzurufen."

Danke.  Das steht da; nur seh' ich da mehr Fragen als Antworten:


Was bedeutet «auch über das HTTPS‐Protokoll aufrufen»?  Dann habe
ich im Fall, dass sowohl HTTP als auch HTTPS funktioniert haben,
zwei Dokumente?  Welches wird mir dann angezeigt?

Andere Konfigurationselemente aus der "browser.fixup."‐Hierarchie
bezeichnen immer etwas, was gemacht wird, wenn das ursprünglich
gewollte scheitert, weil irgendetwas nicht richtig war; und das
legt ja auch der Begriff «fixup» nahe.  Hier in diesem Fall muss
aber nichts scheitern, damit HTTPS versucht wird?  Oder ist
<https://www.netzware.net/post/firefox-leitet-immer-auf-https-deaktivieren>
ungenau in der Beschreibung?

Arno Welzel

unread,
Sep 9, 2022, 11:24:22 AM9/9/22
to
Helmut Waitzmann, 2022-09-07 22:10:

> Arno Welzel <use...@arnowelzel.de>:
>> Helmut Waitzmann, 2022-09-03 17:22:
>
>>> zu «browser.fixup.fallback-to-https» habe ich da nichts
>>> gefunden.
>>
>> <https://www.netzware.net/post/firefox-leitet-immer-auf-https-deaktivieren>
>>
>> "Mit Einführung der Firefox Version 100 gibt es die Option
>> browser.fixup.fallback-to-https. Solange der Wert auf true
>> steht, wird immer versucht die angegebene Andresse auch über das
>> https-Protokoll aufzurufen."
>
> Danke.  Das steht da; nur seh' ich da mehr Fragen als Antworten:
>
>
> Was bedeutet «auch über das HTTPS‐Protokoll aufrufen»?  Dann habe
> ich im Fall, dass sowohl HTTP als auch HTTPS funktioniert haben,
> zwei Dokumente?  Welches wird mir dann angezeigt?

Nein, dann wird versucht, HTTPS zu benutzen, falls HTTP nicht
funktioniert - auch dann, wenn man nicht explizit HTTPS angegeben hat.

Helmut Waitzmann

unread,
Sep 18, 2022, 12:21:23 PM9/18/22
to
Danke für die Präzisierung.  Das bedeutet dann, dass dieses
Einstellelement Christian @Soemtron nichts helfen wird:  Sein
Problem ist ja, dass das Aufrufen mittels HTTP von Dokumenten,
die nachweislich (nur) mittels HTTP erreichbar sind, länger
dauert, weil zuvor unnötigerweise (vergebens) versucht wird,
HTTPS zu verwenden.  Und es bedeutet auch, dass die Erklärung auf
<https://www.netzware.net/post/firefox-leitet-immer-auf-https-deaktivieren>
falsch ist.  Richtig?

Helmut Waitzmann

unread,
Sep 18, 2022, 12:21:24 PM9/18/22
to
Arno Welzel <use...@arnowelzel.de>:

> Wenn Websites HTTPS anbieten, sollten sie *selber* darauf
> umleiten und es nicht vom Browser abhängig machen, ob er das
> selber findet oder nicht.

Nein, das sollten sie nicht.  Sie sollten es dem Anwender
überlassen, ob er HTTPS möchte und deshalb effektiv auf Proxies
verzichten möchte oder ob ihm Abhör‐ und Fälschungssicherheit egal
ist und er lieber die Beschleunigung eines Proxies in Anspruch
nehmen möchte.

Weil die meisten Anwender sich darum keinen Kopf machen, ist es
gut, wenn Browser so voreingestellt[1] sind, dass sie zunächst
selber versuchen, statt mit vom Anwender aus
Unwissenheit/Bequemlichkeit gewünschten HTTP mit HTTPS
zuzugreifen.

[1] «Voreingestellt» bedeutet, dass der Anwender auf eigenen
Wunsch das Probieren mit HTTPS auch abstellen kann.

Provide mechanism, not policy.

Arno Welzel

unread,
Sep 19, 2022, 8:11:12 AM9/19/22
to
Helmut Waitzmann, 2022-09-18 16:02:
Ich weiß es nicht. Ich habe nur verschiedene Möglichkeiten erläutert,
wie man das vielleich lösen kann.

Arno Welzel

unread,
Sep 19, 2022, 8:15:34 AM9/19/22
to
Helmut Waitzmann, 2022-09-18 16:18:

> Arno Welzel <use...@arnowelzel.de>:
>
>> Wenn Websites HTTPS anbieten, sollten sie *selber* darauf
>> umleiten und es nicht vom Browser abhängig machen, ob er das
>> selber findet oder nicht.
>
> Nein, das sollten sie nicht.  Sie sollten es dem Anwender
> überlassen, ob er HTTPS möchte und deshalb effektiv auf Proxies
> verzichten möchte oder ob ihm Abhör‐ und Fälschungssicherheit egal
> ist und er lieber die Beschleunigung eines Proxies in Anspruch
> nehmen möchte.

Es geht aber nicht darum, was der *Anwender* will, sondern was der
Website-Betreiber rechtlich machen *muss*.

Nach DSGVO *müssen* bestimmte Angebote grundsätzlich *immer* HTTPS
zwingend nutzen - und wenn solche Angebote auch den Abruf per HTTP
erlauben, verstoßen Sie schlicht gegen geltendes Recht.

Oder anders ausgerückt: wenn HTTPS nicht erforderlich ist, sollte man es
auch gar nicht erst anbieten. Aber *wenn* man HTTPS anbietet, dann
*immer* und nicht nach den Maßgaben irgendwelcher persönlicher Vorlieben.

Eine Automatik im Sinne von "probiere es mal mit HTTPS, weil der
Anwender zu doof ist, das selber einzugeben und der Website-Betreiber zu
doof, eine Weiterleitung einzurichten" bringt in der Praxis exakt *nichts*.

Axel Berger

unread,
Sep 19, 2022, 9:26:56 AM9/19/22
to
Arno Welzel wrote:
> wenn HTTPS nicht erforderlich ist, sollte man es
> auch gar nicht erst anbieten.

Der Zug ist lange abgefahren, was auch hier in der Gruppe konsequent
bejubelt wird. Wäre es anders könnte ich vollkommen öffentliche
Informationen, auf die ich rein lesend zugreifen will, problemlos noch
unter Windows 98 erreichen. Das geht fast nirgends und aktuelle Broser
werten meine eigenen Seiten im Netz allein deshalb ab, weil sie als
http: angeboten werden.

Arno Welzel

unread,
Sep 19, 2022, 10:46:01 AM9/19/22
to
Axel Berger, 2022-09-19 15:28:

> Arno Welzel wrote:
>> wenn HTTPS nicht erforderlich ist, sollte man es
>> auch gar nicht erst anbieten.
>
> Der Zug ist lange abgefahren, was auch hier in der Gruppe konsequent
> bejubelt wird. Wäre es anders könnte ich vollkommen öffentliche
> Informationen, auf die ich rein lesend zugreifen will, problemlos noch
> unter Windows 98 erreichen. Das geht fast nirgends und aktuelle Broser
> werten meine eigenen Seiten im Netz allein deshalb ab, weil sie als
> http: angeboten werden.

Unter Windows 98 hast Du nicht nur mit HTTPS Probleme, weil es da nur
Uralt-Browser gibt, die kein TLS 1.2 beherrschen. Auch aktuelles HTML5
und CSS3 dürfte da kaum noch problemlos darstellbar sein, da Browser,
die sowas können, da ebenfalls nicht angeboten werden.

Ich sehe auch keinen Vorteil darin, 25 Jahre alte Software benutzen zu
können. Wenn das die Maxime sein soll, dass das möglich sein muss, darf
man generell nichts mehr weiterentwickeln.

Helmut Waitzmann

unread,
Sep 30, 2022, 6:48:53 PM9/30/22
to
Arno Welzel <use...@arnowelzel.de>:
> Helmut Waitzmann, 2022-09-18 16:18:
>
>> Arno Welzel <use...@arnowelzel.de>:
>>
>>> Wenn Websites HTTPS anbieten, sollten sie *selber* darauf
>>> umleiten und es nicht vom Browser abhängig machen, ob er das
>>> selber findet oder nicht.
>>
>> Nein, das sollten sie nicht.  Sie sollten es dem Anwender
>> überlassen, ob er HTTPS möchte und deshalb effektiv auf Proxies
>> verzichten möchte oder ob ihm Abhör‐ und Fälschungssicherheit egal
>> ist und er lieber die Beschleunigung eines Proxies in Anspruch
>> nehmen möchte.
>
> Es geht aber nicht darum, was der *Anwender* will, sondern was
> der Website-Betreiber rechtlich machen *muss*.

Gut.  Wenn der Website‐Betreiber rechtlich HTTPS machen muss,
darf er HTTP nicht anbieten, auch nicht mit einer automatischen
Umleitung auf HTTPS, denn in dem Moment, wo er HTTP anbietet,
ermöglicht er es einem Angreifer, das HTTP‐Angebot so zu
fälschen, dass die Umleitung auf HTTPS des Website‐Betreibers
unterbleibt und statt dessen eine Umleitung auf das
HTTP(S)‐Angebot des Angreifers geschieht.

> Nach DSGVO *müssen* bestimmte Angebote grundsätzlich *immer* HTTPS
> zwingend nutzen - und wenn solche Angebote auch den Abruf per HTTP
> erlauben, verstoßen Sie schlicht gegen geltendes Recht.

Eben.

> Oder anders ausgerückt: wenn HTTPS nicht erforderlich ist,
> sollte man es auch gar nicht erst anbieten.

Nein.  Das ist nicht derselbe Sachverhalt anders ausgedrückt, und
es folgt daraus auch nicht.

> Aber *wenn* man HTTPS anbietet, dann *immer* und nicht nach den
> Maßgaben irgendwelcher persönlicher Vorlieben.

Eben nicht:  Wenn HTTPS nicht erforderlich ist, darf der
Website‐Betreiber sowohl HTTP als auch HTTPS anbieten.

> Eine Automatik im Sinne von "probiere es mal mit HTTPS, weil der
> Anwender zu doof ist, das selber einzugeben und der
> Website-Betreiber zu doof, eine Weiterleitung einzurichten"
> bringt in der Praxis exakt *nichts*.

Ein (vom Anwender abschaltbarer) automatischer HTTPS‐Versuch im
Browser bei HTTP‐URLs bringt jedenfalls mehr als eine angreifbare
automatische Umleitung auf HTTPS, die der Website‐Betreiber bei
HTTP‐Anfragen durchführt:  Wenn der Browser des Anwenders
automatisch zunächst HTTPS probiert, obwohl der Anwender zu doof
ist, statt HTTP HTTPS selber zu wählen, hat der Angreifer keine
Möglichkeit, das zu unterbinden.

Arno Welzel

unread,
Oct 9, 2022, 7:04:45 AM10/9/22
to
Helmut Waitzmann, 2022-09-30 19:11:

> Arno Welzel <use...@arnowelzel.de>:
>> Helmut Waitzmann, 2022-09-18 16:18:
>>
>>> Arno Welzel <use...@arnowelzel.de>:
>>>
>>>> Wenn Websites HTTPS anbieten, sollten sie *selber* darauf
>>>> umleiten und es nicht vom Browser abhängig machen, ob er das
>>>> selber findet oder nicht.
>>>
>>> Nein, das sollten sie nicht.  Sie sollten es dem Anwender
>>> überlassen, ob er HTTPS möchte und deshalb effektiv auf Proxies
>>> verzichten möchte oder ob ihm Abhör‐ und Fälschungssicherheit egal
>>> ist und er lieber die Beschleunigung eines Proxies in Anspruch
>>> nehmen möchte.
>>
>> Es geht aber nicht darum, was der *Anwender* will, sondern was
>> der Website-Betreiber rechtlich machen *muss*.
>
> Gut.  Wenn der Website‐Betreiber rechtlich HTTPS machen muss,
> darf er HTTP nicht anbieten, auch nicht mit einer automatischen
> Umleitung auf HTTPS, denn in dem Moment, wo er HTTP anbietet,

Dafür hast Du sicher eine Quelle - also für die Behauptung, dass das
juristisch relevant wäre.

Helmut Waitzmann

unread,
Nov 2, 2022, 2:08:55 PM11/2/22
to
Arno Welzel <use...@arnowelzel.de>:
>> Gut.  Wenn der Website‐Betreiber rechtlich HTTPS machen muss,
>> darf er HTTP nicht anbieten, auch nicht mit einer automatischen
>> Umleitung auf HTTPS, denn in dem Moment, wo er HTTP anbietet,
>
> Dafür hast Du sicher eine Quelle - also für die Behauptung, dass
> das juristisch relevant wäre.

Du hattest geschrieben:  «Nach DSGVO *müssen* bestimmte Angebote
grundsätzlich *immer* HTTPS zwingend nutzen - und wenn solche
Angebote auch den Abruf per HTTP erlauben, verstoßen Sie schlicht
gegen geltendes Recht.»

Verfolgt die DSGVO nicht unter anderem das Ziel, die Daten, die
der Browser an den Website‐Betreiber übermittelt, vor unbefugtem
Mitlesen Dritter zu schützen?  Wie könnte der Website‐Betreiber
sonst sicherstellen, dass die Daten, die er vom Browser erhält,
nicht in falsche Hände gelangen?

Axel Berger

unread,
Nov 2, 2022, 3:19:24 PM11/2/22
to
Helmut Waitzmann wrote:
> die Daten, die der Browser an den Website†Betreiber übermittelt,

Klar, private Daten von Besuchern müssen geschützt werden. Da gibt es
gar keine Zweifel. Aber vollkommen öffentliche Daten? Sagen wir die
kostenfreie Startseite der Bildzeitung? Warum ist die so geheim, daß sie
eine Verschlüsselung neuesten Standards verlangt?

Meine eigenen Seiten sind alle http, auch das Kontaktformular. Aber das
muß niemand benutzen, es werden genug andere Kontaktangebote gemacht.

N.B: Auf Firmenseiten ohne Email, die nur ein Formular anbieten von mir
aber eine Mailadresse zwingend fordern, ist die Standardadresse
"geht...@garnix.an". Im Mailbody nenne ich dann den URL meines
Kontaktformulars.

Arno Welzel

unread,
Nov 5, 2022, 1:46:14 PM11/5/22
to
Helmut Waitzmann, 2022-11-02 18:53:

> Arno Welzel <use...@arnowelzel.de>:
>>> Gut.  Wenn der Website‐Betreiber rechtlich HTTPS machen muss,
>>> darf er HTTP nicht anbieten, auch nicht mit einer automatischen
>>> Umleitung auf HTTPS, denn in dem Moment, wo er HTTP anbietet,
>>
>> Dafür hast Du sicher eine Quelle - also für die Behauptung, dass
>> das juristisch relevant wäre.
>
> Du hattest geschrieben:  «Nach DSGVO *müssen* bestimmte Angebote
> grundsätzlich *immer* HTTPS zwingend nutzen - und wenn solche
> Angebote auch den Abruf per HTTP erlauben, verstoßen Sie schlicht
> gegen geltendes Recht.»

Ja - weil da z.B. eine Anmeldung mit Benutzernamen und Passwort erfolgt
und *das* dann nur über HTTPS zulässig ist.

Wie kommst Du darauf, dass dann eine Weiterleitung von HTTP zu HTTPS,
*vor* dem Laden des Anmeldeformulars unzulässig ist?

> Verfolgt die DSGVO nicht unter anderem das Ziel, die Daten, die
> der Browser an den Website‐Betreiber übermittelt, vor unbefugtem
> Mitlesen Dritter zu schützen?  Wie könnte der Website‐Betreiber
> sonst sicherstellen, dass die Daten, die er vom Browser erhält,
> nicht in falsche Hände gelangen?

Ein Website-Betreiber kann nicht verhindern, dass ein Browser eine
Anfrage per HTTP sendet. Er kann diese Anfrage nur ignorieren oder mit
einem Redirect auf HTTPS antworten.

Aber nochmal: welche juristische Relevanz hat es, wenn man
HTTP-Anfragen, die beim Server rein technisch eintreffen, nicht
ignroriert, sondern mit Redirect auf HTTPS beantwortet?

Arno Welzel

unread,
Nov 5, 2022, 1:49:38 PM11/5/22
to
Axel Berger, 2022-11-02 20:20:

> Helmut Waitzmann wrote:
>> die Daten, die der Browser an den Website†Betreiber übermittelt,
>
> Klar, private Daten von Besuchern müssen geschützt werden. Da gibt es
> gar keine Zweifel. Aber vollkommen öffentliche Daten? Sagen wir die
> kostenfreie Startseite der Bildzeitung? Warum ist die so geheim, daß sie
> eine Verschlüsselung neuesten Standards verlangt?

Wer behauptet das?

Nur weil ein Server https bevorzugt, bedeutet nicht, dass die Inhalte
geheim sind. Es ist aber oft einfacher, pauschal https zu nutzen und für
HTTP/2 erst recht.

> Meine eigenen Seiten sind alle http, auch das Kontaktformular. Aber das

Das wiederum könnte ein Problem sein, da Kontaktdaten bei der
Übermittlung nach dem Stand der Technik zu schützen sind.

> muß niemand benutzen, es werden genug andere Kontaktangebote gemacht.

Das ist irrelevant! Dein Kontaktformular wird von *Dir* angeboten und
Besucher müssen sich darauf verlassen können, dass diese Daten geschützt
werden - wie Du ja selber eingangs schon schreibt. Und zu diesen Daten
gehören auf deinem Formular (<http://berger-odenthal.de/Kontakt.php>)
neben Name auch E-Mail-Adresse, Telefonnummer und Adresse.

Helmut Waitzmann

unread,
Nov 20, 2022, 1:00:46 PM11/20/22
to
Arno Welzel <use...@arnowelzel.de>:
> Helmut Waitzmann, 2022-11-02 18:53:
>> Arno Welzel <use...@arnowelzel.de>:
>>>> Gut.  Wenn der Website‐Betreiber rechtlich HTTPS machen muss,
>>>> darf er HTTP nicht anbieten, auch nicht mit einer
>>>> automatischen Umleitung auf HTTPS, denn in dem Moment, wo er
>>>> HTTP anbietet,
>>>
>>> Dafür hast Du sicher eine Quelle - also für die Behauptung,
>>> dass das juristisch relevant wäre.
>>
>> Du hattest geschrieben:  «Nach DSGVO *müssen* bestimmte
>> Angebote grundsätzlich *immer* HTTPS zwingend nutzen - und
>> wenn solche Angebote auch den Abruf per HTTP erlauben,
>> verstoßen Sie schlicht gegen geltendes Recht.»
>
> Ja - weil da z.B. eine Anmeldung mit Benutzernamen und Passwort
> erfolgt und *das* dann nur über HTTPS zulässig ist.
>
> Wie kommst Du darauf, dass dann eine Weiterleitung von HTTP zu
> HTTPS, *vor* dem Laden des Anmeldeformulars unzulässig ist?

Ein Angreifer kann die vom Web‐Server angestoßene Weiterleitung
von HTTP zu HTTPS unterbinden und statt dessen eine Weiterleitung
zu seinem eigenen Server bewirken.

Wenn also eine Weiterleitung von HTTP zu HTTPS zulässig
ist, greift das Verbot, HTTP anzubieten, zu kurz und verfehlt
seinen Sinn.

>> Verfolgt die DSGVO nicht unter anderem das Ziel, die Daten,
>> die der Browser an den Website‐Betreiber übermittelt, vor
>> unbefugtem Mitlesen Dritter zu schützen?  Wie könnte der
>> Website‐Betreiber sonst sicherstellen, dass die Daten, die er
>> vom Browser erhält, nicht in falsche Hände gelangen?
>
> Ein Website-Betreiber kann nicht verhindern, dass ein Browser
> eine Anfrage per HTTP sendet. Er kann diese Anfrage nur
> ignorieren oder mit einem Redirect auf HTTPS antworten.
>
> Aber nochmal: welche juristische Relevanz hat es, wenn man
> HTTP-Anfragen, die beim Server rein technisch eintreffen, nicht
> ignroriert, sondern mit Redirect auf HTTPS beantwortet?

Die juristische Relevanz besteht darin, dass ein Gesetz, das in
gewissen Fällen eine Umlenkung auf HTTPS erlaubt, anstatt in
diesen Fällen HTTP‐Anfragen zu verbieten, ein schlechtes Gesetz
ist.  Im Einzelnen:

Es gibt für einen WWW‐Server drei Möglichkeiten, mit
HTTP‐Anfragen zu verfahren:  Sie anzunehmen, sie auf HTTPS
umzulenken oder sie gleich gar nicht anzubieten.  Alle drei sind
vom technischen Standpunkt her ohne die Mitarbeit des Anwenders
unsicher.

Sicherheit ist nur gegeben, wenn der Anwender von Anfang an eine
HTTPS‐Anfrage an den (richtigen) Web‐Server richtet und dabei die
Fähigkeiten seines Browsers, die dabei verwendete
Zertifikate‐Kette zu prüfen, nutzt.

Wenn das Gesetz trotzdem den ersten der drei Fälle verbietet, den
zweiten aber erlaubt, weil der Gesetzgeber hofft, auf diese Weise
die aus der fehlenden Mitarbeit des Anwenders (s. o.) folgende
Unsicherheit ausbügeln zu können, leistet das Gesetz nicht, was
es soll: den Web‐Server‐Betreiber dazu zu bringen, alles in
seiner Macht stehende zu tun, um sichere Datenübertragung zu
gewährleisten.

Der dritte Fall garantiert ebenfalls nicht zwangsläufig
Sicherheit, hat aber immerhin den Vorteil, dass der Anwender im
Fall, dass gerade kein Angreifer am Werk ist, vom Browser keine
Verbindung zum Web‐Server sondern nur eine Fehlermeldung bekommt,
die ihn, wenn sie häufig genug auftritt, lehrt, im URL stets
«https:» stehen zu haben.

Im Gegensatz zum zweiten Fall, bei dem aus Sicht des unbedarften,
unwissenden oder unvorsichtigen Anwenders HTTP anscheinend
funktioniert, lernt der Anwender beim dritten Fall den
Unterschied zwischen HTTPS und HTTP unmittelbar kennen:  Das eine
funktioniert, das andere funktioniert nicht.

Die einzige Stelle, die dem Anwender unter die Arme greifen kann,
ist der Web‐Browser, wenn man ihn so einstellt, dass er jede
HTTP‐Anfrage durch eine entsprechende HTTPS‐Anfrage ersetzt und
warnt, falls er keine sichere Verbindung hinbekommt.

Ein Gesetz, das eine vom Web‐Server angestoßene Umlenkung von
HTTP zu HTTPS erlaubt, trägt damit genau genommen zur Verdummung
der Anwender bei.