TLS protocol vulnerable to Man In The Middle attack – Opera Security Advisories


A vulnerability has been discovered in all current versions of the SSL and TLS protocols, that may allow an attacker to inject data and instructions into the HTTPS connection and trick the server to believe the date and instructions came from the client.

The attacker accomplishes this by first establishing its own secure connection to the server, sending a partial request to the server, and starts forwarding the SSL/TLS handshake data from the clients, triggering a renegotiation of the SSL/TLS connection’s security parameters. In some cases such a renegotiation involves establishing secure identification of the client, such as with Client Certificates, and the server incorrectly uses these credentials to authenticate the data and instructions injected by the attacker, triggering unauthorized transactions made in the name of the user. Similar attacks can be mounted against the client.

The cause of the problem is a lack of a cryptographic association between the first set of security parameters on the SSL/TLS connection, and the parameters resulting from the renegotiation, meaning that the client and server are not aware that the other renegotiated the connection.

The IETF TLS Working Group has defined an update of the TLS protocol that binds the security parameters of the first connection state with the renegotiated security parameters, and allows detection of an attempt to inject data. The update will only work if “both” client and server have support for the new functionality. If either side does not support the new functionality the connection is still vulnerable, though the patched side can detect that the other is unpatched.

This problem affects the HTTP over TLS protocol (HTTPS), as well as IMAP, POP, SMTP, IRC, and NNTP over TLS.


Moderately severe

Opera’s response

Opera Software has released Opera 10.50 on Windows, 10.52 on Mac, and 10.60 on Linux and FreeBSD, where the client side part of this issue has been fixed. For the user to be protected the secure server use by the Web site the user is accessing also has to be patched. If the server has not been patched the user is still vulnerable to the described attacks.

While Opera will allow access to unpatched servers at the present time, a notice about the server vulnerability is provided in the Security Information dialog which is available when clicking on the security toolbar in the address bar.

Within a few months, dependent on server patch upgrade rates, installed versions of Opera will be auto updated (via a preference) to display a a certificate warning dialog about the unpatched servers. The user may add an exception for these servers, but no padlock will be displayed for these sites.

Some months later a further auto update will disable support for unpatched servers entirely.

The introduction of the warning step and the complete disabling step will be coordinated with other browser vendors and an announcement will be made in advance of the update.

Users that wish to be warned about unpatched Web sites before Opera Software updates their client to show a warning, can add the flag value [X] to the preference [Y]. If they want to block all access to unpatched sites they may use the value [Z] instead.

Note to SSL/TLS server vendors

Opera’s implementation makes the following assumptions about patched servers:

  • The server correctly implements the SSL/TLS version negotiation algorithm where the client identifies its highest supported version, which for Opera is TLS 1.2 (protocol version 3.3). Opera will NOT perform version fallbacks against servers supporting the Renegotiation Info extension, but will report a connection failure. The server may still only support an older version of the SSL/TLS protocol, but must accept that the client identifies a higher version.
  • The server correctly implements support for TLS Extentsions, also if the server only supports SSL v3. All TLS connections from Opera to patched servers will use TLS Extensions.


The vulnerability was originally discovered by Marsh Ray, and independently discovered later by Martin Rex.

The specification for the updated protocol was authored/edited by Eric Rescorla and others, together with members of the IETF TLS WG mailing list.


The specification:

Discussion of the problem