TLS Renegotiation

Overview

TLS Renegotiation is a feature of TLS that allows both sides of a secure connection to renegotiate the terms. This feature is one of the most problematic and fragile parts of TLS, and infamously resulted in the 2009 SSL/TLS Renegotiation Attack (CVE-2009-3555). Renegotiation was completely removed in the latest version of TLS (v1.3). However, the Logbook server relies on this feature to function. It may be possible to use the new TLSv1.3 Post-Handshake Authentication (PHA) instead at some point in the future, but at the moment PHA appears to be poorly supported.

Problems relating to Renegotiation seem to crop up when the Logbook server or client software is upgraded.

Renegotiation is needed to allow the logbook server to use one-way TLS for most of the server, but allow two-way TLS (with client certificates) for a single resource path (/incoming). In summary:

• To submit a log entry an HTTP PUT request is sent to the logbooks server at path /incoming
• To ensure only authorized users are making log entries the PUT request is required to be done using two-way TLS
• The wrinkle is that the logbook server only requires one-way TLS on initial session establishment, and for all URL paths EXCEPT that one special path /incoming

Details

TLS Renegotiation is a dark seedy corner of TLS and the exact details of how this works changes depending on TLS version, HTTP version, and server and client versions (Apache httpd server and Java client libraries).

Early implementations of TLS Renegotiation attempted to minimize back and forth requests by simply holding the original request in a cache server side while the renegotiation occurred. This turned out to be very problematic because the request could be very large and overflow the server cache/buffer.

An HTTP/1.1 Expect header was introduced to help with the cache overflow problem.

TLSv1.3 introduced Post-Handshake Authentication (HPA), which supersedes use of TLS Renegotiation, but this does not play nice with Java and HTTP/2.

Other common issues that may get in the way while troubleshooting:

• The client cert expires periodically
• The client cert key size (encryption) may be too weak with a newer more strict logbook server

Note: It may be possible to avoid renegotiation all-together if a totally separate virtual host was configured on the server. For example, if there was an upload.logbooks.jlab.org, then renegotiation would be avoided. This would result in technically two separate logbook server apps, instead of one. There would also likely need to be a totally independent TLS certificate. It's possible we could attempt to rely on a certificate with a Subject Alternate Name, or possibly a wildcard certificate, but we'd need to verify that renegotiation was not initiated.