it-swarm.com.de

Sind HTTPS-URLs verschlüsselt?

Sind alle URLs bei Verwendung der TLS/SSL-Verschlüsselung (HTTPS) verschlüsselt? Ich möchte wissen, dass bei Verwendung von TLS/SSL (HTTPS) alle URL-Daten ausgeblendet werden sollen.

Wenn Sie mit TLS/SSL eine vollständige URL-Verschlüsselung erhalten, muss ich mich nicht darum kümmern, vertrauliche Informationen vor URLs zu verbergen.

907

Ja, die SSL-Verbindung besteht zwischen der Ebene TCP und der HTTP-Ebene. Der Client und der Server stellen zuerst eine sichere verschlüsselte TCP Verbindung her (über das SSL/TLS-Protokoll) und dann sendet der Client die HTTP-Anforderung (GET, POST, DELETE ...) über diese verschlüsselte TCP Verbindung.

829
Marc Novakowski

Da niemand für eine Kabelerfassung gesorgt hat, hier eine.
Servername (der Domain-Teil der URL) wird im Paket ClientHello in Klartext ​​dargestellt.

Das Folgende zeigt eine Browseranfrage an:
https://i.stack.imgur.com/path/?some=parameters&go=here

ClientHello SNISiehe diese Antwort für weitere Informationen zu TLS-Versionsfeldern (es gibt 3 davon - keine Versionen, Felder, die jeweils eine Versionsnummer enthalten!)

Von https://www.ietf.org/rfc/rfc3546.txt :

3.1. Angabe des Servernamens

[TLS] stellt für einen Client keinen Mechanismus bereit, um einem Server den Namen des Servers mitzuteilen, mit dem er Kontakt aufnimmt. Es kann wünschenswert sein, dass Clients diese Informationen bereitstellen, um sichere Verbindungen zu Servern mit mehreren Hosts zu ermöglichen 'virtuelle' Server an einer einzigen zugrunde liegenden Netzwerkadresse.

m den Servernamen anzugeben, KÖNNEN Clients im (erweiterten) Client eine Erweiterung vom Typ "Servername" einfügen.


Zusamenfassend:

  • FQDN (der Domain-Teil der URL) KANN übertragen werden in clear innerhalb des Pakets ClientHello, wenn die SNI-Erweiterung verwendet wird

  • Der Rest der URL (/path/?some=parameters&go=here) hat nichts mit ClientHello zu tun, da die Anforderungs-URL eine HTTP-Sache ist (OSI-Schicht 7) und daher niemals in einem TLS-Handshake (Schicht 4 oder 5) angezeigt wird 5). Das wird später in einer GET /path/?some=parameters&go=here HTTP/1.1 HTTP-Anfrage kommen, NACH der sichere TLS-Kanal wird eingerichtet.


ZUSAMMENFASSUNG

Der Domainname kann in Klartext übertragen werden (wenn die SNI-Erweiterung im TLS-Handshake verwendet wird), die URL (Pfad und Parameter) wird jedoch immer verschlüsselt.


UPDATE MÄRZ 2019

Vielen Dank carlin.scott , dass Sie dieses Thema angesprochen haben.

Die Nutzdaten in der SNI-Erweiterung können jetzt über dieser Entwurf eines RFC-Vorschlags verschlüsselt werden. Diese Funktion ist nur in TLS 1.3 vorhanden (als Option und es liegt an beiden Enden, sie zu implementieren) und es besteht keine Abwärtskompatibilität mit TLS 1.2 und darunter.

CloudFlare macht das und Sie können hier mehr über die Einbauten lesen - Wenn das Huhn vor dem Ei kommen muss, wo legen Sie das Huhn ab?

In der Praxis bedeutet dies, dass der vollqualifizierte Domänenname nicht mehr im Klartext (wie in der Wireshark-Capture-Show) übertragen, sondern jetzt verschlüsselt wird.

HINWEIS: Hiermit wird der Datenschutzaspekt stärker als der Sicherheitsaspekt angesprochen, da ein Reverse-DNS-Lookup den beabsichtigten Ziel-Host möglicherweise trotzdem erkennen lässt.

507
evilSnobu

