The HTTPS-only experience

EFF recently announced that We’re Halfway to Encrypting the Entire Web.” As a celebration of this achievement I’ve started an experiment: as of yesterday, no unencrypted HTTP traffic reaches this machine*.


Even though securing your web site is easier than ever it will take some time before everybody encrypts. But there are a bunch of sites which support both secure and insecure HTTP transfer, and there are a few tricks to tilt the scales and make the current experience better:

  • The HTTPS Everywhere browser extension ensures that you use HTTPS whenever possible on thousands of sites.
  • Editing the URL to add “https://” at the start works for some sites. If you get the dreaded certificate error page make sure to report them, and only add an exception if … well, that subject is too big to get into here. Just don’t.

Many sites have excellent HTTPS support, and have enabled HTTP Strict Transport Security (HSTS). In short, if your browser knows that the domain supports HTTPS (by visiting it or the browser being installed with it) you can simply type the domain name in the URL field and the browser will default to fetching the secure version of the site. On the other end of the spectrum I can still visit sites which have no HTTPS support at all if I really need to by using Tor, which provides privacy but not integrity or authenticity.

pacman stopped working after setting this up. It turns out the package database is fetched using unencrypted HTTP by default, but it was easy to generate a new list of only HTTPS mirrors.

Some sites have a strange HTTPS setup. The BBC only support HTTPS for the front page, which is just weird. Why go to all that trouble for 1% of the gain? Other sites require authentication to access using HTTPS, possibly not realising that setting up HTTPS for everyone would be easier.

My home router runs DD-WRT, and the web interface for it is only accessible by HTTP by default. This is easy to configure though.

OCSP uses HTTP (at least in Firefox), since the returned file signature has to be checked separately anyway. So if I go to about:config, change security.OCSP.require to true, and visit a site I haven’t seen for a while, I get an error message like this:

An error occurred during a connection to The OCSP server experienced an internal error. Error code: SEC_ERROR_OCSP_SERVER_ERROR

The solution is to either allow OCSP queries specifically or to allow HTTP to specific hosts. Let’s see what can be done…

The Steam client uses insecure HTTP for both game updates and the store pages. There doesn’t seem to be any way to force it to use HTTPS, so I have submitted suggestion to Valve using the official channel.

These have been the only major hassles so far. The only other sites I really can’t get to work over HTTPS are various hold-outs like Wikia and BBC.


The change was a simple addition to my Puppet manifest:

