it-swarm-eu.dev

Versteckt SSL / TLS (https) die URLs, auf die zugegriffen wird?

Angenommen, ich tippe dies in meinem Browser ein

https://www.mysite.com/getsecret?username=alice&password=mysecret

und ein Angreifer beobachtet den gesamten Datenverkehr von mir zu meinem ISP.

Welche Informationen sind durch HTTPS geschützt? Wird die URL angezeigt? Werden die Parameter der Get-Anfrage angezeigt?

Bietet HTTPS auch Integrität für die URL?

Ich habe versucht, verschiedene HTTPS-Artikel und die TLS-Spezifikation zu lesen, konnte dies jedoch nicht herausfinden.

[EDIT:] Es ist in Ordnung, wenn nur der Serverdomänenname angezeigt wird. Kein Teil von ?username=alice&password=mysecret sollte enthüllt werden.

71
Jus12

Das Protokoll HTTPS entspricht der Verwendung von HTTP über eine SSL oder TLS Verbindung (über TCP).

Daher wird zuerst ein TCP-Verbindung (an Port 443) für den Server geöffnet. Dies reicht normalerweise aus, um den Hostnamen des Servers anzuzeigen (d. H. www.mysite.com in Ihrem Fall) an den Angreifer. Die IP-Adresse wird direkt beobachtet und:

  1. normalerweise haben Sie zuvor eine unverschlüsselte DNS-Abfrage durchgeführt.
  2. viele HTTPS-Server bedienen nur eine Domäne pro IP-Adresse.
  3. Das Serverzertifikat wird in einfacher Form gesendet und enthält den Servernamen (möglicherweise zwischen mehreren).
  4. in neueren TLS-Versionen gibt es die Angabe des Servernamens, mit der der Client dem Server angibt, welcher Hostname gewünscht wird, damit der Server das richtige Zertifikat vorlegen kann, wenn er mehrere hat. (Dies geschieht, um von 2 weggehen zu können.)

Dann findet ein TLS-Handshake statt. Dies beinhaltet die Aushandlung einer Verschlüsselungssuite und anschließend einen Schlüsselaustausch. Angenommen, mindestens einer Ihrer Browser und der Server haben die Verschlüsselung NONE nicht in die akzeptierten Suites aufgenommen, wird alles nach dem Schlüsselaustausch verschlüsselt.

Und vorausgesetzt, es gibt keinen erfolgreichen Man-in-the-Middle-Angriff (dh einen Angreifer, der die Verbindung abfängt und ein gefälschtes Serverzertifikat vorlegt, das Ihr Browser akzeptiert), ist der Schlüsselaustausch sicher und kein Lauscher kann alles entschlüsseln, was dann ist zwischen Ihnen und dem Server gesendet, und auch kein Angreifer kann einen Teil des Inhalts ändern, ohne dass dies bemerkt wird. Dies umfasst die URL und alle anderen Teile der HTTP-Anforderung sowie die Antwort vom Server.

Natürlich, als D.W. Erwähnungen: Die Länge sowohl der Anfrage (die nicht viel mehr variable Daten als die URL enthält, möglicherweise einige Cookies) als auch der Antwort kann dem verschlüsselten Datenstrom entnommen werden. Dies kann die Geheimhaltung untergraben, insbesondere wenn sich nur eine geringe Anzahl unterschiedlicher Ressourcen auf dem Server befindet. Auch alle nachfolgenden Ressourcenanforderungen.

Ihr Passwort in der URL (oder einem anderen Teil der Anfrage) sollte jedoch immer noch sicher sein - höchstens die Länge kann bekannt sein.

59
Paŭlo Ebermann

Wie Ihnen @ Paŭlo Ebermann und @ Jeff Ferland mitgeteilt haben, ist die GET-Anforderung unter SSL verschlüsselt und somit sicher. Allerdings, vergessen Sie nicht, dass viele Webserver GET-Anforderungen und -Parameter protokollieren und alle Anmeldeinformationen oder anderen vertraulichen Informationen, die Sie über GET senden, irgendwo in ein Protokoll geschrieben werden können. Aus diesem Grund sollten Sie beim Übermitteln vertraulicher Daten POST (das auch unter SSL verschlüsselt wird) verwenden.

Dies fällt in die Kategorie "Verschlüsselung ist keine magische Sicherheit, die alle Ihre Probleme löst."

26
gowenfawr

Sie sollten davon ausgehen, dass die URL nicht geschützt ist, d. H. Dass ein passiver Lauscher möglicherweise erfahren kann, welche URL Sie besuchen.

