132

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?

Pang
  • 8,605
  • 144
  • 77
  • 113
Jader Dias
  • 81,082
  • 147
  • 410
  • 611

10 Answers10

152

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.

dan-gph
  • 14,921
  • 12
  • 55
  • 75
Marcelo Cantos
  • 167,268
  • 37
  • 309
  • 353
  • 2
    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. – Abhishek Anand Mar 24 '14 at 21:23
  • 1
    @Abhishek: The hostname isn't present in the TCP/IP header. I cover IP addresses in my answer. – Marcelo Cantos Mar 29 '14 at 02:22
  • 1
    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](http://www.ietf.org/rfc/rfc4366.txt) – hafichuk Jul 11 '14 at 17:02
  • @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. – Marcelo Cantos Jul 13 '14 at 05:37
  • 1
    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. – Tim G Aug 02 '16 at 23:59
65

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.

Thomas
  • 150,847
  • 41
  • 308
  • 421
  • 2
    +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 :) – orokusaki Jan 21 '11 at 16:20
  • 3
    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). – Thomas Jan 21 '11 at 16:24
  • 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 – Ricardo Pessoa Dec 30 '14 at 10:42
  • 1
    You should put these in the POST body, not the URL query string. – Thomas Dec 31 '14 at 11:04
  • 1
    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. – Serge Profafilecebook Feb 09 '15 at 13:24
  • 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. – Thomas Feb 09 '15 at 19:31
  • 1
    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. – Steen Schütt Mar 20 '15 at 14:19
22

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

DVK
  • 119,765
  • 29
  • 201
  • 317
19

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.

orokusaki
  • 48,267
  • 47
  • 159
  • 244
levis501
  • 3,753
  • 20
  • 22
7

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

Eugene Mayevski 'Callback
  • 43,492
  • 7
  • 62
  • 119
  • 1
    which servers? accessible to whom? – Jader Dias Nov 10 '10 at 11:46
  • 2
    @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. – Eugene Mayevski 'Callback Nov 10 '10 at 18:10
5

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

cHao
  • 78,897
  • 19
  • 136
  • 168
5

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!

Jeff Lamb
  • 5,135
  • 4
  • 33
  • 54
4

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.

Darin Dimitrov
  • 960,118
  • 257
  • 3,196
  • 2,876
3

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.

Morfildur
  • 12,196
  • 6
  • 32
  • 54
0

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.

Michael Burr
  • 311,791
  • 49
  • 497
  • 724
  • JFYI: There is a TLS extension that lets the client specify the host name and so the server can choose the corresponding certificate. – Eugene Mayevski 'Callback Jan 20 '11 at 19:22
  • @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. – Michael Burr Jan 20 '11 at 19:38