Sind HTTPS-URLs verschlüsselt?

Question

Werden alle URLs verschlüsselt, wenn die TLS/SSL-Verschlüsselung (HTTPS) verwendet wird?Ich würde es gerne wissen, weil ich möchte, dass bei der Verwendung von TLS/SSL (HTTPS) alle URL-Daten ausgeblendet werden.

Wenn Sie mit TLS/SSL eine vollständige URL-Verschlüsselung erhalten, muss ich mir keine Sorgen machen, vertrauliche Informationen vor URLs zu verbergen.

Answer 1

Ja, die SSL -Verbindung besteht zwischen der TCP -Schicht und der HTTP -Schicht. Der Client und der Server stellen zunächst eine sichere verschlüsselte TCP -Verbindung (über das SSL/TLS -Protokoll) her, und dann sendet der Client die HTTP -Anforderung (Get, post, löschen ...) über diese verschlüsselte TCP -Verbindung.

Answer 2

Da niemand eine Drahtaufnahme zur Verfügung gestellt hat, hier ist einer.
Servername (Der Domänenteil der URL) wird in der dargestellt ClientHello Paket, in einfacher Text.

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

Siehe diese Antwort Weitere Informationen zu TLS -Versionsfeldern (es gibt 3 davon - keine Versionen, Felder, die jeweils eine Versionsnummer enthalten!)

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

3.1. Servername -Anzeige

TLS] bietet einem Client keinen Mechanismus zur Verfügung, um einem Server den Namen des Servers mitzuteilen, den er kontaktiert. Für Clients kann es wünschenswert sein, diese Informationen bereitzustellen, um sichere Verbindungen zu Servern zu ermöglichen, die mehrere "virtuelle" Server in einer einzelnen zugrunde liegenden Netzwerkadresse aufweisen.

Um den Servernamen anzugeben, können Clients eine Erweiterung des Typs "server_name" in das (erweiterte) Client Hallo enthalten.

Zusamenfassend:

• FQDN (der Domänenteil der URL) KANN übertragen werden in klar im Inneren ClientHello Paket, wenn die SNI -Erweiterung verwendet wird

• Der Rest der URL (/path/?some=parameters&go=here) hat kein Geschäft im Inneren ClientHello Da die Anforderungs -URL ein HTTP -Ding ist (OSI -Schicht 7), wird sie daher niemals in einem TLS -Handshake angezeigt (Schicht 4 oder 5). Das wird später in einem kommen GET /path/?some=parameters&go=here HTTP/1.1 HTTP -Anfrage, NACH das sicher Der TLS -Kanal wird etabliert.

ZUSAMMENFASSUNG

Der Domänenname kann in klar übertragen werden (wenn die SNI -Erweiterung im TLS -Handshake verwendet wird), aber URL (Pfad und Parameter) wird immer verschlüsselt.

März 2019 Update

Vielen Dank carlin.scott um dieses zu erwarten.

Die Nutzlast in der SNI -Erweiterung kann jetzt durch verschlüsselt werden Dieser Entwurf des RFC -Vorschlags. Diese Fähigkeit besteht nur in TLS 1.3 (als Option und es ist bis zu beiden Enden, um es zu implementieren) und es gibt keine Rückwärtskompatibilität mit TLS 1.2 und darunter.

Cloudflare macht es und Sie können hier mehr über die Interna lesen -Wenn das Huhn vor das Ei kommen muss, wo setzen Sie das Huhn?

In der Praxis bedeutet dies, dass es jetzt verschlüsselt wird, anstatt den FQDN in einfachem Text zu übertragen (wie die Wireshark -Aufnahme).

HINWEIS: Dies befasst sich mehr mit dem Datenschutzaspekt als die Sicherheit, da eine umgekehrte DNS -Suche den beabsichtigten Zielhost ohnehin enthüllen kann.

Answer 3

Als die Sonstiges Antworten HTTPS "URLs" sind bereits darauf hingewiesen. Ihre DNS -Anfrage/-antwort bei der Auflösung des Domain -Namens ist jedoch wahrscheinlich nicht, und wenn Sie einen Browser verwenden, werden Ihre URLs natürlich auch aufgezeichnet.

Answer 4

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

Beachten Sie, dass bei Verwendung eines HTTP -Proxy die Adresse (Domäne) des Zielservers kennt, den angeforderten Pfad auf diesem Server jedoch nicht kennt (dh Anforderung und Antwort sind immer verschlüsselt).

Answer 5

Ich stimme den vorherigen Antworten zu:

Explizit sein:

Mit TLS den ersten Teil der URL (https://www.example.com/) ist immer noch sichtbar, wenn sie die Verbindung herstellt. Der zweite Teil (/honearemygetParameters/1/2/3/4) wird durch TLS geschützt.

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

Erstens, wie bereits von anderen erwähnt: - Leckage durch Browseradressenleiste - Leckage durch die Geschichte

Darüber hinaus haben Sie die URL -Leckage über den HTTP -Referator: Der Benutzer sieht Site A auf TLS und klickt dann auf einen Link zu Site B B. Wenn beide Websites auf TLS sind, enthält die Anforderung an Site B die vollständige URL von Site A in Der Refererparameter der Anfrage. Und Admin von Site B kann es von den Protokolldateien von Server B abrufen.)

