PyGrunn: SSL, CAs and keeping your stuff safe - Armin Ronacher¶

Tags: pygrunn, python

(One of the summaries of the one-day 2014 PyGrunn conference in Groningen in the Netherlands).

Armin often talks at PyGrunn. I’ve got three older summaries: the future of wsgi and python 3 (2010), the state of python and the web (2011), and I am doing http wrong (2012). The one I liked most was his 2011 talk at the EU djangocon about the impact of Django.

He’s proposing a new title for his talk: a capitalistic and system conformant talk about encryption. Well, no, it is just about SSL. He’s working at “splash damage/fireteam”: infrastructure for games. They want to keep someone from gaming the games, so they encrypt everything. (Note: I like one of their ipad games very much, rad soldiers).

It is too easy to forget the bigger picture. He uses an analogy between bitcoin and credit cards. Bitcoins are completely encrypted and whatever. The credit card number, in contrast, is very insecure and unencrypted. But the whole credit card process is very secure. If someone steals your bitcoin key, you lose all the money, but you won’t have the same problem with your credit card if it were stolen. So: think about the bigger picture!

Regarding encryption: remember why you encrypt. Some people have https for their weblog. Why would you do that? The NSA does not care about your shitty blog.

Why? One reason is starbucks. Starbucks popularized free wifi. Unencrypted wifi. This killed unencrypted logins. So… suddenly you felt insecure at the airport’s wifi and https fixes that.

There’s a difference between passive and active eavesdropping. Active is about active attacks (man-in-the-middle). Passive about generic “firesheep” stuff.

Question: who checks self-signed certificates? Two hands went up in the room. If we as developers don’t check it, will our users? No. That’s why we have certificate authorities (CA). Companies that are trusted (somehow) that verify if you are who you say you are. And your browser trusts the CA.

For an API, such a CA is pointless. Explicitly trust the self-signed certificate of the API. So you have to check it manually.

What Armin things is the only sane way: run your own CA. Issue certificates for 24 hours. Trust your own CA only. And screw revocations (many browsers even don’t support it). And distribute the certificate of your own CA to the endpoints of your API. The “requests” library makes it easy to tell it to use a certain CA.

A problem they had was with Windows antivirus programs: they noticed a non-regular certificate authority and warned the user… So in the end they had to do it in an insecure way and use a certificate signed by a CA…

Revocating certificates doesn’t work. There are too many certification authorities for checking it all the time to be worthwhile. And… any CA can sign anything. One shitty employee at one shitty CA can impersonate any certificate. (There was such a case in the Netherlands with diginotar. Iran spied on encrypted gmail traffic by having a fake, but CA-certified, gmail certificate…). The browser trusts it! It is a fundamentally broken system.

Question “best practices”. For instance openssl. Used to be the best practice to use, but is absolute horrible code. Likewise: self-signed certificates might be the best thing you can do. But it isn’t best practice as it doesn’t work as nice in browsers. And the weird thing is that https, which is best practice, was actually less secure in a way than plain http during the heartbleed bug…

To get really scared, look at the openssl valhalla rampage page with a collection of dirty, idiotic and horrible stuff in openssl.

It is a good thing to plan for the worst. Assume something gets hacked. Keyloggers still exist, you know? What happens to the customer? What happens to your data? Don’t trust your encryption too much!

Encryption is hard and security should not be your only defense!