This post goes into what tor’s onion service authentication features do, how they work, and when they should be used based on your threat model because I couldn’t find any other documentation about it besides reading the spec. “Stealth” only provides “stealthy” properties against malicious HSDirs and basic has some additional obfuscation measures that might make your service better protected. Onion Service Authentication Feature An onion/hidden service supports two types of built in authentication:
One of Docker’s many updates this year was adding seccomp support. In short, seccomp/secomp-bpf is a way of filtering the system calls that you want to allow an application to make. It’s used for sandboxing enforcement it a lot of projects including Chromium, bubblewrap, and SubgraphOS. In Docker, it’s enabled by default (in supported environments) and has a default profile that is fine, but there’s always ways to customize it.
I’ve written about customizing PhantomJS to defend against fingerprinting but I never really looked at what affect Selenium (the driver that control lots of different Browsers) has on the fingerprintability of say something like the Tor Browser Bundle. Some people at the Tor Project are looking into using tor-browser-selenium or the like to automate control of a Tor Browser instance. For tasks like trying to detect whether an exit is manipulating content to the user it would be useful to emulate exactly what a user’s experience would be with TBB.
Continuation from previous posts: 1 and 2 Website Fingerprinting Defenses at the Application Layer I like research projects on subjects that I feel have no hope. So here’s hoping for hope! This research is attempting to specifically defend onion services from being fingerprinted. The most common attack scenario is when an adversary is able to inspect the traffic between the tor client and the network and correlate the amount of traffic sent, to the size of known onion services.