Wie die anderenAntworten bereits betont haben, sind https- "URLs" in der Tat verschlüsselt. Ihre DNS-Anfrage/Antwort beim Auflösen des Domainnamens lautet jedoch wahrscheinlich nicht. Wenn Sie einen Browser verwenden, werden möglicherweise auch Ihre URLs aufgezeichnet.

150
Zach Scrivena

Die gesamte Anfrage und Antwort wird verschlüsselt, einschließlich der URL.

Beachten Sie, dass bei Verwendung eines HTTP-Proxys die Adresse (Domäne) des Zielservers bekannt ist, der angeforderte Pfad auf diesem Server jedoch nicht bekannt ist (d. H. Anforderung und Antwort werden immer verschlüsselt).

96

Ich stimme den vorherigen Antworten zu:

Um es deutlich auszudrücken:

Bei TLS ist der erste Teil der URL ( https://www.example.com/ ) weiterhin sichtbar, während die Verbindung hergestellt wird. Der zweite Teil (/ herearemygetparameters/1/2/3/4) ist durch TLS geschützt.

Es gibt jedoch eine Reihe von Gründen, warum Sie keine Parameter in die GET-Anforderung einfügen sollten.

Erstens, wie bereits von anderen erwähnt: - Durchsickern der Adressleiste des Browsers - Durchsickern der Historie

Darüber hinaus tritt ein URL-Verlust durch den http-Verweis auf: Der Benutzer sieht Site A in TLS und klickt dann auf einen Link zu Site B. Wenn sich beide Sites in TLS befinden, enthält die Anforderung an Site B die vollständige URL von Site A in Der Referer-Parameter der Anfrage. Und der Administrator von Site B kann es aus den Protokolldateien von Server B abrufen.)

92
Tobias

Eine Ergänzung zur hilfreichen Antwort von Marc Novakowski: Die URL wird in den Protokollen auf dem Server gespeichert (z. B. in/etc/httpd/logs/ssl_access_log). Wenn Sie also nicht möchten, dass der Server die Informationen länger beibehält Begriff, setzen Sie es nicht in die URL.

46
Rhodri Cusack

Ja und nein.

Der Serveradressenabschnitt wird NICHT verschlüsselt, da er zum Einrichten der Verbindung verwendet wird.

Dies könnte sich in Zukunft mit verschlüsseltem SNI und DNS ändern, aber ab 2018 werden beide Technologien nicht mehr häufig verwendet.

Der Pfad, die Abfragezeichenfolge usw. werden verschlüsselt.

Hinweis: Bei GET-Anforderungen kann der Benutzer die URL weiterhin aus der Adressleiste ausschneiden und einfügen, und Sie möchten wahrscheinlich keine vertraulichen Informationen einfügen, die für jeden sichtbar sind, der auf den Bildschirm schaut.

26
SoapBox

Ein Drittanbieter, der den Datenverkehr überwacht, kann die besuchte Seite möglicherweise auch ermitteln, indem er Ihren Datenverkehr untersucht und mit dem Datenverkehr vergleicht, den ein anderer Benutzer beim Besuch der Website hat. Wenn zum Beispiel nur zwei Seiten auf einer Site vorhanden sind, von denen eine viel größer ist als die andere, zeigt ein Vergleich der Größe der Datenübertragung, welche Seite Sie besucht haben. Es gibt Möglichkeiten, dies vor dem Zugriff Dritter zu verbergen, aber es handelt sich nicht um normales Server- oder Browserverhalten. Siehe zum Beispiel dieses Papier von SciRate, https://scirate.com/arxiv/1403.0297 .

Im Allgemeinen sind andere Antworten richtig, obwohl dieses Papier zeigt, dass die besuchten Seiten (dh die URL) sehr effektiv bestimmt werden können.

8
pbhj

Sie können sich auch nicht immer auf den Datenschutz der vollständigen URL verlassen. Zum Beispiel, wie es manchmal in Unternehmensnetzwerken der Fall ist, werden gelieferte Geräte wie Ihr Unternehmens-PC mit einem zusätzlichen "vertrauenswürdigen" Stammzertifikat konfiguriert, damit Ihr Browser einer Überprüfung des https-Verkehrs durch einen Proxyserver (Man-in-the-Middle) im Hintergrund vertrauen kann . Dies bedeutet, dass die vollständige URL zur Überprüfung verfügbar gemacht wird. Dies wird normalerweise in einem Protokoll gespeichert.

