4 posts categorized "tls renegotiation"


Disabling TLS Renegotiation in Apache

Let me begin by saying "Don't do this unless you are absolutely certain of the nature of ssl connections connecting to your Apache servers!"  OK, with that out of the way, if you need to disable TLS Renegotiation on your Apache sites look to version 0.9.8m or higher of OpenSSL.  From my reading of the release notes, the only production quality version of Apache that is compiled with OpenSSL v0.9.8m is Apache 2.2.15.  This means that if you are still using version 1.3 or version 2.0 and SSL, it's really time to upgrade to 2.2.

Apache v2.2.15 binaries or source when compiled against OpenSSL v0.9.8m actually fixes the TLS renegotiation vulnerability.  If you download the source to compile it yourself and compile against a version of OpenSSL older that 0.9.8m, you will not have these fixes. Unfortunately, the fix needs to be available from the client that is RFC 5746-compliant as well so v2.2.15 introduces a new directive: SSLInsecureRenegotiation that will allow for backwards compatibility for those connections or applications that need them. Enabling this directive though re-introduces the TLS Renegotiation vulnerability however.

I'm maintaining a list of potential issues when TLS renegotiation is disabled on my post from last week. If your customers are not connecting to your apache servers using one of these methods, you should be ok and should not need to worry about setting the SSLInsecureRenegotiation directive but for this upgrade, I do recommend spending more time on regression testing.

If you compile your apache implementation against OpenSSL 0.9.8l, you will completely disable TLS renegotiation. Personally, I would try to stay away from this.

If you need to enable old-style renegotiation, add the following to your SSL configuration on your apache servers:

    SSLInsecureRenegotiation on



Java's Recent SSL Problems

This ultimately adds more fodder for my recent post regarding SSL but Oracle seems to be having a few problems with SSL and TLS too lately.  Outside of disabling TLS Renegotiation in Java 1.6 Update 19, which has the potential to cause us quite a few headaches, Update 19 also broke a lot of ssl connections that utilized perfectly valid ssl certificates signed using the older MD2/MD5 root certificates.  Java applications typically would see exceptions like this one in their logs for this particular bug:

sun.security.validator.ValidatorException: PKIX path validation failed: java.security.cert.CertPathValidatorException: algorithm check failed: MD2withRSA is disabled

Fortunately for me, at least, this didn't cause too many issues for my site's customers and the issue finally appears to be fixed in Update 21 but, boy, Update 19 sure wasn't a very pleasant update for me professionally.  My gentle reminder to anyone running JVMs is do not enable that Automatic Update option on your servers or important client systems and read those release notes very carefully!


TLS Renegotiation Remediation is Going to be Unpleasant

I was contacted by my colleagues in network engineering late last week to investigate what could possibly be causing a production issue that had started earlier that same week. An in-house client application making soap calls over an ssl connection periodically for data provided by a third party financial services firm began failing and they suspected a change somewhere in the network being the cause since "nothing changed in the application". The very same app continued operating just fine going to the exact same web service in an in-house test environment. Access to the service at the financial services firm was over ssl/tls-only and restricted by client certificate.

Below is a sample of the log for this web services client application:

16-Jul-2010 14:54:28 org.apache.commons.httpclient.HttpMethodDirector authenticateHost
WARNING: Required credentials not available for BASIC @redacted.host.tld:443

16-Jul-2010 14:54:28 org.apache.commons.httpclient.HttpMethodDirector authenticateHost
WARNING: Preemptive authentication requested but no default credentials available

16-Jul-2010 14:54:28 org.apache.commons.httpclient.HttpMethodBase readResponseBody
INFO: Response content length is not known
javax.net.ssl.SSLException: HelloRequest followed by an unexpected  handshake message

Later, the systems administrator informed me that they were able to workaround the issue by setting a system property at initialization of the jvm:


Ultimately, what this turned out being was an update of the JVM on the production boxes from whatever version was there previously to version 1.6.0_20. As we all know, java updates for the most part are cumulative and update 19 added what Oracle calls an "interim fix" for the TLS renegotiation vulnerability. I won't go into detail about the TLS Renegotiation vulnerability here—there is an excellent write up about it on the Educated Guesswork blog that I'm linking to, if you want to know more.

In a nutshell, version 1.6.0_19 disables TLS Renegotation by default. I think in the case of an ssl or tls connection that requires authentication by client certificate, the initial connection is made to the server by the client, then the server responds with a 403 looking for a client certificate. The client then renegotiates the session presenting the client certificate. The change to the jvm behavior due to the TLS Renegotiation vulnerability breaks this. In the case of a java application using the apache httpclient, it fails with a javax.net.ssl.SSLException: HelloRequest followed by an unexpected  handshake message exception.

Unfortunately, many vendors are utilizing this type of workaround while waiting for the TLS protocol to be fixed. As in Oracle's case, vendors, like Microsoft, are providing "patches" that simply disable auto renegotiation by default and letting support staff discover on their own when applications are broken. So, in case anyone finds this doing a search on the web, and because many vendors are not really providing examples of the types of applications and connections that _could_ fail should someone implement one of these patches, below is my draft list detailing the types of TLS/SSL connections that could fail. I have not personally tested or verified this list as it is an attempt to brainstorm potential issues so if anyone has any experience with them and knows that a particular item is incorrect, let me know and I'll update this post.

  • SSL or TLS connections to servers that require client certificates.
  • In apache specifically, if you upgrade encryption ciphers for specific sections of your site using Location directives, you could see problems.For example, if you specify Medium grade encryption as acceptable for most of the site and upgrade the cipher to a High grade one for login pages or Order Completion pages, this forces a renegotiation of the connection, which could break.
  • FTPS (also known as FTP-SSL or simply FTP over SSL) connections in Explicit Mode.
  • Secured LDAP connections where a STARTTLS operation is invoked and the existing unencrypted connection is upgraded to a secured connection.
  • IMAP, POP3, NNTP, and SMTP connections that step up to a secured connection. These also invoke a STARTTLS operation to renegotiate the existing connection using TLS.
  • I don't know of anything supporting it yet but connections supporting RFC 2817 - Upgrading to TLS Within HTTP/1.1 could potentially be impacted as well.