Author: Martijn

A clever trick taking advantage of the fact that Gmail ignores dots in email addresses could be used to trick someone into paying for your Netflix subscription – demonstrating the importance of confirmed opt-in.
Read more on Virus Bulletin’s blog.

This blog is now also available at http://bgaxaar7xx6dpptt.onion/, in other words, as a Tor Hidden Service (or location-hidden service, as the Tor Project itself calls it). It was surprisingly easy to set it up like this, and I thought I’d explain what I did.
First, however, let me make it clear that the location of this blog isn’t hidden. The Tor and non-Tor version run on the same server, which is hosted on a VPS at Bitfolk. There are a number of reasons why I decided to set it up like this as well, one of which is that it’s fun to do so. However, I believe it also helps support Tor in general and hidden services in particular — just like Facebook setting up a hidden service at their not-too-hidden servers did. Anonymity needs friends and by accessing this blog through Tor, you can be such a friend.
In what follows, I will assume that you are interested in setting things up for the same reasons. If you actually have something you really want hide from a powerful adversary, you should do some proper research and not just copy and paste things from a blog like mine. And at the very least, you shouldn’t run a non-Tor version of the blog on the same server.
I will also assume that you are running your WordPress site on a Linux server that you fully control, that the server runs Apache and that you aren’t afraid of the Linux command line. And I will assume that you have already installed Tor, which on most Linux distributions is trivial.

1. Configure your hidden service
   (See here for a slightly more detailed version of the first two points.)
   Tor comes with a configuration file, which is probably called /etc/tor/torrc. Open this file in a text editor and look for the bit that says
   ############### This section is just for location-hidden services ###
   a few lines below, you should see see lines like
   # HiddenServiceDir /var/lib/tor/hidden_service/
# HiddenServicePort 80 127.0.0.1:80
   Uncomment these two lines, by removing the # in front of them.
2. Restart Tor
   You do this by running something like
   service tor restart
   You can now access your site as a Tor Hidden service. To find its .onion address, go to the directory /var/lib/tor/hidden_service/ configured above and look for the file hostname inside it.
   (If you don’t like the hostname, remove the whole directory, restart Tor and repeat until you’ve got one you like. The hostname some kind of hash of the randomly generated private key, so you can’t control it and you’re unlikely going to have the resources to repeat this until you’ve got something you really like.)
3. Configure Apache
   Depending on how you have configured Apache, accessing your blog using the .onion address may redirect you to the default web server, outside of Tor. That’s not what you want, so you need to add a virtual server to your Apache settings.
   Apache changes its structure every few years, but in my case (I’m running Apache 2.4.10 on Debian Linux) I had to edit /etc/apache2/sites-enabled/000-default.conf. In this file, look for a block starting with <VirtualHost that defines your current WordPress site. Just copy this block, paste it into the same file and substitute your .onion domain for the one of your blog.
   In my case, the new block looked like this:
   
<VirtualHost *:80>
ServerName bgaxaar7xx6dpptt.onion
ServerAdmin youremail@address
DocumentRoot /var/www/lapsedordinary
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/lapsedordinary>
Options FollowSymLinks
# Options -Indexes FollowSymLinks
AllowOverride All
Order allow,deny
allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/tor_lapsedordinary_error.log
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/tor_lapsedordinary_access.log combined
</VirtualHost>

   (Note that I created separate log files for people accessing my blog via the .onion domain. If you do so, you can see how many people access your blog this way and what pages they access. You don’t have to though.)
   Finally, restart Apache (service apache2 restart in my case).
4. Set up the Domain Mirror plugin
   Now your blog should be accessible using the .onion domain. However, internal links will probably go to the domain you’ve set up in the WordPress settings. To let it work with both domains, you’ll need a plugin, of which there are a few. For me, the Domain Mirror plugin worked well (though I had to rename the installation directory). Once installed, it’s really easy to set up. Now internal links for those accessing your blog as a Tor hidden service should point to the .onion domain as well.

That’s all.
You will notice that, while I run HTTPS by default on the non-Tor version of the blog, the Tor version uses plain HTTP. That’s not a problem though: connections to hidden services are encrypted by design. One can get a certificate for a .onion domain (Facebook has one) but that’s just to get the Green lock in your browser’s address bar, which is something for people to look for before they enter their credentials.

