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
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
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.
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
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]
