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.


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]

Reply via email to