"I have seen this certificate before, and I assert that I want to
allow it for limited purposes -- if only because I want to make sure
that third-parties can't see what URLs I'm looking at. I do NOT want
to post my credit card or other sites' login information to this site,
so warn me if I do so."
See, it comes down to "what's the trust anchor?" It's been fairly
well-established here that the trust anchor is the public key that
I've obtained that's is mathematically related to the private key that
can be verified with it. I can authenticate that trust anchor based
on a prior interaction or based on a third party through whom I've
obtained the fingerprint -- while techncially this makes the third
party the trust anchor, it can't be verified mathematically, so the
computer's idea of the trust anchor is the key associated with the
fingerprint that I've already fed it.
This is the example which points out the false black & white
bifurcation of your view: I want to authenticate that I'm talking to
who I think I'm talking to, but I don't want to give it every
permission that the browser vendor forces me to. i.e., I want to
authenticate, and then separately apply the authorization step.
-Kyle H
On 12/6/06, David Schwartz <[EMAIL PROTECTED]> wrote:
> > 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]
--
-Kyle H
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
