Verschlüsselt https die gesamte URL?

Question

Ich googelte viel und viele Antworten sind Ja. Zum Beispiel: Is GET data also encrypted in HTTPS? Aber der leitende Sicherheitsingenieur in unserer Firma sagte mir, dass die URL nicht verschlüsselt wäre.

Bild, dass, wenn die URL verschlüsselt wurde, wie findet der DNS-Server den Host und verbinden?

Ich denke, das ist sehr stark, obwohl es gegen die meisten Antworten ist. Also bin ich wirklich verwirrt und meine Fragen sind:

1. Verschlüsselt HTTPS alles in der Anfrage? (einschließlich der URL, Host, Pfad, Parameter, Header)
2. Wenn ja, wie der DNS-Server die Anfrage entschlüsseln und an den Host-Server senden?

Ich versuchte https://www.amazon.com/gp/css/homepage.html/ref=ya_surl_youracct und mein IE schickte zwei Anfragen an den Server zuzugreifen:

Erstens:

CONNECT www.amazon.com:443 HTTP/1.0 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: www.amazon.com 
Content-Length: 0 
DNT: 1 
Connection: Keep-Alive 
Pragma: no-cache 

Zweitens:

GET /gp/css/homepage.html/ref=ya_surl_youracct HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: en-US,zh-CN;q=0.5 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: www.amazon.com 
DNT: 1 
Connection: Keep-Alive 

Es ist mein Browser zweimal angefordert hat, scheint : das erste Mal ist es, die Verbindung mit Host (ohne Verschlüsselung) herzustellen und das zweite Mal eine verschlüsselte Anfrage über https zu senden? Habe ich recht? Wenn ich das richtig verstehe, wenn ein Client die RESTFUL API über HTTPS aufruft, sendet er die Anfragen (Verbindung und Get/Post) jedes Mal zweimal.

Answer 1

Die URL IS ist verschlüsselt, sobald sie den Browser verlässt, bis sie den Zielserver erreicht.

Was passiert ist, dass der Browser den Domain-Namen und den Port aus der URL extrahiert und verwendet, um DNS selbst aufzulösen. Dann startet es einen verschlüsselten Kanal zum Zielserver IP: Port. Dann sendet es eine HTTP-Anfrage über diesen verschlüsselten Kanal.

Der wichtige Teil ist jeder außer Ihnen und der Zielserver kann nur sehen, dass Sie eine Verbindung zu einer bestimmten IP-Adresse und einem Port herstellen. Sie können nichts anderes angeben (wie bestimmte URLs, GET-Parameter usw.).

Angreifer können die Domäne in den meisten Fällen nicht einmal sehen (obwohl sie es ableiten können, wenn es tatsächlich eine DNS-Suche gibt - wenn sie nicht zwischengespeichert wurde).

Die große Sache zu verstehen ist, dass DNS (Domain Name Service) ist ein völlig anderer Dienst mit einem anderen Protokoll von HTTP. Der Browser macht DNS-Suchanfragen, um einen Domänennamen in eine IP-Adresse umzuwandeln. Dann verwendet es diese IP-Adresse, um eine HTTP-Anfrage zu stellen.

Aber zu keiner Zeit erhält der DNS-Server eine HTTP-Anfrage, und zu keinem Zeitpunkt macht er etwas anderes als ein Domain-Name - IP-Mapping für Benutzer bereitzustellen.

Answer 2

Die URL (auch als "Uniform Resource Locator" bekannt) enthält vier Teile:

1. Protokoll (zB https)
2. Hostname (zB stackoverflow.com)
3. -Port (nicht immer inbegriffen , in der Regel 80 für hTTP und 443 für https)
4. Pfad und Dateiname oder Abfrage

einige Beispiele:

ftp://www.ftp.org/docs/test.txt 
mailto:user@test101.com 
news:soc.culture.Singapore 
telnet://www.test101.com/ 

Die URL als ganze Einheit ist nicht wirklich verschlüsselt, da sie nicht vollständig übergeben wird. Die URL wird tatsächlich in Bits auseinander gezogen und jedes Teil wird auf verschiedene Arten verwendet. Z.B. Der Protokollteil teilt Ihrem Browser mit, wie er den Rest der URL verwenden soll, der Hostname sagt ihm, wie er die IP-Adresse des beabsichtigten Empfängers nachschlagen soll, und der Port teilt ihm mit, welcher Port verwendet werden soll. Der einzige Teil der URL, der in der Nutzlast selbst übergeben wird, ist der Pfad und die Abfrage, und dieser Teil ist verschlüsselt.

