Study and analysis of some known attacks on transport layer security

© Mohammad Nazmul Hossain. All rights reserved.
Study and Analysis of some Known
attacks on Transport Layer Security
[Mohammad Nazmul Hossain]
[Dept. of Communication Systems & Network
TH Köln]
24th
May, 2017

1 | P a g e
Technische Hochschule Köln

2 | P a g e
Table of Contents
1 Abstract..................................................................................................................................................... 3
2 Introduction.............................................................................................................................................. 3
3 Transport Layer Security (TLS).................................................................................................................. 3
3.1 TLS Handshake.....................................................................................................................4
3.1.1 Client Hello....................................................................................................................4
3.1.2 Server Hello ...................................................................................................................4
3.1.3 Client Key Exchange .....................................................................................................5
3.1.4 Change Cypher Spec......................................................................................................5
4 Testbed Methodology............................................................................................................................... 6
4.1 Software and Tools used .......................................................................................................6
5 Some Well-known attacks ........................................................................................................................ 6
5.1 SSL Stripping ........................................................................................................................6
5.1.1 Process and remedies .....................................................................................................7
5.1.2 Study on Testbed environment ....................................................................................12
5.2 BEAST Attack.....................................................................................................................14
5.3 STARTTLS Command Injection Attack.............................................................................15
5.4 Certificate and RSA related attack ......................................................................................15
5.5 Theft of RSA Private Keys..................................................................................................16
5.6 Diffie-Hellman Parameters..................................................................................................16
5.7 Attacks on RC4 ...................................................................................................................17
5.8 Triple Handshake ................................................................................................................18
5.9 Padding Oracle Attacks.......................................................................................................19
6 Recommendations.................................................................................................................................. 19
7 Conclusion............................................................................................................................................... 20
8 Acknowledgements ................................................................................................................................ 20
9 References .............................................................................................................................................. 21

3 | P a g e
1 Abstract
This paper is focused on study on some practically feasible attacks and threats against TLS based
connection. The reader can also get an idea on SSL Strip attack presented here based on an experiment
in a testbed environment. There are also some other attacks on TLS protocol such as BEAST, Padding
Oracle Attack, STARTTLS command injection attack, Theft of RSA Private Keys, Triple Handshake
etc. which are also discussed here descriptively. This study summarizes the common known attacks
following RFC 7457 and their existence, appliance and remedies for the TLS activated server. Some
attacks can be avoided by configuring the server carefully and by applying TLS 1.2 protocol and its
protections properly. The importance of using TLS 1.2 and some other protocols to protect TLS based
servers are also discussed. Some of these threats are no longer is a threat if the server is using TLS
1.2 and some other protocols. Updated and secured web browsers are also important against some
attacks on TLS 1.2 also discussed here.
2 Introduction
The current version of TLS is TLS v1.2 which is standardized in RFC 5246 in August 2008, and work
is now underway to define TLS v1.3 [28]. At the beginning TLS was known as SSL (Secure Sockets
Layer). SSL has developed from SSL v1, SSL v2, SSL v3 to SSL v3.1 which is named as TLS v1.0
(SSL v 3.1 = TLS v1.0).
TLS is regarded as a secure connection between two peers and used widely now a days. But there
still some pitfalls which makes this protocol insecure for certain conditions. There are some attacks
on TLS communication based of some vulnerability of servers. Some common attacks are described
in RFC 7457. There are also defensive models against these attacks.
3 Transport Layer Security (TLS)
Let’s start from Application layer. At the application layer of the TCP/IP model the application
creates some data and transfers it to the Transport layer. The created data in the Application layer
have different protocols according to their uses and creator. For example to transfer files from one
host to another host we use FTP (File Transfer Protocol), to provide bidirectional interactive text-
oriented communication facility we use a virtual terminal connection which is called Telnet protocol,
to provide web page contents we use HTTP (Hypertext Transfer Protocol) or to send E-mail we use
SMTP (Simple Mail Transfer Protocol) and to receive E-mail we use POP3 (Post Office Protocol
version 3).
In the transport layer the commonly used protocols are TCP (Transmission Control Protocol) or UDP
(User Datagram Protocol). There are also some other transport layer protocols for TCP/IP like RSVP
(Resource Reservation Protocol), DCCP (Datagram Congestion Control Protocol), SCTP (Stream
Control Transmission Protocol), PPTP (Point-to-Point Tunneling Protocol), UDP-Lite etc.
Transport layer then transfers this data to the next Internet layer. Network layer adds IP (v4 or v6)
(Internet Protocol), ICMP (Internet Control Message Protocol) or IGMP (Internet Group
Management Protocol) according to the application layer protocol.
Internet layer then transfers this data to the next Link layer. This layer adds the final header and trailer
(footer) to the data, make a frame, and transfers the frame to the host or next hop through the physical
interface like cable, Wi-Fi etc. The protocols used by this layer are ARP (Address Resolution
Protocol), NDP (Neighbor Discovery Protocol), OSPF (open Shortest Path First), MAC (Media
Access Control) or PPP (Point to Point Protocol) etc.