Answer 6

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 Begriff, stecken Sie es nicht in die URL.

Answer 7

Ja und nein.

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

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

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

Hinweis für GET -Anfragen Der Benutzer kann die URL weiterhin aus der Standortleiste schneiden und einfügen, und Sie möchten wahrscheinlich nicht vertrauliche Informationen einsetzen, die von jedem gesehen werden können, der auf den Bildschirm schaut.

Answer 8

Ein Drittanbieter, der den Verkehr überwacht, kann möglicherweise auch die Seite ermitteln, indem Sie Ihren Datenverkehr untersuchen und ihn mit dem Datenverkehr vergleicht, den ein anderer Benutzer beim Besuch der Website hat. Wenn es beispielsweise 2 Seiten nur auf einer Site gab, eine viel größer als die andere, würde ein Vergleich der Größe der Datenübertragung erkennen, welche Seite Sie besucht haben. Es gibt Möglichkeiten, dass dies vor dem Drittanbieter verborgen sein könnte, aber kein normaler Server- oder Browserverhalten. Siehe zum Beispiel dieses Papier von Scirate, https://scirate.com/arxiv/1403.0297.

Im Allgemeinen sind andere Antworten korrekt, praktisch, obwohl dieses Papier zeigt, dass Seiten (dh URL) recht effektiv bestimmt werden können.

Answer 9

Verknüpfung mit meiner Antwort auf a doppelte Frage. Die URL ist nicht nur im Browserverlauf verfügbar, die Server -Seitenprotokolle, sondern wird auch als HTTP -Referator -Header gesendet.

Answer 10

Sie können sich auch nicht immer auf die Privatsphäre der vollständigen URL verlassen. Wie beispielsweise in Enterprise-Netzwerken, die gelieferten Geräte wie Ihr Firmen-PC beispielsweise mit einem zusätzlichen "vertrauenswürdigen" Root-Zertifikat konfiguriert sind, kann dies beispielsweise mit einem zusätzlichen "vertrauenswürdigen" Root-Zertifikat konfiguriert werden, sodass Ihr Browser still . Dies bedeutet, dass die vollständige URL zur Inspektion ausgesetzt ist. Dies wird normalerweise in einem Protokoll gespeichert.

Darüber hinaus sind Ihre Passwörter freigelegt und wahrscheinlich protokolliert, und dies ist ein weiterer Grund zu verwenden einmal Passwörter oder um Ihre Passwörter häufig zu ändern.

Schließlich wird auch der Anforderungs- und Antwortinhalt freigelegt, wenn nicht anders verschlüsselt.

Ein Beispiel für das Inspektionsaufbau wird von beschrieben Checkpoint hier. Auf diese Weise kann auch ein alter "Internetcafé" mit versorgten PCs eingerichtet werden.

Answer 11

Es ist jetzt 2019 und der TLS V1.3 wurde veröffentlicht. Laut CloudFlare kann der SNI dank TLS v1.3 verschlüsselt werden. Also habe ich mir großartig gesagt! Mal sehen, wie es in den TCP -Paketen von CloudFlare.com aussieht. Ich habe ein "Client Hello" Handshake -Paket aus einer Antwort des CloudFlare -Servers mit Google Chrome als Browser & Wireshark als Paket -Sniffer gefangen. Ich kann den Servernamen im Klaren -Hello -Paket immer noch im klaren Text lesen.

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

Es sieht also so aus, als ob die Verschlüsselung des SNI zusätzliche Implementierungen erfordert, um zusammen mit TLSV1.3 zu arbeiten

Der folgende Artikel beschreibt die Verschlüsselung der von CloudFlare als Teil von TLSV1.3 bereitgestellten SNI. Alle HTTPS -URLs von CloudFlare.com befinden sich jedoch im TCP -Paket unter TLS V1.3 in einem einfachen Text

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

Answer 12

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

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

Das einzige „Vielleicht“ wäre hier, wenn Client oder Server mit Schadsoftware infiziert sind, die die Daten sehen kann, bevor sie in https verpackt werden.Aber wenn jemand mit dieser Art von Software infiziert ist, hat er Zugriff auf die Daten, egal, was Sie für den Transport verwenden.

Answer 13

Wenn Sie eine erholsame API erstellen, werden die Probleme mit Browser -Leckagen und HTTP -Referenten außerdem meist gemildert, da der Kunde möglicherweise kein Browser ist und Sie möglicherweise keine Personen haben, die auf Links klicken.

Wenn dies der Fall ist, würde ich die OAuth2 -Anmeldung empfehlen, um einen Trägertoken zu erhalten. In diesem Fall wären die einzigen sensiblen Daten die anfänglichen Anmeldeinformationen ... die wahrscheinlich ohnehin in einer Postanfrage liegen sollten