SSL Secure Socket Layer Based Protocol Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

In The growing popularity of web commerce the most important thing which stands out is be able to protect information, while maintaining higher level of trust. SSL (Secure Socket Layer) protocol was established by Netscape version 1.0. However, it was never publicly until the release of version 2.0 in 1995, which had various security problems. In 1996, SSL version 3.0 (Rescorla 2001) was released. SSL provides cryptographic protection. The main idea was to secure transmission of information. Further, SSL has played significant role in the progress of online security. The progress we have come across in the last decade would not be possible without SSL. However, tremendous endeavours have attracted fraudsters for financial gains. Even the highest level of security has been breached. A common observation suggests that almost every location can be routed by independent systems by snooping, spoofing etc. The main target of fraudster is to steal credentials such as credit card numbers, PIN number, financial or personal information.

E:\Dissertation work\Figures\figure 1.png

Figure 1 - Non-Secure Transmission Request vs. Secure SSL Transmission Request

The Secure Socket Layer (SSL) is layered above the TCP/IP protocol and underneath the application protocols such as SMTP, HTTP and FTP. Secure Socket Layer is used by HTTPS access method. Figure 1 shows the difference between a non-secure HTTP request and secure SSL transmission request.

Secure Socket Layer is a cryptographic protocol which is widely adapted for securing communications on the internet. A counterpart to SSL is TLS which substantially works on the same principles as SSL and also a cryptographic protocol.

SSL protocol overview:

The Secure Sockets Layer Handshake Protocol usually abbreviated as SSL is an

excellent protocol capable of securing any protocol that works over TCP.

And is short to say, SSL is recognized as the bottom line in security, which stands for

securing the communications between servers-to-client and server-to-server, load balancing devices.

The protocol is composed of two layers.

SSL Record Protocol:

It is layered on top of some reliable transport protocol

(e.g., TCP). The SSL Record Protocol is used for encapsulation of various

higher-level protocols.

SSL Handshake Protocol

It is layered above record layer is a key exchange protocol. It synchronizes and initializes cryptographic state at the two end points. Once key exchange protocol finishes then the sensitive application data can be transferred through SSL Record layer.

The SSL Handshake offers a secure connection with three attributes.

It provides a private connection, after the initial handshake encryption is used by defining a secret key. Data is encrypted using symmetric cryptography(e.g. DES)

Public key cryptography or asymmetric key cryptography is used to verify peer's identity (e.g., RSA, DSS, etc.).

It ensures a reliable connection with integrity checks using keyed MAC. Further secure hash functions (e.g., SHA, MD5, etc.) are utilized for MAC computations.


SSL consists of two layers, in a way each uses services from the lower layer and provide functionality to upper layers.

SSL Record Layer:

The main function of this layer is to provide authenticity, confidentiality and replay protection over a connection-oriented reliable transport protocol such as TCP.

SSL Handshake Protocol:

SSL 2.0 used a weak MAC construction. Further, in block cipher modes it feeds padding bytes into the MAC. In this process it leaves the padding length unauthenticated. This may allow an attacker to delete bytes from the end of messages.

Applications of SSL:

Secure Socket Layer is considered as the de facto for encryption and authentication between server and clients. To this date all transactions carried out on the internet are secured by SSL. But the range of SSL does not limit only for web commerce transactions. It expands to a variety of areas some of them are:

Financial Institutions: These are the primary example where SSL is implemented to secure confidential information, such as PIN numbers and account information.

Business -to-Business (B2B) organizations: extranets uses SSL to implement transaction between their suppliers, clients, partners and customers.

Email Providers: uses SSL to provide secure webmail for users.

Insurance companies: uses SSL to secure confidential information.

Method of Secure Socket Layer:

A Secure Socket Layer provides a secure and private connection between client and server by performing number of steps for example. It provide authentication, to verify the identity of a client and a server. Once the authentication process completes encryption is based on key-exchange based encryption start which then creates a secure "tunnel" between server and client preventing unauthorized system to access the information. Integrity checks frequently ensure that the modification of encrypted data does not go un-detected.

SSL Authentication:

For the purpose of SSL authentication both server and client needs to be SSL-enabled. For examples, SSL- enabled clients like Microsoft Internet Explorerâ„¢ or Google Chromeâ„¢. Similarly servers, such as Microsoft IISâ„¢ or Apache are SSL-enabled.

Certificate Authorities:

These are third parties Certified Authorities (CAs) authenticates an individual's claimed identity.

Public & Private keys:

Public keys and Private keys are components of cryptographic systems.

