Secure Socket Layer Design And Architecture Computer Science Essay

Published:

The purpose of this report is to analyse the design and architecture of Secure Socket Layer protocol. For this purpose the detailed analysis of the protocol has been discussed using existing research. A comprehensive insight about the vulnerabilities has also been identified, which affects overall SSL reliability. Similarly, existing mitigations for weaknesses examined. After profound analysis it has been found that SSL plays a significant role in securing communications and so far the foremost technology available. Finally in all the scenarios SSL holds the key role in future. However, the weakness does raise alarming concerns for the confidentiality of personal and corporate data.

List of Abbreviations

Table of Contents

CHAPTER 1

INTRODUCTION

Overview

In The enormous growth of internet securing communication has become significantly important. We live in world today in which millions of businesses are based on internet. The most important thing for any business is to develop higher level of trust with its customer. 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.

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

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.

Objectives

The objective of this report is to analyze the design and architecture of a very significant protocol Secure Socket Layer SSL (Secure Socket Layer), which is broadly the de facto means of securing communications on internet and has played a key role in web commerce. Also to identify the developments in this protocol and weaknesses that may exist. Further, to review the future progress in this area.

Scope

The project is intended to perform a detailed literature review on SSL functionality, its current techniques. The study includes the effects of various vulnerabilities related to SSL.

The SSL is used to operate the secure transfer of data.

.

CHAPTER 2

Secure Socket Layer

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.

Cryptography Overview

Cryptography is a recognized term in order to change the message so that only the intended

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

recipient can read. It is also used for the verification of sender

and make sure that the message has not changed in the time of transfer.

SSL uses a variety of cryptographic algorithms to ensure secure tranmission.

Four key concepts of Cryptography used for SSL

Symmetric Key encryption ( Private Key)

Asymmetric Key encryption (Public Key)

Digital Signatures and Message Digest

Certificates

Symmetric Key (secret key) encryption

This is a single key based encryption, it works with one key to encrypt and decrypt data. The encryption algorithm changes plain text into ciphertext, which is encrypted form of data. This data is then transferred to the receiver. The same key is used by recipient to decrypt the ciphertext into its original state.

There are two types of Symmetric ciphers:

Block Ciphers:

These are broadly used ciphers. The data is divided into fixed size blocks, the blocks are then encrypted individually. If there is any data left over it is padded.

Stream Ciphers:

On the other hand, the stream ciphers use a starting seed as a key and produces stream of random, which is called keystream. They generate cryptographic pseudorandom numbers. Stream cipher simply encrypts data by performing XORs with the keystream. The strength of security is dependant of the length of the key. The longer key length strengthen security and difficult to break.

Although, the longer keys may require more time to decrypt and slow down performance.

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

Asymmetric Key Encryption

Asymmetric encryption uses a public and private key infrastructure to send and receive data.

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.

This method sometimes becomes difficult to implement in case of large e-commerce sites such as amazaon.com. Let's consider amazon.com, it would not be possible to assign private keys to all customers. In that case public key is more often emerge as a solution, any customer can communicate to the server by using the public key.

SSL protocol is also using secret key decryption, which works faster than public key. They are used in accordance a public key encrypts a randomly generated secret key. The secret key encrypts the actual message. This technique is called hybrid encryption.

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

Digests

These are used for the assurance of message validity and to ensure it's not altered during any part of transmission. It is usually short, but fixed length summary of a message. The size of generally is around 128 bits. The hash function is applied on the original message to create a digest. A digest along the original message are send to the receiver. The integrity of the message is then ensured when recipient computes the message digest and compares it to the digest received. Any modification in the data may result invalid digest.

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.

Digests

These are used for the assurance of message validity and to ensure it's not altered during any part of transmission. It is usually short, but fixed length summary of a message. The size of generally is around 128 bits. The hash function is applied on the original message to create a digest. A digest along the original message are send to the receiver. The integrity of the message is then ensured when recipient computes the message digest and compares it to the digest received. Any modification in the data may result invalid digest.

Certificates

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

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

Examples of our work

A certificate in simple words is a file containing information about a machine. It is used to identify a machine. Consequently, both clients and server have their own certificates and used for the authentication during transmission. A certificate usually holds the information below.

Machine name

Organization or Company name

Machine location

Expiry date of the certificate

and Public and Private keys.

Certificate Authority

Signature of certificate Authority

Note: A certificate can be self-signed, but cannot trusted in the reliable means of communication. That is why trusted certificates by Certificate Authorities are only considered as safe for secure communication.

CHAPTER 3

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.

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.

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.

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.

