Ist egal. Die erste verbindung zum server und die antwort darauf (mit der weiterleitung) ist unverschlusselt und manipulierbar. Ein Machine-in-the-middle Angreifer kann die Antwort abfangen und die Weiterleitung dropen. Du hast dann zum Angreifer ne unverschlüsselte Verbindung und der leitet das dann in ner verschlüsselten Verbindung zum Server weiter. Nennt sich SSL stripping.
Trotzdem ist es immens wichtig bereits mit HTTPS die Anfrage zu beginnen. Mal angenommen ich rufe die fiktive Seite http://feddit.org/login?username=einkorn&password=hunter2 auf. Da ich kein HTTPS verwendet habe, weiß jeder Server, über den meine Anfrage an feddit.org weitergeleitet wurde nun, dass mein Nutzername einkorn und mein Passwort hunter2 ist. Erst wenn die Anfrage beim Zielserver ist, sagt dieser dann “Ich nehme keine HTTP Anfragen an, versuchs mal mit HTTPS”. Wird von Anfang an HTTPS verwendet ist der erste Schritt immer eine sichere Verbindung herzustellen, bevor anderweitige Daten übertragen werden.
Sehr gute Erklärung. Würde der Vollständigkeit halber noch hinzufügen dass Seitenbetreiber davor zumindest ein Stück weit schützen können, indem sie HSTS + preload konfigurieren.
…wird der Hostname, also example.com, über DNS aufgelöst. Wenn die DNS-Anfrage nicht verschlüsselt ist, dann kann man den Hostnamen sehen. Der Rest ist aber teil des HTTP Protokolls. Und HTTP findet auf der Anwendungsschicht statt:
HTTPS ist ja HTTP+TLS. Und TLS findet auf der Transportschicht statt (deswegen auch “Transport Layer Security”). Also ist alles, was in den Schichten darüber passiert verschlüsselt, inklusive dem HTTP-Zeug.
Oder vielleicht noch anders ausgedrückt:
Das Konzept einer URL existiert erst in HTTP. (Und unabhängig davon auch in FTP und Co.) Die Schichten darunter interessieren sich nur für Hostnamen+Port.
Tatsächlich, nachdem ich den Kommentar verfasst habe, bin ich zurück zu meinem Post-Feed gewechselt und hab mich erstmal gefragt, welchen Technik-Post ich gerade kommentiert hatte. Hat dann 'ne Weile gedauert bis ich drauf gekommen bin. 😅
Mit HTTPS wüsste ein potentieller Mann-in-der-Mitte aber nur die IP-Adresse, mit der du kommunizierst, nicht den Gastgebername oder Pfad. Zumindest wenn auf dem Servierer noch andere Seiten liegen, ist das schon eine Stufe datensparsamer.
Hostname kann meist auch außerhalb gesehen werden, weil die DNS-Anfrage meist unverschlüsselt ist. Also das passiert halt noch bevor der HTTPS-Teil los geht und müsste unabhängig verschlüsselt werden.
DNS verschlüsseln ist seit ein paar Jahren möglich, aber hat auch Nachteile, daher wird es bisher nicht standardmäßig gemacht.
Also, ja, aber jede vernünftige Seite hat doch auch automatische redirects von nicht-SSL auf SSL?
Edit: Ich lernte dazu, vielen Dank :)
Ist egal. Die erste verbindung zum server und die antwort darauf (mit der weiterleitung) ist unverschlusselt und manipulierbar. Ein Machine-in-the-middle Angreifer kann die Antwort abfangen und die Weiterleitung dropen. Du hast dann zum Angreifer ne unverschlüsselte Verbindung und der leitet das dann in ner verschlüsselten Verbindung zum Server weiter. Nennt sich SSL stripping.
Betonung liegt auf “vernünftige”.
Trotzdem ist es immens wichtig bereits mit HTTPS die Anfrage zu beginnen. Mal angenommen ich rufe die fiktive Seite
http://feddit.org/login?username=einkorn&password=hunter2auf. Da ich kein HTTPS verwendet habe, weiß jeder Server, über den meine Anfrage an feddit.org weitergeleitet wurde nun, dass mein Nutzername einkorn und mein Passwort hunter2 ist. Erst wenn die Anfrage beim Zielserver ist, sagt dieser dann “Ich nehme keine HTTP Anfragen an, versuchs mal mit HTTPS”. Wird von Anfang an HTTPS verwendet ist der erste Schritt immer eine sichere Verbindung herzustellen, bevor anderweitige Daten übertragen werden.Sehr gute Erklärung. Würde der Vollständigkeit halber noch hinzufügen dass Seitenbetreiber davor zumindest ein Stück weit schützen können, indem sie HSTS + preload konfigurieren.
Ich sehe hunter2 und wähle hoch
Was ist so besonders an *******?
die Daten in der URL sind bei https auch nicht verschlüsselt also ist dein Beispiel nicht korrekt
Dachte das lange Zeit auch, aber doch, die Query-Parameter sind verschlüsselt.
Bei so einer URL:
https://example.com/hallo.html?name=welt
…wird der Hostname, also
example.com, über DNS aufgelöst. Wenn die DNS-Anfrage nicht verschlüsselt ist, dann kann man den Hostnamen sehen. Der Rest ist aber teil des HTTP Protokolls. Und HTTP findet auf der Anwendungsschicht statt:HTTPS ist ja HTTP+TLS. Und TLS findet auf der Transportschicht statt (deswegen auch “Transport Layer Security”). Also ist alles, was in den Schichten darüber passiert verschlüsselt, inklusive dem HTTP-Zeug.
Oder vielleicht noch anders ausgedrückt:
Das Konzept einer URL existiert erst in HTTP. (Und unabhängig davon auch in FTP und Co.) Die Schichten darunter interessieren sich nur für Hostnamen+Port.
Bei einem Artikel über Beziehungen lacht mir das OSI Modell entgegen? Sowas gibts nur auf feddit 👍
Tatsächlich, nachdem ich den Kommentar verfasst habe, bin ich zurück zu meinem Post-Feed gewechselt und hab mich erstmal gefragt, welchen Technik-Post ich gerade kommentiert hatte. Hat dann 'ne Weile gedauert bis ich drauf gekommen bin. 😅
Doch sind sie. Über die domain könnte man noch diskutieren. Wenn du es nicht glaubst wirf einen Blick ins Protokoll.
Mit HTTPS wüsste ein potentieller Mann-in-der-Mitte aber nur die IP-Adresse, mit der du kommunizierst, nicht den Gastgebername oder Pfad. Zumindest wenn auf dem Servierer noch andere Seiten liegen, ist das schon eine Stufe datensparsamer.
Hostname kann meist auch außerhalb gesehen werden, weil die DNS-Anfrage meist unverschlüsselt ist. Also das passiert halt noch bevor der HTTPS-Teil los geht und müsste unabhängig verschlüsselt werden.
DNS verschlüsseln ist seit ein paar Jahren möglich, aber hat auch Nachteile, daher wird es bisher nicht standardmäßig gemacht.