1. Good morning ladies and gentlmen
Good morning ladies and gentlmen. Today we are presenting about a very hot topic
Recently we read on the news, both technical and mainstream, how hackers, criminals and governments as well have been using and abusing two of the pillars of the online secure communication
Their goals and motivations are obviously divergent and the real impact of their actions is still often «blurred»
Today we’ll present a case history of attacks, their alleged actors, adn the state of the art about corresponding countermeasures, trying to shed some light on the question everybody is wondering about: 1

2. Can SSL and TOR be intercepted?2

3. Secure Socket Layer
Since the two topics are rather complex we’ll discuss them sepàrately. Let’s start with: 3

4. De-facto standard to encrypt communications
Can ensure the identity of the peer
SSL or TLS in its newest versions is the defacto standard for encrypting internet connections: not only facebook and gmail, but also banks, insurances and governments as well rely upon it.
Its diffusions is mainly due to its peculiarities: public key cryptography, digital certificaes and Certification authorities grant not only strong encryption but also unambiguous peer identification. 4

5. Prerequisite to decrypt a communication: You have to monitor it!
Before starting the attack showcase let’s make a step back. It may sound obvious but if you want to eavesdrop an encrypted communication you have to be able to monitor it at the very least.
This kind of attack is commonly known as «passive interception» 5

6. Most of the SSL attacks are MITM-based
But, most of the attacks aimed to decrypt SSL require a further step: the attacker must be able to actively modify the communication (in a somewhat transparent way).Such attack category is commonly known as «man in the middle attacks» 6

7. Physically in the middle
Rogue AP, ISP, etc.
There are several ways to be «in the middle».
The first and more obvious is to be physically in the middle
In a tactical way, for instance pretending to be a fake wifi Access Point (tomorrow we’ll demo an attack of this kind)
Or in a strategical way, placing a probe within the ISP 7

8. Logically in the middle
Take a look at our 2003 BlackHat presentation…
If being physically in the middle is not a viable scenario, you can try to obtain the «in the middle» position logically.
There are several tools that by mangling routing protocols can reach this goal, but it’s out of scope for this presentation.
If you want to know more take a look to our 2003 BlackHat presentation. Even if it’s a bit dated it’s still quite useful
Furthermore, if you want to get your hands dirty give a try to a tool we wrote few years ago called ettercap 8

9. Ok but…can SSL be intercepted?
Ok we autocelebrated ourselves enough. Back to the main question
Generally speaking SSL ecosystem (consisting in protocol, certificates, Cas) is well designed
By the way there are few weak spots that can be attacked, resulting in a variety of attacks 9

10. Three attacks’ categories
We identified 3 main attacks’ categories, targeting 3 different weak spots 10

11. Protocol design and math Chain of trust The User
The protcol itslef and the math behind it
The global infrastructure that assigns and verifies digital certificates
And the weakest link of the chain: the fool, sorry, the user 11

12. Let’s start with…

13. Protocol design and math

14. Weak encryption can be easily cracked
Protocol and algorithms are negotiated during the handshake
This “attack” can be performed passively
First of all: Weak encryption can be easily cracked
Probably the most intuitive attack: since algorithms and keys for encryption are negotiated dynamically during the handshake.
If you use weak keys or algorithms an attacker can decrypt, in a totally passive way, the traffic by using a simple cryptoanalytic brute force attack. 14

15. 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
Luckily almost seventy percent of the encrypted internet traffic relies upon strong encryption.
This percentage reaches almost one hundred percent if we consider big players only.
By the way it’s not easy to tell which algorìthm or key length can be considered strong enough. If you ask this question to a microsoft developer of the nineties and to a NSA agent today maybe you’ll get different opinions
As a side note: almost all the percèntages in this presentation are taken from a 2014 census by the Trustworthy Internet Movement that analyzed almost one hunderd fifty thousands websites
This kind of attack is valid against any version of the protocol. Let’s now move to version specific attacks 15

16. SSLv2 Downgrade Attack No integrity check on the handshake
Weaker encryption algorithms can be forced
Let’s start with the very old version 2.
This version had no integrity check on the handshake. It means that an attacker could modify it and force an encryption algorythm of her choice and then leverage the attack discussed earlier. 16

17. SSLv2 Downgrade Attack SSLv2 disabled by default on most systems
Luckily, int he modern age nobody uses SSLv2 anymore! 17

18. SSLv3 is vulnerable as well…
POODLE attack (September 2014)
could be used to decrypt HTTPS cookies
Few months ago it turned out that SSLv3 as well was vulnerable by-design to several attacks:
The latest was discovered in last September by google engineers
Such attack allowed the decryption of HTTPS cookies given a target website 18