Verification and Acceptance

After the planning phases verification and acceptance phases started. The main aim of this phase is to find the errors, possible mistakes that might have occurred during the installation. The final target of this prelaunch phase is to make sure the best operation of the network. Network optimisation continues and launch goes in to more detail level. It is very important to meet all the goals like to attain the specified coverage, capacity with relevant to Key performance indicators,

SSL Cryptographic Algorithms

SSL offers wide variety of Cryptographic algorithms, which are also called ciphers. Through these algorithms authentication, establishing session keys and transmission of certificates They are used for authentication is performed. Once a device is SSL-enabled it may support multiple set of ciphers, which are called cipher suites. In case a client and server both supports more than one cipher suites, the strongest supported cipher suite is selected, supported by both parties.

Some of the examples of cryptographic algorithms are as follow.

Key exchange algorithm: The algorithm which is asymmetric and mainly used for symmetric key exchange. For example RSA.

Public key algorithm: This is an asymmetric key algorithm used for authentication. For instance, RSA and DSA.

Bulk encryption Algorithm: This is symmetric data encryption algorithm. AES, Triple-DES and RC4 are commonly used.

Message digest algorithm: These are algorithm used to implement integrity checks. Examples are SHA-1 and MD5.

SSL and the OSI Model

The SSL provides security and is positioned in the OSI model, on top of TCP protocol. The application layer like IMAP or HTTP handles user's requests. Simmilarly, protocols controlling sessions are in session layer. A transport layer protocol manages the flow of data. In the OSI model SSL works as an independent protocol and can use any application or transport layer protocol.

E:\Dissertation work\Figures\OSI SSL.png

The Figure above illustrates how SSI functions in OSI model

The data is received unencrypted from application layer to session layer. SSL encrypts the data and pass it through. Consequently, on the other end server receives data it passes it to the session layer. Then SSL perform decryption and pass the data to the application layer.

The Cost of Encryption

E:\Dissertation work\Figures\SSL cost.png

As illustrated in figure 4 the Secure Socket Layer transfer data confidentially. Users can generate a variety of malware including viruses, pass the of the confidential business communication over an HTTPS connection that uses port 443. Since no IT organizations, have visibility into SSL sessions, they are unaware of any potential threat sending data over HTTPS. The security threat makes it difficult for companies to use and apply assess bandwidth usage and intelligent control policies to ensure maximize user productivity.

In addition, the signing key and certificate verification are very intense. Many sensitive sites that have implemented, experience bottlenecks created by SSL processing and management sessions. End result is that SSL web server performance degrades considerably and network transactions crawl. By performance degradation cause by SSL, many organizations cannot perhaps implement SSL, for budgetary constraints or infrastructure. Some limits SSL to the extent of sensitive data or transactions.

CHAPTER 4

openssl an introduction

SSL can be implemented in various ways, Open SSL is a recognized open source broadly used for SSL implementation. Although, OpenSSL supports all SSL versions, such are SSLv2, SSLv3 and TLS but the most commonly used is SSLv3. Eventually, application programmer adds SSL support. OpenSSl library is interactive with existing sockets libraries. The following section elaborates the four main phases of a SSL connection:

Initialization

Authentication

Data transfer

Termination

Programming with OpenSSL

Establishing a SSL connection begins with initialization. The main steps in

Initialization include the creation of appropriate data structures used in the subsequent phases and loading certificates.

The figure below illustrates the initialization stage

.

The implementation of this phase is simple and is shown in the figure.

The actions of the client and server are different. The server starts communicating to the specific port, and the client is trying the same port to connect. The subsequent phases will be assumed that the client initiates a connection to the server.

The second phase includes the authentication. OpenSSL can be used for none, one or request

both parties for identity verification. The process is the same for the client and server so that only one perspective is shown.

Figure 2 shows authentication phase

If the verification has completed without any errors the communication can now start. The socket will be shut immediately if the certificate is invalid or not trusted, no further communication will be made in that case. This could be a malicious attacker might impersonate to the server and has tampered TCP packets during the transmission. The data transmission stage is critical and shows the strength of SSL. Its not difficult for someone who knows about sockets, to read and write information from an SSL connection.

After the data exchange is over the connect must be terminated. However, the disconnection is not rapid but is taken care by SSL libraries, which sends a encrypted request for termination. For the reason a malicious user can try to terminate a connection unexpectedly. Genuine parties can terminate the connection.

Figure

Termination Stage below

As shown above all connections have ended.

Analysis of OpenSSL

