Category Archives: Security

Posted on
by

6a0120a85dcdae970b016301e98de2970d-800wi One of the good things to come out of the recent revelations that the NSA have been doing what we always supposed that they might be doing, as well as our lot pushing ahead with ill conceived plans to do the same, is that it has made the public at large much more aware of the need to protect themselves online. It has also acted as a spur for many of us in the tech community to pick up our game a little, and to work to better protect ourselves and others online by redoubling our efforts to finally stamp out cleartext communication protocols.

The humble email, sent for the most part in the clear and readable to everyone, is one of the last legacy unencrypted technologies still in common use. These days HTTPS can be being switched on for just about everything, and it is considered the height of irresponsibility in the tech community to still use telnet or ftp.

Technologies for securing email have been around for decades, but haven’t seen widespread adoption. PGP is the canonical example, however s/mime, which does the same job and is often forgotten about, may be more practical for most people, for two main reasons: 1) most mail clients have native support, including native support in iOS, 2) it does a much better job at key exchange, in the most part handling it transparently (as long as you have the “sign email” option turned).

Setting it up is still far from a one click “make my email secure” button, but once set up it is transparent and easy to use, so there is very little reason not to do it if you’re reasonably tech savvy (or know someone who is who can help you). Even if you use one of the NSA’s free webmail services (gmail et al), providing you don’t use the webmail interface to read your email, you can still set this up.

What this won’t do

Even if your email is encrypted, there are a number of gotchas which you should be aware of…

  • It relies on both parties switching on encryption – this is an age old issue.
  • Subject lines are never encrypted.
  • The spooks and other ne’er do wellers can still see who you contacted and when, leaving you vulnerable to being caught by the inevitable guilt by association fallacy that such mass surveillance programs are guaranteed to produce.

Setting up S/MIME

  1. Obtain a signing certificate: Unlike PGP, which relies on self generated keys and a web of trust to establish authenticity, S/MIME relies on signed certificates in the same way as HTTPS does. These are in many cases free to obtain. I currently sign my emails with a Comodo certificate obtained via their handy online form.
  2. Collect your certificate: Next, you need to collect your certificate, this is done via your web browser, and is possibly the most confusing step. You must visit a link, and your browser will generate and install a certificate into itself. What this means is that once you’ve clicked on the link, you should get a message along the lines of “Certificate from xxxx installed”, but you won’t be able to directly use it in your email client. You must also use the same browser on the same computer throughout the whole signup and retrieval process, which caught me out.
  3. Export your certificate: In order to be able to use your new certificate to sign and encrypt email, you must first export it as a certificate file. From your browser, visit your advanced settings and export the certificate. In chrome, this is under Settings -> Advanced -> Manage certificates. Save it somewhere safe, give it a password you’re going to remember.
  4. Import the certificate into your mail client: Here’s how on thunderbird, OSX/ios, outlook.

If you’re tech savvy, this isn’t too painful a process, and once it’s done its done (at least until the certificate expires). If you’re not, then I think it is up to those who are to help. Stamping out unencrypted communication protocols can be considered a civic responsibility in tech circles.

Hand holding is a start, however I see absolutely no reason whatsoever that this process can’t be made into a nice click button wizard. For the most part, S/MIME is natively supported in all modern mail clients, so is it not high time that the setup process was made a good deal simpler? Why on earth is this not all done by the setup wizard?

As a community, lets make a pledge to make this better and to stamp out clear text communication protocols once and for all, making security an invisible process for everybody. What do you say?

Posted on
by

It was recently revealed that the NSA and FBI have been using the US Patriot act to conduct blanket, unwarranted, surveillance of US citizens (and anyone who happens to talk to a US citizen), and of course comes as no surprise. The fact that major companies, Google, Verizon, Apple, to name but a few, were complicit in this, is very disappointing.

In the UK, the security services already track your phone calls, RIPA makes it a criminal offence to refuse to decrypt data (or what they believe is encrypted data) on the government’s request, and with plans to re-introduce universal internet surveillance (shamelessly capitalising on the tragic murder in south London of a young man, re-branded as “Terrorism”), we are taking the lead in creating the “Cradle to Grave” Surveillance State.

History shows that the greatest threat to an individual’s liberty comes from the state itself, rather than some foreign actor. My good friend Ben Werdmuller recently coined a new “Second Amendment”, which I thoroughly agree with:

Privacy being necessary to the sanctity of a free state, the right of the people to own and encrypt data shall not be infringed.

Of course, it is easier said than done. You can’t trust cloud based services to protect you; Apple, Google, Twitter, Facebook, your phone company and ISP are all complicit.

Wider use of encryption would be a start, but that’s hard to do in isolation. Email encryption is a microcosm of the problem; I’ve had a public key available for over a decade, but the grand total of encrypted emails I’ve received can be counted on the fingers of one hand. This is not because encryption or key management is necessarily complicated, it’s just that there is no motivation for me to use it if nobody else is as well.

It is useless in isolation.

Newer technologies fare better, without the need to carry too much legacy baggage, they can afford to switch on encryption from the get-go. Many, especially IM clients, have another advantage in that they are synchronous, and so could do content negotiation ahead of time. So, perhaps a mail client/webmail client with Webfinger support, and wider adoption of that?

Might help.

However, I think the biggest issue is that society at large tolerates the state doing this sort of thing. Perhaps “We the people” should start presenting a more unified opposition.

Posted on
by

The server-status page gives you a wealth of information about your apache server, and among other things it is necessary for the Apache munin plugin to work. However, by default it exposes sensitive data when run behind a squid reverse proxy.

In order to lock this down, you need to modify your /etc/squid/squid.conf file slightly…

acl no_stats urlpath_regex /server-status
http_access deny no_stats

This defines an ACL that will prevent squid from giving access to any request ending in /server-status. Because, in a reverse proxy configuration, it is squid that is hit when a client request a page from port 80, this prevents public access.

You’re not quite done though, because this setting assumes that your real web server (sitting behind the squid proxy on a different port) is NOT publicly visible. This can be achieved by placing it behind the firewall.

Munin

If you’re using munin to monitor your apache processes, you’ll need to make a small modification to the /etc/munin/plugin-conf.d/munin-node file, add/modify the following:

[apache_*]
env.url http://127.0.0.1:%d/server-status?auto
env.ports [apache server port]

This will tell the apache plugins where the server status page is, and what port the real apache instance is running on.