SECURE COMMUNICATION CHANNELS SUCH AS SSL OR TLS ARE NOT AS

SECURE AS MOST MIGHT THINK

Introduction:

Today commercial use of internet continues to arise at an incredible pace, and

securing web transactions have become increasingly critical to business, organisation, and

individual users. For secure communication organisation and individual users relies upon

browser based secure socket layer (SSL).

The purpose of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS)

protocols is to provide a mechanism for secure communications between two parties over a

network which neither party has end-to-end control over and thus has the potential for third

parties to intercept communication. The Internet is a good example of such a network

(Horms, 2005). There are basically two main roles of TLS data integrity and end-point

verification. When two parties are communication it is important that data send or received

on both ends should not be modified or inspected at any point. To achieve this data integrity,

SSL/TLS employs a variety of cryptographic techniques.

Asymmetric and symmetric encryption is used to provide privacy by preventing third-

parties from being able to access the contents of a message even if it is intercepted. This also

provides protection against messages being removed and inserted. Message digests are used

to protect against messages being modified (Horms, 2005).

Considering all these techniques of securing the communication or transactions, most of the

internet users think that they are secure because they are using secure internet communication

with SSL enabled browsers but unfortunately these browsers are becoming more vulnerable

1

due to various reasons. For instance, today all Internet browsers use the SSL/TLS for

encryption and “Certificate Authority Trust Model" (CA Trust Model) to verify the identity

of websites on behalf of end-users. Unfortunately, both SSL and CA trust model are deeply

flawed, leaving it vulnerable to attack in various ways. These attacks include direct SSL

attacks, "man-in-the-middle", as well as "phishing" attacks using fake servers.

In addition to this, SSL/TLS has become most frequently used protocol for internet

communication whenever privacy and authentication is required. Thus, most of the

passwords, PINs, TANs, credit card numbers, stock exchange prices and other important

information that are sent encrypted via the Internet, are secured by SSL, which makes SSL to

be an attractive target to various kinds of attacks (Doberitz, 2007).

Further essay is divided into two parts, section 2 gives the overview of SSL/TLS,

section 3 discuss the vulnerability analysis of SSL/TLS and recent SSL attacks, which proves

that SSL/TLS are not as secure as most might think.

2. SSL/TLS overview:

SSL (secure socket layer) is a transport layer security protocol that was proposed and

developed by Netscape in 1990’s. SSL and TLS protocols are so similar that sometimes TLS

1.0 referred as SSL 3.1. TLS comes into existence after 1996 when SSL development

becomes the responsibility of an international standard organisation. IETF developed

standard for internet for example TCP, IP and SSL 1.0, after this Netscape shipped SSL 2.0

and SSL 3.0 and IETF renamed SSL to transport layer security (TLS) which was released in

1999. So regardless to the changed name, TLS is just a new version of SSL.

2

The most important difference between the two is that TLS uses the keyed-Hashing

for Message Authentication Code (HMAC) algorithm instead of the SSL Message

Authentication Code (MAC) algorithm; HMAC produces more secure hashes than MAC.

There are other minor differences such as the exclusion of the Fortezza algorithms (which are

not open for public review), and the allowance of certificates to go back to an intermediary

certificate authority (CA) instead of going all the way back to the root CA. Because of these

improvements, the TLS and SSL 3.0 protocols don’t fully interoperate, but TLS 1.0 has a

mode to fall back to SSL 3.0 (Lee,Malkin, and Nahum, 2007).

SSL is used to establish a secure connection between client and server. Part of this

protocol is a handshake protocol that is responsible for two way authentication and key

establishment. Encrypted communication takes place between client and server after a

handshake and then cryptographic parameters are exchanged. SSL is divided into two layers;

first layer contains handshake protocol, change cipher spec protocol, application data

protocol and alert protocol whereas record layer which is lower layer serves as additional

security layer between application and transport layer. This layer provides confidentiality,

authenticity, and replay protection over a connection-oriented reliable transport protocol such

as TCP. Figure 1 shows the layering of SSL and figure 2 shows the process of authentication

and key establishment while handshake.

