Re: RE: HTTPS security model
"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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
--
-Kyle H
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: RE: HTTPS security model
> > 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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
RE: RE: HTTPS security model
> > 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 Listopenssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: RE: HTTPS security model
On Wed, Dec 06, 2006 at 07:16:32PM +, [EMAIL PROTECTED] wrote: [ Authentication vs. Authorization ] Yes, the real issue is that encryption without authentication does not necessarily provide confidentiality, the party on the other end of the encrypted connection could be the same attacker that motivated the encryption of the traffic, only this time the attacker is active (MITM) rather than a passive eavesdropper. I rarely bother with mandatory encryption without authentication, the security model is questionable... -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: RE: HTTPS security model
> I don't understand this argument at all. The two questions you > seem to
> think are being confused are the *same* question.I don't think so.> When I
> type in "https://www.amazon.com";, what I want> to know is - do I have a
> secure connection to Amazon?This is an authentication question.> A secure
> connection to someone who is out to steal my> credit card is not really any
> better or worse than in > insecure connection to Amazon.True. > 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. >
> Authentication and authorization are the same thing.Absolutely not!
> Authentication is "who I am talking to". Authorization is "what I allow you".
> Indeed, usually authorization is meaningless without authentication (not
> always: many systems have the policy "and everybody outside of the group of
> authenticated peers shall be allowed only ...").> They are both requiredThis
> 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.Note that authorization often is degraded to
> "allow or deny login", based on wheher the peer authenticated correctly or
> not.