Public key is used by sender to encrypt data. The recipient can only decrypt the data with the corresponding private key.

Public keys are known to everybody, but private keys are only known to the certificate owner.

E:\Dissertation work\Figures\public key.png

Digital signature:

Certificate Authorities (CAs) validate the digital signature on the certificates to ensure that the transmission is not intercepted by an imposter by providing false public key, for which they might have correct private key.

Integrity Checks:

During the secure connection these checks are performed to ensure that the transmission of data remains secure and private and it is not intercepted by unauthorised access. If at any point SSL finds the connection is not secure the connection is then terminated and re-established.

Symmertric key encryption:

Symmetric key encryption

is much faster than public-key encryption, but public-key encryption provides better authentication techniques. So SSL uses

public key cryptography for authentication and for exchanging the symmetric keys that are used later for bulk data encryption.

E:\Dissertation work\Figures\symmetric key.png

SSL Transactions:

SSL transactions are composed of two main phases.

SSL Handshake (key exchange)

SSL Data transfer

These phases work jointly to secure a SSL transaction

Figure 2 illustrates an SSL transaction:

The following is a stepwise explanation of a SSL Transaction:

The handshake starts when SSL enabled client connects to SSL enabled server, requests a secure connection and the list of supported ciphers and versions is presented.

The negotiation comes to an end when the strongest cipher and hash function is selected from the list presented, which is also supported by the server. The server then notifies client.

The client verifies the validity of a certificate and the Certificate Authority (CA) is listed in the trusted list of CAs.

The server than responds in the form of Digital Certificate, which contains name of the server, trusted Certificate Authority (CA), and public key. In some cases a server may require client's signed certificate normally in case of online banking. Although most organisations does not deploy client-side certificate for the reason of overhead involved to manage public key infrastructure (PKI).

The client only generates a master secret if it establishes the certificate is valid. It then encrypts the master secret with server's public key and sends it to the server. The server decrypts the secrets with its private key. It cannot be decrypted other than the server's private key.

The master secret is then converted to a set of symmetric keys, which is called keyring or a session keys. The fact that these keys are only known to the client and server the transmission remains private.

The handshake is than concluded and secured connection begins allowing the bulk data transfer. The data is encrypted by client's browser and decrypted by server until the connection ends. However, failure of any of the above results into connection failure.

It is important to note that SSL encryption and authentication only takes friction of a second. The user can tell when the secure tunnel has been established, by the sign of small closed lock sign on the left of the address bar. To identify a secure SSL enabled website its address should starts with https instead of http.

Renegotiation Vulnerability in SSLv3 and TLS:

In 2009 details of a vulnerability related to SSLv3 and TLS protocol were published by Marsh Ray, Steve Dispensa and Martin Rex. The vulnerability affects a large number of platforms and protocols. Also the impact may vary application to application and protocol to protocol. In case of "Man in the Middle" attack an attacker may alter and change data. However, in this case attacker piggybacks an existing encrypted and authenticated SSL sessions in order to inject arbitrary text of its own choice. The attacker not necessarily be able to read or alter session. What is most significant about this vulnerability it is not limited to HTTPS, it may exploit all application or protocol SSL v3 or TLS implements.

Renegotiation prefix injection vulnerability in SSLv3 and TLS:

attack 1.png

Figure ? Generic TLS renegotiation prefix injection vulnerability


1.1 TLS hand shake is initiated by the client. Attacker holds packets, but the attacker may open a TLS session in advance without actively holding client packets.

1.2 The attacker negotiates a new session with server and executes a full TLS exchange.

2 The attacker then uses previously established TLS session to send application level commands.

3 Renegotiation Triggers for one the following reasons:

Certificate authentication as server sees the command get/dir and requires a certificate of directory.

Different resources have cipher requirements (Server initiated).

By the client.

TLS handshake Session 2 between server and attacker is now being let to the server. A new TLS handshake is performed by the server over the previously established encrypted TLS session 2.

Due to the renegotiation TLS endpoint has to consider the previously sent data. The end points assumes the previous data (1.2) to have been sent from the same client.


HTTPS can be abused in number of ways for the reason of injecting traffic into an authenticated stream. Frank Heidt(Leviathan Security) uncovered an attack vector but decided not to published the details. However, Thierry Zoller (G-SEC) rediscovered this vector, which allows downgrading and existing SSL session to plain text. The consequences could be alarming.

The two new methods proposed to exploit the TLS renegotiation vulnerability

