tommorris.org

Discussing software, the web, politics, sexuality and the unending supply of human stupidity.


https


Firefox 52 adding insecure form warnings

The latest version of Firefox’s Developer Edition (formerly known as Aurora) now ships with more prominent warnings for when you send passwords from an insecure context. For a long time, some sites have attempted to justify having login forms on insecure HTTP pages with the argument that the credentials would be encrypted in transmission as they were being sent to an HTTPS endpoint. The problem with this is that it doesn’t actually prevent password sniffing, it just makes it slightly harder. Rather than sniffing the credentials as they go over the wire, you instead use a man-in-the-middle attack to intercept the HTTP page and insert JavaScript into it that sniffs the password upon entry and then sends it via Ajax to the interceptor.

Firefox’s new implementation uses a fairly simple algorithm described in the new W3C Secure Contexts spec that is attempting to standardise some of the key concepts of browser-side security. Hopefully, users being warned that they are submitting passwords insecurely will start prompting websites to stop doing the login-form-on-HTTP-that-submits-via-HTTPS anti-pattern.

My usual go-to example when illustrating the problem is airline websites, specifically the online checkin or frequent flyer account login page. You give airlines quite substantial amounts of money and personal information. For a long time, most were vulnerable to this kind of attack. Malicious hackers also have been known to steal and sell frequent flyer miles, although not necessarily though man-in-the-middle attacks on the login forms.

British Airways used to have a login form for their Executive Club frequent flyer programme on their homepage—they’ve now fixed this and the whole site seems to be HTTPS.

But the following (mostly randomly selected) airlines still are vulnerable to man-in-the-middle password stealing through JavaScript injection.

And that’s just one sector: airlines. There’s plenty more sites that ordinary people use everyday that have potential vulnerabilities caused by these purportedly-secure-but-really-not login forms. Browsers giving prominent and irritating warnings about it is the first step to getting the companies to pay attention.

When the next big attack happens, there will–as always–be non-technical people from government and business lamenting how difficult all this information security stuff is, and how the vectors of attack are always changing. Let it be on the record that this kind of vulnerability is extremely simple, well-known and relatively easy to exploit. There are interesting and ingenious ways to attack Transport Layer Security, but if you don’t turn it on to start with, one doesn’t need to DROWN POODLEs or really do anything that will make technical people go “ooh, that’s clever”. Firefox warning users about this really old and boring way of breaking user security might mean that people spend less time speculating about the scary difficult emerging threats and fix the basic glaring security errors right in front of them.


Why you need to care about HTTPS

(Yes, even you with the content-focussed site.)

One of the recurring themes from IndieWebCamp this weekend in Brighton was a desire to get a lot more websites SSL-enabled. It became something of a friendly competition: with both the level scheme laid out on the IndieWeb wiki and the Qualsys SSL Labs report generator, a bunch of sites which did not have HTTPS before today now do, including my own.

Qualsys rate tommorris.org A+ on the SSL front. It’s not perfect: there’s still stuff on the website that is mixed content (that is, both HTTP and HTTPS on the same website) in the archives, although I’ll be working to reduce the amount of stuff I post that isn’t HTTPS enabled.

For a long time, the standard policy for a lot of people has been “HTTPS is important for interactive sites, but isn’t really needed for content sites”. This has a certain level of truth. If you are collecting user data—requiring people to login—you should be using HTTPS. It’s not a negotiable. E-commerce sites, social networking sites, dating sites, email sites, web applications, forums—pretty much anything you are expecting people to login to should be HTTPS only to protect the user from having their packets sniffed between you and them.

But what about those “content sites”? Those sites that just publish content for you to read with no expectation of you interacting? Blogs, for instance.

You still need SSL. Especially if you write about anything controversial. Politics, religion, sexuality and so on. With HTTPS turned on, those sniffing the packets going between client and server will spot only that there is communication with your web server—the exact request made is not revealed.

I am already aware that in at least one evangelical Christian high school in New Zealand, I am filtered as a purveyor of immoral and unchristian lifestyles. I’m assuming it is because of my use of the Ruby programming language rather than for being a hell-bound atheist sodomite. But I’m hoping that now the repressed subjects of other censorship-based societies can worry slightly less about the exact pages they are reading on my site being disclosed to their censorious masters. That’s worth a tenner a year and a few minutes futzing around with Nginx config files.

HTTPS is not NSA or GCHQ proof. SSL certificates are issued by Certification Authorities (CAs) and if you don’t think that the CAs are in league with the government, you are very naïve. Read up on DigiNotar. Ideally, at some point, we’ll also do something like Monkeysphere so that we can apply GPG-style Web of Trust principles to HTTPS. I trust security-conscious wise Unix neckbeard types to verify identities far more than I trust big companies in the pay of surveillance states that put on an elaborate show of being liberal democracies.

NSA and GCHQ proof is a tall order. There are lots of scumbags trying to spy on you that aren’t NSA or GCHQ. Even if we can’t defeat the surveillance state, we can fight against corrupt ISPs, corporations and universities monitoring and censoring the web on behalf of those in their charge.

And, yes, HTTPS/SSL sucks in a lot of ways. But you still need to do it. CAs are kind of craptastic. The experience of setting up HTTPS is annoying—although it is a lot less painful with Nginx than it ever was with Apache. If you publish a website, set up SSL. It’s not very painful and so long as you do it right, you are helping protect your users from some forms of surveillance and privacy intrusion.

(Next on the “let’s be less creepy” front: switching out Google Analytics for something like Piwik. I went with GA because I’m lazy. But there’s no point building independent tooling for the web and still giving a load of user data to Google given they seem to be creatively reinterpreting the whole not being evil thing these days.)