At Mon, 2 Nov 2009 16:45:37 -0500, Steve Kent wrote: > > At 12:19 PM -0500 11/2/09, Rob Austein wrote: > >At Mon, 2 Nov 2009 11:07:40 -0500, Steve Kent wrote: > >> > >> I am not sure what motivates Rob to say that he is not convinced > >> about the extent of the session security offered by HTTPS. (Is it > >> related to the session resumption feature in TLS?) > > > >Nope. It's related to HTTP not really having any such thing as a > >session to protect. It is of course possible that we all (or perhaps > >just I) misunderstood your advice, in which case please expound. > > In the TLS context I think of a session as the set of traffic sent > after the TLS handshake completes and before a new handshake occurs, > between the same pair of IP addresses. Yes, there is no explicit end > of session message in TLS, which makes it hard to define the end of a > session. However, if a server times out an inactive session, the > client will need to perform a handshake to re-establish it, so there > is an opportunity for the server to unilaterally end a session at any > time. Since the goal of using TLS here is to help protect servers, > this seems like a reasonable strategy. (And as I noted above, a > session resumption request by a client can always be rejected by a > server.) Any received traffic that is not protected under the keys > established at the start of the session will be rejected. I assume > that a new handshake should cause the old keys to be replaced. So the > server is well-positioned to decide when a session has ended.
I think we are talking slightly past each other, and have been on this topic all along. I said "HTTP", you seem to have read "TLS". HTTP has no real notion of a session. Even with persistent HTTP connections, the server is free to blow away the connection after the first request/response cycle completes. There's some attempt at letting the server tell the client what timer value the server is using, but between the mishmash of HTTP versions doing things different ways and the ad hoc nature of early attempts to support persistent connections, the advice I was able to find all said to ignore that. So all a client can really do is request a persistent connection if for some reason it wants one, and hope for the best. This means that a client can't rely on the server ever leaving the connection open for more than one request/response cycle, so the notion of insisting that a series of request/response cycles MUST happen in the same "session" to avoid replay is a bad fit. Wrapping HTTP in TLS doesn't fix HTTP's weird semantics. Most web-based protocols that implement sessions do so on top of this entire mess, using cookies or URL tricks or application data. At the moment we're not doing any of that. Remember that the reason we were originally told to use TLS here was replay protection. I know you keep saying server protection, but that's not how we originally got here. I'm not seeing much replay protection in what we've implemented to date, which concerns me, as we added a fairly heavyweight mechanism that as far as I can tell has not solved the original problem. My implementation uses OpenSSL's TLS code directly, thus I could, in theory, peek at TLS session data structures and hook into OpenSSL's TLS callbacks to figure out whether this is the same TLS session or not, using your definition of "session" (above). Sounds a bit painful, but is probably doable. Question is whether it's worth it, or whether there's some better way to handle the threats. I'll let APNIC speak to how much of a problem this would be for them. _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