19. SSLv3 is vulnerable as well…
Most browsers dismissed SSLv3
Providers are going to dismiss it as well
By the way most browsers and the biggest content providers dismissed (or are going to dismiss) SSLv3… 19

20. 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
...and as you can see most of the secured contents available on the internet can be accessed using TLS1.0 , which is considered reasonably secure. 20

21. Implementation-specific attacks
OpenSSL "Heartbleed" (CVE )
Oracle Java JSSE (CVE )
OpenSSL "Freak" (CVE )
And many others...
Concluding the list of the protocol-related attacks we have to mention few of them that are not strictly related to the design of the procol but rather to a bad implementation
We go from forcing no encyption at all to reading the server memory remotely
Pretty scary isn’t it?
And that’s why some of these vulnerability, recently, received a very significant media coverage (even if in some cases such coverage was not proportional to the real world impact of the vulnerability)
On purpose we omit to discuss code execution attacks (like sslmageddon) since they are out of the scope of this presentation 21

22. Implementation-specific attacks
Keep your system up to date!
Google’s Nogotofail tests connections for known bugs and weak configurations
The best approach to protect against such attacks is to keep your system up to date
And in order to help sys admins and regular users in cheking the encryption status of their communications, Google released a tool called Nogotofail that, by monitoring the network traffic, tests all the connections for known bugs and weak configurations 22

23. Chain of Trust Let’s now move to the second weak spot: Chain of Trust
By Chain of Trust we mean the whole infastructure in charge of creating, distributing, verifying and revoking digital certificate, from the root CA straight to the browser on your very laptop.
Pleas note that most of the SSL interception appliances works by exploiting this weak spot. 23

24. 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
It may sound obivious but: If you have the private key you can see the traffic!
Practically impossible to detect by the endpoints and, unless some specific technique is used (such as Perfect Forward Secrecy)
this attack can be performed in a totally passive way and in a retroactive way as well: a stolen key could be used to decrypt a pre-recorded network dumps.
There have been few methods to «steal» a key such as the well known Heartbleed attack. 24

25. 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
Luckily as of today none of these methods work anymore
As a consquence attackers are left with two options: either they can steal the key (in a traditional way) or they can have a very hard time trying to bruteforce it 25

26. Custom CA on the client device
Often used by AVs to inspect traffic
Sometimes used by vendors to insert Ads
Another problem consists in having custom CAs installed on the client devices.
Each device, in order to verify a digital certificate, must have a list of known and trusted CA.
Inserting a malicious CA could break the whole chain of trust, allowing an attacker to impersonate any website of choice.
Unfortunately it could be difficult to identify an attack like this because this technique is often used for legitimate reasons by enterprise AV appliances, that inspect encrypted communications to search for viruses and spyware.
Sometimes this technique is also used by vendors to insert advertisements into web browsing:
recently Lenovo was caught deploying the same CA certificate (and related private key) on its laptops, technically allowing an attacker to perform MITM attacks in the wild against any Lenovo customer. 26

27. Custom CA on the client device
Don’t install untrusted CA certificates
Keep your OS/AV up to date
For this reason, install a custom CA on your device only if you are really aware of what you are doing!
Moreover keep your OS and AV up to date to let them remove unwanted or malicious certificates or bugged software (once spotted). 27

28. 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
Quite likely, at this point of the presentation you should have been asking yourself: who guarantees that a CA (the pillar of the chain of trust) is really trusted?
Thinkn about it: a malicious CA (either root or intermediate) could actually monitor all the encrypted traffic in internet.
The same concept applies if someone was able to steal a CA’s private key: This is VERY scary isn’t it? And guess what, it happened in the past! 28

29. Rogue CA Public Key Pinning EFF SSL Observatory monitors trusted CAs
Google and Facebook actively search for rogue CAs
There are few woarkarounds that permit to mitigate this kind of risk (such as Public Key Pinning, a feature supported by Chrome and Firefox)
Furthermore, internet’s big players are constantly and actively searching for malicious CA certificates in the wild, to have them revoked. 29

30. 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
And what they found out?
In December % of all connections to Facebook were established with forged certificates
Such percentage may not seem a lot, but try to consider how many connections facebook receives in a month!
And
In 2014 Google found evidence from France and India of certificates signed by rogue Cas. Is that some sort of govèrnmental surveillance? 30

31. Future alternatives to the Chain of Trust
Trust Assertion for Certificate Keys
DNS-based Authentication of Named Entities
As you can see the chain of trust is not perfect.
Some alternative infrastructures are currently under development but it may take a while for average users to use it as the default option (think about IPv6) 31

32. The User
Last but not the least, the weakest link in the chain: the user 32

