0% found this document useful (0 votes)
148 views66 pages

SSL Tls and Their Attacks

This document provides an introduction to SSL/TLS and some of its vulnerabilities. It begins with an introduction of the presenter and their qualifications. It then discusses why SSL/TLS is important for securing communications and some of its history. Key points covered include SSL/TLS certificates, cipher suites, and vulnerabilities like Heartbleed, POODLE, BEAST, and DROWN attacks. The document aims to provide a high-level overview of SSL/TLS rather than technical details.

Uploaded by

Joseph Diallo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
148 views66 pages

SSL Tls and Their Attacks

This document provides an introduction to SSL/TLS and some of its vulnerabilities. It begins with an introduction of the presenter and their qualifications. It then discusses why SSL/TLS is important for securing communications and some of its history. Key points covered include SSL/TLS certificates, cipher suites, and vulnerabilities like Heartbleed, POODLE, BEAST, and DROWN attacks. The document aims to provide a high-level overview of SSL/TLS rather than technical details.

Uploaded by

Joseph Diallo
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 66

Introduction

to SSL/TLS &
Rian Saaty
Senior Cybersecurity
Consultant

Their Attacks
Who Am I?

´ Bachelor’s Degree in Computer Science from Duquesne University


´ Master’s Degree in Cybersecurity Engineering from Johns Hopkins University
´ Worked as a lecturer at King AbdulAziz University, FCIT
´ Worked as Cybersecurity Techniques Unit Manager at the IT Deanship at KAU
´ Currently a Penetration Testing & Vulnerability Assessment Consultant at one of the biggest
cybersecurity consulting firms in the Kingdom
´ Hold a number of top-notch industry certificates such as OSEP, OSCE, OSCP, GPEN, CRTE,
CRTO, GWAPT, GDAT, eCPTX, OSWP, etc.
Why Talk About SSL/TLS Now?

´ It doesn’t seem that people really understand what’s going on …


´ Does TLS make a website legit/secure 100%?
´ Is it about the lock?
´ Is it about the version? The ciphers?
It is WIDELY USED!

´ SSL/TLS is a widely used protocol, a vulnerability in it or in an application


that implements it WILL result in millions of websites exposed including the
big ones!
´ In 2014, when the HeartBleed vulnerability was discovered, a lot of major
websites such as Github, Amazon AWS, Reddit, Wikipedia, Yahoo, etc. were
vulnerable to it!
´ Some government entities temporarily shut down their servers!
´ More on HeartBleed later
Appetizers
SSL/TLS Certificates

´ Certificate Authority (CA): a trusted organization that verifies websites’ SSL/TLS


certificates.
´ Usually there are 2 types of certificates:
1- Self-Signed (You are the CA) – May be good enough. I.e. Google
2- Signed by a trusted CA - $$ (May be included with some CDNs I.e. Cloudflare)
´ If a website has a signed certificate that is valid, it doesn’t mean that the
website is NOT malicious!
´ If a website has a self-signed certificate, it does NOT mean that it is malicious!
Self-Singed Certificate Example
Imagine a CA compromised

´ We trust CAs
´ If they were compromised, we will STILL trust them until we revoke the
certificate!
´ We can sign as the CA and users will TRUST us!
´ This happened in 2011 with a CA called, DigiNotar, who got bankrupt in
weeks after the incident.
SSL/TLS

´ Used to encrypt/secure reliable protocols such as?


´ Does not require pre-shared keys (Public Key)
´ The talk will NOT go deep into SSL/TLS rather it will be an intro to it & to some
of the critical vulnerabilities in it.
Why Do We Use TLS/SSL?

´ Let’s consider that we don’t have it …


Threat Models

Passive Adversary
Threat Models

Active Adversary
In Other Words …
SSL/TLS History

´ SSLv1 born at Netscape. Never released (insecure). (~1994)


´ SSLv2 released one year later (Had a lot of problems … i.e. export keys)
´ SSLv3 (1996) (less flaws but still a huge security risk)
´ TLS 1.0 (1998) (name was changed because of Microsoft)
´ TLS 1.1 (2006)
´ TLS 1.2 (2008)
´ TLS 1.3 (2018)
SSL/TLS

´ VERY flexible protocol (good and bad)


´ So many options!
´ Backwards compatibility (TLS1.0 >SSLv3 > SSLv2)
SSL/TLS: Negotiation

This is called client hello


This is called server hello

Negotiate Capabilities

I choose TLS 1.0 I speak SSLv3 & TLS 1.0


I choose cipher suite X I support cipher suites X, Y
Cipher Suites

´ Consists of:
1. Key Agreement Protocol (I.e. RSA, DH, Elliptic Curve)
2. Symmetric Encryption Protocol (AES)
3. HASH Function
´ KA_SE_Hash
SSL/TLS: Certificate Exchange

Exchanging Certificate

Sends a certificate:
{PK, example.com, expiration
date, signed by PK}
SSL/TLS: Certificate Exchange
SSL/TLS: Session Key Establishment

Session Key Establishment

Here is our new master secret key


SSL/TLS: Change Cipher Spec