This week, messaging app WhatsApp was shut down by the government in Brazil for 48 hours. It is worrying that a government did this. It is also worrying that they technically could, at least to the point where it was unusable for most people in the country.
Rob Graham suggested WhatsApp should do what botnets have been doing for years to make the individual bots find the command and control server, even in the face of regular take-down by law enforcement and security firms: use domain generating algorithms (DGA).
Rob’s post is worth a read, if only because it shows that there may be things to be learned from how botnets operate, despite the fact that they generally use evil means to do evil things. But much as it is a nice idea, DGAs won’t work for WhatsApp.
Firstly, the pseudorandomly generated domains still need to point to one or more IP addresses. This quickly becomes a single point of failure: a government that wants to block the service can simply block this IP address. WhatsApp can respond by moving its servers somewhere else, but the number of places where it can go are limited. You can’t run WhatsApp from your parents’ basement. A game of whack-a-mole between the company and law enforcement wouldn’t give a great user experience either.
Secondly, DGAs make “sinkholing” very easy. This is the process where someone (typically a security researcher or a law enforcement officer) registers one of the pseudorandom domains used by the service and consequently find the individual nodes (bots or WhatsApp clients) connect to their server. Note that malware researchers regularly crack the DGAs used by botnets (which tend to hide their code far better than WhatsApp would ever want to do) and even if they can’t do that, they could just run the app in a sandbox and see what domains it performs DNS lookups against.
In theory, a service can be setup so that sinkholing can’t do any harm, for instance by using public key cryptography and only communicate to servers that show possession of a public key. In practice, things are more complicated. It turns every security vulnerability that requires a man-in-the-middle position to exploit into one that anyone can exploit at scale (man-in-the-middle scales badly for most attackers). It also provides all kinds of DDoS opportunities, both against WhatsApp and against unrelated third-party services that the domains can be pointed to.
It is often said that if you use a free product on the Internet that you are the product rather than the customer. Generally speaking, this is true. But unlike individual bots, who are rightly often called “zombies”, these product-customers can and will leave if the service becomes unavailable a lot of the time.
Should a service like WhatsApp really be concerned by governments trying to take them down, they will be pleased to know that Tor has become a lot faster in recent years. And while running your infrastructure as a Tor-hidden service won’t prevent a really powerful three-letter agency from taking it down, it should provide ample protection against silly judges with even sillier court orders.

Earlier this year, a research paper presented a new attack against the Diffie-Hellman key exchange protocol. Among other things, the paper came with a reasonable explanation of how the NSA might be able to read a lot of the Internet’s VPN traffic. I wrote a blog about this in May.
Last month, the paper was presented at a conference and thus made the news again. Because I believed some of the news articles misunderstood the paper I just like writing about cryptography, I thought I’d explain what Diffie-Hellman is, what the paper showed and what its consequences are.

Chicken or the egg

Diffie-Hellman (named after its inventors Whitfield Diffie and Martin Hellman) attempts to solve the chicken-or-egg problem in cryptography: for Alice and Bob to communicate securely over a public channel such as the Internet they need to share a common encryption key. But for them to agree on such a key they need to be able to communicate securely over a public channel.
(N.B. in a typical situation where the protocol is used, Alice is a web browser or a VPN client; Bob is a web server using HTTPS, or a VPN server.)
Diffie-Hellman is called a key-exchange protocol, which is a bit of misnomer, as rather than exchange a previously generated key, the protocol actually generates the key.
In the first step, Alice and Bob both choose a (large) random number, which they both keep secret. Let’s call Alice’s number a and Bob’s number b.
Now using a ‘mechanism’ (more on which later) that is part of the protocol, Alice uses a to compute a second number, which is denoted g^a. Bob uses the same mechanism to compute a number g^b. Alice and Bob then share g^a and g^b with each other, over a public channel.
So we are now in the following situation:

• Alice knows a, g^a and g^b;
• Bob knows b, g^a and g^b;
• Anyone being able to read their communication only knows g^a and g^b.

