Was verschlüsselt HTTPS genau?

[Sparta8]

Nehmen wir mal an ich surfe über den offenen Gäste WLAN in einem Restaurant. Die besuchte Webseite bietet eine HTTPS Verbindung.
Was bleibt dem WLAN Betreiber nun genau verborgen? Was kann er einsehen?

z.B.: GET https://www.eineseite.com/unterseite?filter=autos

Kann er einsehen dass ich eineseite.com ansurfe? Kann er sehen welche Unterseite oder Parameter ich abrufe?
Kann er einsehen, dass ich bei einem Nameserver abfrage wie die IP zu eineseite.com ist? Kann er die Antwort des Nameservers einsehen?
Den Inhalt der GET Antwort und sonstige Daten die ich z.B. im Body von POST Abfragen sende, kann er nicht einsehen. (?)

Danke!

 

[BFF]

Wenn DNS-Anfrage nicht verschluesselt ist welche Seite. Ja.
Der Inhalt. Nein.

 

[SpamBot]

Wenn er es drauf hat spielt er den Mittelmann und kann alles abgreifen.

 

[Helge01]

Eigentlich ist schon alles gesagt, wenn die DNS Abfrage verschlüsselt ist, sieht er immer noch die Ziel IP-Adresse. Er kann aber nicht sehen, welche Domain aufgerufen wurde.

 

[S.Kara]

Die Unterseite ist verschlüsselt.

 

[Hancock]

Wenn er es drauf hat spielt er den Mittelmann und kann alles abgreifen.

Dann muss er aber mit den Zertifikaten spielen. Falls er das ohne Eingriff auf dem Endgerät hinbekommt, bekommt er viel Geld, da er dann asymmetrische Krypto geknackt hat.

Falls der DNS-Eintrag auf deinem Gerät nicht gecached ist, und du DNS nicht über einen Drittserver machst, sieht er den DNS-Teil der URL. Falls die URL mehrere Zertifikate und Webseiten auf der selben IP hat (z.B. Webhosting), dann sieht er auch den DNS-Teil bei jeder Anfrage. Den Rest sieht er nicht.

 

[SpamBot]

@Hancock Es reicht doch wenn ich die 20 wichtigen Fake Seiten parat habe. Paypal, Yahoo, Gmail, GMX, Amazon... einfach auf die eigene Fake Seite umleiten. Okay, hier würde wohl ein Passwort Manager schon schützen aber im Offenen Wlan gibt es viele Wege.

Der ein oder Andere PW Manger schlägt ja mittlerweile bei Fake Seiten schon vor das richtige Passwort einzugeben

 

[benneq]

Dann muss er aber mit den Zertifikaten spielen. Falls er das ohne Eingriff auf dem Endgerät hinbekommt, bekommt er viel Geld, da er dann asymmetrische Krypto geknackt hat.

In öffentlichen WLANs sollte das eigentlich kein großes Problem sein. Da darf man ja oft schon auf irgend so eine Anmeldeseite, evtl. noch irgendwelche Anweisungen befolgen. 99% der Nutzer wird es nicht auffallen, wenn man dabei ein selbsterstelltes Zertifikat bestätigt.

 

[Dalek]

Welche Domains Du besuchst ist nicht verschlüsselt. Aber alle Inhalte die Du abrufst sind vollständig verschlüsselt (wenn die Seite keine mixed-content Warnungen anzeigt). Die vollständige URL und Parameter sind ebenfalls verschlüsselt.

Eigentlich ist schon alles gesagt, wenn die DNS Abfrage verschlüsselt ist, sieht er immer noch die Ziel IP-Adresse. Er kann aber nicht sehen, welche Domain aufgerufen wurde.

Wenn SNI aktiv ist, ist auch die Domäne unverschlüsselt sichtbar. Das muss sein damit mehrere Domains auf der gleichen IP funktionieren kann.

 

[Sephe]

@Hancock Es reicht doch wenn ich die 20 wichtigen Fake Seiten parat habe. Paypal, Yahoo, Gmail, GMX, Amazon... einfach auf die eigene Fake Seite umleiten.

Dann will ich sehen, wie du es schaffst eine Fake-Seite mit gültigem https zu basteln, OHNE das du an dem client PC ein Zertifikat installierst.

 

[SpamBot]

wenn man dabei ein selbsterstelltes Zertifikat bestätigt.

@Sephe Der Trick ist die Gewöhnung des Users... siehe hier:

Die meisten klicken Automatisiert auf JA. Auf der Arbeit darf ich täglich 10 mal irgendwelche Warnungen Ignorieren weil unsere IT etwas langsam ist.

 

