Tips for running an onion

labsdetectify

When deploying an onion there are a few things you need to have in mind because Tor-users may be more meticulous about their integrity. Because the .onion is a complete different domain than your regular one you often need to adjust your settings so the site works with good security. This blog post will teach a few tips and tricks you can use when deploying an onion-domain as an alternative way to use your website.

But first I need to clarify a healthy security design on Tor.

  • The user should only get resources from your onion-domain.
  • Have in mind that most users will have JavaScript and Flash disabled (due to Tor Browser Bundle).
  • No need for HTTPS! Tor is end-to-end.
  • Tracking is often useless for anonymous users.
  • Verification is important! Without Extended Verification certificates you need to find another way for the user to verify that he/she is on the correct domain.


About resources and leaking IP

A user should never need to get resources (images, CSS and scripts) from your main domain if they are using your onion-domain. This is because the web server will see the request and therefore the current exit relay for that specific user. If a user only gets resources via the onion-domain the web server will only see 127.0.0.1 as IP.

 

In most cases this is an easy fix. The best fix is to never direct link resources in your code, that is “https://example.com/scripts/jquery.js“, instead you should just have it as “/scripts/jquery.js”

 

If you are using CSP you could use the ‘self’-directive because the browser will interpret that as the onion-domain in this case. Note that CSP is supported in Tor Browser Bundle and you should use it because attacks such as XSS and CSRF are still very possible on onion-domains! Speaking of CSP, if you have the report-uri-directive you must point that to your onion if you are hosting the CSP-violate-logger locally.

 

Tracking onion-users

There is often no need to track users on Tor because they are anonymous as in they often leave the same User Agent and IP-address since they almost exclusive use TBB and therefore have the same User Agent and your web server will see the IP as 127.0.0.1 if they are connecting via the Tor network. Therefore you should not rely on analytic tools such as Google Analytics and Piwik to work on your onion-domain, instead you could let your web server log the requests and use a log analyzer to see number of users and traffic your onion gets.

 

If you are using Apache as webserver it is very important that you also disable “mod_status” because with this setting enabled anyone can see statistics about your visitors. You disable this with “sudo ap2dismod status”.

No HTTPS!

Because Tor is end-to-end there is no need for extra encryption. The only reason to have HTTPS on your onion is because it is easier to verify that you are on the correct onion-domain. In the case of Facebook (https://blog.digicert.com/anonymous-facebook-via-tor/), Blockchain (https://www.cryptocoinsnews.com/tor-users-can-now-connect-blockchain-infos-onion-address-securely-ssl/) and Cyph (https://cyphdbyhiddenbhs.onion) the only reason they would get a certificate with their onion-domain in the SAN is because users will much easier to verify that they are on the correct domain. These are domains with a lot of users so they are more likely to be targeted for phishing.

 

The chance for you getting a certificate for your onion-domain is small because they are only given out for special use (as of right now) so you need to self-sign to get HTTPS and this will show a warning to the user and may be counterproductive and scare them away.

No referrer!

If you have outbound links to clear net you should make sure the user send no referrer at all. Leaked referrers is exploited to sniff out hidden services as read in Tor’s trac. This is not a blog post about hidden services, but hiding the referrer is a good idea because the user may be victim of timing attacks, information disclosure or tracking.

 

Tor Browser Bundle has support for CSP 1.1 so you can add the referrer no-referrer;-directive to your CSP that you have on your onion-domain.

 

Verification

In June 2015 there were 255 fake onions found. It has happened before and will probably happen again.

 

Verification that the user is on the correct onion is important because you do not have the same control over your onion-domain as your “real” domain. Anyone can generate as many onion-domains as they wish and be fully anonymous if they choose to make a phishing-page and it’s harder to take down onions. So verification is important!
There are a few ways you can counteract phishing attempts on Tor. The most important thing is to clearly display the URL to your onion-domain on your main website. It’s also very important that your main site is protected by HTTPS (and maybe preload-HSTS) because otherwise exit nodes may rewrite the onion to a fake one.
If you have a login on your onion-domain you could have a picture with the onion-URL. This is better than regular text because if someone saves your site to use in phishing-attempts they will rewrite from your onion-domain to the the one they are using. Rewriting images is much harder for bots, but does not give full protection. Here’s an example:

onion

You could also have users to select a personal welcome message once they login. If they do not see this message every time they login, they will know that something is wrong. The downside with this method is that the user already logged in. However, you could have a form on the login that lets the user enter a secret phrase and the server will respond with another one that the user has selected.

 


 

Author: 

Chloe
Security Researcher
Twitter: @dotchloe