On Friday, Chris posted an excellent technical write-up on the TLS Session Renegotiation vulnerability. As he mentioned, nCircle has recently experienced an influx of questions from customers regarding the vulnerability, specifically with regard to PCI.
The most important thing to understand is that the existence of this vulnerability will result in PCI non-compliance from an ASV's point of view. The reason for this is fairly self-explanatory: the CVE (CVE-2009-3555) has a CVSS score of 6.4 and anything over a 4.0 is a fail in PCI-land.
When this vulnerability was first announced I was one of the first to say that it wasn't a "sky is falling" situation (like Conficker was) and I still believe that I was correct. That doesn't mean that I feel this vulnerability is insignificant and from a PCI standpoint, I think it addresses one of the key security aspects that merchants need to focus on; TLS, aka securing communication between the customer and the merchant website.
Q: What is the primary goal of PCI?
A: If you said, "The protection of cardholder data", then you're theoretically correct.
The primary means of protecting that data when it is entered into a website is that little technology that we call TLS. Many years have been spent trying to teach users to check for that yellow lock (and now the green bar) and to get them to trust it. It's not enough that merchants undermine these teaching attempts to save a buck or due to incompetence, now we have a flaw that undermines the protocol itself.
So how do we protect users at this point? We turn off legacy TLS Session Renegotiation and remove the flaw from the protocol implementation. The IETF is working on the latter and it's up to ASVs everywhere to ensure the former while we wait. So if you're dealing with nCircle, or any competent ASV and have this vulnerability, expect us to document it and report you as non-compliant until you resolve it.