4 | P a g e
So far we have learned the processes the data created by the Application layer transferred to the
Transport layer is in plain text. The transport layer just adds a header, make a segment and transfers
the segment to the Internet layer. Internet layer then also adds a header to the segment, make a
datagram and transfers it to the Link layer. Link layer then adds the final header to the datagram,
make a frame and transfers it to the destination through routers and cables or radio frequencies to the
destination host(s).
The total communication process is in plain text, unencrypted and if any 3rd
person sits between this
two hosts, observe the total communication and access the frames he may be able to remove the
headers and can easily read the data created by the application layer.
So here we have introduced the term encryption by which the data information is changed to a group
of symbols using or following some algorithms which is only known and shared by the two
communication parties or hosts so that only they can read the data by decrypting the encrypted data
using that certain algorithm. So using this method the data is going to be secured and cannot be read
by third parties who do not know the algorithm used in this encryption process.
SSL (Secure Sockets Layer) was introduced by Netscape Communications in February, 1995 which
was actually version 2.0. The SSL 1.0 had a lot of serious security flaws. SSL is applied over other
application layer protocols like FTP over SSL (SFTP), HTTP over SSL (HTTPS) or SMTP over SSL
(SMTPS) etc.
Later on the SSL has named as TLS (Transport Layer Security) from SSL 3.1 (SSL 3.1 = TLS 1.0).
The newest version of TLS is TLS 1.2. TLS 1.3 is in draft process and still incomplete.
3.1 TLS Handshake
Let’s talk about TLS Handshake process. The TLS Handshake uses Transmission Control Protocol
(TCP).
The TLS handshake process is initiated by TCP 3-way Handshake (SYN, SYN-ACK and ACK)
between Server and client. The client starts the TLS Handshake process from an initial port by sending
the [SYN] command to the server’s port number 443. Server then replies the client with a TCP [SYN,
ACK] command from its port 443 to the client’s initial port. Client then sends a TCP [ACK]
command to server’s port 443 to finish the TCP handshake process.
After finishing the TCP handshake with server the client initiates the TLS handshake process.
3.1.1 Client Hello
The TLS handshake starts with a Hello command from client to server. The client Hello includes the
offered Cipher Suites from the client which let the server know which Cipher Suites the client can
deal with. The client Hello also includes the current TLS version it offered, a random number for later
use and of course the session ID. If the session ID matches with the previous session ID, then the
client and server resumes the previous TLS session.
3.1.2 Server Hello
After Client Hello finishes, Server replies back to client with a Server Hello message. In the server
Hello message it includes the current TLS version. It also includes session ID, the selected cipher
suite from the offered cipher suites by client Hello message. The server also sends its certificate to

5 | P a g e
the client. Here this certificate is very important for client to verify the server’s authenticity and
securely exchange the client key to the server.
3.1.3 Client Key Exchange
After getting the server Hello message and the certificate from the server, the client verifies the server
certificate by verifying the certificate’s signature value by the CA’s public key. Client get the CA’s
public key from CA’s certificate. Client also checks the certificate revocation list from CA’s server
or by OCSP (Online Certificate Status Protocol). Client must trust the CA.
After verifying the certificate’s validity client then takes the server public key from the server
certificate and use this public key to encrypt the Premaster Key. This Premaster Key is generated by
the client according to the key generation algorithm agreed by the server and client. This agreed key
generation algorithm can be found in the server’s Hello message where the cipher suite is selected by
the server. For example ECDHE-RSA-AES128-GCM-SHA256 cipher suite is agreed by both parties
where ECDHE-RSA is the key generation algorithm.
Using this key generation algorithm client generates certain size of key and encrypt this key by the
server public key. Which results in an encrypted Premaster secret. Client then sends this Premaster to
the server by Client Key Exchange message.
3.1.4 Change Cypher Spec
The change cipher spec protocol is used to change the encryption being used by the client and server.
It is normally used as part of the handshake process to switch to symmetric key encryption. The CCS
protocol is a single message that tells the peer that the sender wants to change to a new set of keys,
which are then created from information exchanged by the handshake protocol.
Figure 1: TlS Handshake