Injecting Plaintext and abusing usingX-Ignore:/n (Marsh Ray) or using or using unfinished POST to a web application reflecting content ( Anil Kurmus)

Summary: The attacker injects prepend commands such as GET/POST HTTP but does not terminate the last command that way when both http requests from attacker and victim are merged, which results into part of the victim requests are ignored.

Active Man in the Middle attack by down grading from HTTPS to HTTP.

Summary: An injected HTTP request to resource accessible over SSL but redirected the client to HTTP.

"When trace comes back to bite you". The attacker injects trace command and by doing so controls the content sent from the server to the victim.

content that is send from the server to the victim over HTTPS

E:\Dissertation work\Figures\attack 2.png


This is an example of how this vulnerability can affect HTTPS. We are aware that in this case a simple XSRF5 attack could have achieved the same effect, but it is an easy to

understand example. This attack can be used to abuse specific functions of the relevant web

application, such as POC showed how Twitter credentials used to steal

This flaw6.

The attacker performs a full TLS exchange by negotiating a new session.

Fictional weak e-banking application receives GET request from the attacker. Note HTTP 1.1 pipelining allow attacker to send multiple request but only the last request grab the cookie.

Renegotiation is triggered

The TLS handshake held back by attacker, which started at step 1 is now being let to the server. The server performs a new TLS handshake once again over the encrypted TLS session 2 previously established (Attacker<>Server).

Due to the renegotiation TLS endpoint has to consider the previously sent data. The end points assumes the previous data (1.2) to have been sent from the same client.

"The requests

1.2 : Attacker -> server GET /ebanking/ paymemoney.cgi?acc=LU00000000000000?amount=1000 Ignore-what-comes-now: And 4: Client->server

GET /ebanking Cookie: AS21389:6812HSADI:3991238"

5 "The request is prefixed to the request issued by the client in (4) and is merged into

GET /ebanking/ paymemoney.cgi?acc=LU00000000000000?amount=1000 Ignore-what- comes-now: GET /ebanking Cookie: AS21389:6812HSADI:3991238

Interpreted by the HTTP daemon as :

GET /ebanking/ paymemoney.cgi?acc=LU00000000000000?amount=1000 Cookie:


E:\Dissertation work\Figures\attack 2..png


SSLstrip7 is a tool introduced by Marlin Spikes at Blackhat 2009 - allows us to execute an active MITM attack by stripping of SSL from the victim's connection. The attack had a special disadvantage, it was not possible to downgrade an existing SSL session, and only works if the users bank via HTTP first then try to present his credentials to HTTPS.

Abuse of the TLS renegotiation vulnerability but it is now possible, even SSLstrip set up SSL connections.

The proof of concept for this attack is available at:

1 The attacker sends a GET request he knows will redirect the HTTP client to a non HTTPS page on the server.

1.2The attacker knowingly send GET request to redirect HTTP client to a non HTTPS page on the server

renogiation triggers.

The TLS handshake held back by attacker, which started at step 1 is now being let to the server. The server performs a new TLS handshake once again over the encrypted TLS session 2 previously established (Attacker<>Server).

Due to the renegotiation TLS endpoint has to consider the previously sent data. The request is taken as a prefix to the request sent by the client in (4) and therefore merged as one request. Finally the attacker is successful in replacing the GET request.

In response the server replies with a 302 and redirects the victim to a HTTP page.

The victim's HTTP browser automatically follows the redirect sent by the server and requests the HTTP page.

The attacker is able to see the plain text requests, and may rewrite the HTTP request fromt he victim the way he wants. The attacker continues from this point with SSLtrip.

E:\Dissertation work\Figures\attack 3.png


TRACE allows the attacker to manipulate response from the server to the client, unlike the original attack that only the control of the request to the server, using trace control allows control over the response within its boundaries.

At the moment it is believed that TRACE is unlikely to be used for client-side JavaScript code to execute, this is due to the "content-type: message / http" header servers adds to the response and ask the browser to start a download. Binary content injection by TRACE seems not be possible if the filename the browser stores the data is not controlled by the attacker. There are several third-party browsers use their own sockets to send / receive HTTP data and Trident engine (mshtml.dll) to render the web pages. This implementation is vulnerable to JavaScript injection. That is because IE component does not renders HTTP header data as if would be HTML.

E:\Dissertation work\Figures\attack 3.3.png

The TRACE method can also be abused, for example, in situations where custom code is used, ignoring the content-type and analyzed only for specific data.

For example, one can imagine that a number of automatic updates and server to server communication protocols are vulnerable to this attack. Because the client expects a response to a GET request, it is likely that developers do not have time to investigate whether the answer is really look like from a GET request.

