There are two schools of thought about the vulnerabilities related to the use of renegotiation in SSL 3.x (including TLS 1.x). Briefly, they are: a) It's SSL/TLS's fault, a failure in the design of renegotiation, or b) It's the fault of the applications that assume (incorrectly) that all sessions over a single SSL/TLS connection are necessarily between the same two parties.
SSL 3.x's renegotiation feature allows a single connection to switch over time between one "session" and one or more other sessions. It allows new sessions to be created, and/or old sessions to be resumed. It is possible for a pair of peers at the ends of a TCP connection to switch back and forth (to "multiplex") repeatedly between two or more sessions on a single connection. Each of those different sessions may be associated with a different identity than the other sessions, at either end. One session might represent one client user, and a second session might represent another client user. By the same reasoning, one session might represent one virtual server, and another session might represent another virtual server. When a particular session is resumed, SSL/TLS does offer cryptographic assurances that it is between the same pair of identities as before, but SSL/TLS make so such assurances about the pairs of identities between one session and another. Seen in this light, the SSL/TLS renegotiation facility is not flawed at all. It is simply a mistake of any client or server product to assume that all the sessions on a SSL/TLS connection represent the same pair of client and server identities. The trouble is that for the last decade or so, everybody and his brother (including me, I must admit) misunderstood the SSL/TLS renegotiation feature's capabilities and purposes. They/we ASSUMED that it offered the assurance that all sessions were between the same pair of (id)entities, and when they learned that it did not, they did not say "Oh, we've had a bad assumption all along". They said "It's terribly flawed and vulnerable!" In some sense, the question is: what was SSL/TLS _INTENDED_ to do? Was it intended to offer the assurance that everyone assumed it did? If so, then indeed it had failed to do that and is flawed. Or, was intended to offer what it actually offers, session multiplexing, in which case it is not flawed at all? At present, the IETF TLS working group appears to have decided that it was intended to have offered the assurance that everyone assumed that it did, but actually did not. They (we) are working on defining a new form of renegotiation that does offer that assurance. I suspect that in the next version of TLS, that will be the only form of renegotiation defined, and that the older session multiplexing form that offers no such assurances will no longer be offered. I suspect that is no real loss, in practice. Personally, I have sat of both sides of this issue. I think that it was probably the original intent for the renegotiation feature to offer multiplexing without any assurances of tying of identity between sessions. But I think the market now demands those assurances, so it is probably good to make this change. It is unfortunate that the original designers are being smeared as having erred when (I suspect) they did not. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
