TLS

The most important cryptographic protocol on the Internet

Who am I?

Hanno Böck

Freelance journalist (Golem.de, Zeit Online, taz, LWN)

Find and fix security vulnerabilities and bugs in free software (Fuzzing Project, supported by Linux Foundation's Core Infrastructure Initiative)

Monthly Bulletproof TLS Newsletter

Transport Layer Security

Can be put on to of formerly insecure protocols

Provides secrecy and authenticity

Example: HTTP + TLS = HTTPS

We use TLS all the time

SSL versus TLS

1994: SSL v2

1995: SSL v3

1999: TLS v1.0

2006: TLS v1.1

2008: TLS v1.2

Soon: TLS v1.3

SSL is just the old name of TLS

Protocol bugs

BEAST-attack (2011)

Followed by CRIME (2012), BREACH (2013), Lucky Thirteen (2013), RC4 attacks (2013), Triple Handshake (2014), POODLE (2014), Logjam (2015), SLOTH (2016), DROWN (2016)

Known weaknesses

BEAST (2011) - Bard (2004)

Lucky Thirteen (2013) - Vaudenay (2002)

RC4 attacks (2013) - Fluhrer, Mantin, Shamir (2001)

SLOTH (2016) - Dobbertin (1996), Wang et al (2004, 2005)

DROWN (2016) - Bleichenbacher (1998)

Heartbleed

The first TLS bug that made international headlines.

Heartbleed was not a protocol bug, it was a faulty software implementation.

Heartbleed was a wakeup call

Software projects that are crucial to a functioning Internet had very little support from the Industry.

Core Infrastructure Initiative was formed.

Implementation bugs

Goto fail (Apple, 2014),BERserk (Mozilla NSS, 2014), MS14-066 (Microsoft Schannel, 2014) SChannel, FREAK (Microsoft / OpenSSL, 2015)

Legacy of the cryptowars

1990s: Export controls caused creation of weak "export" cipher modes with very short keys

This still causes trouble: FREAK (2015), Logjam (2015), DROWN (2016)

TLS matters

HTTPS by default

Push from some large players (Google, Mozilla).

New and powerful features require HTTPS (HTTP2, Brotli compression, access to camera, microphone or geolocation).

HTTPS by default - how?

Redirect all HTTP requests to HTTPS.

Addition: HSTS (HTTP Strict Transport Security).

HTTPS - pushback

Not everyone agrees that we should move to HTTPS.

Counterarguments are largely either outdated or based on misunderstandings or myths.

HTTPS is more than encryption

TLS guarantees secrecy and authenticity.

You may not always want to keep your transmitted data secret, but you always want it to be correct.

HTTPS myth: It's enough to encrypt the login

"Our webpage is HTTP, but if you log in the data will be transmitted securely over HTTPS."

Only login encrypted

This is *not* secure!

Attacker can manipulate form (SSL Stripping, Marlinspike 2009).

HTTPS myth: Too slow

People often largely overestimate the computational costs of encryption.

In January this year (2010), Gmail switched to using HTTPS for everything by default. [...] In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers [...] will help to dispel that. (Adam Langley, Google)