I seem to be fielding more and more questions of late around the rather well-known SSLv3 and TLS renegotiation flaw. For those who aren’t familiar, the TLS renegotiation flaw allows the injection of data into a SSLv3 or TLS stream, potentially causing data injection or the program to misbehave in some other fashion. It is not a full man-in-the-middle attack because the attacker can’t read what’s in the data stream, only inject into it. Ultimately, this is a protocol flaw—one that’s been fixed as an extension to TLS as dictated by RFC 5746—but adoption in SSL libraries has been relatively slow.
I’m seeing this come around how to deal with the flaw when it’s reported in a scan, such as a PCI ASV scan. If encountered as part of an ASV scan, it could result in non-compliance, which makes it a cause for concern. However, as with many flaws, the TLS renegotiation issue can be a false positive depending on the implementation of the system.
If the flaw is reported against a system that the scanner accesses directly—perhaps only passing through a firewall—then how to react to the report is pretty straightforward. In these instances, I have not encountered any circumstance in which the flaw might be a false positive if the service is allowing TLS renegotiation. The best recommendation in these situations is to disable TLS renegotiation if possible. In most cases, renegotiation is not truly needed.
Things get more interesting when load balancers are involved, at which point it depends on the how the load balancers are implemented. Usually, one of two basic approaches are used when implementing a load balancer between the internet and the service.
First scenario: the load balancer is completely responsible for handling the SSL. The SSL connection is received, and a new connection is established between the load balancer and the service. In this approach, the connection between the service and the load balancer may or may not be encrypted. In this implementation, if TLS renegotiation is enabled on the load balancer, it is not a false positive because the load balancer is responsible for the renegotiation taking place, and the flaw can manifest.
Second scenario: the load balancer passes through the connection to the service and never interrupts the SSL channel, so the end service decides whether TLS renegotiation occurs. It is this circumstance that can cause tests for TLS renegotiation to be false. The load balancer will report back to the scanner or tester that it handles TLS renegotiation, but it is, in fact, the service that is responsible. If the service itself does not support TLS renegotiation, the finding is very likely a false positive.
Secure Renegotiation has been added as an extension to the TLS protocol to support RFC 5746; therefore, if you utilize an SSL implementation it should support Secure Renegotiation. Otherwise, if an RFC 5746-compliant SSL library must be used (and unless there is an explicit need for TLS renegotiation to be enabled), it is recommended that you disable it.