SSL 3 is broken. RC4 is broken. Diffie-Hellman is broken. SHA-1 is all but broken. And millions of servers on the Internet are still supporting these protocols and algorithms. If the Internet hasn't broken down already, it will any time now.
Or will it?
This presentation aims to give the audience a more nuanced view. In non-technical terms, it will explain not only the details of some major vulnerabilities and how they could be exploited, but also look at how likely such exploits are in practice.
It will explicitly not give the audience an excuse not to deploy the best cryptographic protocols available, but it will help them understand what to consider when a choice has to be made between supporting weaker protocols and making services unavailable to people with older devices. It will also help understand that crypto, despite its apparent flaws, rarely ever is the weakest link in a secure system.
14. Computing public keys
Using the “group mechanism” Alice computes ga
and shares this with Bob.
Bob computes gb
and shares this with Alice.
ga
gb
15. Generating the secret key
● Alice combines a and gb
to compute (gb
)a
.
● Bob combines b and ga
to compute (ga
)b
.
● Mathematics is kind to us:
(gb
)a
= (ga
)b
● This is the secret key they will use.
● The key is broken if Eve can compute a from
g and ga
(or b from g and gb
).
16. Nothing is impossible!
● Like most cryptographic algorithms, Diffie-
Hellman can be broken. It is just very expensive
to do so.
● Breaking 1024-bit Diffie-Hellman costs about
$100m.
● No one will ever pay that to crack a single
key!
17. How would such an attack work?
● The expensive part is typical only to the group g.
● Only a small and cheap part is specific to the
numbers ga
and gb
.
● It would be really bad if many Alices and Bobs
used the same group g.
18. Guess what?
● Many Alices and Bobs do indeed use same
group g: e.g. some HTTPS, VPN
implementations.
● For $100m worth of “preparations” you can crack
all these implementations at once, in (near) real-
time.
● This is the LogJam attack.
● It is believed that this is how the NSA has broken
many VPN connections.
19. Is Diffie-Hellman broken?
● The Diffie-Hellman protocol has not been
broken.
● 2048-bit Diffie-Hellman is very secure.
● 1024-bit Diffie-Hellman with a unique g is also
secure in practice (but it's best avoided).
22. Make the plaintext a little nicer
● Add a MAC to “avoid tampering”.
● Add padding to fill up final block.
23. Padding
? ? ? ? 4
Size of the rest
of the padding
Anything will do
24. In HTTP, Eve has a lot of control
● Eve can make sure padding fills the final block.
● And also replace that block by a previous block.
25. Bob doesn't suspect anything
? ? ? ? ????
● Bob's decryption attempt is “successful” if the
final byte is “correct”.
● This happens one in every 256 times.
● If Bob's attempt fails, he'll tell Alice (which Eve
hears) and Eve tries again.
● If he succeeds, Eve can compute one byte of
plaintext.
26. HTTP(S) requests are predictable
POST /xxxx HTTP/1.1
Host: target.website
Cookie: ??????????
xxxxxxxxx
Eve can force this to
vary to ensure the
padding fills the last
block…
…and for this to be
the final byte of a
block.
And thus “construct”
the cookie byte by
byte.
27. The POODLE attack against SSLv3
● Makes it easy for Eve to crack a session cookie
(under reasonable conditions).
● Does require HTTPS; doesn't work against
SMTP, FTP etc.
● Does not allow Eve to decrypt full requests, or
any part of the response.
● There are often mitigations against session
hijacks in place.
28. And there's (NO)MORE
NOMORE attack against RC4
● Stream cipher rather than block cipher.
● RC4 is “too good to be true”.
● Known to be (somewhat) bad for years.
● Best known attack (“NOMORE”) takes ~75 hours
and still only gives you session cookie.
29. DROWING in vulnerabilities
The DROWN attack against SSLv2
● Uses clever maths (“Bleichenbacher attack”) to
crack RSA private key.
● This key is often shared between weaker and
stronger servers.
● In worst/best case scenario, it is very cheap –
but still doesn't scale well.
● Most of the problems have to do with openssl
issues.
30. Preliminary conclusion
● Diffie-Hellman is safe, but beware of key sizes.
● Avoid SSLv3 for HTTPS.
● RC4 in general isn't broken in practice, but there
are better alternatives.
● Don't support SSLv2. Not even under the
counter.
32. Bob authenticates to Alice
● He signs something with the a private key,
corresponding to the public key in his certificate.
● His certificate is signed with a private key,
corresponding to the public key in another
certificate.
● This certificate is signed with a private key,
corresponding to the public key in a certificate
Alice already has.
35. Cryptographic hashes
One-way encryption: turns an arbitrary sequence
of bytes into a fixed-length block that gives no
information about the original.
Examples: MD5, SHA-1, SHA-256 etc.
sha-1("hello world") = 2aae6c35c94fcfb415dbe95f408b9ce91ee846ed
sha-1("Hello world") = 7b502c3a1f48c8609ae212cdfb639dee39673f5e
36. What could go wrong?
Information on certificate
Information on signer
Public key
Signature
hash
If Eve could
forge a
certificate with
the very same
hash as that of
Bob’s, she
could add the
signature of
Bob’s certificate
and
authenticate as
Bob.
37. From easy to difficult
● Find a hash collision for a weaker form of SHA-1
(“free start collision”).
● Find two blocks with the same SHA-1 hash
(“collision”).
● Find an arbitrary block of bytes with SHA-1 hash
value equal to that of another block.
● Find a certificate with the same SHA-1 hash as a
given certificate. What Eve wants
Where we are now
SHA-1 broken
38. Why the panic?
“The presented
attack does not yet
threaten practical
applications of
MD5, but it comes
rather close”.
Dobbertin, 1996. “We know, we know” Flame malware, 2012
A brief history of MD5
39. Breaking up with SHA-1 is hard to do
● Certificates often last for many years; we can't
just stop accepting those using SHA-1.
● Upgrading your certificates won't prevent
people from impersonating you!
● Phasing out will last years; it has already hurt
people.
● Flame-like attacks have been mitigated.
41. Why bother?
● Attacks only get better, they never get worse.
● I may be wrong!
● It shows that you care.
42. But please remember
A cryptographic protocol is unlikely to be the
weakest link in your organisation!
43. When is it OK to use weak crypto?
● If the alternative is worse.
● And you understand the attacks.
● You can respond to new threats quickly.
Example: Google supporting SSLv3 on its mail
servers for encrypted SMTP.