6 | P a g e
4 Testbed Methodology
In this paper the SSLStrip attack has been performed using Python based tool named Pythem [1].
There is a HTTP server setup over TLS 1.2 using LAMPP software. Generally it is called XAMPP
but for Linux environment (Ubuntu 16.04) it is called LAMPP. It has a configuration file named
‘httpd-ssl.conf’ file which can be edited to use certificates and key files. This will be enabled to use
https connection to load the web page from its apache server.
To enable TLS 1.2 one must have OpenSSL version to 1.0.1 or higher installed. Earlier versions of
OpenSSL does not support TLS 1.2
The vulnerabilities of TLS server can be examined by using tools. There are several tools available
on Internet to test the TLS server. Only Pathem has been described and performed here. The common
attacks can be defended by writing some python or java based scripts and also by using some other
protocols and secured browsers. Some vulnerabilities are avoidable by configuring the server
carefully which are also discussed here.
4.1 Software and Tools used
Here is a list of Softwares and Tools used in the testbed experiment:
●Two PCs with Linux OS ●Two Laptops with Linux OS ●Smartphone with Android OS
●LAMPP ●Wireshark ●PATHEM
●Popup Browser BETA ●Google Chrome ●Mozilla Firefox
5 Some Well-known attacks
A lot of Researches have been described several flaws and attacks on SSL/TLS. In this paper only
some common and well-known attacks are discussed. These common attacks have been also
described and documented by Internet Engineering Task force in RFC 7457 [2]
. Bellow some of them
are discussed.
5.1 SSL Stripping
SSL Stripping also known as Downgrade attack. SSL Strip is a technique where the web traffic is
downgraded from HTTPS to HTTP. That means if a website uses Secure Socket Layer / Transport
Layer Security (SSL/TLS) over HTTP, there are some attack techniques where the adversary can
remove these use of SSL/TLS.
HTTP and HTTPS are application layer protocol in TCP/IP model where the suffix‘s’ resembles the
HTTP traffic is using TLS connection. Through HTTP data passes as unencrypted plain text which
can have secret information or user login credentials to the webpage.
If any adversary gets access between a user and a Website (for example a bank website), and if the
connection between them is http, then the adversary can easily read the unencrypted traffic between
them.
But if the user sends the encrypted login credentials to the webserver, then the adversary cannot read
any data sitting in the middle between them.
So, the point is, to secure the data every traffic should be encrypted between the webserver and the
user client. That is why the HTTP traffic should be always HTTPS by using Transport Layer Security.

7 | P a g e
5.1.1 Process and remedies
Now a days most of the web pages specially Bank and Email pages are using HTTPS connection.
Those servers have TLS enabled and the traffic they send and receive are HTTPS. For example
https://www.bankpage.com/online_banking.
But in the browser we do not type the ´bank web address like this. We usually type bankpage.com or
www.bankpage.com. A user never type http or https on his browser. When a user just types
‘www.bankpage.com’ the browser by default adds http:// just before the address typed by user, also
adds the application layer header on it and sends it the transport layer. Which will then be processed
by Internet layer and Physical layer and sent to the router for the server destination.
When the bank server gets an HTTP request it upgrades the HTTP connection to the HTTPS and
sends response (the webpage content) to the user’s browser application. When the browser gets the
response as HTTPS, then the connection between them will be encrypted for the next communication.
As a result if the user now types login credentials including password, it will be encrypted by the
browser application and passed to the bank server.
Now an adversary in the middle may capture the traffic between them but he actually can learn
nothing as the traffic is encrypted.
In SSL Strip attack an attacker sits between the user and the bank and act like a proxy server usually
known as Man in the Middle attack (MITM). The user is forced to use the proxy server without being
notified. This forced use of hidden proxy is done by various methods. The common methods are
setting up browsers proxy manually, ARP Spoofing or creates own hotspot and let the victim connect
to it.
As the user is connected to the proxy any traffic he sends will now pass through this proxy server.
The adversary in the proxy server can now read any traffic to or from the victim user and even modify
the traffic. But the thing is he can only modify the plain text traffic not the encrypted traffic.
Now as we have already discussed that an user normally do not type http or https on the browser, the
default HTTP request to the ‘www.bankpage.com’ will go the MITM proxy server first. The MITM
will then forwards the HTTP request to the bank server. The bank server will then upgrade the
protocol to HTTPS and sends the login page to the user. This reply HTTPS traffic from the bank
server will then reach to the MITM proxy first. The MITM will then modify the HTTPS traffic and
downgrade to the HTTP protocol. MITM will then sends this downgraded HTTP traffic to the user.
Now the user sees the login page from the bank server in his browser application. But there will be
neither any certificate security alert as HTTP do not uses certificates nor any protocol downgrade
alert as the browser application has no idea about this protocol downgrade.
As the protocol is HTTP to the victim any password submitted in this webpage will be sent as
unencrypted. The proxy MITM now easily get the password and send the user credentials to the bank
server through HTTPS traffic which will be then encrypted.
The bank server gets no idea that the traffic is being modified and the victim thinks he is using the
webpage securely as because the MITM proxy is hidden both to them.
The only way to avoid this kind of attack is to use always use HTTPS and never use HTTP. To do
this one possible solution is that the user will always type https before the website address. But it
cannot be done always because it depends on user manually. Another solution can be the browser

8 | P a g e
application itself adds the https before the website address. Yes, this is what is happening in practical
right now. But there should be a protocol behind this. The protocol is called as HTTP Strict Transport
Security (HSTS) [29].
Victim < == HTTP == > Attacker modifies traffic < == HTTPS == > Webpage
Victim < == HTTPS == > Attacker can’t modify < == HTTPS == > Webpage
HSTS protocol forces the browser to use https for the HSTS enabled websites from the very first
request made by user to access the website. And this protocol never let the user to use http version of
webpage. As a result the user always sends encrypted traffic to the server by force.
HSTS works like this. Users requests an http URL from the browser. The corresponding server
redirects the HTTP to HTTPS and responses to the browser including an HSTS header over HTTPS
connection. This header contains the max age time for the HSTS protocol. It also contains
‘includesubdomains’ command which defines whether the subdomains will follow HSTS or not.
Syntax
Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
For example:
Strict-Transport-Security: max-age=31536000; includeSubDomains
This response HSTS header will prevent the corresponding domain and also sub-domains to be
accessed via HTTP for the next one year. After the max age time finishes the user can again access
the domain via HTTP and from the second request he will again force to use HTTPS after he got the
HSTS response on the first request. That means the very first request is still insecure and unencrypted.
That is why HSTS over HTTP is always ignored. Following figure shows how www.yahoo.com
responses the Chrome browser with HSTS header and redirects to de.yahoo.com over HTTPS
connection.

