I am new to setting up Hidden Services.

I have my service up and running, listening on port 80, and redirecting to localhost:8080. I have my web-server anonymized and listening on port 8080 for traffic, and everything there seems to work fine.

What I want is client side ssl certificates to identify and secure all access to my service. I understand how to do this process for a normal clear-net server, but am unsure how to proceed to accomplish this on a tor service.

I know that I can have two Virtual Servers in Apache, each listening on localhost to different ports (8080 and 4433), and under the same HiddenServiceDir in torrc have a 2nd HiddenServicePort listening on 443 and directing https traffic to 4433, no problem, but that still allows access via a non-https version of the site. I also know that I could just kill off the standard and only publish my https version fo the service.

Are these assumptions all correct? How would I force all traffic to https without breaking traffic coming from tor2web service?

  • added information on tor2web
    – cacahuatl
    Commented Jul 29, 2016 at 7:49

1 Answer 1


It's exactly the same excepting that no CA will sign your CSR (it'll be a self-signed certificate) and it's mostly superfluous because .onion is already providing end-to-end authenticate encryption.

Update to address comments and updated question:

There is no difference between the approach over tor or a dangernet site, you'd setup something like:

HiddenServiceDir /var/lib/tor/onion
HiddenServicePort 80 8080
HiddenServicePort 443 4433

Then configure your httpd to 301 to https://$hostname for any requests on 8080, just as you would for a dangernet website.


If you're interested in client authentication then onion services can actually provide this, depending on your requirements and the size of your userbase, this would remove the requirement for a TLS stack on the server, clients setting TLS exceptions on their browser and installing a client-side TLS certificate.

To do this, you'd create a config like:

HiddenServiceDir /var/lib/tor/onion
HiddenServiceAuthorizeClient basic alice,bob,charlene,diane,edgar
HiddenServicePort 80 8080
HiddenServicePort 443 4433 # maybe irrelevant now?

Now you'd have a file in /var/lib/tor/onion/hostname that'd look like:

w27mu53v64gcpfru.onion Bq1T05QWOWhZG5/EN5oqfQ # client: alice
w27mu53v64gcpfru.onion n5I/fRj05aQG/2gqy1KC3g # client: bob
w27mu53v64gcpfru.onion rN+OCpC5ntgDGnCW0Quxpw # client: charlene
w27mu53v64gcpfru.onion 0K5Fd2zOiSo/Fc0t7YYgPQ # client: diane
w27mu53v64gcpfru.onion fu2LxUfA5QWxuC5PgEDSaQ # client: edgar

Now you give each user their "cookie", no one can access the hidden service without a valid "cookie". Alice, for example, would edit her torrc to include this line:

HidServAuth w27mu53v64gcpfru.onion Bq1T05QWOWhZG5/EN5oqfQ

Now Alice can use w27mu53v64gcpfru.onion as normal, and you'd know that the visitor was authorized because without their cookie they'd be unable to connect. If at any time you want to revoke access, you can remove Alice from the client list in the HiddenServiceAuthorizeClient line and reload tor to invalidate their cookie.

This is "basic" authorization for onion services, there is a further "stealth" but it does not scale anywhere near as well as "basic" because it published a descriptor for every client, each client uses a different .onion address to access the site too. It might be of interest if your userbase is small and high risk or high security. It also has some interesting extra security properties too, but it's going a bit beyond just replacing client-side TLS certificates.


"tor2web" is an SSL MITM. You make an https request to tor2web, it makes an http request to the .onion, it proxies the response back to you. It would follow a 301 to an https address but it would fail when it encountered a self-signed, or otherwise "untrusted" TLS cert.

In your case this would present problems.

Firstly the client certificate, if used, would be served to tor2web and wouldn't be carried to your httpd, it would break client cert based authentication.

Secondly the HidServAuth wouldn't work, tor2web wouldn't be able to connect to the .onion as it wouldn't have the required authorization cookie.

Thirdly tor2web represents the security anti-pattern of "SSL Added and Removed Here :¬)", tor2web can, and must, see all of the activity performed through it. Infact facebooks onion service explicitly recommends against tor2web for this very reason, as you can see from this example request:

$ curl https://facebookcorewwwi.onion/ -H 'x-tor2web: 1'
Using Facebook over Tor2web (or other SSL-intermediaries) is a bad idea; by using such services you may expose your account details to the service provider and thereby risk interception or account theft. Please instead connect to Facebook in a normal way.

The x-tor2web header is the header that tor2web should send to indicate it's in use, but it doesn't have to send it. You can use this header to detect it's use and handle it appropriately.

  • Right, self signed CA for Client SSL is fine. To be sure, it's the client authentication that I want, in lieu of passwords, to keep my community of users tight. And also for added security as per here eff.org/pages/tor-and-https When I set this up, do I merely set torrc to listen on port 443, routing it to localhost 4433, and rout it to an additional virtual server set to listen for ssl on that port?
    – Joshp.23
    Commented Jul 28, 2016 at 18:54
  • Those questions have been answered. I added a Listen port to my webserver configuration, and all is well.
    – Joshp.23
    Commented Jul 28, 2016 at 20:02
  • I altered the question to be more specific.
    – Joshp.23
    Commented Jul 28, 2016 at 20:30
  • 1
    Updated my answer, also that eff page doesn't apply for onion services because there is no "exit" node, as mentioned they're already end-to-end encrypted. See this question and answer
    – cacahuatl
    Commented Jul 29, 2016 at 3:20
  • 1
    Yes, I did mean https. I've fixed that typo. I don't use or recommend trying to use tor2web, I think it's somewhat of a misfeature (it would likely also mangle your client-side TLS being passed through). It probably works for facebook because their TLS cert if valid for the .onion (EV cert associated with both their real domain and the .onion) where as yours and most others would likely be self-signed and would fail any TLS validation checks done by tor2web. Tor Browser can probably accept client certs, but I've honestly never tried and they'd likely be discarded on shutdown.
    – cacahuatl
    Commented Jul 29, 2016 at 4:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .