Post by Arno WelzelPost by Helmut WaitzmannPost by Arno WelzelPost by Helmut WaitzmannGut. 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.
Post by Arno WelzelPost by Helmut WaitzmannVerfolgt 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.