firewall { '100 drop insecure outgoing HTTP traffic':
  chain  => 'OUTPUT',
  dport  => 80,
  proto  => tcp,
  action => reject,

The resulting rule:

$ sudo iptables --list-rules OUTPUT | grep ^-A
-A OUTPUT -p tcp -m multiport --dports 80 -m comment --comment "100 drop insecure outgoing HTTP traffic" -j REJECT --reject-with icmp-port-unreachable

* Technical readers will of course notice that the configuration simply blocks port 80, while HTTP can of course be served on any port. The configuration wasn’t meant as a safeguard against absolutely every way unencrypted HTTP content could be fetched, but rather focused on the >99.9% of the web which serves unencrypted content (if any) on port 80. I would be interested in any easy solutions for blocking unencrypted HTTP across the board.

When MFA is not enough

I hope you’ll excuse the format of this post. Coffee does strange things to my brain.

In the beginning, there was the username. And it was deemed good enough, because everybody on the machine was a trusted colleague. Then came machines shared by strangers, and with them the password. And it was deemed good enough, because the resources to crack it were beyond most. Then came the Internet, and the world flourished and grew. But the world contains more villains than the password, in its myriad implementations, could withstand. And thus came multi-factor authentication. And it was deemed good enough, because only someone in possession of the authenticated device could gain access.

But they were all deceived, because the service providers foretold that their users would lose their authenticated device, and lock themselves out of their accounts, and would blame them rather than their own misfortune. And so it was that, fearing their users’ wroth, the service providers gave their support personnel unfettered access to override MFA at the behest of a phone call.

Some service providers were wiser, and gave out backup codes after authenticating, thus allowing users to regain access by themselves, and promised not to give access to anybody with a honeyed voice, and reminded their users ever and anon that they should be mindful of their backup codes, and even gave them the option to be told when their account was logged into. And their users were at peace, trusting that their service providers knew what the fuck they were doing, that their files were safe, and being forever loyal to them.

SMS authentication on fail recently added two step authentication. Hooray for taking security seriously! Unfortunately the setup page is full of fail:

  • No indication whether the trunk prefix should be included in the number. I tried both with and without one, twice, but never received a single message. It is not obvious how it would occur to anyone to try both, especially for people who always use one or the other.
  • Why is Google Authenticator so massively emphasized over SMS? Granted, many rich* people have a smartphone, but there is no indication why using a third party app is preferable to the solution which works on every mobile phone capable of connecting to an existing network. YAGNI, and if GitHub gets by with SMS then it’s good enough for me.
  • Why is there a separate “Send SMS” button? Surely by the time the “Verify Code” page shows up you should have sent the message.
  • The first page contains an obvious button to go to the next step. The second page contains three differently styled button-ish elements to show download links for one app and two plain links to go to the next page. The third page (after following the “use Two Step Authentication via SMS” link) contains one left-aligned and one right-aligned button. I haven’t got to the last page yet; I just hope it isn’t too crazy.
  • No relevant help page in sight.
  • No context-sensitive support link. For a new feature of such importance and with the possibility of locking people out pending manual intervention I’d expect more direct support integration.
  • Most search results for “sms authentication” in their forums seem to revolve around problems deactivating this feature. Sounds like it’s simply not ready yet.

PS: I’m using SMS codes for several other international services, and they all work fine.

* If you’re reading this, then you are very likely within the 10% richest people on the Earth.

Review: Liars and Outliers by Bruce Schneier

tl;dr An enormously important book about understanding and optimizing security in the 21st century.

On the Internet, nobody knows you’re a dog. I don’t know Bruce Schneier, and he certainly doesn’t know me. Even so, when he announced a heavily discounted signed edition of Liars and Outliers he was effectively testing the main hypothesis of the book: That in any society it is reasonable to uphold a non-zero level of trust even in complete strangers:

  • Schneier trusted 100 (or at least many enough to make a net gain) random strangers to reciprocate the offer by writing and publishing a review of the book.
  • 100 random people trusted him to sign copies of the book and send it to the correct addresses upon receipt of the money.
  • All 101 of us trusted essentially the rest of the human race not to interfere in the transaction, even when interference could mean easy money with virtually no chance of retribution.

Schneier goes on to explain, with his famous lucidity and reference to much contemporary research, why this trust is essential to all human interchange, how trustworthiness is highly dependent on the situation and not just the person, how a society with 100% conformity is not just a terrible goal but literally impossible, the human and artificial pressures to cooperate or not, how more severe punishments are often ineffective or even counter-effective, and how social and technological evolution is too fast for democracy to stabilize the overall level of trust.

[At this point I wanted to double-check the scribbled-down criticisms below, but the book is 3,000 km away with a nephew. Please take the following with a grain of salt. And now that I’ve lowered your expectations, let’s continue!]

In some very few places I found the wording misleading. For example, the iTunes store doesn’t allow you to buy music, merely to license it for your personal use. As far as I understand from what very little I’ve read of this, when iTunes shuts down, there are many jurisdictions where you would not be allowed to download songs which are audibly indistinguishable from what you had paid for.

The graphs are generally informative, but sometimes confusing. For example (pages 72-73):

  • Traits/Tendencies and natural defenses are both in the social pressures box, while the text says neither is a social pressure.
  • There’s an incentives line and a separate box.
  • Why are some of the lines double? If they’re strong, a thick line would be clearer.

One note is terrifying: On average, 7% of terrorists’ policy objectives are achieved? What method could conceivably be considered more effective than 7% for a (usually) tiny group of what is often foreigners? Compare it to normal bureaucratic channels, where usually only billionaire citizens or corporations have the slightest chance to change policy within a reasonable time.

Conclusion: I wish this had been compulsory reading at high school. With entertaining anecdotes, scary implications of human nature, and scientifically grounded careful optimism it’s the most dangerous book everyone should read.

Social contract – Fulfilled!

Usable security tokens

Security tokens are pretty common these days. You know the kind: A credit card-sized piece of plastic with an RFID chip and maybe a magnetic strip to boot. Touch and go! But besides the credit card form factor, are they actually practical? They are brittle, and they can’t be attached to anything without drilling (which would make them even more fragile). Here’s an idea: Get a small RFID chip, and put it into a small piece of ABS plastic with a metallic ring that goes into the middle of the ABS and extrudes just enough to include the whole thing on a key ring (see below). Now if you have an RFID reader somewhere on your desktop, it should be enough to sit close to the desk for it to read the chip. So you won’t end up with a broken card, you won’t have to put your entire wallet (or some other container) in your pocket to protect the card, and you won’t have to leave it on the desk at all.

PS: Is it possible to make stuff like this (with embedded metal, and without destroying the chip) on a 3D printer?