33. SSL Strip attack Intercept the “redirect to HTTPS” reply
HTTP-to-HTTPS Proxy for the whole communication
Replace HTTPS with HTTP in any link
The typical attack against the user works like this: the attacker force the target to send sensible data (which were meant to be sent encrypted) in cleartext.
The attacker then proxies the whole communication actively removing any occurence of HTTPS links. 33

34. 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
There are few technologies, both client and server-side (such as HSTS) that mitigates this attack by forcing HTTPS.
By the way, the best protection in this case is to pay attention to the lock icon in the address bar while accessing secured websites!!!!! 34

35. The Onion Router
Well, first part is over and the clock is ticking very fast, so let’s move straight to the second topic
As you can see, during its first 20 years of life, SSL resisted against several attacks.
TOR, which stands for The Onion Router, even if younger (it’s barely a teen ager), is no less. 35

36. De-facto standard to browse and publish content anonymously
Less used alternatives are less anonymous (e.g.: I2P)
TOR is the most used tool for browsing and publishing contents on the internet in an anonymous way and can be used for licit means such as fighting censorship or whistle blowing.
By the way it is used the most for obviously illegal activities: drug dealing, money loundering, pedopornography and so on.
There are few alternatives like the peer-to-peer-based I2P, the one used by the new SilkRoad, but so far they are not so widespread. 36

37. “Relay Early” Attack
Aimed at monitoring clients and publishers of hidden services
There is a quite long history of more or less theoretical attacks aimed at deanonimyzing the TOR network
The latest example is the «relay early» attack
It was aimed at monitoring clients and publishers of hidden services, that are the building blocks of the so called Darknet. 37

38. “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
It has been carried on by introducing «malicious» nodes in the TOR network and using a technique called «traffic confirmation attack» 38

39. “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
Such malicious nodes were introduced in January 2014 and the attack was identified in July only
The author and the real impact are both still open topics 39

40. “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? ;)
But....
Last summer a speech regarding a very similar topic was scheduled during the well known BlackHat conference, in United States.
This speech was pulled away at the very last moment.
Any relationship with some US agency?
Any relationship with the SilkRoad2.0 takedown that took place in November 2014?
Who knows... 40

41. “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
This is just one of the possible attacks that involve controlling at least two nodes in a TOR circuit
Depending on the nodes under control, an attacker can reveal some elements of the communications that flow through them:
A HiddenService IP address, clients of a given website and so on 41

42. “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 protocol has been patched to prevent this specific attack (and other similar attacks)
By the way, low latency anonymizing networks like TOR are prone, by design, to fall victims of statistical traffic analysis.
This issue can be mitigated but not prevented at all.
Some researches claim that nearly 80% of the TOR traffic could have been deanonymized in this way, but there aren’t enough public data to draw precise conclusions. 42

43. The “Legal” Attack Russia wants to ban TOR
FBI is asking permission to persecute TOR users
Some countries are willing to fight TOR on legal basis
Russia aims to inhibit the use of any anonymizing tool like TOR
FBI wants to change Federal Rules in order to obtain a warrant to search for electronic data without providing any specific details as long as the target is using TOR or a VPN. 43

44. The Snowden Affair
NSA presumably uses several technologies targeting TOR Quantum, FoxAcid, etc.
Just in case we haven’t bothered US agencies enough, let’s talk a bit about Edward Snowden’s revelations.
Based on the documents released in 2013, the US used several technologies targeting TOR, such as Quantum and FoxAcid 44

45. The Snowden Affair
TOR Client
Entry Guard
Exit Node
Quantum
Website
TOR Client
Entry Guard
Malicious Exit Node
Website
More in details, the Quantum system is capable of modifying TOR clients
connections by eavesdropping the network in proximity (or above) TOR
exit nodes. 45

46. The Snowden Affair
QuantumCookie injected malicious cookies to track targets
QuantumInsert inserted malicious code to exploit vulnerabilities inside the TOR browser
By modifying the traffic, the Quantum system was not only able to track the users, but also to execute code on a client device by leveraging TOR browser vulnerabilities. 46

47. Executing arbitrary code allows complete target monitoring
It’s easy to understand how code execution allows a far more in depth monitoring than standard traffic analysis.
That’s exactly what our product allows to
So if you are curious to see 47

48. *it could be not as cool as the NSA one ;)
Wanna see it in action?
Come to our presentation this afternoon*
*it could be not as cool as the NSA one ;)
some NSA-like technology in action, come this afternoon to our live demonstration
even tough the name is not as cool as the NSA’s one ;) 48

49. Ballroom A 13:30 Intruding personal devices with Remote Control System49