9 | P a g e
Figure 2: HTTP request to yahoo.com redirects to HTTPS
Figure 3: yahoo.com request is redirected to de.yahoo.com server

10 | P a g e
Figure 4: HSTS header response by de.yahoo.com with maximum age of 2592000 seconds
There is still risk for the very first request when a user visits any domain for the first time as HSTS is
not enabled and known to the browser. To avoid this browsers contain a preloaded HSTS enabled
domain and subdomain list. If the website address the user is going to visit is in this preloaded list,
the browser will automatically redirects the web address from HTTP to HTTPS if the age limit has
not expired for HSTS. Following figures show how the Chrome browser redirects request internally
for amazon.de from HTTP to HTTPS.
Figure 5: Internal redirection of amazon.de from HTTP request to HTTPS

11 | P a g e
Figure 6: HSTS response header from amazon.de over HTTPS connection
The reader can check the STS preload list maintained by google whether a URL is in it or not [23]
Figure 7: STS Preload list showing that www.amazon.de exist in the preload list
Or one can checks his browser if it contains any URL in its STS preloaded list or not. Example for
Chrome browser is here: chrome://net-internals/#hsts

12 | P a g e
Figure 8: STS preload check in Chrome browser
Although there is a STS preloaded list, it not possible to cover the entire web. A solution can be
achieved by using DNS records to declare HSTS and accessing them via DNSSEC [3].
Even with STS preloaded list some advanced attacks cannot be avoided by using HSTS such as
BEAST or CRIME attacks.
5.1.2 Study on Testbed environment
During this research there was a testbed study on SSL Strip which has been executed in a self-made
web server. The server has configured using apache server from the LAMPP software. Using LAMPP
(an open source software) a user can easily launch a web server or even an ftp or SQL database server.
In this experiment a web server has been set up by using the default http server configuration and
PHP script. The SQL database is also the default configuration. The web page is consists of new user
registration and user login. A self-signed certificate has been created for the web page using OpenSSL
software. The certificate is needed for the TLS based http connection to the web server from the
client. The apache server configuration has been changed later on to make security updates.
There is a configuration file named ‘httpd-ssl.conf’ in this apache server which is used to configure
the HTTPS connection to the web server. The self-signed certificate must be installed on the browser
manually in order to validate HTTPS connection and accept the certificate to the browser application.
There was three computers in this experiment. One computer has the running web server on it.
Another computer acts as a client where there is a browser application and the third computer acted
as a man in the middle (MITM).
At first, the HTTP only connection to the web server from client computer of the same network has
been requested. The server was not set up to force any HTTPS connection this time. The handshake
process and communication between them has been observed from the third computer as a Man in
the Middle (MITM) using ARP poisoning. It has been found that the username and password was in
plaintext and accessing the recorded *.pcap file Wireshark tool can easily read them. So for plaintext

13 | P a g e
communication it is not secure as the password is not encrypted and any adversary wiretapping their
communication can easily learn user credentials.
Next, the server was configured with HTTPS redirection (302 Redirection). That means when the
server get a request from any remote user, whether the request is HTTP or HTTPS, it will reply to the
client as https and redirects the connection for the next communication to the HTTPS.
After configuring to 302 redirection another HTTP request to the web server is requested. But this
time the server replies with HTTPS protocol and the next communications were encrypted HTTPS.
Now, from the MITM computer SSStrip attack has been initiated (fig 8) by using a tool founded in
GitHub named PYTHEM [1]. This time the PYTHEM tool successfully shows the user credentials.
Of course it should, because the user is using HTTP connection to the web server and sends plain text
data. Using Wireshark this user credentials can easily be seen.
Figure 9: SSL Strip attack by Man in the Middle
So, how this has worked. PYTHEM tool’s ARP (Address Resolution Protocol) spoofing (fig 9) did
this easily. ARP spoofing is a kind of attack where the attacker choses its target and begins sending
ARP packets which contains targets IP address and MAC address. As a result hosts on the LAN cache
the spoofed packets and data that is sent to the victim will go to the attacker instead. So the attacker
then modify the traffic (for this experiment it downgrades the HTTPS to HTTP) and sends it to the
victim [4]. The traffic from server is also routed through the MITM computer as it is ARP poisoned.
So, both the traffic originated from client and server are routed through the MITM computer and the
adversary modifies them to make the communication as a plain text. To the client the adversary
impersonate himself as a gateway and to the gateway the adversary impersonates himself as the client
by cloning their MAC address to its IP address.
At last, the web server was configured with HSTS. Now, when the client tried to reach the server and
made requests, it got no response from web server and after certain time browser shows no connection
to the server error. This is because the PYTHEM is programmed to remove the HTTPS from the
request and sends HTTP request. But the browser now knows that the target server has HSTS and so
browser will not any more accepts any HTTP response from the server. Because, the HSTS works on
application level and once the browser gets the max_age for HSTS from the server it will not accept
any HTTP response from that certain server for that time (max_age) period.