Figure .1 SSL layers from (Doberitz, 2007)

3

Figure 2: SSL handshake from (Doberitz, 2007)

For establishing SSL connection handshake protocol is used in the beginning for the

negotiation of cryptographic parameters. There are four stages of handshake as shown above,

in which client initiate the communication with client hello then client and server synchronize

with each other. In step 2, server provides a public key certificate to client in a Certificate

message, an optional ServerKeyExchange message and CertificateRequest message is also

sent for authentication, and a ServerHelloDone message to finish the message sequence.

4

In step 3, Client provides a certificate in a Certificate message , a pseudo-randomly generated

master secret for the SSL/TLS session encrypted with the server’s public key (found in the

Certificate message) in a ClientKeyExchange message, and an optional CertificateVerify

message (again, if the server wants the client to authenticate itself using a public key

certificate). Finally, Client and Server exchange ChangeCipherSpec and Finished messages.

Afterwards, all messages that are subsequently transmitted between Client and Server can be

cryptographically protected in terms of authenticity, integrity, and confidentiality with

cryptographic keys derived from the master secret.

SSL/TLS runs “above” the Transmission Control Protocol/Internet Protocol (TCP/IP),

which governs the transport and routing of data over the Internet, and “below” higher-level

protocols such as the Hypertext Transport Protocol (HTTP), which use TCP/IP to support

typical application tasks such as downloading Web pages. SSL lets an SSL-enabled server to

authenticate itself to an SSL-enabled client and vice-versa, and allows both machines to

establish an encrypted connection. All the while, SSL uses TCP/IP on behalf of the higher-

level protocols (Lee,Malkin, and Nahum, 2007).

3. Vulnerability analysis of SSL and recent SSL based attacks:

SSL/TLS is something not many people talk about but in reality it has changed the

people’s perception about web security. According to people’s popular belief if we are using

SSL then our web site, data and transactions are indeed secure. Moreover, when they see

those bold statements saying “This Web site is secured by 128-bit encryption" Or, there may

even be a graphical link to a certificate authority further "proving" that Web security is taken

seriously then their belief become more strong about how secure they are but in today’s

world encryption only is not able to provide all security. Despite of lot of improvement in in

5

web security SSL/TLS still have some vulnerability that can make SSL unsecure and prone to

attacks.

SSL 2.0 had many security weaknesses but in the new version of SSL 3.0 most of its

previous vulnerabilities has been fixed but still there are some weaknesses due to which

attacks are possible on SSL. These attacks are divided into two categories direct and indirect

attacks on SSL.

3.1. Direct attacks:

3.1.1. Ciphersuite rollback attack:

It is a kind of attack in which an active attacker modifies the list of cipher suite by

intercepting the hello message of client. This attack is possible in previous versions of SSL

because in SSL 1.0 and 2.0 hello message between client and server is transmitted in plain

text. By taking the advantage of this vulnerability an active attacker could silently force a

client to use export-weakened encryption, even if both endpoints supported and preferred

stronger-grade algorithms. This vulnerability has been fixed by SSL 3.0 as it authenticate all

handshake protocol messages with the master_secret but this attack could be possible if client

is using the older version of browsers which are not compatible with latest SSL versions.

3.1.2. The version rollback attack:

This is the most effective attack on SSL and this can be done on the latest versions of

SSL too because new versions like SSL 3.0 are flexible enough to accept SSL 2.0

connections. This threatens to create the potential for version rollback attacks, where an

opponent modifies the client hello to look like a SSL 2.0 hello message and proceeds to

exploit any of the numerous SSL 2.0 vulnerabilities (Wagner and schneier, 1996). To

6

overcome this vulnerability Paul Kocher designed a fascinating strategy which can detect the

version rollback attack on SSL 3.0.

This attack can be detected by embedding some fixed redundancy in the RSA PKCS

padding bytes to indicate that they support SSL 3.0. Server which supports SSL 3.0 will

refuse to accept RSA-encrypted key-exchanges over SSL 2.0 compatibility connections if the