Summary: The attacker injects a TRACE command, this allows the attacker to control the content, that is from the server to the victim over HTTPS.

The proof of concept for this attack is available at:


There are two important ways TLS with SMTP to use - STARTTLS and TLS from the beginning. With STARTTLS you access to the SMTP port used for simple text and then request a TLS connection with the command "STARTTLS".

T. Zoller (G-SEC) and W. Venema (Postfix) this protocol researched independently, the following represents a summary of what is currently known. Venema has published a PDF that summarizes his views8.

Discussions with M. Venema led to the following information based attacks in line with protocol requirements. A successful attack vereis'n SMTP server that uses a TLS engine that reads the data as soon as it comes, vendors need to evaluate products in order to determine whether their product is vulnerable. Currently there are no independent research results for SMTP. As an example of software that uses TLS engine in a manner necessary for this attack to work, Venema quoted STUNNEL.

SMTP Protocol vulnerability matrix:

Attacker without an account on SMTP server

Attack theoretically possible if

TLS private cert authentication without SASL

SMTP over TLS without SASL

Attacker with an account on SMTP server

Attack theoretically possible if

TLS private cert authentication without SASL

TLS private cert authentication with SASL

SMTP over TLS with SASL

SMTP over TLS without SASL

E:\Dissertation work\Figures\attack 4.png


A complex example shows how SMTP can be exploited over TLS or SSL v3 (STARTSSL). The attacker needs an SMTP account for this attack.

This is a complex example of how this vulnerability could be used to exploit SMTP over TLS (STARTSSL) if the attacker has an account

Attacker initiates a TLS session (STARTTLS) by connecting to SMTP.

The attacker performs a full TLS session after negotiating a new session.

The attacker does not terminate SMTP session but sends a SMTP command. In the example shown the attacker controls the source and destination email addresses.

Renegotiation is triggered.

By establishing a new TLS session (TLS HELLO) attacker get victim to carry out a new TLS handshake, over the encrypted session 2 previously established. (Attacker<>Server).

Due to the renegotiation TLS endpoint has to consider the previously sent data. The end points assume the previous data (1.2) to have been sent from the same client. Accordingly the client now gets response from the attacker injected commands.

The victim SMTP client generates its commands to send mail. However the commands sent ends up in the body of mail, which was previously started by attacker.

"The SMTP server receives:

EHLO whatever

AUTH PLAIN whatever

MAIL FROM attacker-chosen-sender>

RCPT TO:<attacker-chosen-recipient>

attacker:DATA victim:EHLO victim:AUTH PLAIN whatever victim:MAIL FROM victim:whatever

victim: DATA<crlf>"

So the :<attacker-chosen-recipient> receives a mail including the other data as well as the authentication data.

Client side attack detection

Unlike HTTPS protocol client has a way to detect that he was attacked at the application layer as the server answers come before the victim has sent the commands.

Important Note

According to this research this vulnerability may not affect POSTFIX.


FTPS is an SSL / TLS-based implementation of FTP, it is not to be confused with SFTP (FTP over SSH). Alun Jones9 Author WFTP has an analysis of the impact on FTPS implementations and potential vulnerabilities that might happen to be present, contains the analysis of an interesting note about degrading encryption for compatibility of the NAT impact beyond the TLS / SSL renegotiation vulnerability. This among other things, the reason why it is recommended over FTPS.

FTPS is particularly interesting because there are two channels, the control and data channel is encrypted can be requested separately. Please note the description for more insight into FTP connections.

Renegotiations due to NAT support (Data Channel)

Due to renegotiations NAT support (Data Channel)

NAT devices must track and have support connections to rewrite FTP connections on the fly, to allow FTP to work through NAT. The problem that appeared with FTPS that the NAT devices could not peek into the PASV or PORT Commands no longer and as such not be able to NAT FTP.

For this reason and to be able to support FTPS over NAT, multiple vendors further support CCC 10command (Clear Command Channel). The FTP server drops the secure connection to allow NAT device to rewrite PASV and PORT commands. This allows the attacker to see control channel to see in plain text. This enables attacker to know, when and which files are currently being transferred, if the server will accept TLS renegotiation, the attacker could then time to clear the text control channel to inject data into files to be uploaded to transfer by renegotiating the beginning of a new file.

Abuse: Client uploads a binary file; an attacker injects binary code of his own choice.

Client certificate-based authentication (Control Channel)

