TOR ONION WEBSITES VERIFICATION

TOR ONION WEBSITES VERIFICATION

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. It has happened before and will probably happen again. In June 2015 there were 255 fake onions found. 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.

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. Leaked referrers is exploited to sniff out hidden services as read in Tor’s trac. If you have outbound links to clear net you should make sure the user send no referrer at all. 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. These are domains with a lot of users so they are more likely to be targeted for phishing. In the case of Facebook (), Blockchain () and Cyph () 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. The only reason to have HTTPS on your onion is because it is easier to verify that you are on the correct onion-domain. No HTTPS!īecause Tor is end-to-end there is no need for extra encryption. You disable this with “ sudo ap2dismod status”. 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. 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. 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. 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. If you are using CSP you could use the ‘self’-directive because the browser will interpret that as the onion-domain in this case. The best fix is to never direct link resources in your code, that is “ “, instead you should just have it as “/scripts/jquery.js” If a user only gets resources via the onion-domain the web server will only see 127.0.0.1 as IP. This is because the web server will see the request and therefore the current exit relay for that specific user.

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.Ī user should never need to get resources (images, CSS and scripts) from your main domain if they are using your onion-domain.

Tracking is often useless for anonymous users.

Have in mind that most users will have JavaScript and Flash disabled (due to Tor Browser Bundle).

The user should only get resources from your onion domain.

But first I need to clarify a healthy security design on Tor. 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. onion is a complete different domain than your regular one you often need to adjust your settings so the site works with good security.

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.

Tor onion websites