Ab wann beginnt die Verschlüsselung bei HTTPS?

[Uli Boerner]

Ab wann beginnt denn genau die Verschlüsselung bei HTTPS?

wenn eine URL lautet:

https://www.zielserver.de/Passwort?Das geheime Passwort lautet 123

wird dann das geheime Passwort schon verschlüsselt oder geht das einmal unverschlüsselt durchs Netz?

[Rolf B]

Hallo Uli,

nach meinem Kenntnisstand finden hier folgende Schritte statt

1. DNS Abfrage an den Nameserver, um die Server-IP zu finden. Je nach DNS-Protokoll verschlüsselt oder nicht. Hier wird nur die Domain übertragen.

2. Anfrage des Browsers an den Server via IP, um den Schlüssel auszuhandeln. Klartext, aber hier werden Zertifikate und Public Key Verfahren genutzt und der eigentliche Transportschlüssel ist natürlich PK-Verschlüsselt

3. HTTP-Request wird über die verschlüsselte Verbindung gesendet. Die URL Parameter und die HTTP Header werden also nicht im Klartext gesendet.

Rolf

[Robert B.]

Moin,

Ab wann beginnt denn genau die Verschlüsselung bei HTTPS?

wenn eine URL lautet:

https://www.zielserver.de/Passwort?Das geheime Passwort lautet 123

wird dann das geheime Passwort schon verschlüsselt oder geht das einmal unverschlüsselt durchs Netz?

die Transport-Verschlüsselung hat @Rolf B ja schon erklärt, allerdings lässt die Formulierung „durchs Netz“ noch einen Punkt offen: Sofern die URL irgendwo gespeichert wird (Browser-History, Lesezeichen, Linkliste), kann dieser Speicher natürlich auch „durchs Netz“ gehen, indem sich der Speicher auf einem Remote-Server befindet.

Viele Grüße
Robert

[Raketenwilli]

wenn eine URL lautet:

https://www.zielserver.de/Passwort?Das geheime Passwort lautet 123

1.) Dann kann es Plugins geben, welche die URL an Dritte verpetzen (z.B. das frühere Alexa-Plugin)

2.) Dann wird dieser Abruf im Logfile des Servers im Klartext geloggt.

3.) Dann wird dieser Abruf womöglich im Zwangsproxy eines Benutzers sichtbar - jedenfalls dann wenn dieser die Requests und Antworten selbst entschlüsselt und verschlüsselt (und visa versa) was der Fall sein kann.

4.) ...

Tu das nicht, nie und nimmer.

[Hans]

Hallo Uli,

dem Satz "Tu das nicht, nie und nimmer." von Rakentwilli würde ich auch zustimmen ... allein schon, wenn die URL an Deinem Monitor so schön glänzt und alle erschrocken wegschauen müssen, die hinter Dir stehen .... und wie es dann weiter hinten aussieht, steht ja schon oben. Sensible Daten NIE (und natürlich auch nicht und nimmer) per GET versenden. Beim Post ist die Verschlüsselung auf jeden Fall drin und die Daten sind nicht ganz so leicht zu erspähen.

Liebe Grüße,

Hans

[Julius]

Hallo Raketenwilli,

um deinen Appell noch einmal zu verstärken, möchte ich darauf verweisen, wie man im OAuth-Kontext mit sensitiven Query-Parametern umgeht. Das Fass mache ich deshalb auf, weil es aufgrund der Relevanz (z. B. PSD2) viel Material mit Best-Practices (z. B. RFC 9700 mit Verweis auf den Referrer als weitere Problemquelle) und formalen Analysen gibt.

Solche Query-Parameter sind i.d.R. kurzlebig (im Fall eines authorization code wenige Minuten) und durch Erweiterungen des Standards auch nur durch die Partei einlösbar, die zusätzlich noch andere Informationen vorweisen kann, die nicht im URL-Parameter enthalten waren (siehe PKCE).

Aufgrund dieser Probleme gibt eine OAuth-Erweiterung namens Pushed Authorization Requests (RFC 9126), die die Problematik dadurch umgeht, dass die sensiblen Daten gar nicht erst in irgendwelchen Query-Parametern landen (siehe Introduction in RFC 9126).

Viele Grüße
Julius