Can SSL and TOR be intercepted? Secure Socket Layer.

Can SSL and TOR be intercepted?

Secure Socket Layer

De-facto standard to encrypt

communications

Can ensure the identity of the peer

Prerequisite to decrypt a communication:

You have to monitor it!

Most of the SSL attacks are MITM-based

Physically in the middle

Rogue AP, ISP, etc.

Logically in the middle

Take a look at our 2003 BlackHat presentation…

Ok but…can SSL be intercepted?

Three attacks’ categories

Protocol design and math

Chain of trust

The User

Let’s start with…

Protocol design and math

Weak encryption can be easily cracked

Protocol and algorithms are negotiated during the handshake

This “attack” can be performed passively

Weak encryption can be easily cracked

~70%* of the Internet uses only “strong” encryption

What’s “weak” and what’s “easy”? Ask the NSA…

* Trustworthy Internet Movement 2014/10/3 on 151.509 web sites

SSLv2 Downgrade Attack

No integrity check on the handshake

Weaker encryption algorithms can be forced

SSLv2 Downgrade Attack

SSLv2 disabled by default on most systems

SSLv3 is vulnerable as well…

POODLE attack (September 2014)

could be used to decrypt HTTPS cookies

SSLv3 is vulnerable as well…

Most browsers dismissed SSLv3

Providers are going to dismiss it as well

Protocol version Website Support

SSL 2.0 19.4%

SSL 3.0 98.0%

TLS 1.0 99.3%

TLS 1.1 42.0%

TLS 1.2 44.3%

Website coverage

TLS Logjam attack

Published on May 2015

Forces TLS connection with weak key

TLS Logjam attack

Vendors are patching

Implementation-specific attacks

OpenSSL "Heartbleed" (CVE-2014-0160)

Oracle Java JSSE (CVE-2014-6593)

OpenSSL "Freak" (CVE-2015-0204)

And many others...

Implementation-specific attacks

Keep your system up to date!

Google’s Nogotofail tests connections for known bugs and weak configurations

Chain of Trust

If you have the private key you can see the traffic!

Very hard to detect

This “attack” can be performed passively if no PFS is used

If you have the private key you can see the traffic!

Don’t give your private key to anyone ;)

Forward Secrecy available on almost 40% of the websites

Custom CA on the client device

Often used by AVs to inspect traffic

Sometimes used by vendors to insert Ads

Custom CA on the client device

Don’t install untrusted CA certificates

Keep your OS/AV up to date

Rogue CA

A malicious CA can sign fake certificates

CAs’ certificates were stolen in the past (eg: Diginotar 2011)

Allows any “active” probe to impersonate any website

Rogue CA

Public Key Pinning

EFF SSL Observatory monitors trusted CAs

Google and Facebook actively search for rogue CAs

Rogue CA

In December 2013 0.2% of all connections to Facebook were established with forged certificates

In 2014 Google found evidence from France and India of certificates signed by rogue Cas

In 2015 Google removed all China NIC and EV CAs from their products

Future alternatives to the Chain of Trust

Trust Assertion for Certificate Keys

DNS-based Authentication of Named Entities

The User

SSL Strip attack

Intercept the “redirect to HTTPS” reply

HTTP-to-HTTPS Proxy for the whole communication

Replace HTTPS with HTTP in any link

SSL Strip attack

Pay attention to the “lock”

Servers using HSTS can force HTTPS on the clients

HTTPS Everywhere plugin doesn’t allow HTTP connections

Mozilla pushes for full HTTPS