Wenn Sie einen Blick auf eine HTTP-Anforderung in der rohen nehmen, sieht es so etwas wie dieses:

GET /docs/index.html HTTP/1.1 
Host: www.test101.com 
Accept: image/gif, image/jpeg, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 
(blank line) 
--Body goes here-- 

Was Sie im Beispiel siehe oben geführt wird. Beachten Sie, dass die vollständige URL nirgendwo angezeigt wird. Der Host-Header kann tatsächlich vollständig weggelassen werden (er wird nicht zum Routing verwendet).Der einzige Teil der URL, der hier angezeigt wird, befindet sich rechts neben dem GET-Verb und enthält nur den rechten Teil der ursprünglichen URL. Das Protokoll und die Portnummer erscheinen nirgendwo in der Nachricht selbst.

Kurze Antwort: Alles rechts neben der Portnummer in der URL ist in den Nutzdaten der https-Anfrage enthalten und wird tatsächlich verschlüsselt.

Answer 3

Während die anderen Antworten soweit korrekt sind, gibt es viele andere Überlegungen als nur die Verschlüsselung zwischen dem Browser und dem Server. Hier sind einige Dinge, über die Sie nachdenken sollten ...

• Die IP-Adresse des Servers ist aufgelöst.
• Der Browser stellt mithilfe von TLS eine TCP-Socket-Verbindung zur IP-Adresse des Servers her. Dies ist die CONNECT, die Sie in Ihrem Beispiel sehen.
• Die Anforderung wird über die verschlüsselte Sitzung an den Server gesendet.

Wenn dies alles war, ist es erledigt. Kein Problem.

Aber warten Sie, es gibt mehr!

die Felder in einem GET anstelle eines POST Having zeigt sensible Daten, wenn ...

• Jemand in den Protokollen Server sucht. Dies kann ein snoopy Mitarbeiter sein, aber es kann auch die NSA oder eine andere dreibuchstabige Regierungsbehörde sein, oder die Logs können öffentliche Aufzeichnungen werden, wenn sie in einer Testversion vorgeladen werden.
• Ein Angreifer führt dazu, dass die Website-Verschlüsselung auf Klartext oder eine defekte Chiffre zurückfällt. Werfen Sie einen Blick auf the SSL checker von Qualsys Labs, um zu sehen, ob eine Website dafür anfällig ist.
• Jeder Link auf der Seite zu einer externen Site zeigt den URI der Seite als Referrer an. Benutzer-ID und Passwörter werden auf diese Weise ungewollt an Werbenetzwerke vergeben. Manchmal sehe ich diese in meinem eigenen Blog.
• Die URL ist im Browserverlauf verfügbar und daher für Skripts verfügbar. Wenn der Computer öffentlich ist (jemand überprüft Ihre Website vom Gast-PC in der Hotel- oder Flughafenlounge), gibt die AnfrageDaten an andere Personen aus, die dieses Gerät verwenden.

Wie ich schon erwähnte, finde ich manchmal IDs, Passwörter und andere sensible Informationen in den Referrer-Logs meiner Blogs. In meinem Fall kontaktiere ich den Besitzer der verweisenden Website und erzähle ihnen, dass sie ihre Benutzer Hacking ausgesetzt sind. Eine weniger skrupulöse Person würde Kommentare oder Aktualisierungen der Website mit Links zu ihrer eigenen Website hinzufügen, um die sensiblen Daten in ihren Referrer-Logs zu sammeln.

Der leitende Sicherheitsingenieur Ihres Unternehmens ist also der Ansicht, dass die URL an vielen Stellen, an denen dies extrem wichtig ist, nicht verschlüsselt ist. Sie und die anderen Befragten sind auch richtig, dass es ist verschlüsselt in dem sehr engen Anwendungsfall des Browsers im Gespräch mit dem Server im Kontext einer TLS-Sitzung. Vielleicht hat die von Ihnen erwähnte Verwirrung mit dem Unterschied im Umfang dieser beiden Anwendungsfälle zu tun.

Bitte beachten Sie auch:

• Testing for Exposed Session Variables (OTG-SESS-004)
• Session Management - How to protect yourself (Beachten Sie, dass "immer verwenden POST" wird immer und immer auf dieser Seite.)
• Client account hijacking through abusing session fixation on the provider