Werden GET-Daten auch in HTTPS verschlüsselt?

127

Wenn du bekommst

https://encrypted.google.com/search?q=%s

Die %sAbfrage ist verschlüsselt? Oder nur die Antwort? Wenn dies nicht der Fall ist, warum sollte Google seine öffentlichen Inhalte auch verschlüsseln?

https http-get

— Jader Dias
quelle

145

Die gesamte Anforderung wird verschlüsselt, einschließlich der URL und sogar des Befehls ( GET). Das einzige, was eine intervenierende Partei wie ein Proxyserver ermitteln kann, ist die Zieladresse und der Port.

Beachten Sie jedoch, dass das Client-Hello-Paket eines TLS-Handshakes den vollständig qualifizierten Domänennamen über die SNI- Erweiterung im Klartext ankündigen kann (danke @hafichuk) ankündigen kann, die von allen modernen Mainstream-Browsern verwendet wird, einige jedoch nur unter neueren Betriebssystemen.

EDIT: (Da ich gerade ein "Good Answer" -Abzeichen bekommen habe, sollte ich wohl die gesamte Frage beantworten ...)

Die gesamte Antwort wird ebenfalls verschlüsselt. Proxies können keinen Teil davon abfangen.

Google liefert Suchanfragen und andere Inhalte über https, da nicht alle öffentlich sind. Möglicherweise möchten Sie auch einige öffentliche Inhalte vor einem MITM verbergen . In jedem Fall ist es am besten, Google selbst antworten zu lassen .

— Marcelo Cantos
quelle

2

Ich bin ein wenig unglücklich über die Behauptung, dass die URL verschlüsselt ist. Wird der Hostname nicht als Teil der URL betrachtet? Wenn ja, ist die Aussage falsch. Es gibt keine Möglichkeit, den Hostnamen / die IP-Adresse vor dem ISP / Proxyserver auszublenden, so wie Sie die Zieladresse beim Senden physischer E-Mails nicht ausblenden können.

— Abhishek Anand

1

@Abhishek: Der Hostname ist im TCP / IP-Header nicht vorhanden. Ich gehe in meiner Antwort auf IP-Adressen ein.

— Marcelo Cantos

Die Domain ist nicht verschlüsselt. Dies dient zur Unterstützung von namenbasierten virtuellen Hosts (im Vergleich zu IP-basierten). @MarceloCantos ist völlig korrekt, dass der Rest der URL (dh der GETBefehl) verschlüsselt ist. Dies ist in RFC 4366

— Hafichuk

@ Hafichuk: Danke dafür. Ich wusste nicht, dass TLS für den FQDN werben kann. Das letzte Mal, als ich versuchte, einen https-Multiserver einzurichten (ich gebe zu, vor einigen Jahren), schien es über eine einzelne IP unmöglich.

— Marcelo Cantos

Wirklich wichtige Ergänzung zum TLS mit dem Domainnamen: Vergessen Sie nicht die Klartext-DNS-Anfrage, die auch den Domainnamen enthält. Möglicherweise kann jemand, der Ihren verschlüsselten HTTPS-Verkehr sehen kann, auch Ihre DNS-Anforderungen überwachen.

— Tim G

63

Die URL selbst ist verschlüsselt, sodass die Parameter in der Abfragezeichenfolge nicht einfach über die Leitung übertragen werden.

Beachten Sie jedoch, dass URLs, einschließlich der GET-Daten, häufig vom Webserver protokolliert werden, während dies bei POST-Daten selten der Fall ist. Wenn Sie also vorhaben, so etwas zu tun /login/?username=john&password=doe, dann tun Sie es nicht. Verwenden Sie stattdessen einen POST.

— Thomas
quelle

2

+1 danke. Dies befindet sich auf meinem eigenen physischen Server, daher mache ich mir keine Sorgen um Protokolle, aber das ist eine gute Überlegung für alle, die dies in einer gemeinsam genutzten Hosting-Umgebung in Betracht ziehen. Es ist auch wichtig zu berücksichtigen, da ich Kreditkartennummern auf diese Weise übertragen werde und sie definitiv nicht protokollieren möchte :)

— orokusaki

3

Es ist nicht wirklich wichtig, dass es Ihre eigene Box ist. Sie möchten auch nicht, dass jemand anderes, dem es gehört (dh böse Hacker), diese Passwörter im Klartext sieht. Oder diese CC-Nummern (vorausgesetzt, Sie speichern diese nicht auch anderswo).

— Thomas

1

Sie sollten diese in den POST-Text einfügen, nicht in die URL-Abfragezeichenfolge.

— Thomas

1

Befürchten Sie, dass der wbeserver weniger Einschränkungen beim Zugriff auf seine Protokolle hat als beim Zugriff auf die Daten der Website (DB, Datei usw.)? IMHO, solange die Daten sicher auf den Webserver zugreifen, ist alles in Ordnung. Die einzigen Personen, die Zugriff auf den Webserver haben, sollten als zuverlässig angesehen werden, denn wenn dies nicht der Fall ist, können Sie sie auf keine Weise daran hindern, die Daten auf die eine oder andere Weise zu lesen.

— Serge Profafilecebook

1

