With HTTPS, are the URL and the request headers protected as the request body is?

Question

Just want to verify, when making a SSL connection (http post) to say:

https://www.example.com/some/path?customer_key=123123123

If you don't want anyone to know about customer_key, this approach will not work even if I am making a https connection correct?

All data that I want secured has to be in the request body right?

Just to clarify (seeing some other answers). Your problem is about eavesdropper in the middle, right? Are you worried about the way you store *your* logs too (presumably you're running this server)? — Bruno, Jan 13 '12 at 23:18
possible duplicate of [Are https URLs encrypted?](http://stackoverflow.com/questions/499591/are-https-urls-encrypted) — Gumbo, Jan 14 '12 at 12:19

score 39 · Accepted Answer · edited Oct 07 '21 at 05:46

Quoting the HTTPS RFC:

When the TLS handshake has finished. The client may then initiate the first HTTP request. All HTTP data MUST be sent as TLS "application data".

Essentially, the secure SSL/TLS channel is established first. Only then the HTTP protocol is used. This will protect all the HTTP traffic with SSL, including HTTP headers (which contain the URL and cookies).

What may be visible in the handshake is the host name itself, since it's contained in the server certificate which will be visible in clear in the handshake (and it's often easy to guess the host name by looking at the destination IP address anyway).

When using Server Name Indication, the requested host name should also be visible in the server_name extension in the ClientHello message. Otherwise, there may be a bit of ambiguity (for the eavesdropper) to guess the host name from the certificate if the certificate is valid for multiple host names (e.g. multiple Subject Alt. Names or wildcards). In this case eavesdropping the DNS request from the client might give the attacker a clue.

Reading other people's answers and comments, some mention issues about Referer (lost an r in the spec) and logs.

Referrers shouldn't be sent when going from HTTPS to HTTP (but they are often sent when going from one HTTPS site to another HTTPS site).
About the history: you'll just have to trust whoever can potentially get that key legitimately (i.e. your users) not to spread it around. If needed, have a strategy to change it once in a while.
About the logs: I was assuming you were after protection over the network. The URL (including query) will be in the logs indeed, but if someone is able to attack your machine so as to get the logs, you have more to worry about that your app keys.

One of the remaining potential weak points is how you give that link to the user. If it's embedded in a web-page served over plain HTTP, anyone who can read that page would be able to see it. You should serve such a page over HTTPS too. If you send that link by e-mail instead, I'd say all bets are off, since mail servers rarely encrypt the connections between themselves and users also often to access their e-mail account without any encryption.

EDIT:

In addition, if you're using client-certificate authentication, the client certificate will be visible if it is negotiated during the initial handshake. This may leak the name of the user accessing the website (often Subject DNs contain the user name). The client certificate will not be visible if it is sent during a re-negotiated handshake.

score 8 · Answer 2 · answered Jan 13 '12 at 22:34

8

Only www.example.com will be visible to snoopers. The path section of the request is protected by SSL/TLS.

Obviously, you need to have sent original the hyperlink by HTTPS, too.

answered Jan 13 '12 at 22:34

artbristol

32,010
5
70
103

score 3 · Answer 3 · answered Jan 13 '12 at 22:43

3

Request data will be sent after establishing Secure connection, so no worries with above URL, but remember your data is not encrypted, only channel between server and client is encrypted, if one can crack this channel, then can clearly see your data.

SSL is wrapper encrypted channel on top of your data. If data is plain, anyone who can crack the SSL can see your data clearly.

answered Jan 13 '12 at 22:43

kosa

65,990
13
130
167

What is the difference between channel encryption and data encryption. In ssl handshake, the server and http client agree on a secret key and the data sent is encrypted using that secret key, right? – Ashwin Mar 27 '12 at 11:10
1

@Ashwin, assume you are sending ABC on wire, ssl wraps ABC using secret key, then it will be something like [ABC], [] is wrapper (or) key, but the content inside that is still ABC. If anyone know [] (your key), they can easily get your data. – kosa Mar 27 '12 at 16:55
How will anyone know my key. It is a secre shared only between the client and the certificate? Are there any ways to know the secret key by a third person? – Ashwin Mar 28 '12 at 04:38
1

That is what hackers job is, isn't it? They are there to crack secrets. – kosa Mar 28 '12 at 15:05

score 1 · Answer 4 · answered Jan 13 '12 at 22:34

1

Revising my answer to NO! Apparently only the host name is sent in clear text before the SSL connection is established.

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

answered Jan 13 '12 at 22:34

dbrin

15,525
4
56
83

score 0 · Answer 5 · answered Jan 13 '12 at 22:38

0

That Depends..

If you use a packet sniffer you cannot see the data sent over the wire. The main problem with this approach is that the request url is often saved in the server's log in plain text, the browser history keeps the url, URLs are passed in Referrer headers and maybe persisted by third party services (google analytics).

answered Jan 13 '12 at 22:38

Leo

1,102
2
11
18

well this is server to server, not client browser to server. – codecompleting Jan 13 '12 at 22:40
1

The `Referer` shouldn't be passed around with HTTPS: http://stackoverflow.com/a/8848843/372643 – Bruno Jan 13 '12 at 23:05

With HTTPS, are the URL and the request headers protected as the request body is?

5 Answers5

Linked

Related