RSA encryption includes those distinctive non-random padding bytes ( Lee, Hur, Won, and

Kim, 2009).

Paul Kocher’s this approach was very clever and somehow effective but there are still

some vulnerability left for instance, the success of the countermeasure depends vitally on the

assumption that SSL 2.0 will only support RSA key-exchange; non-RSA public key-

exchange algorithms will not admit the special padding redundancy, so version rollback

attacks cannot be detected if the server supports non-RSA key- exchange methods while

operating in SSL 2.0 mode. In fact, this assumption can be violated in servers which support

both SSL 2.0 and SSL 3.0. The SSL 3.0 specification optionally allows servers which support

SSL 2.0 backwards compatibility to accept SSL 3.0 ciphersuites in SSL 2.0 client hello

messages (schneier and Wagner, 1996).

Client hello

1. C -- M : v 3.0 , SSL_RSA

1’ C--M : v 2.0, SSL_DHE

Server hello

2. S-- C : v 2.0, SSL_DHE

7

Server key exchange:

S--C : {p; g; y} KS; diffie hellman

Client key exchange:

3. S--C : {p; g; y} KS; diffie hellman

Above example shows that both client and server support SSL 3.0 and SSL 2.0 have been

transparently forced to revert to SSL 2.0 protocol. Moreover, neither client nor server is

allowed to learn that other endpoint supports SSL 3.0 as RSA key-exchange has been

avoided. Now it will be easy for an attacker to exploit attacks on SSL 2.0 taking the

advantage of various vulnerabilities of SSL 2.0.

3.1.3. The dropping change cipher spec attack:

One quirk of the SSL key-exchange protocol is that the change cipher spec message is

not protected by the message authentication in the finished message (schneier and Wagner,

1996). Dropping change cipher spec attack disrupts the renewing of cipher suite by

intercepting change cipher spec. In SSL version 2.0 before the receipt of change cipher spec

message, current cipher suit offers no encryption but this vulnerability was later fixed in SSL

version 3.0, in which change cipher message is checked before verifying the finished

message. This implementation surely correct a flaw of the dropping change cipher attack but

still the attack can be carried out by combining the two attacks firstly the version rollback

attack then dropping change cipher attack.

8

3.1.4. The exchange algorithm rollback attack:

There is one more design flaw in SSL 3.0 handshake protocol due to which an

attacker can replace the algorithm of cipher suite that a client transmit with a randomly

selected key exchange algorithm of his own .

In SSL 3.0 handshake protocol a server can send short-lived public key parameters,

signed under its long-term certified signing key, in the server key exchange message. Several

key-exchange algorithms are supported, including ephemeral RSA and Diffie-Hellman public

keys. Unfortunately, the signature on the short-lived parameters does not protect the field

which specifies which type of key-exchange algorithm is in use (schneier and Wagner, 1996).

Therefore, an attacker can modify the key excahnge algorithm field and can abuse server

legitimate signature.

3.2. Indirect attacks on SSL:

There are various indirect attacks could also be possible on SSL which ultimately

compromise the security provided by the SSL/TLS. These attacks exploit vulnerabilities of

the services that are based upon SSL/TLS for example certificates and web browsers. These

types of attacks are known as Man in the Middle (MitM) attacks and side channel attacks.

Some attack for example MD5 collide certificate, SSL striping and SSL Null prefix attacks

are described below.

3.2.1. MD5 collide certificate attack:

According to (El-Hajj, 2011) ,MD5 is a widely used cryptographic hash function, has

been employed in a wide variety of security applications. It is supposed to provide the

following properties:

9

Given message m, it is computationally easy to get the hash h=H(m).

Given hash h, it is computationally infeasible to get m out of h, such that h=H(m).

Given m and h=H(m), it is computationally infeasible to get another message n, such

that H(n)=H(m). This property is known as collision resistance.

MD5 has shown some vulnerability for instance, it is not collision resistance so it is not

suitable for applications like SSL certificates and signatures. Today clients are still facing

problems and compromising their security because some CA’s are still using this

cryptographic hash function in SSL/TLS certificates and digital signature. Despite of warning

