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):
- (Sub)domain in the DNS query
- (Sub)domain in the Client Hello (SNI)
- (Sub)domain in server certificate
- URL is sent encrypted via TLS
For more details read the explanation below.
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:
- You type in https://example.com/supersecretpage.
- The browser submits the (sub)domain in a special TLS extension (called SNI)
- 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
how-to-develop-tls.com. These entries are called Subject Alternative Names and the cert is valid for all of them.
- After the client verified the certificate and the client and server choose a cipher the traffic is encrypted.
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
* If the certificate is a wildcard certificate it does not include the subdomains, but just
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":
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.