14 | P a g e
Figure 10: ARP spoofing to make impersonate attack
5.2 BEAST Attack
BEAST, short form of Browser Exploit against SSL/TLS, was first revealed in September 2011,
which uses weakness in cipher block chaining (CBC) to exploit the SSL/TLS protocol. SSL BEAST
affects only the TLS 1.0 version and not the later versions because later versions do not use CBC.
The only reliable way to defend against BEAST is to prioritize RC4 cipher suites. [5]
In CBC mode encryption an initialization vector is used to make the encryption indeterministic.
Without initialization vector each time for the same block of data the encrypted output will be the
same with the same key. But, using this method if we use same key, the encrypted output will not be
the same even the data blocks are same.
An attacker who is intelligent enough can predict initialization vector, see what an encrypted data
look like and influence the data encryption by guessing the plain texts. Actually he does not decrypt
the cypher text rather than make guesses and find out it was right or wrong. With sufficient guesses
he can discover some amount of data.
Actually it needs enough guesses to uncover small fragment of data. So it’s very hard to uncover big
data streams. But what it does in many protocols it finds out very important fragments like session
cookies, URL-based session tokens and authentication credentials etc. By which it can take control
over users or servers.
Earlier, it was thought that using RC4 cipher suites will mitigate the BEAST attack. As it is a client
side vulnerability, the servers have to enforce to use RC4 cipher suite as an encryption method. But
later several researches found out that RC4 is much weaker that it was previously thought. So it is
clear then RC4 cannot be used today [6].
Now the only way to mitigate BEAST attacks is to use TLS 1.2 and GCM cipher suites. The thing is
BEAST is no longer a threat now while the servers and clients support TLS 1.2 and GCM cipher
suites. According to the survey report on March 2017 of project SSL Pulse 84.6 % of website are now
using TLS 1.2 and they are no longer considering BEAST as a threat in their survey [27].

15 | P a g e
5.3 STARTTLS Command Injection Attack
STARTTLS is an extension to plain text communication protocols that offers a way to upgrade a
plaintext connection to an encrypted (TLS or SSL) connection instead of using a separate port for
encrypted communication. A number of IETF application protocols use STARTTLS command to
upgrade a clear text connection to TLS connection. Some implementations of STARTTLS includes
vulnerabilities which allows attacker to inject commands during plaintext protocol phase. These
injected commands will be executed during cipher text protocol phase. This vulnerability is caused
because of applications I/O buffering layer during plain-text to TLS transaction. The injected
commands could be used to steal victim’s email or SASL (Simple Authentication and Security Layer)
user credentials.
There are two solutions to address the flaw and also they can be used together: (a) as documented in
RFC 3207, STARTTLS must be the last command in a pipeline group. (b) If unexpected plaintext is
received after the STARTTLS command then an alarm could be raised as a protocol violation. (c) If
a program uses the same input buffer before and after the switch to TLS, it should discard the contents
of the input buffer, just like it discards SMTP protocol information that it received during the plaintext
protocol phase.
5.4 Certificate and RSA related attack
SSL certificate vulnerabilities consists of certificate mismatch, Internal names, missing or
misconfigured fields and values in certificates, SHA-1 Hashing Algorithm, weak Hashing algorithm
and weak keys. A recent certificate fuzzing tool (Brubaker 2014 Using) uncovered lots of
vulnerabilities in different TLS libraries related to certificate validation. Digicert’s certificate
inspector tool [7] checks certificate vulnerabilities and it is free to use. It checks the following
vulnerabilities which a certificate creator should take care of.
 Certificate name mismatch
 Internal name problem
 Less secured SHA-1 and or other weak Hashing algorithm
 Weak Key
Certificate Common name or Subject must be same as the domain name. For example www.th-
koeln.de must be the certificate’s Common Name otherwise browser will not accept the certificate
for www.th-koeln.de website and it will generate not secured warning message and block the website
access.
An internal name is an IP address or domain name that is a part of private network. The Common
Name or subject contains the internal name. Such as any IPv4 or IPv6 address, NetBIOS names,
Hostnames and server name. After November 1, 2015 CAs are no longer issuing certificate to internal
names. So all servers must be configured to use public names.
Though there is no hashing algorithm that is 100% collision resistant but SHA-1 hashing is much
more insecure to collision attack than SHA-2. In 2005, a research team from China found weak
collision resistance property which made this hashing algorithm much more vulnerable to collision
attack. So it was an NIST requirement to stop using SHA-1 algorithm by January, 2011. Google
started phasing out SHA-1 certificates from November, 2014 and Microsoft started phasing out from
2016. But on August 2015 NIST published SHA-3[8] hashing algorithm and currently SHA-3 is only
accepted algorithm for Certificate issuing [9]. So NIST requires all Federal agencies to replace their
hashing algorithms with SHA-3. Readers are advised to learn more about hashing algorithm from
NIST’s secure hash algorithms [10]

