Is GET data also encrypted in HTTPS?

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?

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.

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.

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

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.

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).

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

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!

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.

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.

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.

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.