made in 2004 regarding the use of MD5, there are still thousands of certificates which are

using MD5 instead of SHA1.

With the help of MD5 collide certificate man in the middle can generate two different

certificated having the same certificate digest or signature. This allows an attacker to create a

rouge CA certificate trusted by all major browsers and other common applications (El-Hajj,

2011).

For successful MD5 collision attack two conditions should be fulfilled. First a valid

legitimate certificate signed by real Certificate Authority (CA), second the certificate should

use MD5 and should be accepted by all browsers. There is one root CA known as Equifax

Secure Global eBusiness CA-1 provides these properties. In an attack scenario the attacker

first issue a certificate request to be signed by the CA. After getting the signed certificate

attacker creates another certificate request with forged information, which will help to cause

the MD5 collision. Without sending the request to the legitimate CA attacker uses the same

signature digest of first real certificate and adds it to the rouge certificate. Now this rouged

10

certificate is valid over the signature. Moreover, this also helps in creating other rouge leaf

certificates. For conducting this type of attack over SSL, tool known as sslsniff version 5 can

be used. Following figure 3 represent the details of the attack.

Figure 3 MD5 collision attack (from (El-Hajj, 2011))

Now a day these types of attacks are rising, recently an Iranian hacker stole multiple

SSL certificates belonging to some of the web biggest sites like Google, Microsoft and

yahoo. According to Gregg Keizer On March 23, Comodo acknowledged the attack saying

that, eight days earlier, hackers had obtained nine bogus certificates for the log-on sites of

Microsoft's Hotmail, Google's Gmail, the Internet phone and chat service Skype and Yahoo

Mail. A certificate for Mozilla's Firefox add-on site was also acquired.

11

These stolen certificates validate the legitimacy of a Web site to the browser and users are not

able to realise that they are not connected to the real site. However, all the data between client

and server is encrypted.

Furthermore, the login.live.com domain used for logging in to Windows Live

accounts was one of the domains compromised by the rogue Comodo certificates. Microsoft

has issued a security advisory, and released mitigation update to update the certificate

revocation list on Windows PCs and prevent them from accepting the fake SSL certificates as

legitimate (Bradley, 2011).

3.2.2. SSL stripping attack:

SSL connection is not always used by the website throughout the open session.

Whenever, there is a need of secure communication SSL/TLS plays there role. For

connection between client and server URLs are used and some time these URLs are too long

to remember, so http redirection is used to facilitate for the user the access to the long URL

though shorter one. This is known as http 301 permanent redirection while for the secure

connection another redirection 302 temporary redirection is used. These redirections provide

some vulnerability and give attacker an opportunity to attack SSL. The attacker known as

Man in the Middle can exploit 302 redirection and transfer the communication to its machine

instead of forwarding it to legitimate server. For exploiting this vulnerability an elusive tool

called sslstrip can be used at the point where 302 redirection occur. This tool can be used to

tell user to use http connection instead of https between client and attacker whereas,

connection between attacker and server remain https which is encrypted and legitimate. Now

all the communication between client and attacker is in clear text and this way attacker can

get all credentials of the user.

12

3.2.3. SSL null-prefix attack:

SSL null-prefix attack is another Man in the Middle attack which uses some aspects

of x509 certificate vulnerabilities. SSL/TLS relay heavily on the x509 certificate structure

for in order to deliver authenticity and both parties in SSL/TLS connection have the

opportunity to identify themselves with an x509v3 certificate (Marlinspike, 2009). X509

certificates support PASCAL strings which are represented as a series of bytes mediated by

another series of bytes indicating the length of the string followed by the data itself (El-Hajj,

2011). For example one might issue a certificate requesting like www.paypal.com\

0.hackerworld.com, the Certificate Authority will ignore the prefix and only test the root

domain. Certificate will be issued to the person if he/she is the legitimate owner of the site

hackerworld.com. Consequently, submitting a request for www.hackerworld.com or

www.paypal.com\0.hackerworld.com yield no difference.

However, on the other hand SSL/TLS uses ordinary C string functions for comparison

and manipulation. In C string functions NULL character (“/0”) is used to terminate the string