16 | P a g e
Exhaustive key searches or Brute Force attacks are more dangerous to weaker keys. So NIST
recommended to use key size for RSA (Rivest-Shamir-Adleman) is 2048 or 3072 bits and Curves P-
256 or P-384 for ECDSA (Elliptic Curve Digital Signature Algorithm) [11]
.
There is an attack named Bleichenbacher’s Ref 1-million-chosen-ciphertext Attack [12] is an attack
against PKCS#1 v1.5 [13] (a)
. To perform this attack the adversary has to have access to a decryption
device. Let the adversary wants to decrypt ciphertext C. He chooses ciphertexts C1, C2, C3... different
from C and gets information about the plaintexts from the decryption ORACLE device. The adversary
chooses new ciphertexts depending on the decryption results from the previous chosen one. After
successive chosen ciphertext attacks the attacker gets the full plaintext information [14]. If he does
not get the full plaintext as in Bleichenbacher’s attack, then it is called partial chosen ciphertext attack.
This attack can be mitigated by using TLS 1.0 or later.
Klima attack [15] is feasible on RSA-based sessions in SSL/TLS protocols. This attack is based on
stealing premaster secret. An attacker who can discover the premaster secret can then easily decrypt
the corresponding captured SSL/TLS session. The attack uses the Bleichenbacher’s attack with
several changes to disclose the premaster secret for an arbitrary captured SSL/TLS session. However
this attack can be mitigated through using TLS 1.1 or later [2].
5.5 Theft of RSA Private Keys
If, the cipher suites used for TLS based sessions are not Diffie-Hellman or do not have the property
of forward secrecy (where the private key is only used for one session and destroyed after end of that
session), then it will be a threat for stealing private key attack. If the private key is stolen and the key
does not have the property of forward secrecy then the attacker eavesdrop any traffic using that private
key and can observe the SSL/TLS sessions as plaintexts. Which can be passwords, credit card
numbers and personal or private information. It can also execute MITM attack and impersonate as a
client to the server.
The way to mitigate this kind of attack is to use forward secrecy and or if the key stolen then revoke
the certificate and reissue new certificate and also update the certificate revocation list.
5.6 Diffie-Hellman Parameters
As described in the paper of Wagner and Schneier [16] .An attacker, who has the power to intercept,
read and change the exchanged message between the client and server, act as a client to the server
and as a server to the client. Then the attacker will make the client to think that the key exchange
method used in the session is Ephemeral RSA but actually the server uses the Diffie-Hellman method.
As a result when there is a key exchange occurs from the server during server Hello message, the
client interprets the data inside the key exchange message as RSA parameters. Client will assume the
DH prime number an RSA modulus and the generator g as a RSA exponent. Client will then encrypt
the secret key k and with the equation d = kg
mod p; and send it to the attacker as a part of client key
exchange message. When the attacker receives the client key exchange message he will calculate the
gth
root of the received data and discovers secret key k. Now the attacker can modify (decrypt and
then encrypt) any data coming from client or server and forward them.
As this attack is performed using two protocols (RSA and DH) together, it is so called Cross protocol.
Reader can learn more details from the research paper made by four researchers based on the attack
described by Wagner and Schneier [17].

17 | P a g e
Figure 11: Cross protocol attack
Thus an attacker can use the Diffie-Hellman parameters to hijack any TLS session without letting the
parties have any knowledge as they have been attacked. To mitigate this kind of attack IETF advised
to use predefined DH groups, as proposed in the [18].
5.7 Attacks on RC4
In cryptography RC4 is a stream cipher (Symmetric key cipher) where each plaintext bit is encrypted
one at a time with the corresponding bit using exclusive-or of a cipher bit stream which is a
pseudorandom keystream.
The stream cipher is implemented using a pseudorandom generator S (permutation of all 256 Bytes)
and two 8 bit index pointers ‘i’ and ‘j’. A key scheduling algorithm (KSA) is used to construct the
initial state of the permutation S0 using a long RC4 key of L Byte (varying between 5 and 256). Then,
the stream of pseudorandom bytes known as keystream is generated using the initial state S0. This
keystream is XOR-ed with the plaintext to generate ciphertext.
There is a flaw called the Invariance weakness in an RC4 key which preserves part of state
permutation intact throughout the initialization process. This intact part consists of least significant
beats of the permutation when processed by the PRGA.
In the attack process the adversary sniffs a large number of SSL connections encrypted with RC4 and
waits for the weak key. Once the weak key is found the attacker predicts the LSBs and tries to extract
the LSBs of the plaintext. To find out the weak key the adversary use the first encrypted bytes which
includes ‘Finished’ message and HTTP request.

