Tag Archives: snowden

Posted on
by

Tor is a powerful anonymity tool that lets people communicate and share ideas without disclosing who they are or what they’re viewing to prying eyes.

One cool thing that the network lets you do is create a site as a hidden service, which is a service accessible only from within the tor network, is end to end encrypted and can be viewed entirely anonymously via a .onion domain.

I thought it could be cool to be able to run Known as a hidden service, and potentially build an entirely distributed social network, one that resists metadata surveillance as well as content surveillance. Anyway, baby steps…

Install Tor

The first thing you need to do is install tor. I don’t mean the tor browser, although you’ll need that to visit your hidden service, I mean the underlying tor program itself. On a debian based network this is really easy:

apt-get install tor

Next, you need to configure your hidden service(s) by editing the configuration in /etc/tor/torrc:

HiddenServiceDir /var/lib/tor/hidden_service/
HiddenServicePort 80 127.0.0.1:80
HiddenServicePort 443 127.0.0.1:443

Restart tor and you will find a file containing your .onion domain name in /var/lib/tor/hidden_service/hostname. More details on configuring tor hidden services can be found on the tor project website.

Install Known

Download and install Known in the usual way.

My setup for my test onion site is Apache2 + modules + MariaDB (because I wanted to try Maria out). You of course can run nginx with mysql or mongodb, it won’t matter too much for tor.

To run through the Known installation procedure, you’ll need to visit your site via the tor browser. Find the name of your hidden service in /var/lib/tor/hidden_service/hostname (which will look something like xa7txi2q5okg36f6.onion), fire up your tor browser and visit that URL. All being well, you should see the Known installation.

Configuring Known to use tor

By default, Known will attempt to connect to web services and send webmentions directly. This will usually work if the machine you’re running your hidden service on is also directly connected to the internet, however you should consider routing this through tor since this communication could unmask your service.

So, you need to configure tor as a proxy, and then configure Known to use it.

First, edit torrc and add/uncomment the line:

SocksPort 9050

Next, configure Known’s web services to use it. Add the following to your Known config.ini file:

proxy_string = 'localhost:9050'
proxy_type = 'socks5-hostname'
disable_ssl_verify = 'yes'

These commands tell Known’s webservice calls to use the tor proxy to connect to the internet, and to use tor for DNS resolution in order to get access to .onion domains. This is important so that you are able to, among other things, send webmentions to other .onion sites from within the tor network. The last line disables ssl verification for HTTPS certificates (see the note below).

Note, for these settings to work you need to be running a version of Known that includes my curl settings patch.

Restart tor, and now all web service calls (which use Known’s web service library) should be sent via your tor proxy.

Known issues

There are some things you will need to consider when running Known as a hidden service:

  • The default PuSH hub is the public one at https://withknown.superfeedr.com/. This may cause unacceptable leakage of activity, so you may want to consider leaving this blank or using the Known native PuSH hub.
  • For the same reason, you may want to consider turning off emails, or sending emails through something like Mixmaster.
  • Only things that use Known’s web services libraries will use the proxy. Third party plugins (especially syndication plugins which use third party libraries, e.g. Facebook) will still try to connect directly. You may consider not using these plugins.
  • Currently there are no valid TLS certificates available for .onion domains, so you have to self sign if you want HTTPS. However, a .onion address is end to end encrypted in any case and there is some lively discussion about whether certificate authority based HTTPS is necessary or even desirable for hidden services. That you can’t get valid SSL certs for hidden services is a known problem (as opposed to a Known problem), so it’ll be resolved eventually one way or another.

Anyway, happy hacking!

Posted on
by

So yesterday, we were greeted with another bombshell from the Snowden archives.

After finding out the day before that GCHQ had spied on lawyers, we now find out that GCHQ and the NSA conspired to steal the encryption keys to pretty much every sim card in the world, meaning that they can easily break the (admittedly weak) encryption used to protect your phonecalls and text messages.

Personally, I’m not terribly concerned about this, because the idea that your mobile phone is insecure is hardly news. What is of concern to me, is how they went about getting those keys.

It seems that in order to get these keys, the intelligence agencies hunted down and placed under invasive surveillance ordinary innocent people, who just happened to be employed by or have dealings with the companies they were interested in.

The full capabilities of the global surveillance architecture they command was deployed against entirely unremarkable and innocent individuals. People like you and me, who’s entire private lives were sifted through, just in case they exposed some information that could be used against the companies which they worked.

Nothing to hide, nothing to fear

If there is a silver lining in all this, with any luck it will go some way towards shattering the idea that because you have nothing to hide, you have nothing to fear.

This is, primarily, a coping strategy. It’s a lie people tell themselves so they can avoid confronting an awkward or terrifying fact, a bit like saying climate change isn’t real, or that smoking won’t kill me.

Generally, it is taken to mean that you’ve done nothing wrong, i.e. illegal (and of course, that’s not what privacy is about, and what you consider being “wrong” has typically not been the same as what those in power consider “wrong”).

