Are HTTPS URLs encrypted? – Dev

The best answers to the question “Are HTTPS URLs encrypted?” in the category Dev.


Are all URLs encrypted when using TLS/SSL (HTTPS) encryption? I would like to know because I want all URL data to be hidden when using TLS/SSL (HTTPS).

If TLS/SSL gives you total URL encryption then I don’t have to worry about hiding confidential information from URLs.


Since nobody provided a wire capture, here’s one.
Server Name (the domain part of the URL) is presented in the ClientHello packet, in plain text.

The following shows a browser request to:

ClientHello SNI
See this answer for more on TLS version fields (there are 3 of them – not versions, fields that each contain a version number!)


3.1. Server Name Indication

[TLS] does not provide a mechanism for a client to tell a server
the name of the server it is contacting.
It may be desirable for
clients to provide this information to facilitate secure
connections to servers that host multiple ‘virtual’ servers at a
single underlying network address.

In order to provide the server name, clients MAY include an
extension of type “server_name” in the (extended) client hello.

In short:

  • FQDN (the domain part of the URL) MAY be transmitted in clear inside the ClientHello packet if SNI extension is used

  • The rest of the URL (/path/?some=parameters&go=here) has no business being inside ClientHello since the request URL is a HTTP thing (OSI Layer 7), therefore it will never show up in a TLS handshake (Layer 4 or 5). That will come later on in a GET /path/?some=parameters&go=here HTTP/1.1 HTTP request, AFTER the secure TLS channel is established.


Domain name MAY be transmitted in clear (if SNI extension is used in the TLS handshake) but URL (path and parameters) is always encrypted.


Thank you carlin.scott for bringing this one up.

The payload in the SNI extension can now be encrypted via this draft RFC proposal. This capability only exists in TLS 1.3 (as an option and it’s up to both ends to implement it) and there is no backwards compatibility with TLS 1.2 and below.

CloudFlare is doing it and you can read more about the internals here —
If the chicken must come before the egg, where do you put the chicken?

In practice this means that instead of transmitting the FQDN in plain text (like the Wireshark capture shows), it is now encrypted.

NOTE: This addresses the privacy aspect more than the security one since a reverse DNS lookup MAY reveal the intended destination host anyway.


There’s now a draft RFC for encrypting the entire Client Hello message, not just the SNI part:

At the time of writing this browser support is VERY limited.


Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE…) over that encrypted TCP connection.


I agree with the previous answers:

To be explicit:

With TLS, the first part of the URL ( is still visible as it builds the connection. The second part (/herearemygetparameters/1/2/3/4) is protected by TLS.

However there are a number of reasons why you should not put parameters in the GET request.

First, as already mentioned by others:
– leakage through browser address bar
– leakage through history

In addition to that you have leakage of URL through the http referer: user sees site A on TLS, then clicks a link to site B. If both sites are on TLS, the request to site B will contain the full URL from site A in the referer parameter of the request. And admin from site B can retrieve it from the log files of server B.)


As the other answers have already pointed out, https “URLs” are indeed encrypted. However, your DNS request/response when resolving the domain name is probably not, and of course, if you were using a browser, your URLs might be recorded too.