18 | P a g e
This weakness of key scheduling algorithm is known as RC4 Attack FMS (Flurer, Mantin and Shamir
attack) which is described by three researches named Fluhrer, Mantin and Shamir (FMS). Readers
are advised to get more knowledge from the reference [19].
There are also other kinds of weakness, e.g. ‘RC4-Attack-PAU’ [20] and ‘RC4-Attack.Man’ [21].
Researches shows that it is required 2^26 sessions or 13x2^30 encryptions for successful attack. So
RC4 is no longer be a secured algorithm.
5.8 Triple Handshake
The triple handshake is a process initiated by a man in the middle where the MITM makes two TLS
connections. One is between him and the client another is between him and the server. In this attack
the client connects to the A assumes that A is actually S. Then A connects to the server S using the
same parameters sent by the C. A here forces C and S to use RSA only by offering corresponding
cipher suites only. Thus the attacker got two individual sessions between C and S where all the session
parameters are same excluding the ‘Certificate’ and ‘Finished’ message.
Using the same parameters A can resume previous connection between C and S but this time the
‘Finished’ messages are same. As the ‘Finished’ messages are same now, the renegotiation process
will be also successful next time.
As a countermeasure TLS client application should abort the handshakes which has no valid
certificate. An internet draft has submitted to the IETF by some researchers including one from
Google and one from Microsoft. They proposed Extended Master Secret which will prevent such
attacks.
Figure 12Triple Handshake attack by creating two TLS connections

19 | P a g e
5.9 Padding Oracle Attacks
Padding Oracle Attack is an attack CBC mode encrypted ciphertext. In CBC mode the plaintext is
encrypted into blocks of several bytes (each byte represents a character). The attack can be mounted
by a MITM (Man in the Middle) who can only see the ciphertext and can inject ciphertext of his own
composition. This attack works on the theory that there is an Oracle server telling the attacker whether
the padding of the ciphertext is right or wrong. The standard way for padding is PKCS7. PKCS#1 has
been updated. The current version is 2.1 [22].
Let us assume C2 is the ciphertext the attacker wants to decrypt. Now the adversary choses his own
ciphertext where C1' [1, 2, 3… 15] are random bytes and C1'[16] is 00. Then he passes (C1' XOR
C2) to the ORACLE server. If the server says that the padding is correct the adversary can find out
the last byte of the encrypted plaintext. But if server tells that the padding is wrong, then the adversary
will try for C1 [16] = 01, 02, 03 … 256. He can try 256 times for each byte and for one time the
ORACLE will say that the padding is correct.
An attacker who knows one byte of the block in either of the last two byte positions can reliably
recover each of the remaining bytes in the block using several sessions. For example, if the plaintext
is base64 encoded, then it will need roughly 219
sessions to recover the bytes of a block.
A standard in TLS is to calculate MAC tag (using Payload, SQN and HDR) and then encrypt. If the
padding is not correct then the MAC check is not performed. But if padding is correct then the MAC
check is done. So it is faster to produce an error message for an incorrect padding than for a valid
padding case.
The corresponding error message are fatal. As a result the TLS session will terminate. So there is a
multi-session setting where the same plaintext is assumed to be transmitted in the same position in
the ciphertext in many sessions.
6 Recommendations
To make a successful use of TLS and DTLS there are some configurations must and should follow.
For the SSL/TLS versions IETF recommended in the paper RFC7525 on May 2015 [24] that the
implementation of a secure server must not negotiate SSL version 2 and 3, should not negotiate TLS
version 1.0, 1.2 and must support TLS 1.2. But my recommendation is now it is time to forget the
older TLS versions. Server can only negotiate TLS 1.1 but it is must for every server to use TLS 1.2
[25]. To avoid SSL Strip attack web servers should use HSTS and HTTP client and server must
support HSTS.
For the cipher suites RC4 must not negotiated. Cipher suites offering less than 112 bits of security
must not negotiated [26]. Implementations must support and prefer cipher suites offering forward
secrecy and should not negotiate RSA key transport. Following this considerations these cipher suites
are recommended [24]:
 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
The length of public keys must be long enough. For DH the key length of at least 2048 bits is
recommended and for elliptic curves the length should be more than 192 bits.

20 | P a g e
For more security recommendations readers are advised to read the paper RFC7525 [24].
7 Conclusion
In this paper variety of possible attacks against TLS have been demonstrated. Most of these attacks
can be mitigate using TLS 1.2 protocol only and avoiding certain cipher suites. Use of GCM cipher
suites is treated as most secure cipher. Public key length is also an important factor for secure
handshake. The length of the key must be long enough.
HSTS must be used to implement TLS successfully. There is a need of certificate to use TLS. But
self-signed certificates will not work. The certificate must be buy or signed by a trusted Certificate
Authority, otherwise the browser will not accept the certificate and there will be a warning message
to the client while he tries to load the web page.
8 Acknowledgements
I thank to the PYTHEM tool developer, is named as ‘m4n3dwo0lf’ [1] online, who supported me to
use his tool and make a successful attack against HTTPS protocol. I have e-mailed him for supports
for my project and he helped me by e-mail reply. I also thank to Prof. Heiko knospe (TH Köln) who
provided me lab facility with more than enough kits I needed with internet facility. Prof. Heiko
Knospe also gave me some tips on how to accomplish my goals in this research.

