6a0120a85dcdae970b016301e98de2970d-800wi

So, let us talk plainly. You absolutely, definitely, positively should be using TLS / HTTPS encryption on the sites that you run.

HTTPS provides encryption, meaning that anyone watching the connection (and yes, people do care, and are absolutely watching), will have a harder time trying to extract content information about the connection. This is important, because it stops your credit card being read as it makes its way to Amazon’s servers, or your password being read when you log into your email.

When I advise my clients on infrastructure, these days I recommend that all pages on a website, regardless of that page’s contents, should be served over HTTPS. The primary reason being a feature of an encrypted connection which I don’t think gets underlined enough.

Tamper resistant web

When you serve content over HTTPS, it is significantly harder to modify. Or, to put it another way, when you serve pages unencrypted, you have absolutely no guarantee that the page your server sends is going to be the page that your visitor receives!

If an attacker controls a link in the chain of computers between you and the site you’re visiting it is trivial to modify requests to and from a visitor and the server. A slightly more sophisticated attacker can perform these attacks without the need to control a link in the chain, a so called “Man on the side” attack – more technically complex, but still relatively trivial with sufficient budget, and has been widely automated by state actors and criminal gangs.

The capabilities these sorts of attacks give someone are limited only by budget and imagination. On a sliding scale of evil, possibly the least evil use we’ve seen in the wild is probably the advertising injection attack used by certain ISPs and Airplane/hotel wifi providers, but could easily extend to attacks designed to actively compromise your security.

Consider this example of an attack exploiting a common configuration:

  • A web application is installed on a server, and the site is available by visiting both HTTP and HTTPS endpoints. That is to say, if you visited both http://foo.com and https://foo.com, you’d get the same page being served.
  • Login details are sent using a POST form, but because the developers aren’t complete idiots they send these over HTTPS.

Seems reasonable, and I used to do this myself without seeing anything wrong with it.

However, consider what an attacker could do in this situation if the page serving the form is unencrypted. It would, for example, be a relatively trivial matter, once the infrastructure is in place, to simply rewrite “https://” to “http://”, meaning your login details would be sent unencrypted. Even if the server was configured to only accept login details on a secure connection (another fairly common practice), this attack would still work since the POST will still go ahead. A really sophisticated attacker could intercept the returning error page, and replace it with something innocuous, meaning your visitor would be non the wiser.

It gets worse of course, since as we have learnt from the Snowden disclosures, security agencies around the world will often illegally conscript unencrypted web pages to perform automated attacks on anyone they view as a target (which, as we’ve also learnt from the Snowden disclosures, includes just about everybody, including system administrators, software developers and even people who have visited CNN.com).

Lets Encrypt!

Encrypting your website is fairly straightforward, certainly when compared to the amount of work it took to deploy your web app in the first place. Plus, with the new Lets Encrypt project launching soon, it’s about to get a whole lot easier.

You’ll need to make sure you test those configurations regularly, since configuration recommendations change from time to time, and most shared hosts & default server configurations often leave a lot to be desired.

However, I assert that it is worth the extra effort.

By enabling HTTPS on the entire site, you’ll make it much much harder for an attacker to compromise your visitor’s privacy and security (I say harder, not impossible. There are still attacks that can be performed, especially if the attacker has root certificate access for certificates trusted by the computer you’re using… so be careful doing internet banking on a corporate network, or in China).

You also add to the herd immunity to your fellow internet users, normalising encrypted traffic and limiting the attack surface for mass surveillance and mass packet injection.

Finally, you’ll get a SEO advantage, since Google is now giving a ranking boost to secure pages.

So, why wait?

GCHQoogle: so much for "Don't be evil"

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.

troll

If 2014 can be remembered for anything, it’ll be, in tech circles at least, the year of the Internet Troll. Online abuse, particularly abuse of women and minorities, has always been there and been a massive problem, but last year it finally broke into the mainstream.

Suffice it to say I’m sick of seeing the people I know and respect get abuse for simply being who they are and daring to use the Internet.

This is primarily a social issue, rather than a technical one, but as a technologist it’s the technology that I know, and as someone who helps build platforms that help people communicate, I can’t help wondering what technological approaches can be adopted to give victims of abuse some extra tools – as a sticky plaster – while we address the much more tricky root social issues (which I think largely revolves around good people not remaining silent about this stuff).

So, I’m wondering, if we were to build a tool like Twitter, or WordPress for that matter, today. What could we do, technically, to help?

Something important to stress as we begin to discuss tools we might be able to provide to a victim, is that in no way should this be interpreted as trying to shift the responsibility for abuse to them. More tools are only ever a sticking plaster to deal with the state of the world as it currently is, and it shouldn’t distract us from trying to make a better world where those tools aren’t needed.

Anyway, here are some rough musings.

A better block button

When someone reports a user for abuse, obviously no more messages should be received by the target from the abuser.

The abuser shouldn’t be explicitly made aware that they’ve been blocked (although it’d not be hard to find out that they have been), and every subsequent message should be redirected and logged, with as much detail as possible, in an evidence package for law enforcement, automatically.

The fact that this is done automatically is important, because it means the victim won’t have to manually process abusive messages in order to gather evidence, which itself can be an upsetting experience.

Shared block lists

This is a concept mooted by a bunch of people, and is something that certain existing services (looking at you Twitter) would be smart to implement.

Basically, a user can share their block list and make it available for others to subscribe to. This would allow people to quickly pre-empt some of the orchestrated attacks we’ve started to see emerging, since it would be a very quick way of distributing lists of trolls and their sock puppets, especially if there are one or two users who are the primary focus of an attack.

The bad side of this is that someone has to maintain these lists. However, if users share these lists with each other, you can easily see a black mark propagating quite quickly.

Graphing the network, degrading performance

Randi Harper created a pretty powerful tool, the GGAutoblocker which works by mapping the social graph of a few key accounts and pre-emptively blocking users who follow more than one.

This approach has been reported as being remarkably effective, and can easily be applied elsewhere.

If you’re building/operating a centralised service, this might be a handy concept to build into your network, specifically when dealing with specific groups of harassers or organised harassment campaign.

Additionally, I’m wondering whether it might be smart to attempt to disrupt these groups… for example, a service could throttle the communication between users who are on the list, so as to slow down their ability to organise using the platform. I imagine this would be particularly effective when applied to nexus nodes (fun fact, this is the theory behind the US metadata collection/drone murder program, but slowing down/hell banning people is probably less extreme).

This last would need to be done at the network level, and would require the network to make some opinionated decisions about who is an abuser and who is not. Probably not that hard to work out in actuality, but the unwillingness of certain popular networks to get involved is often part of the problem.

Problems with a distributed/Indieweb network

The specific problems of how you handle this sort of thing on a distributed network are interesting. In an effect, you could handle abuse in much the same way as you’d potentially handle spam. So, perhaps something like Vouch could help here.

While blocking based on domain (for mentions etc), shared block lists and automatic evidence collection is still applicable, the social graph forms of defence start becoming more tricky. Especially if, as I’m keen to see, the next generation of distributed networks go out of their way to hide/obfuscate the graph in order to protect against bulk metadata collection.

Just thinking out loud here, what are your thoughts?