When visiting a site over HTTPS (HTTP over TLS), the TLS protocol prevents data in transit from being read or manipulated by man in the middle attacks, and an x.509 certificate obtained from a Certificate Authority (CA) validates that the user is actually connecting to a server representing the domain name in the browser address bar.
Modern browsers indicate that a connection is insecure if not using TLS, and require that a TLS connection is authenticated by a CA-issued x.509 certificate.
When visiting a site over the onion services protocol, the Tor protocol prevents data in transit from being read or manipulated by man in the middle attacks, and the onion service protocol validates that the user is connected to the domain name in the browser address bar.
No certificate authority is required for this proof, because the name of the service is the actual public key used to authenticate the underlying connection.
As ".onion" is a special top level domain name, most Certificate Authorities don't have support for issuing X.509 certificates for onion sites.
Right now, HTTPS certificates are only provided by:
- DigiCert with an Extended Validation (EV) TLS certificate, which means a considerable cost for an organization.
- HARICA with Domain Validation (DV) TLS certificates.
That said, there are some specific cases where you would need or want to have an HTTPS for your onion site.
We compiled some topics and arguments, so you can analyze what's the best for your onion site:
As anyone can generate an onion address and its 56 random alphanumeric characters, some enterprise onions believe that associating their onion site to an HTTPS certificate might be a solution to announce their service to users.
Users would need to click and do a manual verification, and that would show that they're visiting the onion site that they're expecting.
Alternatively, websites can provide other ways to verify their onion address using HTTPS, for example, linking their onion site address from an HTTPS-authenticated page, or using Onion-Location.
Another topic of this discussion is user expectations and modern browsers.
While there is extensive criticism regarding HTTPS and the CA trust model, the information security community has taught users to look for HTTPS when visiting a website as a synonym of secure connection, and to avoid HTTP connections.
Tor Developers and UX team worked together to bring a new user experience for Tor Browser users, so when a user visits an onion site using HTTP, Tor Browser doesn't display a warning or error message.
One of the risks of using a certificate issued by a CA is that
.onion names might unintentionally get leaked if the onion service owners use HTTPS due to Certificate Transparency.
There is an open proposal to allow Tor Browser to verify self-created HTTPS certificates.
If this proposal gets implemented, an onion service operator could make their own HTTPS certificate chain using an onion key to sign it.
Tor Browser would know how to verify such a self-created chain.
This will mean that you don't need to involve a third-party in making it, so no third-party will know that your onion exists.
Some websites have a complex setup, and are serving HTTP and HTTPS content.
In that case, just using onion services over HTTP could leak secure cookies.
We wrote about Tor Browser security expectations, and how we're working on onion services usability and adoption.
There are some alternatives you might want to try to address this problem:
- To avoid using an HTTPS certificate for your onion, the easiest answer is to write all your content so it uses only relative links.
This way the content will work smoothly, independently of what website name it's being served from.
- Another option is to use webserver rules to rewrite absolute links on the fly.
- Or use a reverse proxy in the middle (more specifically EOTK with an HTTPS certificate).
Related to the previous point, some protocols, frameworks, and infrastructures use SSL as a technical requirement; they won't work if they don't see an "https://" link.
In that case, your onion service will need to use an HTTPS certificate in order to function.
Actually HTTPS does give you a little bit more than onion services.
For example, in the case where the webserver isn't in the same location as the Tor program, you would need to use an HTTPS certificate to avoid exposing unencrypted traffic to the network in between the two.
Remember that there's no requirement for the webserver and the Tor process to be on the same machine.
Recently in 2020, the Certificate Authority/Browser Forum voted and approved version 3 onion certificates, so CAs are now allowed to issue Domain Validation (DV) and Organization Validation (OV) certificates containing Tor onion addresses.
In the nearby future, we hope that Let's Encrypt CA can start issuing v3 onion certificates for free.
If you're going to purchase an HTTPS certificate be aware that v2 onion service deprecation will happen between July - October 2021.