Is GET data also encrypted in HTTPS?

Question

When you GET

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

Is the %s query encrypted? Or just the response? If it is not, why should Google serve its public content also with encryption?

Leopoldeen

Answer 1

The entire request is encrypted, including the URL, and even the command (GET). The only thing an intervening party such as a proxy server can glean is the destination address and port.

Note, however, that the Client Hello packet of a TLS handshake can advertise the fully qualified domain name in plaintext via the SNI extension (thanks @hafichuk), which is used by all modern mainstream browsers, though some only on newer OSes.

EDIT: (Since this just got me a "Good Answer" badge, I guess I should answer the entire question…)

The entire response is also encrypted; proxies cannot intercept any part of it.

Google serves searches and other content over https because not all of it is public, and you might also want to hide some of the public content from a MITM. In any event, it's best to let Google answer for themselves.

Bricklayer

I am a little unhappy about the claim that the URL is encrypted. Isnt the hostname considered a part of the url? If so, the statement is wrong. There is no way to hide the hostname/IP address from the ISP/proxy server in the same way you cannot hide the destination address while sending physical mail. – Haldes

@Abhishek: The hostname isn't present in the TCP/IP header. I cover IP addresses in my answer. – Bricklayer

The domain is not encrypted. This is to support name based virtual hosts (vs. IP based). @MarceloCantos is completely correct that the rest of the URL (i.e. the GET command) is encrypted. This is covered in RFC 4366 – Hereof

@hafichuk: Thanks for that. I didn't realise TLS could advertise the fqdn. The last time I tried to setup an https multiserver (several years ago, I'll admit), it seemed impossible over a single ip. – Bricklayer

Really important addition to the TLS containing the domain name: Don't forget the plaintext DNS request also including the domain name. Chances are someone who can see your encrypted HTTPS traffic can also watch your DNS requests. – Piacular

do you know if/how it is possible to simulate whole (or at least partially) encryption/decryption in code. I am trying to get encrypted request from code C# and use my own root certifikate on it #70817951 – Ophiolatry

Answer 2

The URL itself is encrypted, so the parameters in the query string do not travel in plain across the wire.

However, keep in mind that URLs including the GET data are often logged by the webserver, whereas POST data seldom is. So if you're planning to do something like /login/?username=john&password=doe, then don't; use a POST instead.

Protractor

+1 thanks. This is on my own physical server, so I'm not too worried about logs, but that's a good consideration for anyone considering this in a shared hosting environment. It's also important to consider because I'll be transferring credit card numbers this way, and will definately not want to log them :) – Parfait

It doesn't really matter that it's your own box. You don't want anyone else who owns it (i.e. evil hackers) to see those passwords in plain text, either. Or those CC numbers (assuming that you're not storing those elsewhere as well). – Protractor

Hi,despite using https and method POST is possible to see in browser the Form Data like username=john&password=doe. In this case we can use encryption, or exist better solution? Thanks – Prostitute

You should put these in the POST body, not the URL query string. – Protractor

Is your fear the wbeserver has less restrictions on access to its logs than on access to the website's data (DB, file,etc.)? IMHO as long as the data securely access the webserver, all is well. the only people whom have access to the webserver should be considered reliable because if they aren't there's no way you'll prevent them to read the data in a way or another. – Produce

Even if administrators of the web server technically have access, that doesn't mean we should show passwords in plaintext on their screen by default. They might unwittingly share the logs, or someone might look over their shoulder. Also, a directory traversal vulnerability would be far more problematic if the web server can read all passwords from its own logs. – Protractor

When passwords are sent over GET and they are logged in the access log, they are NOT hashed. I believe that is the biggest issue. Having hashed passwords in the database doesn't matter if you can just look them up in the access log of the web server. They should be hashed in the database, if they're not, please fix it. – Reveal

Answer 3

HTTPS Establishes an underlying SSL conenction before any HTTP data is transferred. This ensures that all URL data (with the exception of hostname, which is used to establish the connection) is carried solely within this encrypted connection and is protected from man-in-the-middle attacks in the same way that any HTTPS data is.

The above is a part of a VERY comprehensive answer from Google Answers located here:

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

Stoa

Answer 4

The portion of the URL after the host name is sent securely.

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

The /index.php?NAME=FIELD part is encrypted. The somewhere.com is not.

Pico

Answer 5

Everything is encrypted, but you need to remember, that your query will stay in server's logs and will be accessible to various log analysers etc (which is usually not the case with POST request).

Isabelisabelita

which servers? accessible to whom? – Leopoldeen

@Jader to admins of that servers at least and to hackers. With POST request the information doesn't stay in the logs so unless it's logged explicitly, there's no problem with logs. GET queries do stay in logs and if whatever happens with the log (or admin decides to use these logs for any bad activities), you're in trouble. – Leshia

Answer 6

The connection gets encrypted before the request is transmitted. So yes, the request is encrypted as well, including the query string.

Drachm

Answer 7

I just connected via HTTPS to a website and passed a bunch of GET parameters. I then used wireshark to sniff the network. Using HTTP, the URL is sent unencrypted, which means I can easily see all the GET parameters in the URL. Using HTTPS, everything is encrypted and I can't even see which packet is the GET command, let alone its contents!

Looker

Answer 8

Yes, it is secure. SSL encrypts everything.

Excerpt from POST request:

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

Excerpt from GET request:

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

In both cases whatever is sent on the socket is encrypted. The fact that the client sees parameters in his browser during a GET request doesn't mean that a man in the middle would see the same.

Hilel

Answer 9

The SSL takes place before the header parsing, this means:

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

A Request looks something like this (can't remember the exact syntax, but this should be close enough):

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

This is also why having different SSL Certificates for several hosts on the same IP are problematic, the requested Hostname is not known until decryption.

Asafetida

The HTTP/1.1 comes at the end of the first line. – Bricklayer

@Marcelos Cantos: Thanks, it's been a while since i had to write HTTP Requests by Hand. – Asafetida

Answer 10

The GET request is encrypted when using HTTPS - in fact this is why secured websites need to have a unique IP address - there's no way to get the intended hostname (or virtual directory) from the request until after it's been decrypted.

Phenice

JFYI: There is a TLS extension that lets the client specify the host name and so the server can choose the corresponding certificate. – Leshia

@Eugene: Thanks - I'm aware of the TLS extension, but only in the loosest sense of awareness - I know nothing of the details or how widely it might (or might not) be in actual use. – Phenice

Answer 11

There is a little confusion above:

1. despite what is said, it is NOT required, anymore, to have unique IP address since the SNI field tells the server which cert to use
2. everything is encrypted EXCEPT the SNI request which is VERY early. This tells the server which Name and therefore which certificate to use. That is, the Server Name Indicator IS sent unencrypted so that the server and the client can establish and then use a secure connection for everything else.

So, in answer to the original question. Everything EXCEPT the host name (and I guess port) is secured in BOTH directions.

Naturalist