About Me

Posted on 28 Aug 2016 by Matt Traudt

Last upated 18 Jun 2017 at 5:35 pm
permalink
Pinned post

I work for the Naval Research Lab doing research and development on Tor.

I'm interested in preserving people's online privacy. I run some services for the benefit of others, even if there usually isn't anyone else interested in using them.

Tor relays:

Bitcoin node: 5hw6ralvqvnc5ac7.onion:8333

Gitea instance: http://m6su7s3ir7dxggwg.onion

Robohash instance: http://5rqvahiexxwm4p6m.onion

Read the entire post

Mosh over Tor (Except Not Really)

Posted on 18 Jun 2017 by Matt Traudt

permalink

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 usability.

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).

  1. I could use socat to tunnel UDP over Tor. Create the tunnel and then mosh to localhost:some-port.

  2. 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.

#!/usr/bin/env bash
MOSH_IP="ip.of.remotehost.foo"
SSH_HOSTNAME="hostname.foo.from.ssh.config"
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)
Read the entire post

The Last Onion Service Index

Posted on 06 May 2017 by Matt Traudt

Last upated 18 Jun 2017 at 4:10 pm
permalink

I made a thing.

https://onions.system33.pw (or http://ypqmhx5z3q5o6beg.onion/)

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 isn't exciting.

Creating Private Onion Services

Posted on 25 Feb 2017 by Matt Traudt

permalink

You're probably aware of many of the great features of onion services.

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 exits.

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

After this setup is done, clients authenticate automatically with no further work from the user necessary.

Read the entire post

BM v4.0.0 is Released

Posted on 30 Jan 2017 by Matt Traudt

permalink

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.

Important

There are two big changes that should be noted.

Your configuration file needs to move. It used to be in include/bm.conf, but that directory has been emptied out. Your configuration file now belongs in your posts directory, 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 be empty.

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.

terminal 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.

signature note

(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, LICENSE_TEXT, was added. The contents of it will be placed verbatim in the

Read the entire post

BM v3.0.0 is Released

Posted on 16 Jan 2017 by Matt Traudt

permalink

Today I've released a new major version of BM, consisting of about 140 commits! See the changelog for a summary of all the changes, and please report issues at the issue tracker. Here's the important and exciting highlights.

Important

make cannot be called by the user anymore as BM needs to setup the environment for it. It probably should have never been called by hand, and hiding the Makefile in v3.0.0 further discourages manual make calls.

Post URLs have changed, but probably won't do so again for a while--if ever--as this is quite rude of me to do. Now post URLs are limited to the first three words of the post title plus the ID. Before it was all words of the title.

Exciting

Permalinks have been added. This was prompted in part by the previous change. If the option for it is enabled (which it is by default), a little permalink will be added in every post's header. Permalinks consist soley of a post's ID, so they will never change so long as you don't manually change a post's ID!

BM can optionally make the source post files available for download by your readers. If the option is set, not only will /posts/foobar-12345678.html be generated as usual, but /posts/foobar-12345678.bm will as well, the latter being an exact copy of the file you edit.

A 404 page has been added. Special webserver configuration is required to get the most out of it. See the wiki.

Thoughts

This release took a very long time. It introduced many backend changes, most concerning a major design change: move as much dependency logic into the Makefile as possible. Before the majority of BM's logic was in three large scripts. Now

Read the entire post