Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This question already has an answer here:

Let’s say I have never connected to the site example.com.

If this site is https and I write https://example.com/supersecretpage will the URL be sent in clear text since it's the first time I connect to the site and therefore the crypto keys were not yet exchanged? If not when does this take place? Could anyone explain the steps when I type that URL?

share|improve this question

marked as duplicate by Dmitry Grigoryev, Mark Buffalo, Neil Smithline, Steffen Ullrich tls Mar 22 at 6:20

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

1  
Worth mentioning that if you're trying to hide a URI or a GET variable, and especially for the sake of security, you're doing security wrong. Just saying. – Technik Empire Mar 16 at 3:54
2  
@TechnikEmpire: that depends upon whether you are trying to prevemt others from using the url, or from knowing that you used it. Obviously the recipient can know that you used it, but you may not want eavesdroppers to know as well. – jmoreno Mar 16 at 3:58
    
@jmoreno True, makes sense. – Technik Empire Mar 16 at 4:08
2  
@TildalWave: sure they might discover it another way, guess everything should be in clear-text. – jmoreno Mar 16 at 14:23
3  
Closer (more specific) dupe of security.stackexchange.com/questions/7705/… and security.stackexchange.com/questions/34794/… (which rugk linked) – dave_thompson_085 Mar 17 at 9:46

Short answer: No, the URL is encrypted, but the (sub)domain is sent in plain-text. In your case a (passive) attacker knows that you are connecting to example.com, but it does not know which specific page you are accessing.

In short there are three times where an attacker can get information about the site you are accessing (ordered chronological):

  1. (Sub)domain in the DNS query
  2. (Sub)domain in the Client Hello (SNI)
  3. (Sub)domain in server certificate

However the...

  1. URL is sent encrypted via TLS

For more details read the explanation below.

Explanation

Note: When I am writing "(sub)domain" I mean both the domain (example.com) and the subdomain (mydomain.example.com). When I only write "domain" I really only mean the domain (example.com) without the subdomain.

Basically what happens is:

  1. You type in https://example.com/supersecretpage.
  2. The browser submits the (sub)domain in a special TLS extension (called SNI)
  3. At some point the browser gets the SSL certificate from the server.
    Depending on the certificate* this also includes the subdomain you're connecting to, but it may also include more than one subdomain and even more than one domain. So in fact the cert of example.com may also include www.example.com, devserver.example.com and how-to-develop-tls.com. These entries are called Subject Alternative Names and the cert is valid for all of them.
  4. After the client verified the certificate and the client and server choose a cipher the traffic is encrypted.
  5. After all this happened a "usual" HTTP request is send (over the secured TLS channel). This means this is the first time in the whole request where the full URL appears. The request e.g. looks like this:

    GET /supersecretpage HTTP/1.1
    Host: example.com
    [...]

* If the certificate is a wildcard certificate it does not include the subdomains, but just *.example.com.

Another thing is worth mentioning: Before the connection can established at all the client needs to resolve the DNS name. To do this it sends unencrypted DNS queries to a DNS server and these ones also contain the (sub)domain, which can therefore be used by an attacker to see the visited domains.


However this does not always have to happen in this way, because you assume the user manually types in https://example.com/supersecretpage into the URL bar. But this is very rare as most users e.g. would rather type in example.com/supersecretpage. Another issue would be visitors clicking on an insecure link, which uses HTTP - in contrast to a secure HTTPS-link). Such links could e.g. be old links created when the site did not support HTTPS or did not redirect to HTTPS by default. You ask why this matters?

In the (usual) second case there is no https:// in the URL. When no protocol is entered into the URL bar all browsers internally "convert" this URL to http://example.com/supersecretpage (note the http:// there) as they cannot expect the server to support HTTPS. This means the browser first tries to connect to the website using insecure HTTP and only after the website sends a (301) redirect to the HTTPS URL it uses the secure mode.
In this case the attacker can see the full URL in the unencrypted HTTP request.

You can easily test this by yourself by looking into the "network panel" of your browser. There you should see this "HTTPS upgrade":
HTTPS connection upgrade in Firefox

However note that there are techniques to prevent this insecure first HTTP request. Most notably HSTS and - to protect even the first connection you make to the site - HSTS preloading, but also HTTPS Everywhere helps against such attacks. FYI: 95% of all HTTPS servers vulnerable are vulnerable to such (SSL Stripping) attacks.

share|improve this answer
3  
It is also worth noticing that if you are using a proxy script, the URL will be passed to the proxy script which could leak information about the URL through DNS lookups. If your browser is using proxy auto detection the proxy script could be provided by the network you are connected to. – kasperd Mar 16 at 10:18
1  
One nitpick: the way you worded the last section kind of implies that links always use HTTP. – David Z Mar 16 at 17:46
    
@DavidZ Thanks, I changed the wording. – rugk Mar 17 at 0:34

No, the URL will not be sent in clear text.

Immediately after the TCP three-way handshake completes, your client initiates TLS negotiation with the server. Only after that negotiation is complete and encryption is in place is the HTTP request sent.

share|improve this answer

Since you have never visited the site www.example.com, your browser needs to resolve the domain name to IP address. Hence, it sends out a DNS resolution query which contains the domain name of the site which you are trying to connect to. So a MITM can find out which domain you are trying to connect to unless you use secure DNS.

share|improve this answer
    
The DNS query however does only reveal the domain & subdomain, but not the whole URL. And for the DNS query it also does not matter whether you've visited the site before - it is always sent again unless it was cached. – rugk Mar 15 at 21:53
    
Isn't that an integral part of his question whether the domain or sub-domain is revealed or not? He mentions that he has never connected to the site before so I believe that is of more concern to him that than the relative path. I don't really mind being downvoted but the upvoted answers do not clarify the security of the DNS query resolution. – Rahul Mar 15 at 21:59
5  
Question title includes "first connection", question body includes "the first time", and this answer says "since you never visited". Altogether this gives a very strong and false impression that at subsequent visits the situation is different. – techraf Mar 16 at 0:17
3  
I have given my reasons why this answer is badly phrased and misleading. What made you think I was not serious? – techraf Mar 16 at 0:33
2  
@Rahul The point is, this doesn't answer the real question. – Technik Empire Mar 16 at 3:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.