> > There are security paradigms such as SSH where you use "leap of
> > faith": strictly you haven't authenticated the remote end, but you
> > "know" that your peer is the other box next to you, you
> > verified its PK fingerprint visually, so you approve ("authorize")
> > that peer from now on.
>
> You are directly contradicting yourself. You say SSH is an
> example where you don't authenticate the remote end and then
> proceed to explain how you *do* identify the remote end.
"Leap of faith" comes when the user does not verify the peer key
fingerprint, but (99.999% of cases correctly) assumes that the computer he
just connected to (for th first time) is the correct peer. Theoretically it
is not necessarily so, practically it's good enough in most cases. From that
point on, the observed public key is memorized to properly authenticate the
peer.
> In fact, SSH's security model is much the same as HTTPS -- if
> the remote end does not present a certificate that proves it
> is the correct endpoint, the user is forced to manually
> approve the connection. Same thing.
Comparable...
> > > Authentication and authorization are the same thing.
>
> > Absolutely not! Authentication is "who I am talking to".
>
> > Authorization is "what I allow you".
>
> You are changing the context. Obviously, in a very general
> case, authentication and authorization are the same thing.
Hope you meant to say "not".
> But we're talking about HTTPS.
>
> In the case of HTTPS, 'authorization' is the question of
> whether the connection is secure from third parties, those
> other than the endpoint of the SSL connection. In the case of
> HTTPS, 'authentication' is the question of who the other endpoint is.
> In this case, they are the same thing. They are both needed
> to make sure the legitimate party is the only party, and that
> is the *only* thing you care about. It is not possible nor
> sensible to separate them.
OK.
> Let's go back to what I'm replying to:
>
> :The difficulty for the end user here is that the little lock icon is
> :overloaded: it is taken to mean both "session is secured
> against :spying" AND "session is with a trusted partner".
> One could argue that :this confounds authentication
> (verifying the cert.) and authorization :(asserting trust of
> the target site).
>
> If there's nobody the communication needs to be secure from,
> there is no need for security at all.
Yes, but this is not the case.
> If there's somebody the
> communication does need to be secured from, I am just as
> screwed if they are a spy or if they are the endpoint of the
> connection. Soi they are the same question -- there is no overloading.
Proponents of the requested change believe that it is much likelier to have
your communications observed by a passive attacker, than to have an active
attacker in the path that masquerades as e.g. "amazon.com". Not that the
later is impossible - just less probable and less frequent.
I'd adopt the change and created a new icon - say a small "fence" instead of
a small "lock" to denote that the link is encrypted but the peer is not
authenticated. :-)
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
