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: 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
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]
TLS on pure-ftl
Hello all I'm trying to use TLS on pure-ftp. However, I'm unable to establish a secure connection... the debug says [ERROR] SSL/TLS [/etc/ssl/private/pure-ftpd.pem]: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate Any ideas? Best regards, -vcf __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: TLS on pure-ftl
Hello, I'm trying to use TLS on pure-ftp. However, I'm unable to establish a secure connection... the debug says [ERROR] SSL/TLS [/etc/ssl/private/pure-ftpd.pem]: error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate This SSL alert means that your certificate is not accepted by SSL peer. Check that this certificate is not expired and that you have CA certificate/chain available to verify this certificate (on peer). Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Using ITISSL: Fatal error in reader: itissl.build.config, line 79
Hi, I am trying to install ITISSL which is a java wrapper based on SSLEAY/OpenSSL. Ater I modifed the itissl.build.config file and ran make, I got the following error message. (Note I didn't modify the line 79) * make: Fatal error in reader: itissl.build.config, line 79: Unexpected end of line seen * Any thoughts on this error message? Regards, Krishna.
Re: ocsp responder certificate generation documentation( reg)
howto make the OCSP certificate. This is the section I added to my openssl.cnf file. [ ocsp_cert ] # These extensions are added when 'ca' signs a request for an OCSP responder. basicConstraints=CA:FALSE extendedKeyUsage= OCSP Signing noCheck = yes ... Then as my other post said: add -extensions ocsp_cert on the openssl ca command to generate the cert. The document I referred to is openssl standard doc from the site: http://www.openssl.org/docs/apps/openssl.html This one is good, and recently updated, but never mentions OCSP Signing and that is what you need to make the OCSP cert. It does mention noCeck which I also use. http://www.openssl.org/docs/apps/x509v3_config.html# And the OCSP doc: http://www.openssl.org/docs/apps/ocsp.html# Warning: There are a couple of minor mistakes on this page - but you should be able to figure it out. This mentions OCSPSigning (without the space - dont try that in the .cnf file!) but it wont tell you how to make the ocsp cert. Last is the CA doc: http://www.openssl.org/docs/apps/ca.html# PS. I use this OCSP very successfully for testing purposes . It is very lightweight and works so it is worth the effort! You can certainly learn a lot about OCSP responder from using this one. Regards, Simon McMahon Sowjanya Malika [EMAIL PROTECTED] 12/06/2006 10:21 PM To Simon McMahon/Australia/Contr/[EMAIL PROTECTED] cc Subject ocsp responder certificate generation documentation( reg) Hi, I have gone through your mail regarding ocsp responder certificate generation documentation. I just wanted to know abt OCSP and I would like to have the document. Is it confidential? If not please send me. thanks in advance, Sowjanya __ 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: 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]
