Re: HTTPS security model
Hello, Le 08-déc.-06 à 14:48, Victor Duchovni a écrit : Yes, the security of unauthenticated TLS is rather questionable. I, the guy who asked an innocent question at first in this long thread, have well understood this point from the very first two answers I got in this thread and passed to something else since. Thanks again for the initial useful comments. The remaining of the thread was... interesting. ;-) -- Olivier Mascia __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HTTPS security model
On 12/8/06, David Schwartz <[EMAIL PROTECTED]> wrote: I think that's kind of a crazy thing to say. For what possible reason would Microsoft want my credit card information to leak to a cracker? For what possible reason would Microsoft want my computer to be hijacked? It's unlikely that MS would want it -- but on the flip side, they also make it pretty trivial to happen. I think that has nothing to do with anything. Why even bother? Why not just trap my keystrokes and wait for me to enter my credit card info into any program at all? If you can take over my computer, why limit yourself to just what passes over HTTPS? Ah, another fundamental flaw in your view: Just because there's a "high-value" target available does not mean that "lower-value" targets lose their own inherent value. It just means that in your view, the target that you're protecting most because it's the one that you've been taught to fear for the most is the one that will be attacked the most. I don't want credit card numbers. So, you protecting your credit card number is useless against me. What if what I want is knowledge of what you're looking at on Amazon's site, so that I can figure out who to market my own products or services to and what pricepoint to do so at? Credit cards are high-value, so there's a specific process in place to deal with the information leakage. Less stringent safeguards are in place for other valuable data. A security model is defeated if it doesn't do what its implementers want it to do. If it does precisely what its implementers want, then the security model has done all it can do. It can't make the implementation what you might want and it's absurd to expect it to. Let's take that view, and apply it to "okay, now I start giving or selling certificates to websites so that my users can use them, and other users who don't have these certificates can't." While you see this as a fundamentally flawed process, there are situations (such as "I want my users to be able to use the servers that are connected to my network without having to go outside of it to get the content that they're serving, but I also don't want to have to publish the contents of these servers to anyone not on my network so that my own overhead goes up") where this is already the case, and already in place. The security model allowed is based on what the CA administration wants, not necessarily concruent nor even parallel to what the end user wants. The original security model as put forth in SSL2 and SSL3 was that the end user would get what the end user wanted. Not that it could be hijacked by anyone that the system happened to have a certificate for. > David, one of these days you will wake up and understand that the only > real way to have workable security is to have an educated user behind the > wheel. I think that's backwards. The user can *always* screw himself a billion ways. So long as the user can *only* screw himself, the security is workable. Security protects a smart user from a smarter adversary. Nothing protects a dumb user from themself. Except that security can also be said to "protect a dumb user from a smarter adversary". 'smart' and 'dumb' can refer to the same level of knowledge and ability to put that knowledge into practice. ...and while nothing prevents a user from posting his credit card information to Usenet, nothing (aside from contractual obligation, now) prevents the server from having such weak security that when the user sends his information to them as required to complete a transaction the credit card information is available to anyone who happens to know how to get to it. While it's true that you do need to be pretty smart these days to use a computer safely, I think that's unfortunate. It's sad that people have stopped using computers to connect with other people and learn about their world because they can't deal with the sophisticate assaults on them. ...so people should use Office to connect with people even in the face of multiple zero-day attacks that they don't have the means or tools to mitigate? I think it's unfortunate that you're /defending/ the current status quo. Things really can be easy to use without being dumbed down for those who want to get into the nitty gritty. It's just *hard* to get that right. Ah. You're describing the Macintosh. Which still doesn't have it completely right, but it's a LOT closer than Windows. (I don't mean to start a religious argument here... but you're holding onto dogmatic assumptions and presumptions that are preventing you from seeing the validity of other arguments.) -Kyle H __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HTTPS security model
On Fri, Dec 08, 2006 at 04:15:15AM -0800, David Schwartz wrote: > > > Actually, David, the truth is that your really not getting these > > guarentees that > > your looking for. > > Correct. In a technical sense, *you* do not get the guarantees, your end of > the HTTPS connection does. Whether you choose to trust your end or not is a > separate issue. Does this debate belong here? It has been hashed out many times on the cryptography list, and does not appear to be specific to OpenSSL. Yes, the security of unauthenticated TLS is rather questionable. Yes, the security of authenticated TLS with root CAs has many known issues, but is generally stronger than unauthenticated TLS. Not all CAs (especially the process they use to verify domains, by e.g. confirming unauthenticated delivery of email to administrator accounts) are worthy of the same level of trust. It is difficult to only trust a CA to vouch for a subset of the DNS namespace, The marriage of convenience between IETF protocols and X.509v3 leaves much to be desired. I would like to suggest that we leave it there, without additional rounds of back and forth counter-claims. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: HTTPS security model
> Actually, David, the truth is that your really not getting these > guarentees that > your looking for. Correct. In a technical sense, *you* do not get the guarantees, your end of the HTTPS connection does. Whether you choose to trust your end or not is a separate issue. > The problem is that the entire https authentication scheme's > guarentee that > site A is really site A is completely dependent on site A using a root > CA certificate that is present in the web browser. It's all a matter of perspective. What HTTPS actually guarantees is that only source of and listener to my conversation is the owner of the presented certificate, and the certificate actually was issued by the organization it claims to be of. What I (by which I mean my computer/browser) choose to do with that assurance is my business. It is, of course, possible to reach a false conclusion from that information. However, the information is always sufficient to reach a true conclusion, and that's all HTTPS can provide. > In other words, your placing your trust that site A is really site A > entirely > in the hands of the person or organization or group that is releasing > the web browser. That assumes you do not modify the list of root CAs in any way. But you also get to choose what web browser you use. HTTPS provides guarantees to your computer/endpoint. What your software chooses to do with that is your business. Nothing about HTTPS requires you to use a browser that comes with certificates, and not everyone does that. (A lot of HTTPS connections have the client endpoint implemented by software whose sole purpose is to obtain some type of information not intended for direct human viewing.) > While I might be convinced that the Firefox developers really have > placed the real live root CA's into Firefox, and that when I download and > install Firefox the root CA's that are in Firefox are really and truly the > real root CA's for those roots, I just do not have the same trust in > Microsoft. > > Perhaps you do. I think that's kind of a crazy thing to say. For what possible reason would Microsoft want my credit card information to leak to a cracker? For what possible reason would Microsoft want my computer to be hijacked? > Think of it another way. I'm a cracker. I want to spoof Amazon. So > what I do is I make up a fake VeriSign/RSA Secure Server CA certificate. > I then put this into a program that I use a social engineering crack to > get the user to install. (ie: download and run a free game, > etc.) Windows > XP runs regular users as Administrator so when my game install program > runs it can wack out the existing root CA store that Microsoft uses under > Windows and replace it with my own modified one. My installer also > adds in www.amazon..com to the local hosts file pointing to my fake > website. > > All I now have to do is sign the certificate that I'm running on my fake > website > with my fake VeriSign CA certificate and I'm in like flynn. What is even > better is that if the user somehow manages to access the REAL amazon > website, thye will get a certificate error!!! I think that has nothing to do with anything. Why even bother? Why not just trap my keystrokes and wait for me to enter my credit card info into any program at all? If you can take over my computer, why limit yourself to just what passes over HTTPS? > I will point out that Microsoft recognized this which is why Windows Vista > no longer runs IE 7 under the administrator privilege. > > Let's look at another scenario. > > I'm an ISP. I want to use cheap self-signed > certificates on all my webmail and other servers without paying Verisign. > So all I have to do is create my root CA, and take a copy of Microsoft > Internet Explorer, make up a custom install of it that includes my root > CA, using the developer tools that Microsoft has available for ISP's to > use to create "branded" installs of Internet Explorer, then when my new > customers are "signing up" for my service and > installing my dialer program, they also install my copy of MS IE which has > my root CA in it. Since I sign all my certificates with my root CA, I am > in effect creating self-signed certificates without a 3rd party, and my > users are not getting complaints when they hit my sites. Once again > defeating this much vaunted 3-way-party https security model you are > so fond of. That does not defeat the security model at all. That causes the model to do exactly what its implementers want it to do. To call that defeating the security model is arguing that me not being able to withdraw a million dollars I don't have from my bank account defeats the bank's security model just because *I* want to withdraw a million dolla
Re: HTTPS security model
- Original Message - From: "David Schwartz" <[EMAIL PROTECTED]> To: Sent: Thursday, December 07, 2006 6:49 PM Subject: RE: HTTPS security model > > > OK, I'm going to take a humourous punch at what you just said; if > > authentication and authorization are the same thing, why are both > > required? Isn't one enough? Please make up your mind... > > If A and B are the same thing, either neither is required or both are > required. Everything true about one must be true about the other. > > But what I'm really trying to say is that to get any of the guarantees HTTPS > is intended to provide, you need both. So they are the same thing in the > sense that one without the other is no better than neither. > Actually, David, the truth is that your really not getting these guarentees that your looking for. The problem is that the entire https authentication scheme's guarentee that site A is really site A is completely dependent on site A using a root CA certificate that is present in the web browser. This would NOT be a problem if all web browsers were distributed WITHOUT existing root CA certificatess and the users were required to use an out-of-band method to install root CA certificates's. Like for example having Verisign mail them a disk directly with it's root CA. But this isn't the case, instead browsers are distributed with root CA certificates already in them. In other words, your placing your trust that site A is really site A entirely in the hands of the person or organization or group that is releasing the web browser. While I might be convinced that the Firefox developers really have placed the real live root CA's into Firefox, and that when I download and install Firefox the root CA's that are in Firefox are really and truly the real root CA's for those roots, I just do not have the same trust in Microsoft. Perhaps you do. Think of it another way. I'm a cracker. I want to spoof Amazon. So what I do is I make up a fake VeriSign/RSA Secure Server CA certificate. I then put this into a program that I use a social engineering crack to get the user to install. (ie: download and run a free game, etc.) Windows XP runs regular users as Administrator so when my game install program runs it can wack out the existing root CA store that Microsoft uses under Windows and replace it with my own modified one. My installer also adds in www.amazon..com to the local hosts file pointing to my fake website. All I now have to do is sign the certificate that I'm running on my fake website with my fake VeriSign CA certificate and I'm in like flynn. What is even better is that if the user somehow manages to access the REAL amazon website, thye will get a certificate error!!! I will point out that Microsoft recognized this which is why Windows Vista no longer runs IE 7 under the administrator privilege. Let's look at another scenario. I'm an ISP. I want to use cheap self-signed certificates on all my webmail and other servers without paying Verisign. So all I have to do is create my root CA, and take a copy of Microsoft Internet Explorer, make up a custom install of it that includes my root CA, using the developer tools that Microsoft has available for ISP's to use to create "branded" installs of Internet Explorer, then when my new customers are "signing up" for my service and installing my dialer program, they also install my copy of MS IE which has my root CA in it. Since I sign all my certificates with my root CA, I am in effect creating self-signed certificates without a 3rd party, and my users are not getting complaints when they hit my sites. Once again defeating this much vaunted 3-way-party https security model you are so fond of. David, one of these days you will wake up and understand that the only real way to have workable security is to have an educated user behind the wheel. The https model was designed with a flawed premise - that is, that it's possible to have high security with completely uneducated, stone dumb, moron users running the web browser. We will just make the ecommerce sites pay some extra money and the Net Faries will make it all secure. You can no more have safe web browsers by ignorant web browser users than you can have good drivers who don't know how their vehicle operates. This is one of the big flaws in our society today, is this idea that life is way too complex for the average person to understand how anything really works. So we gotta make all the devices so that an ignoramus can operate them. This leads to school systems that graduate kids who know how to work advanced Algebra formulas that they will never use as an adult, yet do not understand the principles of how an internal combustion engine operates, or how a petroleum refinery operates, yet are given voting power ov
RE: HTTPS security model
> OK, I'm going to take a humourous punch at what you just said; if > authentication and authorization are the same thing, why are both > required? Isn't one enough? Please make up your mind... If A and B are the same thing, either neither is required or both are required. Everything true about one must be true about the other. But what I'm really trying to say is that to get any of the guarantees HTTPS is intended to provide, you need both. So they are the same thing in the sense that one without the other is no better than neither. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: HTTPS security model
> 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. Except HTTPS is not supposed to be a "not likely somebody's going to bother to break it" type of security. It's supposed to be security that provides fundamental guarantees. Perhaps the reason passive attacks are more common than active ones is because there really aren't deployed solutions that are vulnerable to one and not the other. So it's not logical to make a more difficult attack when a simpler one will do. That said, there are quite a few people who can and would hijack and actively intercept HTTPS sessions if they *could* do so. If that worked and passive interception didn't, then that type of 'attack' would be become more probable and more frequent. (Almost everyone who currently does so with HTTP would do so with HTTPS if they could.) > 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. :-) The problem is that people may not look at the icon at all. The current model, requiring the user to acknowledge that he is not getting the level of security he expects, ensures the user actually knows what he is getting. Excepting the user to notice that the icon is not the usual one is not sufficient. However, it is true that the current scheme creates an "all or nothing" choice that might result in sub-optimal behavior in many real-world situations. However, any solution that increased the risk of an active attack on HTTPS would be unacceptable, IMO. DS __ 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: HTTPS security model
In message <[EMAIL PROTECTED]> on Tue, 5 Dec 2006 13:45:13 -0800, "David Schwartz" <[EMAIL PROTECTED]> said: davids> Authentication and authorization are the same thing. Generally speaking, that's incorrect, even if you might have a specific case where your statement applies. To take an example, I can *authenticate* you if you show me a legal piece of identity that shows you are you, but that doesn't mean that I *authorize* you to raid my fridge. This simple truth is applicable to security models as well. davids> They are both required ... OK, I'm going to take a humourous punch at what you just said; if authentication and authorization are the same thing, why are both required? Isn't one enough? Please make up your mind... Cheers, Richard -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ "When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up." -- C.S. Lewis __ 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.
RE: HTTPS security model
> 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). One could also argue that end > users should know better than to read it that way, but the UI is just > too simple to do the job required and the protocol hasn't been > supplying all the information that the user really wants. I don't understand this argument at all. The two questions you seem to think are being confused are the *same* question. When I type in "https://www.amazon.com";, what I want to know is -- do I have a secure connection to Amazon? 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. 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? Authentication and authorization are the same thing. They are both required to ensure that only those who are supposed to be parties to the conversation are in fact parties to the conversation. And that is the root security requirement. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: HTTPS security model
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). One could also argue that end users should know better than to read it that way, but the UI is just too simple to do the job required and the protocol hasn't been supplying all the information that the user really wants. The CA and browser folk (http://www.cabforum.org/forum.html) have been working on that and are about to roll out a fix, which they're calling Extended Validation. It looks like, for more money you get a certificate which certifies more about you such as your business' real-world name, and compliant browsers will display the additional information when you connect. This begins to pry off one of the two meanings of the lock. It is at least an interesting attempt. Maybe after a while we'll get browsers which allow us to craft explicit trust lists, so that we can have a little smiley-face or something next to the lock which indicates "you have explicitly told me to trust this object". -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Typically when a software vendor says that a product is "intuitive" he means the exact opposite. pgpz4zisIJ0da.pgp Description: PGP signature
Re: HTTPS security model and TLS anonymous cipher-suites
Dear, Le 04-déc.-06 à 19:15, Victor Duchovni a écrit : TLS includes anonymous cipher-suites (ADH) that do not require or use server certificates. Postfix 2.3 clients using opportunistic TLS with Postfix 2.3 (SMTP+STARTTLS) servers will use anonymous ciphers by default, because SMTP server authentication is not widely practiced or practical: http://www.postfix.org/TLS_README.html#client_tls_limits Le 05-déc.-06 à 00:25, David Schwartz a écrit : If a user types in "https://site-i-trust.com"; and gets the little lock icon and no warning, he's supposed to be allowed to assume that someone he trusts has certified that he has actually reached "site-i-trust.com". That is not my goal of course. I don't need the user to see a lock nor want to fake anything. I wouldn't even need their url scheme to be https://. All I'm seeking is a way to have the browser engage an encrypted link with the server before sending its first query. The TLS anonymous cipher-suites Victor wrote about in the other answer to my question look like what I am looking for, but I have a doubt browsers would generally support this. I'll dig more information and program some tests. There may be ways to solve your outer problem. The most obvious being to either obtain a certificate signed by a trusted third party or to get users to install your certificate themself. That would work of course, but each user-customer runs his own server (and this is no webservers meant to be accessed by the public at large) and getting a certificate for each of those from a public authority is useless because nobody tries to authenticate these servers at first, just to establish encrypted communications between those and their users. We might freely deliver them certificates signed by some root of us that we would ask them to download and install. But that introduces a dependance on us that I don't like to impose on them. I'll probably try to find ways NOT to need encrypted HTTP at first and only upgrade to secured channel at a later stage (when protocol switch to non-HTTP). Thanks so much (Victor and David) for these answers, -- Olivier Mascia __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: HTTPS security model
> This will probably look like a dumb question, but anyway. Is there > any provision and way, in SSL and/or HTTP, to establish a SSL link > without trying to assert anything about the server identity? Such > that a client (a web browser) would happily use the encrypted tunnel > while obviously not offer any guarantee about the real identity of > the server but not complain about it too. > > Something like a flag in a self-signed certificate that would tell > clients : "please I know I'm self-signed and I'm not trying to prove > my identity to you, just trying to establish a secure link between > both of us, so please don't make too much waves about me being self- > signed" ? No. Such an option would destroy the HTTPS security model. If a user types in "https://site-i-trust.com"; and gets the little lock icon and no warning, he's supposed to be allowed to assume that someone he trusts has certified that he has actually reached "site-i-trust.com". If "site-i-dont-trust.com" could send a specially-crafted self-signed certificate to bypass the warning, the user would be duped into thinking his browser is certifying that he reached "site-i-trust.com". The user expects that when he enters an HTTPS URL or gets a lock icon and no warning or error, he has confirmation that he has reached the site he asked for. There may be ways to solve your outer problem. The most obvious being to either obtain a certificate signed by a trusted third party or to get users to install your certificate themself. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
