-----Original Message-----
From: Peter Conrad [mailto:conradtivano.de]
Sent: Friday, July 26, 2002 3:28 AM
>But, as others have pointed out, SSL session IDs are not persistent enough.
>And while I'd like to blame MS for this 'bug' I must admit that the SSL
>spec does not require to resume previously established SSL sessions in
>the next handshake, so actually this is not a bug at all.

>Thinking about it it even makes sense: in SSL you use client certificates
>for authentication. SSL session IDs are merely useful to prevent some
>expensive computation from being repeated over and over again...

Actually, SSL specifically uses a keyed hash on messages in both directions
even in the absence of client certificates - to preclude a third party from
tampering with the communication channel once it has been established. So in
a sense, it provides continuous authentication of the channel. Even though
it might not know with whom it is authenticating, it does know that it is
the *same* person throughout the SSL session. And this makes sense - because
maybe you want to handle the authentication at the application level, where
you first establish a secure channel and then use it to exchange shared
secrets for mutual authentication? (For example, usernames and passwords.)

Of course the SSL protocol allows either client or server to renegotiate SSL
sessions whenever they please, kind of like how a user is free to close and
reopen his/her browser anytime they like. However, the user should not be
surprised that he needs to log in again when he does this. Similarly, it
would be plain stupid for a user's browser to renegotiate the session except
when requested by the user or at times that will be considered "reasonable"
by the user (e.g. when the browser window is closed and reopened). Designing
and implementing a secure, anonymous but authenticated channel and then
renegotiating every second makes as much sense as installing a fancy Medecco
deadlock in addition to the cheap kwickset knob lock, and then leaving the
Medecco unlocked and using only the kwickset. You already paid for the extra
security - you might as well use it!

There was also a question of what makes the SSL session better than cookies,
if the cookie is encrypted anyhow. The answer is that cookies are designed
as general-purpose programming tools, and the software at both the server
and client sides (where the data is unencrypted) are designed to offer many
ways to access this data. Cookies are designed for easy access. Locking down
all possible ways of accessing this information (e.g. client-side javascript
through a cross-site scripting attack) is therefore difficult and
error-prone. The SSL session key, on the other hand, is specifically
designed to be secret, and its exposure is deliberately minimized at both
ends. If the SSL layer was used to provide a sense of the application-level
session, then the feasability of session hijacking would be the subject of
debate in the journals of cryptographers, rather than the past-time of
script kiddies.

Ben

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]