It's important from a programmers view to know how SSL security procedures are implemented. Further, how to interact with SSL libraries using application programs. Implementing SSL is simple and can be divided into stages.

CHAPTER 5

Analysis of SSLV3 AND TLS WEAKNESSES

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

Steps the attack is performed

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 the earlier 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 has now approached the server. A new TLS handshake is performed by the server with the TLS session 2 esablished earlier.

The renegotiation causes TLS endpoints to consider the previously sent data. This caused endpoints to believe the earlier received data (1.2) was from the same client

HTTPS Protocol Vulnerability

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

Plaintext Injection (X-Ignore:/n) or exploiting web application by unfinished post reflecting content.

Summary:

prepend commands are injected by the attacker, 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 that redirects 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

Injecting Commands into a HTTPS session

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

Steps the attack is performed

This is an example of how this vulnerability can affect HTTPS. This is an easy way to carry out HTTPS attacks. This attack can particularly affect functions of the relevant web

application.

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, has now approached server. The server performs a new TLS handshake once again with the encrypted earlier established TLS session 2 (Attacker<>Server).

The renegotiation causes TLS endpoints to consider the previously sent data. This caused endpoints to believe the earlier received data (1.2) was from the same client.

5 "The request is prefixed by the client's request issued in step (4) and is merged into step (5).

Downgrade HTTPS session to HTTP

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

Steps the attack is performed

SSLstrip7 is a tool introduced by Marlin Spikes at Blackhat 2009 - allows to launch an active MITM attack. The main idea is to strip off victim's SSL session. The attack has a limitation that does not allow it to downgrade an existing SSL session. It is workable only if, the user 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 attacker redirects a HTTP client to a non HTTPS page on the server by sending GET request.

2 Renegotiation triggers.

3 The TLS handshake held back by attacker, which started at step 1, has now approached the server. The server performs a new TLS handshake once again with the encrypted TLS session 2 set up earlier encrypted TLS session 2 (Attacker<>Server).

4 The renegotiation causes TLS endpoints 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 in response HTTP page is requested.

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

http://www.thoughtcrime.org/software/sslstrip/

Using TRACE to inject custom response

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

TRACE:

TRACE allows the attacker to manipulate response from the server to the client, unlike the original attack that only the control of the request made to the server. Trace controls response from the server within its limitations.

At the moment it is thought TRACE is that TRACE is not likely to be implemented for client-side JavaScript code, for the reason "content-type: message / http" header server's response is added and ask the browser to start a download. Binary content injection by TRACE implementation is not possible, if the attacker is unable to control the filename in which browser stores the data. A number of third-party browsers use their sockets to send or 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

In case of custom code TRACE method can be implemented, 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; which allows the attacker to control the communication between server and victim over HTTPS.

SMTPS Protocol Vulnerability using STARTTLS

There are two important ways TLS can be used with SMTP.

STARTTLS

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"..

For a successful attack SMTP server that needs TLS engine that reads the data instantly comes, vendors need to evaluate products for vulnerability. So far no independent research is available for SMTP. As an example of software that uses TLS engine in a manner necessary for this attack to work, Venema quoted STUNNEL.

SMTP STARTTLS:

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

SMTP Protocol Vulnerability matrix

Attacker without an account on SMTP server

Attack theoretically possible if

TLS private certificate authentication without SASL

SMTP over TLS without SASL

Attacker with an account on SMTP server

Attack theoretically possible if

TLS private certificate authentication without SASL

TLS private certificate authentication with SASL

SMTP over TLS with SASL

SMTP over TLS without SASL

http://www.porcupine.org/postfix-mirror/smtp-renegotiate.pd

Break down of steps of attack:

An insightful example shows how SMTP can be exploited over TLS or SSL v3 using (STARTSSL).

The attacker needs an SMTP account for this attack.

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, with the encrypted earlier established session 2 (Attacker<>Server).

The renegotiation causes TLS endpoints to consider the previously sent data. This caused endpoints to believe the earlier received data (1.2) was 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 attacker started earlier.

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

Client side attack detection

HTTPS protocol does not help to identify and attack. In this scenario, client may be able to detect that the attack has happened 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 Protocol Vulnerability

FTPS is an implementation of FTP based on SSL / TLS, but is different to SFTP (FTP over SSH). Alun Jones 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. 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.

http://msmvps.com/blogs/alunj/default.aspx

NAT Support Renegotiation (Data Channel)

NAT devices must track and support connections are required to rewrite FTP connections on the fly, to allow FTP to work through NAT. FTPS no longer offers NAT devices to look into the PASV or PORT Commands and as such not be able to NAT FTP.