Certificate based authentication in HTTPS, may become vulnerable in specific circumstance. HTTPS needs to get request to particular directory before opting to requirement of certificate or not, the HTTP server then needs to perform renegotiation. This is different in case of FTPS, the connection is encrypted at the very beginning; the server is unlikely to support renegotiation at that stage.

Injecting the mid transfer by resetting the TCP connection:

Alun Jones pointed to the fact that many FTP clients do not properly terminate the TLS session. Instead the clients terminate the TCP session under (RST, FIN). This is the reason, many FTP server supports these borderline cases and do not report this connection related dismissals as an error.

However, this makes way for clever attack. The attacker can terminate the TCP connection between the server and the victim by sending the particular TCP packet. The FTP client will then try again to upload with REST12 than the attacker (due to CCC) has access to this data, he knows exactly what the file is part of the victim and continued through TLS renegotiation it can precede the transmission parts. In addition, the attacker can modify the REST command, in order to resume server at the location of his choice.

The impact of SSLv3 on other protocols:

The impact of this vulnerability may differ from protocol to protocol. A number of stateless protocols like HTTP, for example, merge the two sessions in one, which allows the attacker to execute arbitrary plaintext in the stream that is processed by the end stream as arriving from the same destination.

This breaks a fundamental assumption of application developers and has an impact on the countless number of custom implementations.


Impact analysis available

Current status



1. Vulnerable to a certain extent, impact may relies on application level logic and structure of the HTTP requests.

2. Attacker can control the response in case TRACE command is supported by server.

3. Attacker can downgrade to HTTP (sslstrip)


Online discussions

Believed to not be vulnerable












Vulnerable only if certain requirements are met



Vulnerable - Further research required



Impact analysis available

Current status


Partially (vendor)

Not vulnerable, does not depend on openssl session capabilities - session handling was strickened after disclosure reports


Partially (vendor)

Vulnerable - mitigations exist



Vulnerable - short term patch available

IIS 7 <=7.5


Vulnerable - not vulnerable to if client initiates renegotiation request.



Vulnerable - patch status unknown, IETF proposal currently being implemented



Vulnerable - short term patches available


This protocol in believed not be vulnerable. For the reason when EAP-TLS is executed no application protocol is involved. Further, the tunnel is not used, only the TLS key material is used. EAP re-authentication is different to TLS renegotiation which executes in the previous TLS tunnel

IETF Draft solution:

The IETF draft presented by, N. Oskov, S. Dispensa, E. Rescorla is a innovative approach to solve the problem.

The idea suggested developing a new TLS extension and binding TLS sessions to clients. Also to let clients know about the renegotiations. Further, defined set of rules was introduced which either allows never to negotiate or renegotiation in case renegotiation extension is being used or renegotiate anyways.

Note: Currently all major vendors are believed to be implementing the above solution.

Patching TLS

The circumstances that involve "vulnerability conditions" the patching requirements may be:


Short term: Disable all renegotiation capabilities

Midterm: By implementing the IETF proposal for handling renegotiation requests and TLS extension tracking.


Mid-term : Implement the IETF proposal for a TLS extension tracking and handling renegotiation requests.

Patching SSLv3

To patch renegotiation vulnerability in SSLv3 is to disable server side renegotiation completely. For the reason SSLv3 does not allow extension above, therefore, proposed Draft cannot be implemented.

Identifying for a renegotiation vulnerability

Openssl provides a toolset which offer the easiest way of finding out if a server supports client-side renegotiation, when the tunnel is established.

Note: The application beneath may not be vulnerable to attacks, but only indicates server is vulnerable to attacks.

Generic Example:

Openssl s_client -connect

"GET / HTTP/1.0

R (Triggers renegotiation - if this works, the server accepts renegotiations within an existing TLS session Req. #1)


<server responds with content> (server merged both sessions Req. #2)"

Patched Server with Disabled renegotiation:

"Openssl s_client -connect

R (Triggers renegotiation)

2860:error:1409444C:SSL routines:SSL3_READ_BYTES:tlsv1 alert no renegotiation:./ ssl/s3_pkt.c:1053:SSL alert number 100"


The vulnerability exists within SSLv3 and TLS and will continue to affect in years to come. The number of custom applications that are on risk is very high.


Servers which support mid-connection renegotiations are more likely to be attacked.

Similarly, those applications which considers 2 TLS sessions coming from the same client are vulnerable.


Clients remain vulnerable for the lack of detection to check if and when a renegotiation triggers. Clients have no means (pre TLS extension) to check if a renegotiation is happening and are vulnerable.