Mir ist klar, dass dies im Widerspruch zu den Behauptungen einiger anderer Leute steht, also sollte ich es besser erklären.

Es ist wahr, dass alles nach dem Domain-Namen verschlüsselt gesendet wird. Wenn die URL beispielsweise https://www.example.com/foo/bar.html Lautet, ist www.example.com Für den Angreifer sichtbar, während die HTTP-Anforderung (GET /foo/bar.html HTTP/1.0) Verschlüsselt ist. Dies verhindert, dass ein Lauscher den Pfadteil der URL direkt sieht. Allerdings kann die Länge des Pfadteils der URL für den Lauscher sichtbar sein. Darüber hinaus können für den Lauscher auch andere Informationen sichtbar sein, z. B. die Länge der von Ihnen besuchten Seite. Dies ist ein Fuß in der Tür für den Angreifer. Es gab einige Untersuchungen, bei denen anhand dieses Fußes in der Tür ermittelt wurde, welche URLs Sie besuchen , wenn der Angreifer Ihren https-Verkehr abhören kann.

Es gibt zwar keine Garantie dafür, dass diese Angriffe erfolgreich sind, aber ich schlage vor, dass es ratsam ist, das Schlimmste anzunehmen: anzunehmen, dass ein Lauscher möglicherweise erfahren kann, welche URLs Sie besuchen. Daher sollten Sie nicht annehmen, dass SSL/TLS vor einem Lauscher verbirgt, welche Seiten Sie besuchen.

Ja, https bietet Integrität für die von Ihnen besuchte URL.

P.S. Eine weitere Warnung: In der Praxis können sslstrip- und andere Man-in-the-Middle-Angriffe gegen viele oder die meisten Benutzer erfolgreich sein, wenn die Website keine [~ # ~] hsts [~ # verwendet. ~] . Diese Angriffe können sowohl die Vertraulichkeit als auch die Integrität der URL verletzen. Wenn Benutzer Websites besuchen, die HSTS nicht über ein unsicheres Netzwerk verwenden (z. B. offenes WLAN), sollten Sie daher vorsichtig sein, dass ein Angreifer möglicherweise erfahren kann, welche Seiten die Benutzer besuchen. Eine teilweise Minderung der sslstrip-Bedrohung besteht darin, dass Benutzer HTTPS Everywhere verwenden und Websites HSTS übernehmen.

25
D.W.

Die folgenden Dinge werden vor Beginn Ihrer Sitzung auslaufen:

  • IP-Adresse des Servers
  • Zertifikat des Servers
    • Dies schließt den auf dem Zertifikat veröffentlichten Domainnamen ein, der jedoch nicht garantiert, dass er mit dem von Ihnen verwendeten übereinstimmt.
  • Sie DNS-Abfragen

Keine Daten oder Anforderungen, die nicht mit dem Erstellen der SSL-Verbindung zusammenhängen (GET ...) werden an den Server gesendet, bevor die SSL-Sitzung beginnt. Die URL wird als Teil der Seitenanforderung gesendet und genauso geschützt wie der gesamte Datenverkehr, der Teil der Sitzung ist.

12
Jeff Ferland

Ja und nein.

Die URL ist ordnungsgemäß verschlüsselt, daher sollten Abfrageparameter niemals direkt angezeigt werden.

Bei der Verkehrsanalyse kann jedoch häufig die Länge der URL ermittelt werden. Die Kenntnis des Servers und der Länge der URL reicht häufig aus, um zu belauschen, auf welche Seiten zugegriffen wird, insbesondere wenn davon ausgegangen wird, dass auf Links auf einer Seite geklickt wird. Google für "Traffic Analysis SSL Browsing" oder ähnliches, wenn das Thema Sie interessiert.

In Ihrem Anwendungsfall ist dies von marginaler Bedeutung. Eine geschickte Verwendung der Verkehrsanalyse kann die Länge des Benutzernamens und/oder die Länge des Kennworts anzeigen, je nachdem, ob die anderen abgerufenen URLs auch den Benutzernamen enthalten. Wenn Sie den Benutzernamen/das Passwort auf eine konstante Länge auffüllen, können Sie diese Angriffe vermeiden, aber es lohnt sich möglicherweise nicht.

11
Nakedible

TLS-Stapel beginnen mit der Übertragung der Servernamenanzeige (SNI, http://en.wikipedia.org/wiki/Server_Name_Indication ; http://www.ietf.org/rfc/rfc3546) .txt ). Dies wird im Klartext gesendet, was bedeutet, dass Lauscher den Servernamen sehen können, den Sie in die Adressleiste eingeben.

9
Steve Dispensa