Now using the same mechanism as before, Alice uses her secret number a and the number g^b, which Bob sent her, to create a new number (g^b)^a. Bob, likewise, uses b and g^a to create a number (g^a)^b. Because maths can be kind like that, (g^b)^a and (g^a)^b are in fact the same number. This is the shared key they will use.
The reason this works is that, while it is easy for Alice to use a to compute g^a, it is impossible for someone who only knows g^a to compute a — and the same of course also holds for b and g^b. It is also impossible to compute the shared secret key using only g^a and g^b.

Nothing is impossible

It is important to note that as so often in cryptography, ‘impossible’ doesn’t literally means that. It just means that it is extremely expensive and time-consuming. If the numbers involved are large enough, it can take the fastest clusters of computers millions of years to crack the algorithm; hence it is considered secure.
But computers keep getting faster, thus sometimes making the impossible possible. Many Diffie-Hellman implementations use numbers of a little over 300 digits long (1024 bits). These keys, the paper showed, can be cracked within a year for around 100 million US dollars. (Some people believe it can be done even more cheaply, but only the ballpark figure matters here.)
While 100 million dollars is not beyond the reach of the most powerful nation states (read: the NSA) it is unlikely that they ever pay this much to crack a single key. There’s almost always a cheaper way to get the same information; buying a very expensive wrench, for example.
Except for one essential detail. The mechanism used by Diffie-Hellman to generate the keys involves a choice: that of something mathematicians call an Abelian group, or, as they are more or less equivalent in this case, that of a prime number.
The attack the paper describes has two parts. The first part is the most expensive bit and involves doing a lot of computations that only depend on the chosen prime number. Only the second part involves the specific numbers g^a and g^b shared by Alice and Bob. An attacker who has done enough computations in the first part can perform the second part in more or less real time.

Sharing prime numbers

Imagine what would happen if many Diffie-Hellman implementations used the same fixed prime number: an adversary could spend a lot of time and money doing the required computations for this prime number and subsequently use that to crack key exchanges as they happen in real time. Knowledge of the secret key allows an adversary to read all the supposedly encrypted traffic between millions of Alices and Bobs around the world.
And this is exactly what was (and to some extent still is) the case: the paper showed for example that one in six of the most used HTTPS servers shared the same prime number. It’s even worse when it comes to VPN servers, of which 66% shared the same prime number. Although the latter figure has been disputed, if this was indeed what the NSA used to read VPN traffic, it would explain some Snowden slides rather well.
It is worth noting that sharing the same prime number is not as stupid as it may seem. Using your own unique prime number may be safer against this kind of attack, there are many traps to avoid when doing so. Most importantly, a lot of prime numbers are unsuitable and make the protocol a lot weaker. The paper also showed that several implementations used such unsuitable primes (and, somewhat intriguingly, some implementations used numbers that weren’t prime at all). There is thus a lot to say for choosing known safe (though widely used) prime numbers, despite the downsides we now understand well.
It would actually be a good rule of thumb to choose the strength of your encryption algorithms such that it would be too expensive for the most powerful adversary to attack, even if they would automatically crack all other implementations of the same protocol. For Diffie-Hellman, using longer numbers of 2048 bits (more than 600 digits) will do just fine.
It is thus not true that the researchers have broken Diffie-Hellman. Nor is it true that choosing “non-random prime numbers” (as I’ve seen someone claim somewhere) is inherently wrong.
However, longer numbers makes the algorithm more expensive to run. There would thus be a good argument to use Elliptic Curve Diffie-Hellman (ECDH) instead, a similar protocol that uses a different kind of maths. Its most important benefit is that it provides the same level of security with much smaller numbers.

Downgrading

On an aside, the paper also showed a related attack, which involves a “protocol downgrade”, where an adversary could convince Alice and Bob that the other could only use a mechanism with 160-digit (512-bit) numbers. The cost of cracking the secret key in this case, even if the mechanism used a unique prime number, is not beyond the means of a small criminal organisation.
Although this is a serious problem, from a cryptographic point of view it is less interesting. I also don’t know how likely it is for this attack to be used in the wild frequently: for a nation-state attacker a downgrade attack leaves too many traces, while for a criminal group, obtaining a man-in-the-middle position isn’t entirely trivial and often not needed to achieve their goals.