Good article!
On 01/12/2009 01:38, Nelson B Bolyard wrote:
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.
What is the use case for multiple sessions? Is this something like the logic of trying to speed up the throughput, like SPDY (spelling? the google idea for speeding it up) or DTLS?
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.
What is the use case for multiple sessions with different identity pairs over a single TLS connection? I don't know if it is just me, but this seems quite ... odd?
Maybe it was to accomodate the Apache HTTPD's desire to allow multiple identity settings per directory?
... It is unfortunate that the original designers are being smeared as having erred when (I suspect) they did not.
I think it is probably unfair to smear them. The protocol had a good run with no real harm until today. The designers did a pretty good job with the circumstances (including some ropey assumptions and not a little politics). Mismatches in expectations occur all the time in the real world, what is somewhat surprising is this one took so long to surface.
If there is a flaw, it is not so much in the protocol, but more likely the committee and the user communities, locked in a deadly embrace of telling each other the protocol is the perfect tool for all purposes.
Thanks for the update! We can't all spend time in every forum. iang -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
