I think he means higher level frameworks, web programming libraries, toolkits, and web page builder stuff; not hooks into SSL sessions. Not to say that a hook into an SSL session is not a good place to get an application sessions identifier from -- it would be, presuming that you can't trick a browser into adopting someone else's SSL session.
I wouldn't know one way or the other if these higher level frameworks fall victim to the session adoption problem as I haven't used them; but it seems plausible that there might exist some that do. If this were the case it would be quite bad as there would presumably be many users of them who had relied on the security of the high-level framework. But I would be suprised if most or many of them did for similar reasons to the reason people are expressing doubt that many hand coded login pages would be affected: it seems like generally a mistake natural login and session managing web programming idioms would not lend themselves to. Adam On Sun, Jun 15, 2003 at 05:52:17PM -0400, Rich Salz wrote: > > The framework, however, generally provides insecure cookies. > > No I'm confused. First you said it doesn't make things like the > session-ID available, and I posted a URL to show otherwise. Now you're > saying it's available but insecure? --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]