On 2009-11-30 19:18 PST, Ian G wrote: > Good article! Thanks.
> 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? Well, I can think of numerous different uses of multiplexing multiple sessions over a connection ... if that multiplexing was efficient. > 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? No. The overhead of renegotiating, switching from one session to another, is at least as great as the overhead of a new TCP 3-phase connection. If you had, say 5 sessions to multiplex, and you used 5 connections, you'd do 5 3-phase connections, one for each session, and that's it. But with SSL multiplexing, you go through that overhead each time you switch from one session to another. It's like paying the overhead to disconnect and reconnect. So, it's definitely not a performance win. >> 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? Well, again, if it was efficient, one could imagine lots of uses. Any of the usual reasons for multiplexing would apply. > Maybe it was to accomodate the Apache HTTPD's desire to allow multiple > identity settings per directory? I don't think so. The original rationale I heard for mid-connection renegotiation was to facilitate re-keying the connections after a certain amount of time or number of bytes had used the old keys. This use case would seem to likewise assume that the identifies don't change when the re-keying occurs. I think the multiplexing angle just fell out of the combinatorics. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