Wenn Passwörter über GET gesendet und im Zugriffsprotokoll protokolliert werden, werden sie NICHT gehasht. Ich glaube, das ist das größte Problem. Das Hashing von Passwörtern in der Datenbank spielt keine Rolle, wenn Sie sie nur im Zugriffsprotokoll des Webservers nachschlagen können. Sie sollten in der Datenbank gehasht werden. Wenn dies nicht der Fall ist, beheben Sie dies bitte.

— Steen Schütt

21

HTTPS Stellt eine zugrunde liegende SSL-Verbindung her, bevor HTTP-Daten übertragen werden. Dadurch wird sichergestellt, dass alle URL-Daten (mit Ausnahme des Hostnamens, der zum Herstellen der Verbindung verwendet wird) ausschließlich innerhalb dieser verschlüsselten Verbindung übertragen werden und wie alle HTTPS-Daten vor Man-in-the-Middle-Angriffen geschützt sind.

Das Obige ist Teil einer SEHR umfassenden Antwort von Google Answers, die sich hier befindet:

http://answers.google.com/answers/threadview/id/758002.html#answer

— DVK
quelle

17

Der Teil der URL nach dem Hostnamen wird sicher gesendet.

Beispielsweise, https://somewhere.com/index.php?NAME=FIELD

Das /index.php?NAME=FIELDTeil ist verschlüsselt. Das somewhere.comist nicht.

— levis501
quelle

6

Alles ist verschlüsselt, aber Sie müssen bedenken, dass Ihre Abfrage in den Protokollen des Servers verbleibt und für verschiedene Protokollanalysatoren usw. zugänglich ist (was bei POST-Anforderungen normalerweise nicht der Fall ist).

— Eugene Mayevskis Rückruf
quelle

1

Welche Server? für wen zugänglich?

— Jader Dias

2

@Jader zumindest an Administratoren dieser Server und an Hacker. Bei einer POST-Anforderung bleiben die Informationen nicht in den Protokollen. Wenn sie nicht explizit protokolliert werden, gibt es kein Problem mit den Protokollen. GET-Abfragen bleiben in Protokollen und wenn irgendetwas mit dem Protokoll passiert (oder der Administrator beschließt, diese Protokolle für schlechte Aktivitäten zu verwenden), sind Sie in Schwierigkeiten.

— Eugene Mayevski 'Rückruf

4

Die Verbindung wird verschlüsselt, bevor die Anforderung übertragen wird. Ja, die Anfrage wird ebenfalls verschlüsselt, einschließlich der Abfragezeichenfolge.

— cHao
quelle

4

Ja, es ist sicher. SSL verschlüsselt alles.

Auszug aus der POST-Anfrage:

POST /foo HTTP/1.1
... some other headers

Auszug aus der GET-Anfrage:

GET /foo?a=b HTTP/1.1
... some other headers

In beiden Fällen wird alles, was auf dem Socket gesendet wird, verschlüsselt. Die Tatsache, dass der Client während einer GET-Anfrage Parameter in seinem Browser sieht, bedeutet nicht, dass ein Mann in der Mitte dasselbe sehen würde.

— Darin Dimitrov
quelle

4

Ich habe gerade über HTTPS eine Verbindung zu einer Website hergestellt und eine Reihe von GET-Parametern übergeben. Ich habe dann Wireshark benutzt, um das Netzwerk zu schnüffeln. Über HTTP wird die URL unverschlüsselt gesendet, was bedeutet, dass ich alle GET-Parameter in der URL leicht sehen kann. Mit HTTPS ist alles verschlüsselt und ich kann nicht einmal sehen, welches Paket der GET-Befehl ist, geschweige denn dessen Inhalt!

— Jeff Lamb
quelle

3

Das SSL findet vor dem Header-Parsing statt. Dies bedeutet:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Eine Anfrage sieht ungefähr so aus (ich kann mich nicht an die genaue Syntax erinnern, aber diese sollte nah genug sein):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

Aus diesem Grund ist es auch problematisch, unterschiedliche SSL-Zertifikate für mehrere Hosts auf derselben IP zu haben. Der angeforderte Hostname ist erst nach der Entschlüsselung bekannt.

— Morfildur
quelle

1

Das HTTP/1.1kommt am Ende der ersten Zeile.

— Marcelo Cantos

@Marcelos Cantos: Danke, es ist schon eine Weile her, dass ich HTTP-Anfragen von Hand schreiben musste.

— Morfildur

0

Die GET-Anforderung wird bei Verwendung von HTTPS verschlüsselt. Aus diesem Grund müssen gesicherte Websites eine eindeutige IP-Adresse haben. Der beabsichtigte Hostname (oder das virtuelle Verzeichnis) kann erst nach der Entschlüsselung aus der Anforderung abgerufen werden.

— Michael Burr
quelle

JFYI: Es gibt eine TLS-Erweiterung, mit der der Client den Hostnamen angeben kann und der Server das entsprechende Zertifikat auswählen kann.

— Eugene Mayevski 'Rückruf

@Eugene: Danke - ich bin mir der TLS-Erweiterung bewusst, aber nur im weitesten Sinne des Bewusstseins - ich weiß nichts über die Details oder wie weit sie tatsächlich verwendet werden könnte (oder auch nicht).

— Michael Burr