Darüber hinaus werden auch Ihre Passwörter angezeigt und möglicherweise protokolliert. Dies ist ein weiterer Grund, Einmalpasswörter zu verwenden oder Ihre Passwörter häufig zu ändern.

Schließlich wird der Anforderungs- und Antwortinhalt auch angezeigt, wenn er nicht anderweitig verschlüsselt ist.

Ein Beispiel für den Inspektionsaufbau wird mit Checkpoint here beschrieben. Auf diese Weise kann auch ein "Internetcafé" alten Stils mit mitgelieferten PCs eingerichtet werden.

4
Don Gillis

Verknüpfung zu meiner Antwort auf eine doppelte Frage . Die URL ist nicht nur im Browserverlauf verfügbar, sondern wird auch serverseitig protokolliert. Sie wird auch als HTTP-Referer-Header gesendet. Wenn Sie Inhalte von Drittanbietern verwenden, wird die URL Quellen ausgesetzt, auf die Sie keinen Einfluss haben.

4
JoshBerke

Es ist jetzt 2019 und TLS v1.3 wurde veröffentlicht. Laut Cloudflare kann das SNI dank TLS v1.3 verschlüsselt werden. Also sagte ich mir großartig! Mal sehen, wie es in den TCP - Paketen von cloudflare.com aussieht. Also habe ich ein "Client-Hallo" -Handshake-Paket von einer Antwort des Cloudflare-Servers mit Google Chrome als Browser und Wireshark abgefangen als paketschnüffler. Ich kann den Servernamen im Client-Hallo-Paket immer noch im Klartext lesen.

enter image description here

Achten Sie also darauf, was Sie lesen können, da dies immer noch keine anonyme Verbindung ist, da ein Vermittler den Namen des Zielservers sehen kann.

Es sieht also so aus, als ob die Verschlüsselung des SNI zusätzliche Implementierungen erfordert, um mit TLSv1.3 zusammenzuarbeiten

Der folgende Artikel beschreibt die Verschlüsselung des von Cloudflare als Teil von TLSv1.3 bereitgestellten SNI. Alle HTTPs-URLs von cloudflare.com sind jedoch unter TLS v1.3 im Paket TCP im Klartext enthalten

[ https://blog.cloudflare.com/encrypted-sni/] [3]

3

Obwohl es hier bereits einige gute Antworten gibt, konzentrieren sich die meisten auf die Browsernavigation. Ich schreibe dies im Jahr 2018 und wahrscheinlich möchte jemand etwas über die Sicherheit mobiler Apps erfahren.

Für mobile Apps, wenn Sie beide Enden der Anwendung (Server und App) steuern, solange Sie HTTPS verwenden Sie sind sicher. iOS oder Android überprüfen das Zertifikat und verringern mögliche MiM-Angriffe (dies wäre die einzige Schwachstelle in all dem). Sie können vertrauliche Daten über HTTPS-Verbindungen senden, die verschlüsselt werden während des Transports. Nur Ihre App und der Server kennen alle Parameter, die über https gesendet werden.

Das einzige "Vielleicht" wäre hier, wenn Client oder Server mit bösartiger Software infiziert sind, die die Daten sehen kann, bevor sie in https eingebunden werden. Wenn jedoch jemand mit dieser Art von Software infiziert ist, hat er Zugriff auf die Daten, unabhängig davon, wie Sie sie transportieren.

1
Ricardo BRGWeb

Wenn Sie eine ReSTful-API erstellen, werden Probleme mit Browserverlusten und http-Verweisen meistens verringert, da der Client möglicherweise kein Browser ist und möglicherweise keine Benutzer auf Links klicken.

In diesem Fall würde ich empfehlen, sich bei oAuth2 anzumelden, um einen Inhaber-Token zu erhalten. In diesem Fall wären die einzigen sensiblen Daten die anfänglichen Anmeldeinformationen ... die sich wahrscheinlich sowieso in einer Post-Anfrage befinden sollten

0
Chris Rutledge