Let’s begin secure communication

Note: in this step, they list and use the ciphersuites that they chose earlier
SSL/TLS: Secure Communication

Encrypted Handshake
Attacks on SSLv2

´ Many issues …
´ Major vulnerabilities:
´ Ciphersuite list that is sent from the client to the server was NOT authenticated
´ Active attacker could modify the message to specify export-weakened
ciphers [will talk about it in the next slide] or even Null!
´ RSA_NULL_NULL
Negotiate Capabilities

I only speak Null


Cipher and SSLv2!
Ok … we can do that I I speak TLS 1.0
guess … I support cipher suites X, Y
Active Adversary
Export Keys

´ 40-bit ciphers
´ In 2004, a home computer can break it in
under 2 weeks
´ With dedicated hardware, it can be
broken in seconds!

Deepcrack (1998)
Browsers No Longer Support Export
Ciphers
´ In 2015, a statistic proved that about 30% of the servers in the wild still use
export ciphersuites!
´ Modern browsers no longer support export ciphers today.
´ However, we can still use curl and wget ^_^
SSLv2 Deprecation

´ SSLv2 was deprecated in 2011


SSLv3

´ All of the problems of SSLv2 has been fixed!


´ The communication message between the client and server is now
authenticated using a MAC (Message Authentication Code) so attackers
can’t change it!
´ However, the “change cipher spec” message is NOT included in the MAC!
´ This means that the attacker can now read your traffic because he CAN
change the ciphers AGAIN!
Version Rollback

´ The release of SSLv3 didn’t make SSLv2 browsers go away immediately


´ Servers still accepted SSLv2 requests
´ Attacker could specify SSLv2 and actually perform SSLv2 Attacks on SSLv3
Traffic Analysis:SSLv3

´ With the request, an attacker can see the size of the HTTP request.
´ This may allow him to “guess” things such as:
´ The file the user downloaded via its size
´ The visited URL
´ This is even worse in VoIP! Why?
´ Silence !
´ How is this fixed?
SSLv3: Weak Ciphers All the WAY!

´ SSLv3 and below only supported cipher suites that were affected by
POODLE (Padding Oracle Attack)
´ The only cipher that wasn’t affected was RC4, which leaks information!
´ As a result, SSLv3 was deprecated in 2015
HTTP > HTTPS

´ How do you visit Google?

This will be an HTTP request on port 80


Google.com

Redirects the user to https://google.com

https://google.com
This will be an HTTPS request on port 443

What’s the problem here?


HSTS (HTTP Strict Transport Security)

´ IF it is enabled at that server, and your browser has already contacted the
server before using a secure communication, it will NEVER send an HTTP
request to that server!
´ Basically, what it does is that it will PIN this website to ALWAYS use HTTPS
´ Downside?
´ Trust on first use
Chrome HSTS
Chrome has a list of websites that it
will always connect to via HTTPS
Deterministic Encryption

m1 m2 m3 m4 m5 m6

´ Enc(plaintext message,key):

c1 c2 c3 c4 c5 c6
Issue of Using Deterministic Encryption

A B A padding padding padding

Enc(plaintext message,key):

? ? ? ? ? ?
Issue of Using Deterministic Encryption
Semantic Security

´ An encryption algorithm is secure if an attacker who


sees the ciphertext learns as much as an attacker who
does NOT see the ciphertext
´ Even if an attacker can request a chosen plaintext.
´ Think about cards (alphabits, cards, etc.)
Solution to the Earlier Problem?

´ Randomization through an Initialization Vector (IV)


´ Different IV in each block
´ CBC Mode for example
Cipher Block Chaining (CBC) Mode
Padding Oracle Attack (POODLE)

´ Allows an attacker to decrypt the data without knowing the encryption key
´ Only works when the application returns different responses to deciphering
messages. I.e. valid or invalid padding/mac.
´ Assuming that an attacker was able to capture the ciphertext & the
destination returns a meaningful message when the padding is wrong.
´ 256 unique ASCII characters.
´ Basically, we need to loop from 0-255 for every byte at the end of the
ciphertext until the oracle says the padding is correct. Once it is correct, we
move on to the next character and so on. Then byte by byte the plaintext
will be revealed.
´ SSLv3 was vulnerable to POODLE
Padding Oracle Attack Testing

Alternatively, you can Use Metasploit’s : auxiliary/scanner/http/ssl_version


SSL’s Solution for the Problem?

´ Removed the messages instead of solving the main issue


´ What can go wrong?
´ TIME!
Best Solution?

´ Use a different mode of operation


´ Otherwise, display a generic message with a delay
´ Even better, implement encrypt THEN MAC. This will result in the ciphertext
being dropped if it was tampered with EVEN with CBC mode.
TLS 1.0

´ Allows for downgrading the connection into SSLv3, which also downgrades
to SSLv2 …
´ Vulnerable to BEAST and DROWN Attack, which will be explained soon
Drown Attack

´ Mainly touches SSLv2


