('binary' encoding is not supported, stored as-is) In-Reply-To: <NAEOJLMPJMJDFPLHIOJOAEAIDAAA.bmordicon-nicholson.com>

In fact, you should never expect SSL reach your
application! The SSL may terminate at an SSL offLoader,
a load balancer or an application firewall which is
used to protect your application by filtering user
data. So your application receives only plain text.

And an URL can have multiple cookies. You can use one
cookie for authentication only like in the SSL and other
cookies for other use.

-----Original Message-----
>
>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 ]