Posted on 28 Aug 2016 by Matt Traudt
Last upated 02 Jan 2019 at 10:01 am
I work for the Naval Research Lab doing research and development on Tor, and
sometimes the Internet in general.
KIST: Kernel-Informed Socket Transport for Tor
ACM Transactions on Privacy and Security (TOPS 2018)
Rob Jansen, Matthew Traudt, John Geddes, Chris Wacek, Micah Sherr, and Paul Syverson
Privacy-preserving Dynamic Learning of Tor Network Traffic
25th ACM Conference on Computer and Communication Security (CCS 2018)
Rob Jansen, Matthew Traudt, and Nick Hopper
HSTS Supports Targeted Surveillance
8th USENIX Workshop on Free and Open Communications on the Internet (FOCI 2018)
Paul Syverson and Matthew Traudt
Tor’s Been KIST: A Case Study of Transitioning Tor Research to Practice
Technical Report arXiv:1709.01044 [cs.CR] (arXiv 2017)
Rob Jansen and Matthew Traudt
Personal: sirmatt |at| ksu d0t edu
Tor: pastly |at| torproject d0t org
Work: matthew d0t traudt |at| nrl d0t navy d0t mil
In general, you can find code I write in public on
GitHub and on my
Simple Bandwidth Scanner
Some of the Tor directory authorities run bandwidth scanners to measure the
bandwidth of relays and include their measurements in their network status
votes. Clients use the consensus of these weights to inform their path
selection process with the hope that every circuit they build will have roughly
equal performance, regardless of the relays chosen. This achieves a form of
Historically, the directory authorities that ran bandwidth scanners (bandwidth
authorities), ran torflow.
Time passed, it slowly become less maintained, and
the collective knowledge of how it worked slipped away.
Simple Bandwidth Scanner (sbws) aims to be a quick to implement, easy to
maintain replacement for torflow.
KIST is a new scheduler for Tor. It is merged into Tor code as of 0.3.2.9. It
prioritizes low-bandwidth, bursty traffic (web traffic) over high-bandwidth,
continuous traffic. See my relevant publications for more information.
BM - Blog Maker
BM is barely maintained.
This blog-like website is created with bm.
BM is a set of scripts that use common GNU utilities to dynamically create a
static blog. See the README at the project page linked above for more
Read the entire post
Posted on 20 Dec 2017 by Matt Traudt
Last upated 27 Dec 2017 at 2:22 pm
Unless you're an edge case (which you aren't).
Why you would want HTTPS
Let's talk about why you normally want HTTPS. Let me know if I missed
You already get this with Tor.
Everything between your local Tor client (using Tor Browser? It runs Tor in the
background) and the Tor client providing the onion service is encrypted. No Tor
relay and no network-level adversary can tell what onion service you are
visiting (which is actually better than what HTTPS-without-Tor to a regular
website would get you).
If you're an onion service operator and you're at the sophistication level of
taking advice from random blogs on the Internet, HTTPS doesn't help you here.
If you're Facebook, Reddit, or YouTube, then you have a sizable datacenter(s)
and are probably no longer running Tor on the same machines as your webservers.
Unencrypted traffic may be flowing over an uncomfortable distance on your
(super secure, right?) network. Maybe you want HTTPS. But you also have the
resources to get a valid certificate for your onion. So do that.
Avoid men in the middle
You already get this with Tor. This is related, but distinct from the previous
When you connect to reddit.com with HTTPS, how do you know no one is MitM'ing
you? The certificate is valid, right? No big scary browser errors. For better
or for worse, we trust the Certificate Authority (CA) system.
When you connect to an onion service, how do you know no one is MitM'ing you?
Easy. It's impossible. The bad guy would have to be in your browser (more
accurately: between the browser part of Tor Browser and the Tor process it runs
in the background) or between the Tor process the onion service operator is
running and the webserver it's pointing at. If you assume your Tor Browser
Read the entire post
Posted on 18 Jun 2017 by Matt Traudt
I'm in the process of setting up a new server and I'm trying to be super ultra
mega secure about it. It's running FreeBSD with some fancy security options
enabled, blah blah blah, oh and I made SSH over Tor the only way to remotely
access it for administration. It's a private onion service,
which is super cool in itself, but since I don't mind leaking the location of
this server, it is also a single-onion service. This does seem to have a
positive impact on the speed and latency to the machine, but after a few weeks
of managing the machine completely over Tor, I determined I wanted more
My main complaint is the lack of immediate local echoing of what I type. Mosh
does that, but mosh uses UDP, which doesn't work over Tor. There's two ways I
could approach this. The first would actually be called "Mosh over Tor," but I
ultimately went for the second as it would actually allow me to roam (another
great feature of mosh).
I could use socat to tunnel UDP over Tor. Create the tunnel and then mosh to
Or I could authenticate over SSH over Tor and then create the actual UDP
connection over the regular Internet.
So I now present to you the script I use to (not really) use mosh over Tor. It's
a healthy mixture of things specific to me and hardcoded values that need
changing for every use case. But it is a starting point if you would like to
try your hand at (2) above too.
Read the entire post
SUCCESS_LINE=$(ssh $SSH_HOSTNAME "mosh-server new -i $MOSH_IP" | grep 'MOSH CONNECT')
[[ "$SUCCESS_LINE" == "" ]] && echo "failed to connect :(" && exit 1
MOSH_PORT=$(echo $SUCCESS_LINE | cut -d ' ' -f 3)
Posted on 06 May 2017 by Matt Traudt
Last upated 04 Feb 2018 at 11:28 am
I made a thing.
http://jld3zkuo4b5mbios.onion and http://vwx4mjvwoszgnagzcrwdjlsq3pq3zyob3zpq5qissxdoivnuyylzn7yd.onion
(it used to be available at onions.system33.pw and
Most of what I wanted to say about it I've already said at those links above.
It got picked up by Motherboard, and then a few other sites picked it up. This
was supposed to be a stupid little Saturday project. It isn't interesting. It
Posted on 25 Feb 2017 by Matt Traudt
Last upated 14 Jan 2018 at 2:37 pm
You're probably aware of many of the great features of onion services.
- end-to-end encryption
- location hiding
- assurance you're talking to the server you think you are
- firewall traversal
You may have ever heard about how misbehaving relays with the HSDir flag can
learn the existence of onion services that their owners literally never
advertised anywhere. This attack and related attacks will be impossible when
the next generation of onion services is deployed (see end of this post for more
information), but did you know can prevent this from happening right now, today,
on your onion services?
This is thanks to a feature of Tor onion services that can prevent anyone from
even connecting to your service if they don't have your permission. I'm not
talking about a login page on example.onion, I'm talking about the inability
for random people to be able to tell that example.onion is up or if it even
I'm talking about the HiddenServiceAuthorizeClient (server-side) and HidServAuth
(client-side) torrc options that you can find in the Tor manual.
There are two ways to use this: basic and stealth. The gist with both is
- the server tells its Tor process to generate some tokens
- the server operator gives a token to each user he wants to allow to access his
- the users tell their Tor processes about their token and then they can connect
After this setup is done, clients authenticate automatically with no further
work from the user necessary.
Read the entire post
Posted on 30 Jan 2017 by Matt Traudt
Yesterday I released yet another new major version of BM! The
changelog has a summary of changes. As before, please report any
issues at the issue tracker.
There are two big changes that should be noted.
Your configuration file needs to move. It used to be in
that directory has been emptied out. Your configuration file now belongs in your
posts/bm.conf. BM comes with a script in
tools/ to help you
transition from v3 to v4, but really it's as simple as moving your configuration
file. After you've moved it, you may delete the include directory. It should
The other major change is themes! Themes allow you to quickly change the look of
your website. They can easily be shared as all the important bits and pieces are
in one directory per theme. Here's the "terminal" theme that I created and will
officially support in addition to the default theme.
For information how how to set your theme, see here. For
information about creating your own theme, see here. It's very
easy, especially if you start out copy/pasting an already good one.
Other new features
Page signing was added. Now, given a gpg fingerprint, BM will automatically
cryptographically sign all output files (even the CSS!) and leave a note in the
footer saying so in officially supported themes.
(Ignore the version number, this was added in v4.0.0. I should probably decide
something about "in development" versioning...)
If page signing is enabled, then
/pubkey.gpg will also be automatically
generated with the public key used for signing.
Licensing your content has been made easier. A new config option,
Read the entire post
LICENSE_TEXT, was added. The contents of it will be placed verbatim in the