21 | P a g e
9 References
[1] m4n3dw0lf – Cyber security researcher, “Pythem – Penetration Testing Framework
v0.66”, < https://github.com/m4n3dw0lf/PytheM>
[2] Y. Sheffer, Porticor, R. Holz, P. Saint-Andre, yet, “summarizing Known Attacks on
Transport Layer Security (TLS) and Datagram TLS (DTLS)”,
<https://tools.ietf.org/html/rfc7457>
[3] Limitations, “HTTP Strict Transport Security”,
<https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security#Limitations>
[4] ARP Spoofing, <https://www.veracode.com/security/arp-spoofing>
[5] Ivan Ristić, “Mitigating the BEST attack on TLS”,
<https://blog.ivanristic.com/2011/10/mitigating-the-beast-attack-on-tls.html>
[6] Ivan Ristić, “Is RC4 safe for use in SSL?”, <https://blog.ivanristic.com/2009/08/is-rc4-
safe-for-use-in-ssl.html>
[7] “DigiCert® Certificate Inspector”, < https://www.digicert.com/cert-inspector.htm >
[8] Federal Information Processing Standards Publication, “SHA-3 Standard: Permutation-
Based Hash and Extendable-Output Functions”, August 2015,
<http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf >
[9] National Institute of standards and Technology, Computer Security divition, “Secure
Hashing > Accepted Algorithms”,
<http://csrc.nist.gov/groups/ST/toolkit/secure_hashing.html>
[10] Federal Information Processing Standards Publication, “Secure Hash Standards (SHS)”,
August 2015, < http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf >
[11] Elaine Barker, Quynh Dang, “Recommendation for Key Management; Part 3:
Application-Specific Key Management Guidance”, January 2015,
<http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57Pt3r1.pdf>
[12] Daniel Bleichenbacher, “Chosen Ciphertext Attacks Against Protocols Based on the RSA
Encryption Standard PKCS #1”,
<http://archiv.infsec.ethz.ch/education/fs08/secsem/Bleichenbacher98.pdf>
[13] B. Kaliski, “PKS #1: RSA Encryption Version 1.5”, <https://tools.ietf.org/html/rfc2313>
[14] Hans Delfs, Helmut Knebl, “Introduction to Cryptography: Principles and Applications”,
<https://books.google.de/books?id=KwmkCgAAQBAJ>
[15] Vlastimil Klima, Ondřej Pokorný, Tomáš Rosa, “Attacking RSA-based Sessions in
SSL/TLS”, <https://eprint.iacr.org/2003/052.pdf>

22 | P a g e
[16] John Kelsey, Bruce Schneier, David Wagner, “Protocol Interactions and the Chosen
Protocol Attack”, <https://www.schneier.com/academic/paperfiles/paper-chosen-
protocol.pdf>
[17] Nikos Mavrogiannopoulos, Frederik Vercauteren, Vesselin Velichkov, Bart Preneel, “A
Cross_Protocol Attack on the TLS Protocol”,
<http://homes.esat.kuleuven.be/~fvercaut/papers/ACM2012.pdf>
[18] Dr. Gillmor, Internet Engineering Task Force, Negotiated Finite Field Diffie-Hellman
ephemeral Parameters for TLS draft-ietf-tls-negotiated-ff-dhe-05,
<https://trac.tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-05>
[19] Scott Fluhrer, Itsik Mantin, Adi Shamir, “Weakness in the Key Scheduling Algorithm of
RC4”, <http://www.crypto.com/papers/others/rc4_ksaproc.pdf>
[20] Goutam Paul, Subhamoy Maitra, “RC4 State Information at Any Stage Reveals the
Secret Key”, <https://eprint.iacr.org/2007/208.pdf>
[21] RC4-Attack.Man ,
<http://saluc.engr.uconn.edu/refs/stream_cipher/mantin01attackRC4.pdf>
[22] J. Jonsson, B. Kaliski, “Public Key Cryptography Standards (PKCS) #1: RSA
Cryptography Specifications Version 2.1” <https://www.ietf.org/rfc/rfc3447.txt>
[23] STS preload list,
<https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_
state_static.json>
[24] Y. Sheffer, R. Holz, P. Saint-Andre, “Recommendations for Secure use of Transport
Layer Security (TLS) and Datagram Transport Layer Security (DTLS)”,
[25] T. Dierks, E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.2”,
August 2008, <https://tools.ietf.org/html/rfc5246>
[26] H. Orman, P. Hoffman, “Determining Strengths For Public Keys Used For Exchanging
Symmetric Keys”, April 2004, <https://tools.ietf.org/html/rfc3766>
[27] Tim Trustworthy Internet Movement, “SSL Pulse”, Survey of the SSL Implementation of
the most popular web sites, <https://www.trustworthyinternet.org/ssl-pulse/>
[28] E. Rescorla, “The Transport Layer security (TLS) Protocol Version 1.3 draft-ietf-tls-
tls13-20”, April 28, 2017, <https://tools.ietf.org/html/draft-ietf-tls-tls13-20>
[29] J. Hodges (PayPal), C. Jackson (Carnegie Mellon University), A Barth (Google, Inc.),
“HTTP Striict Transport Security (HSTS)”, November 2012,

Study and analysis of some known attacks on transport layer security

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Study and analysis of some known attacks on transport layer security

Similar to Study and analysis of some known attacks on transport layer security (20)

More from Nazmul Hossain Rakib

More from Nazmul Hossain Rakib (8)

Recently uploaded

Recently uploaded (20)

Study and analysis of some known attacks on transport layer security