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 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 recently published (September 2014) Can be used to decrypt HTTPS cookies TLS-to-SSLv3 fallback can be forced

SSLv3 is vulnerable as well… TLS_FALLBACK_SCSV mitigated fallback attack (Chrome, Opera) Browsers are going to dismiss SSLv3 (e.g.: Firefox34, Chrome40) Providers are going to dismiss SSLv3 (Facebook, Google, etc.)

SSL 2.0SSL 3.0TLS 1.0TLS 1.1TLS 1.2 Internet Explorer * Disabled Enabled Chrome 39DisabledEnabled Mozilla Firefox 33DisabledEnabled Opera 25DisabledEnabled Safari 8DisabledEnabled Browser coverage * Microsoft released a patch to disable SSL 3.0 on all versions of Internet Explorer

Protocol versionWebsite Support SSL % SSL % TLS % TLS % TLS % Website coverage

Implementation-specific attacks OpenSSL MITM attack (CVE ) OpenSSL Heartbleed (CVE ) And many others...

Implementation-specific attacks Keep your OpenSSL up to date! 95% of the Internet runs updated OpenSSL versions 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 Heartbleed attack could be used to get the key from the server

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 Heartbleed vulnerable sites are now close to 0%

Custom CA on the client device Often used by AVs to inspect traffic

Custom CA on the client device Don’t install untrusted CA certificates

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 (Chrome, Firefox) EFF SSL Observatory monitors trusted CAs Google and Facebook actively searched for rogue CAs

Rogue CA In December % 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 (government surveillance?)

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

The Onion Router

De-facto standard to browse and publish content anonymously Less used alternatives are less anonymous (e.g.: I2P)

“Relay Early” Attack Aimed at monitoring clients and publishers of hidden services

“Relay Early” Attack Used malicious Entry Guard and HSDir nodes Sybil attack to gain reputation Traffic Confirmation attack to link the HS and the client IP address

“Relay Early” Attack Malicious nodes joined the network in January 2014 The attack was identified and blocked in July 2014 The author and the real impact are both still unknown

“Relay Early” Attack Presumably described in a BlackHat 2014 speech by Carnegie Mellon University researchers… …that was presumably blocked by some US agency* * any correlation with the takedown of Silk Road 2.0? ;)

“Relay Early” Attack This is just one of the possible attacks that involve controlling at least two nodes in a TOR circuit: Entry Guard & Exit Node Entry Guard & Rendezvous Point

“Relay Early” Attack The protocol has been patched to prevent this specific attack Similar attacks, based on statistical traffic analysis, can be mitigated but not prevented

The Snowden Affair NSA presumably uses several technologies targeting TOR Quantum, FoxAcid, etc.

The Snowden Affair TOR Client Exit Node Entry Guar d Quantum Website TOR Client Malicious Exit Node Entry Guar d Website

The Snowden Affair QuantumCookie injects malicious cookies to track targets’ browsing QuantumInsert inserts malicious code to exploit vulnerabilities inside the TOR browser

Executing arbitrary code allows complete target monitoring

Wanna see it in action? Come to our presentation this afternoon* *it could be not as cool as the NSA one ;)

Intruding personal devices with Remote Control System Ballroom A 13:30