One of my favorite things about the Tor Project is their proposal system. Every idea that’s worth thinking about goes into a proposal template that talks about the idea, the technical background, why it’s proposed, as well as any risks or design issues that need to be factored in. They read like RFC’s and that will either make you kind of excited or kind of sleepy. But in any case, they are a look into the future of tor as well as some hints about current issues that need to be addressed.

I noticed this bug ticket from Tor Project last week: Make exit flag depend on ports 80 and 443, not 6667 and it reminded me about a short talk I gave regarding how the port you connect to a service on, directly affects the anonymity you’re able to achieve. In short, visiting services on non-standard ports such as https://www.antitree.com:64201 increases the risk of you choosing a compromised circuit compared to visiting https://www.

Tor Project has just released version 0.3.2.1-Alpha of tor that supports the long-awaited, next-generation onion services that aim to repair many its known flaws. Here’s what I understand are the big changes and features compared to the old version. Key Size Current Onion services right now are based on RSA 1024 bit keys which, for long-term keys, aren’t an ideal size. While RSA 1024 hasn’t been publicly cracked, predicts say it should be possible this year.

This is a follow up from the Custom Seccomp profile post which went through some of the background information. Speed up custom seccomp profile generation with Syscall2seccomp You can always manually track down the syscalls that your application makes, and build a custom seccomp profile for your Docker container, but I’ve created the tool syscall2seccomp that helps speed the profile building process up. It takes the output from sysdig or strace and converts it to a usable Docker profile.