TLS is the best technology we have for securing our communications. It comes with many sharp edges though. This talk tries to jumpstart a rough understanding and these links should help you to complete the picture.

So far, I’ve held it at PyCon US 2014 in Montreal, PyCon Russia 2014, EuroPython 2014, and PyCon Poland 2014.

The PyCon US slides are on Speaker Deck.

Update 2015-04-11: One year later, the Python TLS situation improved.

Preamble

PGP for data at rest, TLS for data in motion. Neither are perfect, but both are subjected to intense scrutiny by researchers —Thomas H. Ptacek

Do not try to roll your own crypto or you’ll end up explaining why you thought that RSA keys with a public exponent of 1 are a good idea or why you chose to go for ECB mode and everyone can see the penguin (probably because your crypto library uses it by default).

Put effort into using TLS properly instead. You can’t beat the NSA if they’re really interested in you. But if you act sensibly, you can avoid that some contractor can read your emails out of boredom. If you’re concerned with performance: don’t.

Some people think that encryption by default is unnecessary. There are good reasons to deploy even your cat content using HTTPS though.

History

1995 : SSL 2.0, an inherently insecure Netscape standard. Having this activated is a serious security vulnerability.

: SSL 2.0, an inherently insecure Netscape standard. Having this activated is a serious security vulnerability. 1996 : SSL 3.0. A much better Netscape standard that got an ex post RFC by the IETF. Deploying it is also considered a security problem since the POODLE attack and should be avoided (RFC 7568)

: SSL 3.0. A much better Netscape standard that got an ex post RFC by the IETF. Deploying it is also considered a security problem since the POODLE attack and should be avoided (RFC 7568) 1999 : TLS 1.0. The first official IETF standard. Not to be confused with STARTTLS. Mostly an SSL 3.1 spec-wise.

: TLS 1.0. The first official IETF standard. Not to be confused with STARTTLS. Mostly an SSL 3.1 spec-wise. 2006 : TLS 1.1. Fixed mainly the CBC-related attacks like BEAST.

: TLS 1.1. Fixed mainly the CBC-related attacks like BEAST. 2008: TLS 1.2. Both enhanced security and grew nifty features. Make sure this is what you deploy.

How Does TLS Even Work?

TLS is a protocol that adds authentication (certificates), confidentiality (encryption), and integrity (MACs) to your connection-oriented transport layer (presumably TCP).

The TLS handshake is actually mostly straightforward.

Authentication

Confidentiality

Ciphers

Key Exchange

Since symmetric ciphers are used for the payload, the peers need to agree on identical keys over an unencrypted channel.

As a general rule, you want perfect forward secret (PFS) key exchange so a key leak or a court order doesn’t render the cipher text of all your users into plaintext.

The still most common key exchange method is RSA that we already know from the authentication section. It is fast which is one of the reasons for its wide deployment. And unfortunately not PFS.

Diffie-Hellman ephemeral (DHE) is PFS, but slow.

Elliptic Curve DHE (ECDHE) is both fast and PFS.

Get PFS right and you won’t have to pull stunts like Lavabit and give the FBI your server key printed in a 4 point font.

Getting PFS right in a big distributed system is tricky, be careful to not botch it.

At the end, both sides use the common master secret to derive multiple keys from it.

Integrity

Message authentication codes (MACs) are used to ensure that traffic is not tampered with.

The most common ones are Keyed Hash MACs (HMACs) that are used since TLS 1.0. The hash function that’s part of the cipher suite is then used.

TLS 1.2 allows ciphers to bring their own MACs. Examples are Poly1305 used together with ChaCha20 or the block cipher mode Galois/Counter Mode (GCM) that has an integrated MAC.

Implementations

You get TLS by linking to one of the more or less common TLS libraries.

Summing up, the commonly used one are all terrible, but you should still use one of them since they are the most widely audited. For more alternatives see this handy overview.

The rest of this collection is heavily biased towards OpenSSL because it’s the most widely used cross-platform toolkit. A lot of the links and hints are toolkit-agnostic though.

User Pitfalls

Tin Foil/Out of Your Control

Your computer and phone trust certificate authorities you probably wouldn’t choose to trust yourself. There isn’t much you can do.

We have a rich history of fatal trust incidents.

Some of the trusted root certificates aren’t even actively used. In other words they aren’t useful and just raise the risk of abuse.

Microsoft’s TLS will call home if it can’t verify a certificate to double-check.

Servers

Clients

VERIFY ALL THE THINGS.

Trust DBs

SSL_CTX_set_default_verify_paths will load root certificates from paths specified via environment variables or compiled in default paths. Completely undocumented but this mailing list thread is enlightening.

will load root certificates from paths specified via environment variables or compiled in default paths. Completely undocumented but this mailing list thread is enlightening. Christian Heimes wrote a nice summary of platform-specific trust DBs for OpenSSL in a preparation for a PEP (that probably won’t happen in that form).

OS X’s default OpenSSL is not only hopelessly outdated (0.9.8y as of OS X 10.9.2) but also contains a few hacks that make its verification practices a bit unpredictable. But in the common case it will do exactly what you expect it to do: verify according to the system keychain.

Homebrew’s OpenSSL clones the root certificates from the system keyring on installation and makes SSL_CTX_set_default_verify_paths work.

work. For Windows you’ll need something like wincertstore for Python.

If you’re afraid of rogue CAs, you may want to consider to employ certificate pinning.

Hostnames/Services

Test your settings. How’s My SSL? offers a handy JSON endpoint if you’re writing an HTTPS client.

Python

Common TLS-Related Problems & Attacks

Man-in-the-middle (MITM) attacks are trivial on public networks. A rogue DHCP server or some DNS poisoning at your favorite hipster coffee shop is all it takes.

But your traffic can be hijacked even if you’re at home.

You have always to assume that all of your users can be exposed to everything you offer as compatibility fallbacks due to downgrade attacks.

Insecure Renegotiation should be widely fixed server-side.

Mixed content is dangerous.

Revocation checks are useless.

Some Popular Attacks

Follow These

If you want to stay up to date with all matters TLS, it’s not enough to wait until it hits the major news sources. Here’s a completely incomplete list of sources I’d suggest to tap.

People

Mailing Lists and Newsletters

Books & Courses

Cryptography

TLS

It’s sad, but SSL and TLS: Designing and Building Secure Systems from 2000 is hands down the best resource on the TLS protocol. It lacks TLS 1.1 and 1.2 and the more recent attacks for obvious reasons but is still incredibly throughout and useful.

Ignore their performance advice though.

TLS Deployments

Ivan Ristić of Qualys-fame is writing a book called Bulletproof SSL/TLS and PKI which is in parts already available for early access.

I bought it and can highly recommend it.

His previous work that’s slightly overlapping are the OpenSSL Cookbook and SSL/TLS Deployment Best Practices.

Talks

Cryptography is a systems problem (or) ‘Should we deploy TLS’, an excellent talk by Matt Green at the Dartmouth college. Includes a demo of how broken RC4 is around 0:30.

Got SSL? slides including notes from the November 2013 Chrome Dev Summit. As expected very HTTPS-biased but has nice details.

Acknowledgements

I’d like to thank Laurens Van Houtven who kindly reviewed my crypto claims so I don’t tell you complete bollocks. You should hire him if you need someone who’s actually competent in all things crypto.