Firefox 38 and SSL/TLS servers that are TLS version intolerant

Updated -

Transport Layer Security (TLS, formerly known as SSL or Secure Sockets Layer) is a cryptographic protocol designed to provide secure communications over a network, mainly the internet.

(See also: )

TLS is used by many Internet applications. A popular example is web browsers like Firefox that use the https protocol, which combines http with TLS to securely retrieve information from web servers.

Version 38 of the Firefox web browser will introduce a change in behavior related to the way it handles the TLS and https protocols. This article explains which changes were made, why they were made, what the consequences of the changes are, and how users could potentially work around problems related to these changes.

At the time a communication session is started, both sides of the communication channel (e.g. the web browser and the web server) begin with an introductory phase, where both sides agree to how they would like to secure the channel. This step is necessary because the TLS protocol evolves over time, and either side might have limited capabilities, such as being limited to older versions of TLS.

In the introductory phase, which is also called the TLS handshake, both sides indicate which version of the TLS protocols they are able to use, and an agreement is reached on which protocol version will be used. For example, the browser would propose connecting using the TLS 1.2 protocol. If the web server didn't support TLS 1.2, it could propose connecting with TLS 1.1. The browser would agree and the session would proceed with the TLS 1.1 protocol.

Because at the time of the handshake a secure communication hasn't been established yet, it's a phase an attacker might try to manipulate. A popular attack is the Man In The Middle (MITM) attack, where an attacker is located in the middle between client and server, and is able to intercept data packages sent to either side. One attack is to cause the web server and the browser to negotiate an older version of TLS or SSL that is less secure, potentially allowing the data to be decrypted. Since the TLS handshake protocol is secure, it is difficult to attack directly. However, simply by causing the connection to fail, the MITM can cause the web server and browser to negotiate an older version of TLS.

Firefox 38 has been changed to make it more difficult to trick the client and the server to use an older, less secure version of the TLS protocol.

The TLS protocol allows a client, e.g. a browser, to tell the server the newest protocol it is able to use. If the server supports the TLS protocol, but only an older version of the TLS protocol, the server can inform the client, and the client may decide to continue with the connection.

Because client software evolves much faster than server software, it is often desirable to allow a more modern client to communicate with a server that supports an older version of TLS.

Still, there is a higher likelihood that attackers might have found ways to attack the older versions of TLS, therefore the newest versions should be used whenever possible.

Unfortunately, among the large variety of server software that is deployed on the public Internet and on private Intranets, server software exists that contains flaws in the way it implements the TLS protocols. Some servers simply disconnect when they see a version that they don't support, instead of using the TLS handshake protocol to negotiate the version they would like to use. (This behavior is known as TLS version intolerance.)

In the past, many occurrences of bad implementations were seen, which caused the developers of client software, such as web browsers, to implement workarounds for enhanced interoperability.

In the past, if Firefox attempted to use the newest TLS version 1.2, and the server simply disconnected, Firefox retried to connect using TLS 1.1. If that failed again, Firefox retried to connect using TLS 1.0. (If that failed again, some older versions of Firefox might have even retried using the older protocol SSL 3.0, but this has been disabled by default already, because the SSL 3.0 version has been considered insecure since the POODLE security issue.)

By default, Firefox 38 will no longer retry the connection if the initial attempt with TLS 1.2 failed. Firefox 38 will permit the use of the older TLS versions 1.1 and 1.0 if the server uses the TLS handshake protocol to negotiate these versions.

This means, by default, Firefox 38 will no longer work with servers that are TLS version intolerant. This is intended behavior to address the security issues with TLS version fallback.

The justification for this new default is the automatic retry can be abused by a MITM attacker to trick a client that supports TLS 1.2 and a server that supports TLS 1.2 into using an older protocol like TLS 1.0.

If Firefox were willing to retry, the attacker could simply block the communication attempt that uses TLS 1.2, without telling the server. Firefox would incorrectly conclude that the server is unable to speak TLS 1.2, and would retry with older TLS versions.

By changing Firefox to not retry and not request to use an older TLS version, this kind of MITM attack no longer works.

Because the number of servers that are TLS version intolerant has decreased constantly during the previous years, the developers of Firefox and other modern browsers have decided that disabling the automatic fallback is reasonable, as it affects compatibility with a small number of servers only. Also note that web servers that are TLS version intolerant do not conform to the TLS specification.

Nevertheless, users of Firefox 38 might be affected by this change, and connections to some servers might stop working.

If a connection fails because the server is TLS version intolerant and the server simply disconnected, Firefox might display an error page containing an error message identical or similar to:

"Secure Connection Failed. The connection to HOSTNAME was interrupted while the page was loading."

Unfortunately, there are other scenarios that could produce the same error message, such as a network connectivity issue, so the diagnosis of this condition might not be trivial. Because no error message was sent by the server, all the client knows is that the connection was interrupted, but the client doesn't know why.

The best course of action is to verify the correctness of the server address the user attempted to open, and if the error message still occurs, to get in contact with the administrators of the affected server, tell them about the incompatibility of their server software, and ask them to upgrade their server software to a more modern version that fully supports the TLS protocol.

Should a user decide that it's necessary to connect to a specific server anyway, it is possible to use Firefox configuration settings to override the Firefox default behavior.

The preferred mechanism is to use a whitelist configuration, that instructs Firefox to retry with older TLS versions only for the whitelisted servers. Essentially, this restores the previous Firefox behavior for servers on the whitelist. Alternatively, if you are required to connect to many different servers that have this incompatibility, it might be too cumbersome to enter all of their hostnames into the Firefox configuration. In this case, you could use an alternative configuration mechanism that restores the old Firefox behavior to always retry the connection with older TLS versions for all URLs.

The procedure for both of these methods is documented in the following Red Hat Knowledgebase Solution:

Red Hat will be releasing Red Hat Bugfix Advisories (RHBA) for Red Hat Enterprise Linux 5, 6 & 7 for the Firefox web browser that contain the changes described above in mid May 2015.