> > A secure connection to an unauthenticated source is of
> > no value because the unauthenticated source could be
> > the one person who the connection is supposed to be
> > secured from. If there's nobody the connection is
> > supposed to be secured from, why would you care
> > that the connection is secure?
> In general this is false.
> 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. 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.
> > 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. 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.
> This is correct, of course. Because you cannot perform authorization
> (make decision) unless you know whose access you're deciding about.
> And unless you are going to make different decisions based on
> different peer identities - it makes no sense to authenticate.
Exactly.
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. 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.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