Fundamentally, it misses the point that you don’t get to decide what others are going to find interesting, or suspect you of knowing. In this instance, innocent people had their privacy invaded purely because they had suspected access to information that the intelligence agencies found interesting. This is something that, were I to do something similar, I’d go to jail for a very long time.

Now consider that one of the NSA’s core missions is to advance US economic interests, spying on Brazilian oil companies and European trade negotiations, etc. If I worked at a competitor of a US company, I’d be very careful what I said in any insecure form of communication.

You do have something to hide.

Posted on
by

I have a lot of devices connected to my home network, and like most modern computers, they automatically keep their system clocks correct by use of the Network Time Protocol (ntp), to connect, over the internet, to a very accurate central time server.

Many of the devices on my network phoned home to pre-set servers operated by their manufacturers – Ubuntu machines phoned Canonical servers, Macs and iOS devices phoned Apple, Windows phoned Microsoft. Since, in this post Snowden era we live in, we know for a fact that if something can be used to track you it will, and since I’ve been working to make my network as non-leaky as possible, by stopping all but authorised outgoing network connections, this seemed like something I should change.

My home server itself provides NTP, so there was no need for any other clients to talk to NTP servers elsewhere on the internet. Great, although it presents us with a number of problems:

  1. There are a lot of devices, and I’m lazy, so I don’t want to go around reconfiguring each device.
  2. While some devices allow you to easily change the timeserver, there are a bunch that don’t.
  3. I also want devices to be able to continue syncing themselves when connected to other networks.
  4. It would be nice if visitors to my network were afforded the same protection!

Remapping using Shorewall

Thankfully, I have shorewall running on a Linux box between my network and the wider internet, and also thankfully, NTP is fairly identifiable as a protocol, as it operates over UDP port 123.

So, using DNAT, I was able to remap any request to an outgoing NTP server on UDP port 123 from the network to my local server, using this line towards the end of my /etc/shorewall/rules file.

...

DNAT            loc:!192.168.1.1         loc:192.168.1.1 udp     123

...

This has the effect of redirecting all NTP requests from the network, transparently, to my server, regardless of what servers the client believes it is talking to.

To verify, we can use the tool ntpdate -d to connect to a time server on a bogus, but still technically valid, IP address, e.g. 1.2.3.4 (the -d puts it in debug mode, so we won’t reset any clocks). The bogus IP will be transparently remapped, and we should get a lock.

Before remapping…

24 Mar 16:22:30 ntpdate[13715]: ntpdate 4.2.6p3@1.2290-o Tue Jun  5 20:12:09 UTC 2012 (1)
Looking for host 1.2.3.4 and service ntp
host found : 1.2.3.4
transmit(1.2.3.4)
transmit(1.2.3.4)
transmit(1.2.3.4)
transmit(1.2.3.4)
transmit(1.2.3.4)
1.2.3.4: Server dropped: no data
server 1.2.3.4, port 123
stratum 0, precision 0, leap 00, trust 000
refid [1.2.3.4], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time:    00000000.00000000  Mon, Jan  1 1900  0:00:00.000
originate timestamp: 00000000.00000000  Mon, Jan  1 1900  0:00:00.000
transmit timestamp:  d6dada51.643e780f  Mon, Mar 24 2014 16:22:41.391
filter delay:  0.00000  0.00000  0.00000  0.00000 
         0.00000  0.00000  0.00000  0.00000 
filter offset: 0.000000 0.000000 0.000000 0.000000
         0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000

24 Mar 16:22:43 ntpdate[13715]: no server suitable for synchronization found

After remapping…

24 Mar 16:24:17 ntpdate[13736]: ntpdate 4.2.6p3@1.2290-o Tue Jun  5 20:12:09 UTC 2012 (1)
Looking for host 1.2.3.4 and service ntp
host found : 1.2.3.4
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
receive(1.2.3.4)
transmit(1.2.3.4)
server 1.2.3.4, port 123
stratum 3, precision -20, leap 00, trust 000
refid [1.2.3.4], delay 0.02592, dispersion 0.00000
transmitted 4, in filter 4
reference time:    d6dad7fc.de9a7567  Mon, Mar 24 2014 16:12:44.869
originate timestamp: d6dadabd.0543d5bb  Mon, Mar 24 2014 16:24:29.020
transmit timestamp:  d6dadabd.054a4033  Mon, Mar 24 2014 16:24:29.020
filter delay:  0.02597  0.02596  0.02594  0.02592 
         0.00000  0.00000  0.00000  0.00000 
filter offset: -0.00033 -0.00033 -0.00036 -0.00036
         0.000000 0.000000 0.000000 0.000000
delay 0.02592, dispersion 0.00000
offset -0.000361

24 Mar 16:24:31 ntpdate[13736]: adjust time server 1.2.3.4 offset -0.000361 sec

So, we can see that all network requests for ntp are now mapped to the local server on the quiet. A handy technique, and one I think I’ll start applying to some other protocols (I wonder if anyone has managed to reverse engineer icloud yet?).