For this reason and to be able to support FTPS over NAT, multiple vendor's furthering support to Clear Command Channel. The vulnerability arises, when the secure connection is dropped by the FTP server to allow NAT device to rewrite Port and PASV commands. This exposes the control channel in plain text. This enables attacker to know, when and which files are in transferring, if the server will accept TLS renegotiation, It will allow the attacker to clear the text control channel, for injecting 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.

Authentication of Client Certificate (Control Channel)

This authentication has certain implications and may become vulnerable in specific circumstance. HTTPS generates get request to particular directory, before opting to acquire a 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 does not end the TLS session appropriately. TCP session is terminated by the client, 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 is in control to end TCP connection between the server and the victim by sending the particular TCP packet. The FTP client will then try again to upload with REST than the attacker Clear Command Channel has access to this data, he knows precisely what part of the victim's file continues 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 being processed by 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.

Summary of Protocols

Protocol

Impact analysis available

Current status

HTTPS

Yes

1. Vulnerable to a certain extent, impact may rely 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)

EAP-TLS

Online discussions

Believed to not be vulnerable

IMAPS

No

Unknown

POP3S

No

Unknown

LDAPS

No

Unknown

SMTPS

Yes

Vulnerable only if certain requirements are met

FTPS

Yes

Vulnerable - Further research required

Application

Impact analysis available

Current status

OpenVPN

Partially (vendor)

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

Tomcat

Partially (vendor)

Vulnerable - mitigations exist

Apache

Available

Vulnerable - short term patch available

IIS 7 <=7.5

Available

Vulnerable - not vulnerable to if client initiates renegotiation request.

GNUtls

Available

Vulnerable - patch status unknown, IETF proposal currently being implemented

OpenSSL

Available

Vulnerable - short term patches available

http://www.pubbs.net/openvpn/200911/19535/

http://www.mail-archive.com/users@tomcat.apache.org/msg69335.html

EAP-TLS

This protocol in believed not to be vulnerable. For the reason when EAP-TLS is executed no application protocol is involved. It uses TLS key material, but no tunnel 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:

Server:

Short term: Disable all renegotiation capabilities

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

Client:

Mid-term : For handling renegotiation request and TLS extension tracking the proposed IETF solution can be Implemented.

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.

http://www.openssl.org/

Vulnerability requirements

The preconditions for a TLS or SSLv3 connection to be vulnerable are

1. The server acknowledges and accepts full TLS renegotiations in the middle of a connection and after the initial handshake and

2. The server assumes that both TLS sessions were negotiated with the same client and

3. The server treats both sessions as one and merges them at the application layer

As such this vulnerability might not been seen as a vulnerability in TLS but the as the bad choice to merge two different requests together by the endpoint.

Conclusions:

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:

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

Similarly, the applications are vulnerable which assumes 2 TLS sessions are from one client.

Clients:

Clients remain vulnerable for the lack of detection to check if and when a renegotiation triggers.

https://svn.resiprocate.org/rep/ietf-drafts/ekr/draft-rescorla-tls-renegotiate.txt

http://www.allaboutjake.com/network/linksys/ftp/

CHAPTER 6

recommendation for ssl Future

SSL holds a very key role in the securing transmission in future. Most Certificate Authority (CAs) are using SSLv3 as their preferred solution. The new advancements are underway which makes SSL more concrete. Now a day's 256 bit SSL encryption can be implemented. CAs like Verisign are driving the internet business to new level, as their sign provides reliability to customers. More needs to to done to prevent attacks causing inconvenience and invading people privacy. SSL competitors are also emerging such as Private Communication Technology and Secure Electronic Transmission. SSL still seems promising to lead the future. However, continues improvisation is at large.

CONCLUSION

Secure Socket Layer (SSL) has helped to develop high level trust between the consumer and businesses. For the last decade it has changed our way of shopping and added a whole new experience to our lives. It has brought home convenience and peace of mind. Similarly, we have observed millions of online Small Medium Businesses grow at a rapid pace.

On the other hand, the method of attacked explained in this report clearly demonstrates that SSL can be exploited in a number of ways. The lope holes are much greater concern. Reports of internet fraud suggest that internet fraud is on the rise. SSL cannot be held accountable for all the internet fraud. Millions of pound falls into pray in the hand of imposter. The public and private key infrastructure is sound. The main concern is when the communication between the client and server can be intercepted as shown in the report. There needs to be more improvisation and detection on client side mechanism which tells the client more reliably if and when there is an unprecedented attempt. Much more needed to be done to save the credibility and maintain the trust of customers.