[Dalek]

@Hancock Es reicht doch wenn ich die 20 wichtigen Fake Seiten parat habe. Paypal, Yahoo, Gmail, GMX, Amazon... einfach auf die eigene Fake Seite umleiten. Okay, hier würde wohl ein Passwort Manager schon schützen aber im Offenen Wlan gibt es viele Wege.

Der ein oder Andere PW Manger schlägt ja mittlerweile bei Fake Seiten schon vor das richtige Passwort einzugeben

Wie genau willst Du Zertifikate für Paypal und Amazon erstellen die nicht sofort im Browser alle Alarmglocken auslösen? Das doch genau der Sinn von SSL, so etwas unmöglich zu machen.

 

[SpamBot]

@Dalek Das ist genau das Problem, die meisten User klicken einfach weiter... Dazu gab es mal von CCC erschreckende Tests... Mir würde das wohl auch schnell passieren weil der Mensch ein Gewohnheitstier ist >>> Fehlermeldung >>> schneller klicken als man denken kann.

 

[Helge01]

@Dalek Das ist bei SNI natürlich korrekt. Das sieht man leider auch nicht so ohne weiteres, ob das bei einer Domain der Fall ist.

 

[eigs]

Kann er einsehen dass ich eineseite.com ansurfe?

Ja, wenn du seinen oder einen anderen unverschlüsselten DNS Server verwendest.

Kann er sehen welche Unterseite oder Parameter ich abrufe?

Den Host kann er sehen. Pfad, Querry und Fragment nicht.

Kann er einsehen, dass ich bei einem Nameserver abfrage wie die IP zu eineseite.com ist? Kann er die Antwort des Nameservers einsehen?

Ja, sofern du keinen verschlüsselten DNS Server verwendest. Deine Ziel IP Adresse kann er immer sehen.

Den Inhalt der GET Antwort und sonstige Daten die ich z.B. im Body von POST Abfragen sende, kann er nicht einsehen. (?)

Der Header ist bei https verschlüsselt.

Wenn er es drauf hat spielt er den Mittelmann und kann alles abgreifen.

Ein selbst signiertes Zertifikat erzeugt eine Zertifikatswarnung am Client. Man sollte natürlich keine Zertifikate installieren denen man nicht vertraut.
Es bleibt also nur ein https zu http downgrade Angriff. Funktioniert aber nicht bei Seiten die HSTS einsetzen sofern man die Gültigkeit seit letzten Aufruf nicht überschritten hat oder die Seite in einer preload list im Browser ist.

 

[Helge01]

Am sichersten wäre bei einem öffentlichen WLAN, wenn man eine OpenVPN Verbindung über TCP Port 443 zu sich nach Hause aufbaut und darüber surft (ohne Split tunneling, mit Kill-Switch). Da bekommt dann der Betreiber gar nichts mit. Vor allem betrifft das dann den kompletten Datenverkehr des jeweiligen Gerätes und nicht nur das Surfen.

 

[Kavakuo]

@Dalek Das ist bei SNI natürlich korrekt. Das sieht man leider auch nicht so ohne weiteres, ob das bei einer Domain der Fall ist.

SNI ist eine TLS Extension, die im ClientHello (vom Client) mitgeschickt wird. Somit kann das nicht für eine einzelne Domain aktiviert werden. Die Browser oder andere Clients senden die Extension einfach immer mit.

 

[Helge01]

Das meinte ich ja auch, dadurch kann man nicht festellen, ob die jeweilige Domain SNI nutzt. Man bekommt es nicht mit und es kann passieren, dass man trotz verschlüsselter DNS Abfrage die angesurfte Domain preisgibt. Man müsste jede HTTPS Seite mit SSL Labs prüfen, das wäre dann aber etwas umständlich.

 

[boxte30:Goas]

Weil es immer wieder zu solchen bösen Fehlern kommt, ist die Sicherheit eingeschränkt.
Damit ist MITM ohne Mithilfe des Benutzers möglich, und kann fast überhaupt nicht mehr erkannt werden.
Wenn etwas wirklich vertraulich bleiben soll, dann sind keine Computer zu verwenden.

 

[Matthias80]

Wenn er es drauf hat spielt er den Mittelmann und kann alles abgreifen.

Dann würde man aber im Browser gewarnt werden weil deinen Browser z. B. Das Zertifikat der Firewall fehlt. Also unbemerkt so einfach nicht...


Einfaches Beispiel für https.
Wenn du dich auf eine Seite einloggst...
Wird dein Passwort nicht in klartext übertragen.
Mit wireshark sind das wenige Klicks.

Mfg