so www.paypal.com\0.hackerworld.com means www.paypal.com according to SSL/TLS.

Therefore, the owner of www.paypal.com\0.hackerworld.com certificate can present his

certificate for connections intended for www.paypal.com, and thus breaking the authenticity

of the intended server.

4. Conclusion:

It is true that SSL provide great security against eavesdropping and other passive attacks.

Moreover, SSL 3.0 provides improved security mechanism by implementing complex hash

algorithms for encryption. In addition to this, users also feel themselves secure while using

13

SSL 3.0 enabled web browsers but the fact is that SSL/TLS still have some vulnerabilities

that make it prone to attacks. All of the above attacks prove that SSL/TLS is not as secure as

most might think. This essay presented some most recent and very effective attacks on

SSL/TLS for example SSL NULL prefix attack and version rollback attack are the recent

attacks that can be done on the secure communication channels with the help of latest tools

like sslstrip. Furthermore, SSL protocol makes other protocols like http and SMTP also

vulnerable to attack because these protocols are directly linked with SSL. For proper

mitigation it is important to critically analyse the every mechanism of SSL that take place

while communication and some things need to change. For example Providing clients with

the ability to check that certificates sent from servers are still genuine (check to see if they

have been revoked) automatically and more functionality onto client system so that he/she

will be able to sign and encrypt the actual data instead of establishing secure connection. In

short, there are still a few technical wrinkles left to iron out.

References:

B., R. a. (2010, september 27). Encryption Is Not Enough: Why It's Time for General Counsel To To Weigh In on the Authentication Practices Associated With Secure Communications. Retrieved May 1, 2011, from reedsmith.com: http://www.reedsmith.com/publications.cfm?cit_id=28961&widCall1=customWidgets.content_view_1&usecache=false

Bradley, T. (2011, March 24). Google, Skype, Yahoo Targeted by Rogue Comodo SSL Certificates. Retrieved May 1, 2011, from pcworld.com: http://www.pcworld.com/businesscenter/article/223147/google_skype_yahoo_targeted_by_rogue_comodo_ssl_certificates.html#tk.mod_rel

Doberitz, D. (2007, February 5). Cryptographic Attacks on and Security Flaws of SSL/TLS. 1-17. Germany.

El-Hajj, W. (2011). The most recent SSL security attacks: origins,implementation, evaluation, and suggested countermeasures. John Wiley & Sons, Ltd.

14

Homin K. Lee, T. M. (2007). Cryptographic Strength of SSL/TLS Servers:Current and Recent Practices. IMC' 07 (pp. 83-91). San Diego, California, USA.: ACM.

Horms, S. H. (2005, April). SSL and TLS An Overview of A Secure Communications Protocol. 1-21. Canberra, ACT, Australia: LCA.

Keizer, G. (2011, March 28). Lone Hacker Claims SSL Certificate Thefts. Retrieved May 1, 2011, from pcworld.com: http://www.pcworld.com/article/223463/lone_hacker_claims_ssl_certificate_thefts.html#tk.mod_rel

Marlinspike, M. (2009, July 7). Null prefix attack against SSL/TLS certificates. Retrieved April 30, 2011, from thoughtcrime.org: http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf

SSL: Not enought for today's web services. (n.d.). Forum systems Inc.

Thomas, S. A. (2000). SSL & TLS Essentials Securing the Web. (M. spencer, Ed.) New York, Chichester, Weinheim, Brisbane, Singapore, Toronto: Robert Ipsen.

Wagner, B. S. (1996). Analysis of the SSL 3.0 Protocol. Proceedings of the Second USENIX Workshop on Electronic Commerce. Oakland, California: USENIX.

Why SSL is not enough to secure your credit card details. (n.d.). Retrieved april 29, 2011, from articsoft.com: http://www.articsoft.com/ssl_security.htm

Yunyoung Lee, S. H. (2009). Cipher Suite Setting Problem of SSL Protocol and It’s Solutions. 2009 International Conference on Advanced Information Networking and Applications Workshops (pp. 140-146). IEEE.

15