This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
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:
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 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 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.
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
E:\Dissertation work\Figures\attack 2.png
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
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).
E:\Dissertation work\Figures\attack 2..png
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 proof can be found at: http://www.g-sec.lu/tls-ssl-proof-of-concept.html
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.
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 made to the server. Trace controls response from the server within its limitations.
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.
There are two important ways TLS can be used with SMTP.
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 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
E:\Dissertation work\Figures\attack 4.png
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.
According to this research this vulnerability may not affect POSTFIX.
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. Please note the description http://www.allaboutjake.com/network/linksys/ftp/ for more insight into FTP connections.
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 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 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.
Impact analysis available
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)
Believed to not be vulnerable
Vulnerable only if certain requirements are met
Vulnerable - Further research required
Impact analysis available
Not vulnerable, does not depend on openssl session capabilities - session handling was strickened after disclosure reports
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 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.
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 to track TLS extension.
Mid-term : For handling renegotiation request and TLS extension tracking the proposed IETF solution can be Implemented.
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.
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.
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, the applications are vulnerable which assumes 2 TLS sessions are from one client.
Clients remain vulnerable for the lack of detection to check if and when a renegotiation triggers.
Revisit and finish understanding SSL
Open SSL as a chapter
Revisit Pdf file open ssl
Verisign for a new chapter
Abstract and others and conclusion.