Does SSL/TLS (https) hide the urls being accessed [duplicate]

Question

Suppose I type this in my browser

https://www.mysite.com/getsecret?username=alice&password=mysecret

and an attacker is watching all traffic from me to my ISP.

What information is protected by HTTPS? Is the URL revealed? Are the parameters of the get request revealed?

Also, does HTTPS provide integrity for the url?

I tried looking at various HTTPS articles and the TLS specification but was not able to figure this out.

[EDIT:] It is okay if only the server domain name is revealed. However, no part of ?username=alice&password=mysecret should be revealed.

Answer 1

The HTTPS protocol is equivalent to using HTTP over an SSL or TLS connection (over TCP).

Thus, first a TCP connection (on port 443) is opened to the server. This is usually enough to reveal the server's host name (i.e. www.mysite.com in your case) to the attacker. The IP address is directly observed, and:

1. you usually did an unencrypted DNS query before,
2. many HTTPS servers serve only one domain per IP address,
3. The server's certificate is sent in plain, and contains the server name (between multiple ones, maybe),
4. in newer TLS versions, there is the server name indication, by which the client indicates to the server which host name is wished, so the server can present the right certificate, if it has multiple ones. (This is done to be able to go away from 2.)

Then a TLS handshake takes place. This includes negotiation of a cipher suite and then a key exchange. Assuming at least one of your browser and the server didn't include the NONE cipher in the accepted suites, everything following the key exchange is encrypted.

And assuming there is no successful man-in-the-middle attack (i.e. an attacker which does intercept the connection, and presents a forged server certificate which your browser accepts), the key exchange is secure and no eavesdropper can decrypt anything which is then sent between you and the server, and also no attacker can change any part of the content without this being noticed. This includes the URL and any other part of the HTTP request, as well as the response from the server.

Of course, as D.W. mentions, the length of both request (which contains not much more variable data than the URL, maybe some Cookies) and response can be seen from the encrypted data stream. This might subvert the secrecy, specially if there are only a small number of different resources on the server. Also any follow-up resource requests.

Your password in the URL (or any other part of the request) should still be secure, though - at most its length can be known.

Answer 2

You should assume that the URL is not protected, i.e., that a passive eavesdropper may be able to learn what URL you are visiting.

I realize this contradicts what some other folks are claiming, so I'd better explain.

It is true that everything after the domain name is sent encrypted. For instance, if the url is https://www.example.com/foo/bar.html, then www.example.com is visible to the attacker, while the HTTP request (GET /foo/bar.html HTTP/1.0) is encrypted. This does prevent an eavesdropper from directly seeing the path part of the URL. However, the length of the path part of the URL may be visible to the eavesdropper. In addition, other information -- such as the length of the page you visited -- may also be visible to the eavesdropper. This is a foot in the door for the attacker. There has been some research which uses this foot in the door to learn what URLs you are visiting, if the attacker can eavesdrop on your https traffic.

While there is no guarantee that these attacks will succeed, I suggest that it would be prudent to assume the worst: to assume that an eavesdropper may be able to learn what URLs you are visiting. Therefore, you should not assume that SSL/TLS hides from an eavesdropper which pages you are visiting.

Yes, https does provide integrity for the URL you visited.

P.S. One other caution: in practice, sslstrip and other man-in-the-middle attacks may be successful against many or most users, if the web site is not using HSTS. Those attacks can violate both confidentiality and integrity of the URL. Therefore, if users are visiting web sites that are not using HSTS over an insecure network (e.g., open Wifi), you should be wary that an attacker might be able to learn what pages the users are visiting. One partial mitigation against the sslstrip threat is for users to use HTTPS Everywhere and for sites to adopt HSTS.

Answer 3

As @Paŭlo Ebermann and @Jeff Ferland have told you, the GET request is encrypted under SSL and so is safe. However, don't forget that many web servers log GET requests and parameters, and any credentials or other sensitive information you send via GET could be written to a log somewhere. For that reason, you should use POST (which will also be encrypted under SSL) when submitting sensitive data.

This falls into the category of "encryption isn't magic security that solves all your problems."

Answer 4

The following things will leak before your session starts:

• IP Address of the server
• Certificate of the server
  • That will include the domain name published on the certificate, though that doesn't guarantee it will match what you used.
• You DNS queries

No data or requests that aren't related to creating the SSL connection (GET ...) are sent to the server before the SSL session begins. The URL is sent as part of the page request and protected the same as any traffic that is part of the session.

Answer 5

Yes and no.

The url is encrypted properly, so query parameters should never be revealed directly.

However, traffic analysis can get the length of the URL often - and knowing the server and the length of the url is often enough to eavesdrop what pages are being accessed, especially if assuming that links on a page are clicked. Google for "traffic analysis ssl browsing" or something similar if the topic interests you.

In your use case this is of marginal importance. Clever use of traffic analysis may reveal the length of the username and/or length of the password, depending on if the other URLs fetched also contain the username. If you pad the username/password to a constant length, you can avoid these attacks, but it might not be worth the hassle.

Answer 6

TLS stacks are starting to send Server Name Indication (SNI, http://en.wikipedia.org/wiki/Server_Name_Indication; http://www.ietf.org/rfc/rfc3546.txt). That is sent in the clear, meaning eavesdroppers can see the server name you type into the address bar.