´ However, due to the compatibility “feature” some TLS1.0 was vulnerable!
´ Requires SSLv2 to exist in the server side!
´ Discovered in 2016
´ At the time of the discovery, 33% of the webservers were vulnerable.
´ In 2019, it seems that 1.2% of all webservers are still vulnerable.
DROWN Attack

Picture credit & demo can be seen here: https://www.youtube.com/watch?v=qkc0ZUvWSYo


BEAST Attack

´ An Active MITM attacker can predict the IV, therefore, making the result of
the encryption deterministic.
´ Technically, an attacker can’t decrypt any data, however, he can find out
if his guessing is right or wrong.
´ With enough guessing, any data can be recovered!
´ The only way to prevent BEAST attack from the server side is to enable RC4.
´ However, RC4 is worse!
´ This makes enabling TLS 1.0 a bad idea as well
Beast Attack Risk

´ Guessing is not “really” efficient.


´ ALL browsers addressed it using a
technique called 1/n-1 split.
´ The first packet will be padded
with random data before being
combined with the initialization
vector.
´ The risk from Beast Attack is
actually LOW.
TLS 1.1

´ You can actually get away with TLS 1.1 with certain rules. In fact, Google still
uses TLS 1.1!
´ 1- you MUST disable all the insecure ciphersuites. This may or may not introduce
other problems (i.e. legacy systems)
´ 2- you must NOT have SSL v3.0 or SSLv2.0 enabled in your server.

´ The main issue here (including in TLS 1.2) is the ciphersuites selected!
´ Consider having NULL cipher in TLS 1.2, does that make your connection
secure?

´ Note: I’m NOT suggesting that you keep TLS 1.1, they are old already
Browsers Ended Support for TLS1.0 & TLS1.1 in
2020
Qualys SSLLabs Also Decreased the
Grade!
HeartBleed

´ OpenSSL is an application that implements TLS/SSL.


´ The majority of servers uses OpenSSL to enforce SSL/TLS.
´ HeartBleed was a vulnerability in the OpenSSL
cryptography library, not the TLS protocol itself!
´ The issue was introduced in 2012 and publicly disclosed in
2014.
´ Main reason: invalid validation of boundaries. This
vulnerability is called buffer over read.
´ In 2019, Shodan showed that there are still more than 90K
devices vulnerable to HeartBleed!
´ I actually saw it in an engagement last year!
HeartBleed

´ Basically, when you use OpenSSL, you are securing a socket between you
and the server.
´ A server can only accept and keep alive a number of sockets at the same
time.
´ It terminates a socket after a certain threshold if there is no more activities
and the client will have to renegotiate over and over again.
´ Hence, the “Heartbeat Extension” was introduced to avoid having the
renegotiation and provide a keep-alive functionality without continues
data transfer.
´ The Heartbeat can contain anything up to 64KB of data.
HeartBeat in Action (Normal Usage)

Sends 1KB, and says it is 1KB

Returns the same 1KB


HeartBeat in Action (Malicious Usage)

Sends 1KB, and says it is 64KB


HeartBeat in Action (Malicious Usage)
HeartBleed Exploitation
How to Check for
SSL/TLS Weaknesses?

´ A couple of ways to check the


SSL/TLS versions & the ciphersuites a
server is using.
´ The best tools/websites from my
opinion are the following:
´ Nmap NSE scripts
´ Testssl
´ Qualys SSL Labs (possible privacy
concerns?)
Nmap SSL Checker

´ We will be using 2 NSEs because one is simply not enough when it comes to
Nmap
´ For SSLv2, we will be using the following:
´ nmap -p 443 --script sslv2 TARGET
´ Sample output:

Note: this will ONLY work on


servers that support SSLv2 & it will
NOT check for other versions!
Nmap SSL/TLS
Checker
´ When it comes to SSLv3 and above, we
will be using a different NSE.
´ nmap -p 443 --script ssl-enum-ciphers
TARGET
´ An example of a websites that has the
best practice can be seen here:
Nmap SSL/TLS
Checker
´ What are the issues here?
TestSSL

´ Open-sourced Bash script


´ VERY powerful
´ You don’t need to switch
between 2 scripts like Nmap
´ Tests for supported
protocols & supported
ciphersuites that may cause
an issue
´ It checks the server
preference, HTTP headers,
and even SSL/TLS
vulnerabilities!
Qualys SSL Labs

´ A free website created by Qualys to test


the SSL/TLS strength of websites
´ It gives each website a rating from A+ to
F based on the strength of the supported
protocols & ciphersuites
´ It also gives detailed information about
what is weak exactly in the TLS/SSL your
server/website is using.
´ Keep in mind that this means that you
are using a CLOUD based website.
´ If you are not careful, even other people
can see your search query!
Qualys SSL Labs

´ The screenshot above was taken on


December 31st, 2019, showing
Google.com with grade A even with the
support of TLS 1.0 & TLS 1.1
´ The one below was taken on August 17th,
2021, showing Google with a grade of B
due to its support of TLS 1.0 & 1.1
´ You can see all the details about the
certificate (start & end date, issuers,
supported protocols & ciphers for each,
etc.)
Qualys SSL Labs
Any Questions?

You might also like