Re: Safe signed certificate generation during server installation ?
On Fri, Sep 28, 2007 at 08:37:12PM +0530, Urjit Gokhale wrote: considered as proposition to discussion. Real, secure programming should be based on existing, well checked protocols (which is possible in this case). The OP was going to embed his CA's private key in his installer. The OP was not thinking clearly about key management. My first response to the OP outlined what needs to be done for key-management (a human assisted enrollment process). Thank you all for all the responses and the discussion. I learn from this discussion, that for a complete secured system, I need to consider the key management in better fashion. I will definitely think over it. But for now, I would like you guys to comment if the scheme of allowing the admin to create certificate through installer work ? Turning security off works, shipping the CA private key to every machine turns off security. I am assuming that the admin will guard the installer (and hence the cert generation capability) well, so that no one else gets to create a CA signed cert. This assumption seems unwarranted, and with global distribution of the CA private key it only takes the compromise of one machine to break security globally. I'd be hard-pressed to endorsee this design. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
considered as proposition to discussion. Real, secure programming should be based on existing, well checked protocols (which is possible in this case). The OP was going to embed his CA's private key in his installer. The OP was not thinking clearly about key management. My first response to the OP outlined what needs to be done for key-management (a human assisted enrollment process). Thank you all for all the responses and the discussion. I learn from this discussion, that for a complete secured system, I need to consider the key management in better fashion. I will definitely think over it. But for now, I would like you guys to comment if the scheme of allowing the admin to create certificate through installer work ? I am assuming that the admin will guard the installer (and hence the cert generation capability) well, so that no one else gets to create a CA signed cert. Isn't this as if the installer itself is working as a CA tool, and the admin is acting as a local CA, issuing / creating certificates for the servers to use? I believe the MITM can be avoided with this, in the following way: The admin knows the name of the machine where he is installing the server. He will put this information in the certificate. The client will indeed verify this name as part of cert verification. We assume that acting as a local CA, the admin will not use installer to create incorrect certificates. BTW. I would like to know more about the finished messages David was talking about. Could someone point me to the documentation / article on this? Thank you once again. ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Wed, Sep 26, 2007 at 04:28:15PM -0700, David Schwartz wrote: Victor Duchovni wrote: Use a self-signed cert and and a trusted source of peer-cert or cert fingerprint mappings. The public CA is just one mapping function. Well then you're going to have to argue with yourself since you said not to do this two posts ago: No, use with TLS in the usual fashion, no secondary authentication protocol, the cert *is* the credential. Anyway, I think we are running out of stream. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Hello, Now you *are* saying that if you just use something to validate the certificate, you are safe. You and I are in violent agreement, you just don't see it. You also suggest setting up an SSL connection that provides everything except MITM detection. You then take something from the SSL connection that a MITM cannot fake (in your case, the server's certificate and thus private key, in my case, the finished messages which depend on the keys) and verify it by a means outside of the SSL protocol. This are two different things. Certificate authentication is well defined in SSL/TLS RFC. Sure, but how do you know which certificates to allow and which not to? The RFC doesn't talk about how you get the list of certificates to allow. (I have seen serious bugs in certificate validation.) All what you need is to have (for example) private CA and key/certs for all peers (you said that your peer already have trusted keys so this is not more complicated). After SSL/TLS authentication process you now that you are talking with peer from your CA and based on certificate you decide what to do next, this is well defined, you are not sending anything to your peer. In your method you get Finished hash out of SSL handshake context (is it ok or not ? did you analysed that ?) next you send this over (in reality) clear channel guarded only with your private key (signature) as one message. In SSL certificate authentication Finished messages are exchanged AFTER authentication (and are encrypted too), in your implementation this is main authentication step. Do you see difference ? Is this ok or not ? Victor proposed, a trusted source of peer-cert or cert fingerprint mappings. This is not well-defined. How will you get the list from this source? How will you update it? Where will you store it? Is this ok or not? Everything you do has to be checked. Any time you can't do things exactly the way everyone else does, you have this problem. I'm not against inventing new protocols, but your method may be only considered as proposition to discussion. Real, secure programming should be based on existing, well checked protocols (which is possible in this case). The OP was going to embed his CA's private key in his installer. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Thu, Sep 27, 2007 at 11:38:39AM -0700, David Schwartz wrote: considered as proposition to discussion. Real, secure programming should be based on existing, well checked protocols (which is possible in this case). The OP was going to embed his CA's private key in his installer. The OP was not thinking clearly about key management. My first response to the OP outlined what needs to be done for key-management (a human assisted enrollment process). -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Hello, Now you *are* saying that if you just use something to validate the certificate, you are safe. You and I are in violent agreement, you just don't see it. You also suggest setting up an SSL connection that provides everything except MITM detection. You then take something from the SSL connection that a MITM cannot fake (in your case, the server's certificate and thus private key, in my case, the finished messages which depend on the keys) and verify it by a means outside of the SSL protocol. This are two different things. Certificate authentication is well defined in SSL/TLS RFC. Sure, but how do you know which certificates to allow and which not to? The RFC doesn't talk about how you get the list of certificates to allow. (I have seen serious bugs in certificate validation.) What does it mean ? Are you saying that programmers mistakes, lack of knowledge of X509 or SSL/TLS are worse then using undocumented, unchecked, security protocols ? Certificate validation on cryptography layer should be performed by SSL, certificate validation at application/user layer are performed by programmer. If programmer is not sure how to do this step, there are many popular opensource projects available to look at and learn how to do this (Apache, FreeSWAN, ...). If this is too tiring, he may buy a book with all this details explained. For example Network Security with OpenSSL, chapter 5 SSL/TLS Programming, and look at 5.1.3 Peer Authentication with function post_connection_check() which parses certificate subject, issuer, and extensions with many comments. Almost copy-paste implementation :-) Or if he prefer Java he may buy Beginning Cryptography with Java, go to chapter 10 SSL and TLS and look at Client-Side Authentication and learn. Or he may use Google to get some example code and advises. I want to show the difference between documented/widely used protocols or good practice and undocumented/not widely used methods. Even that you have seen serious bugs in certificate validation, how serious bugs may have security protocol implemented by inexperienced programmer which have only global information about this protocol, no documentation, no RFC, no information of good message format, no test vectors, ... ? All what you need is to have (for example) private CA and key/certs for all peers (you said that your peer already have trusted keys so this is not more complicated). After SSL/TLS authentication process you now that you are talking with peer from your CA and based on certificate you decide what to do next, this is well defined, you are not sending anything to your peer. In your method you get Finished hash out of SSL handshake context (is it ok or not ? did you analysed that ?) next you send this over (in reality) clear channel guarded only with your private key (signature) as one message. In SSL certificate authentication Finished messages are exchanged AFTER authentication (and are encrypted too), in your implementation this is main authentication step. Do you see difference ? Is this ok or not ? Victor proposed, a trusted source of peer-cert or cert fingerprint mappings. This is not well-defined. How will you get the list from this source? How will you update it? Where will you store it? But there is many implementations you can look at and learn. There are RFC that suggests how to proceed, you may look at FreeSWAN source code and config files, you may look at Cisco VPN Client/Server to learn how certificate is processed, what extension are used, what extended key usage are needed, how to select/authorize subject/issuer. In TLS there is progress too, you may look at RFC4681 TLS User Mapping Extension, you may use OCSP to revoke compromised certificates online. Is this ok or not? Its ok. Everything you do has to be checked. Any time you can't do things exactly the way everyone else does, you have this problem. But in this case all may be done with standard methods/protocols/good practice. Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* David Schwartz wrote on Tue, Sep 25, 2007 at 14:47 -0700: [...] I'm not sure if I understand ...including these If, for instance, each side (and only them) share a secret 3DES key and use it for some challenge-response-authentication inside a SSL tunnel then I would assume that this is secure because it would be secure without the SSL and thus should be with it. No, because a MITM could interpose his own SSL connection to both sides, proxy the challenge-response authentication and then view or modify the plaintext. (Ahh, ok, yes, in case the challenge-response itself wouldn't generate a session key, right. I assumed the involved secret 3DES key is not known to the MITM and the session key is derived also using it.) If you don't verify the name in the certificate, SSL provides everything you need *except* MITM detection. So you just need to add that. Once you verify that the two programs that are going to exchange secure data have opposite ends of the *same* SSL connection, SSL does everything you need. Yes, I see, but why encrypt at all if you don't know who can decrypt it? Some authentication must be added (in whatever way) if encryption is required (data must be kept secret), right? So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Exactly. Ahh, ok. I assumed SSL and TLS would specify how to authenticate and how to derive keys (to be interoperable), but also Victor explained my that there are more flexible possibilites such as defining new cipher suites (before, I assumed the standard would require a lowest common dominator such as TLS_RSA_WITH_3DES_EDE_CBC_SHA and so on to get all implementations interoperable). Are such schemes used in practice? Or is it more a theoretical idea showing what would be possible? Yes, they are. Interesting. I assume they are not interoperable with `ordinary' SSL implementations, that is correct, isn't it? So SSL or TLS simply has a wider scope than I assumed before :) Thank you for explaining that (hoping I got it right :)). oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Wed, Sep 26, 2007 at 11:03:21AM +0200, Steffen DETTMER wrote: So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Exactly. Actually not the certificate, it has to be a nonce securely derived from the current SSL handshake, the certificate alone does not qualify. This nonce then has to be used securely in a second authentication step that must work if both sides have the same nonce, and fail otherwise. This is certainly possible, but the vast majority of users (i.e. programmers) this is IMHO a bad idea. I am not alone in this view. Use TLS with a properly integrated cipher-suite and a suitable key management/trust model. Ahh, ok. I assumed SSL and TLS would specify how to authenticate and how to derive keys (to be interoperable), but also Victor explained my that there are more flexible possibilites such as defining new cipher suites (before, I assumed the standard would require a lowest common dominator such as TLS_RSA_WITH_3DES_EDE_CBC_SHA and so on to get all implementations interoperable). Programmers should not define new cipher-suites, protocol designers should design and review them, then standards committees adopt them and toolkit vendors (e.g. OpenSSL) implement them. As a programmer you have a choice of cipher-suites (via the cipherlist preferences in the client and server applications). Some cipher-suites work better with some key management (trust) models. Some cipher-suites that I wish were standardized are not yet available. David's proposal very likely works for him, but IMHO is bad advice, because the sophistication required to execute it correctly is too high. I would not use a product that rolled its own MITM-immune authentication layer post-SSL. With cryptographic products, follow the herd and don't stray. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
On Wed, Sep 26, 2007 at 11:03:21AM +0200, Steffen DETTMER wrote: So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Exactly. Actually not the certificate, it has to be a nonce securely derived from the current SSL handshake, the certificate alone does not qualify. This nonce then has to be used securely in a second authentication step that must work if both sides have the same nonce, and fail otherwise. I am not enough of an expert to comment for sure on this, but it seems that there would be no harm in using the certificate for this purpose. A MITM cannot create an SSL session that uses the same certificate as the real server because that would mean the MITM would have to know the same private key the real server is using. In any event, implementations I know of use a hash of the two finished messages. These implementations were professionally vetted. This is certainly possible, but the vast majority of users (i.e. programmers) this is IMHO a bad idea. I am not alone in this view. Use TLS with a properly integrated cipher-suite and a suitable key management/trust model. So what do you do if the conventional trust model is not the security model you need to implement? Throw out TLS when it does everything you need except detect a MITM? That seems much riskier IMO. Ahh, ok. I assumed SSL and TLS would specify how to authenticate and how to derive keys (to be interoperable), but also Victor explained my that there are more flexible possibilites such as defining new cipher suites (before, I assumed the standard would require a lowest common dominator such as TLS_RSA_WITH_3DES_EDE_CBC_SHA and so on to get all implementations interoperable). Programmers should not define new cipher-suites, protocol designers should design and review them, then standards committees adopt them and toolkit vendors (e.g. OpenSSL) implement them. Definitely. David's proposal very likely works for him, but IMHO is bad advice, because the sophistication required to execute it correctly is too high. Do you know any other good way to get MITM detection other than a certificate issued by a trusted CA? For some applications, that's just not what you want. I would not use a product that rolled its own MITM-immune authentication layer post-SSL. With cryptographic products, follow the herd and don't stray. If you can't trust a TLS/SSL connection to exchange authentication information, then you can't trust a secure web page with a password. That's obviously not right. In practice, what you get if you follow this policy is no MITM detection at all. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Wed, Sep 26, 2007 at 03:58:08PM -0700, David Schwartz wrote: I am not enough of an expert to comment for sure on this, but it seems that there would be no harm in using the certificate for this purpose. A MITM cannot create an SSL session that uses the same certificate as the real server because that would mean the MITM would have to know the same private key the real server is using. David's proposal very likely works for him, but IMHO is bad advice, because the sophistication required to execute it correctly is too high. Do you know any other good way to get MITM detection other than a certificate issued by a trusted CA? For some applications, that's just not what you want. Use a self-signed cert and and a trusted source of peer-cert or cert fingerprint mappings. The public CA is just one mapping function. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Victor Duchovni wrote: Use a self-signed cert and and a trusted source of peer-cert or cert fingerprint mappings. The public CA is just one mapping function. Well then you're going to have to argue with yourself since you said not to do this two posts ago: Actually not the certificate, it has to be a nonce securely derived from the current SSL handshake, the certificate alone does not qualify. Now you *are* saying that if you just use something to validate the certificate, you are safe. You and I are in violent agreement, you just don't see it. You also suggest setting up an SSL connection that provides everything except MITM detection. You then take something from the SSL connection that a MITM cannot fake (in your case, the server's certificate and thus private key, in my case, the finished messages which depend on the keys) and verify it by a means outside of the SSL protocol. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Hello, Now you *are* saying that if you just use something to validate the certificate, you are safe. You and I are in violent agreement, you just don't see it. You also suggest setting up an SSL connection that provides everything except MITM detection. You then take something from the SSL connection that a MITM cannot fake (in your case, the server's certificate and thus private key, in my case, the finished messages which depend on the keys) and verify it by a means outside of the SSL protocol. This are two different things. Certificate authentication is well defined in SSL/TLS RFC. All what you need is to have (for example) private CA and key/certs for all peers (you said that your peer already have trusted keys so this is not more complicated). After SSL/TLS authentication process you now that you are talking with peer from your CA and based on certificate you decide what to do next, this is well defined, you are not sending anything to your peer. In your method you get Finished hash out of SSL handshake context (is it ok or not ? did you analysed that ?) next you send this over (in reality) clear channel guarded only with your private key (signature) as one message. In SSL certificate authentication Finished messages are exchanged AFTER authentication (and are encrypted too), in your implementation this is main authentication step. Do you see difference ? Is this ok or not ? You are saying about professionals that checked your solution. What does it mean ? Nothing. What professionals ? Are some papers from this analysis available ? Is this authentication method documented ? Can you point to real implementations ? (your own does not count). How wide your method is used ? There are may papers of SSL/TLS, DH, many analysis of how this protocols behave in some circumstances, many discussions about weakness in some environments. Internet is full of such documents. Protocol and implementation bugs are tracked and corrected. I'm not against inventing new protocols, but your method may be only considered as proposition to discussion. Real, secure programming should be based on existing, well checked protocols (which is possible in this case). Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* David Schwartz wrote on Mon, Sep 24, 2007 at 07:42 -0700: Storing some fingerprint of a certificate or public key locally in some trusted place (such as a local file system) seems to be quite secure (should be the same level as having a CAs root certificate in a file), however, I'm not sure if this works with OpenSSL which seems to expect to be able to verifiy the whole certificate chain up to the root certificate even if intermediate certificates are locally avialable. As far as I know / understood - please correct me if I'm wrong! Remember, he's using his own server and client code. So he can disable certificate checking in OpenSSL and do his own. [...] After the SSL session is established but before any important data is exchanged, perform your own verification step that meets your own security requirements. In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Ahh, yes, ok. But the result would not be SSL but something-SSL-based, right? Well, by this someone could use e.g. symetric keys for authentication - if it fails the session could be discarded, right. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) I'm not sure if I understand ...including these If, for instance, each side (and only them) share a secret 3DES key and use it for some challenge-response-authentication inside a SSL tunnel then I would assume that this is secure because it would be secure without the SSL and thus should be with it. beside the fact, that I don't see the advantages of SSL here. A MITM could forward this authentication, so based on the challenge-response some session key needs to be derived to be used as encryption key (to make the MITM unable to read or change the forwarded data). Is that right so far (in such a setup, what is the SSL for BTW)? So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Are such schemes used in practice? Or is it more a theoretical idea showing what would be possible? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Mon, Sep 24, 2007 at 21:05 -0400: Whatever you want to call it. The point is, if the client can't validate the self-signed cert, you need some other way to make sure the server and client have opposite ends of the *same* SSL connection, rather than ends of two SSL connections to a MITM. A simple way to do this is to compare each sides 'finished' with the other side's 'peer finished'. No, the challenge is key management. TLS is just fine. What do you mean, `TLS is just fine'? Doesn't it depend on the requirements? I think, for key management itself (like transferring secret keys), TLS is not suited. TLS AFAIK is limited to one session key (someone could wish one for authentication and a second one for encryption). Also, because of asymetric keys, keys cannot be derived (which would be possible for instance with 3DES keys). Revealing a secret keys can be used to decrypt pre-recorded chiphertext (AFAIK). TLS can be at most as good as the PKI (so in standard PC browsers and the many different CAs that are installed with the many different policies and stuff this probably is not so much). Ohh, and not to forget that the X.509 (just BTW, there even is a v1 :)) subject names are more or less `informal'. Some CA may require a `Ltd' company to contain the `Ltd' in the subject, others may not or may allow to omit the country. Today something like a `Extended Validation Certificate' exist which indicates that there are fun-level-security certificates that can only be used for the same level of SSL strength :-) If CAs don't solve key management for you, roll your own key management, but use existing protocols. If for some application (not meaning only a computer program) the usual CAs are inappropriate, maybe for this application PKI is not suited at all, could happen. Maybe I missunderstand you, but I think, when SSL/TLS is not suited then it should not be needed, even if with OpenSSL such a nice lib is avialable :) Or do you mean `existing protocols' in general? Like `do not invent your own cryptosystem' to avoid designing weaknesses but favor well-analysed systems? I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? You said `without requiring secondary protocols', but wouldn't the implementation of that API be nothing else than such a secondary protocol (OCSP or so)? What is meant by certificate-less cipher-suite? A protocol not using certificates, such as SSL without X.509 certificates at all? How would the authentication work? Did I understand correctly that GSSAPI means, that applications do not depend on the implementation (vendor) of some `GSSLIB' but that the applications can `talk' via GSSAPI only to some peer if it uses the same implementation (vendor), because this implementation can use whatever message to transmit tokes? Sorry for my boring noob questions but maybe the one or other could be answered by some URL/link? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses
Re: Safe signed certificate generation during server installation ?
On Tue, Sep 25, 2007 at 11:58:45AM +0200, Steffen DETTMER wrote: No, the challenge is key management. TLS is just fine. What do you mean, `TLS is just fine'? TLS is a sound protocol, the problem is not the protocol, the problem is key management. Doesn't it depend on the requirements? TLS is fine protocol for establishing a secure channel over a reliable transport. Despite all appearances, TLS is not exclusively tied to a CA centric X.509v3 trust model with RSA keys and RSA CA signatures. I think, for key management itself (like transferring secret keys), TLS is not suited. I am making no claims that TLS is (or is not) suited for key management. Key management is a pre-requisite for TLS, one model for key management is X.509v3 CAs issuing certs and revocation lists. This is not the only key management model compatible with TLS, though it is the one most commonly found in products that use TLS. TLS AFAIK is limited to one session key (someone could wish one for authentication and a second one for encryption). This is false. If CAs don't solve key management for you, roll your own key management, but use existing protocols. If for some application (not meaning only a computer program) the usual CAs are inappropriate, maybe for this application PKI is not suited at all, could happen. Maybe I missunderstand you, but I think, when SSL/TLS is not suited then it should not be needed, even if with OpenSSL such a nice lib is avialable :) Don't confuse TLS with PKI. I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) Well, Kerberos is already supported, but only with DES. If TLS is to see wide-scale use *inside* large organizations where CAs are entirely the wrong model, and GSSAPI is already prevalent, we need a GSSAPI (X.509v3 certificate-less) cipher-suite for TLS with modern symmetric ciphers (AES-256, ...). This an IETF issue, not an OpenSSL issue. According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? A new TLS ciphersuite, GSSAPI is both a standard and a protocol. How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? GSSAPI uses Keberos-5 KDCs for key management. You said `without requiring secondary protocols', but wouldn't the implementation of that API be nothing else than such a secondary protocol (OCSP or so)? The programmer would not need to develop a secondary authentication protocol and intergrate it with TLS, it would be correctly used in a standard fashion inside the TLS protocol. X.509v3 signature verification is also a protocol, it is just that the KDCs are off-line (which is most often a bug, not a feature). What is meant by certificate-less cipher-suite? A protocol not using certificates, such as SSL without X.509 certificates at all? How would the authentication work? Do some homework. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Tue, Sep 25, 2007 at 09:27 -0400: On Tue, Sep 25, 2007 at 11:58:45AM +0200, Steffen DETTMER wrote: I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. ohh, now I got so many questions :) Well, Kerberos is already supported, but only with DES. If TLS is to see wide-scale use *inside* large organizations where CAs are entirely the wrong model, and GSSAPI is already prevalent, we need a GSSAPI (X.509v3 certificate-less) cipher-suite for TLS with modern symmetric ciphers (AES-256, ...). This an IETF issue, not an OpenSSL issue. According to Wikipedia, this is an API to standardise how the application uses something like e.g. OpenSSL, is that correct? Or is it something completely different? You wrote `GSSAPI support in TLS' - this would be a standard or would it be an implementation? A new TLS ciphersuite, GSSAPI is both a standard and a protocol. How would it help with key management? Do you mean in this can you could use any standard GSSAPI-using key management tool? GSSAPI uses Keberos-5 KDCs for key management. Ahh, you mean creating a new TLS (version) standard/RFC, that is using GSSAPI and is to be used e.g. inside large organizations that already have some GSSAPI available (because they use Kerberos) to eliminate the need to additionally worry about keys/certificates for this new TLS (but using Kerberos protocol / authentication instead)? oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Tue, Sep 25, 2007 at 05:20:28PM +0200, Steffen DETTMER wrote: GSSAPI uses Keberos-5 KDCs for key management. Ahh, you mean creating a new TLS (version) standard/RFC, that is using GSSAPI and is to be used e.g. inside large organizations that already have some GSSAPI available (because they use Kerberos) to eliminate the need to additionally worry about keys/certificates for this new TLS (but using Kerberos protocol / authentication instead)? Approximately correct, not a new TLS standard, the existing TLS 1.1 is likely sufficient, rather a new standard cipher-suite for TLS 1.1. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* Victor Duchovni wrote on Tue, Sep 25, 2007 at 11:40 -0400: On Tue, Sep 25, 2007 at 05:20:28PM +0200, Steffen DETTMER wrote: creating a new TLS (version) standard/RFC Approximately correct, not a new TLS standard, the existing TLS 1.1 is likely sufficient, rather a new standard cipher-suite for TLS 1.1. Thank you for the explanation! oki, Steffen About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. About Ingenico Throughout the world businesses rely on Ingenico for secure and expedient electronic transaction acceptance. Ingenico products leverage proven technology, established standards and unparalleled ergonomics to provide optimal reliability, versatility and usability. This comprehensive range of products is complemented by a global array of services and partnerships, enabling businesses in a number of vertical sectors to accept transactions anywhere their business takes them. www.ingenico.com This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Ahh, yes, ok. But the result would not be SSL but something-SSL-based, right? Well, by this someone could use e.g. symetric keys for authentication - if it fails the session could be discarded, right. It would be SSL for everything except the MITM detection. SSL provides the transport encryption. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) I'm not sure if I understand ...including these If, for instance, each side (and only them) share a secret 3DES key and use it for some challenge-response-authentication inside a SSL tunnel then I would assume that this is secure because it would be secure without the SSL and thus should be with it. No, because a MITM could interpose his own SSL connection to both sides, proxy the challenge-response authentication and then view or modify the plaintext. If you don't verify the name in the certificate, SSL provides everything you need *except* MITM detection. So you just need to add that. Once you verify that the two programs that are going to exchange secure data have opposite ends of the *same* SSL connection, SSL does everything you need. beside the fact, that I don't see the advantages of SSL here. A MITM could forward this authentication, so based on the challenge-response some session key needs to be derived to be used as encryption key (to make the MITM unable to read or change the forwarded data). Is that right so far (in such a setup, what is the SSL for BTW)? If a MITM forwarded the authentication, the authentication would fail because the authentication objects would not match the 'finished' data. If a MITM interposes his own SSL connections, then the 'finished' data will not match, So your point is that some property from the original certificate (lets say some hash or so) could be included in the extra authentication to detect a MITM (or whatever faked) certificate? In that case, SSL would be used basically for encryption only, right? Exactly. Are such schemes used in practice? Or is it more a theoretical idea showing what would be possible? Yes, they are. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
* David Schwartz wrote on Sun, Sep 23, 2007 at 22:51 -0700: Here is my understanding about a real CA. A real CA would be an agency or like, which would have the infrastructure required to sign certificate requests (say openssl toolkit, its own key pair, its own root certificate etc). In addition to this, it would have capabilities / mechanism to verify the information provided by the requester (subject) in the certificate request. Once the CA verifies that the information provided in the certificate request is correct, it would sign the request, and provide the signed certificate to the requester (subject). If I am missing anything that is important to know, I will be really happy to learn about it. What you're missing is the policies they employ to protect their private keys. If you don't employ anywhere near that level of security, you should definitely not be asking people to add your CA certificate to their browsers for Internet use. I would like to extend this a little. I think, a CA is almost only paperwork in means of policies, auditable procedure descriptions and contracts. Whether X.509 or asymetric cryptography is used or not, for me goes a little bit into being an implementation detail. Whatever cryptoscheme is used, it must fulfill the security requirements of the policies. Trusting a CA means trusting those policies (and that them and only them are always applied correctly, usually verifyable/auditable, retroactively inspectable in means of unmodifyable log records / log books and so on). Whether your level of security is sufficient for non-browser programs or networks other than the Internet is a question only you can answer. But the expert consensus for browsers on the Internet is that this is not nearly sufficient security. Yes, I think this is important: to determine the needed security level for a certain purpose / application. The level of security is given by the policies (those policies need to fulfill the requirements specification of course, if any). Of course, there are common practices for policies of e.g. CAs that make sense, such as protecting secret signing keys effectively (dual control, not readable from hardware security module), but theoretically everything is possible. For instance, you could have a policy allowing certificates without personal authentication (for instance, as cacert.org offers) or you could protect the secrect key by nothing else that an linux crypto file system on a regular hard disk with a single passphrase (allowing the admin who knows this passphrase to take a backup of the system - another cacert example). If this would be documented in the policy and it would be applied letter by letter, you could trust the CA (in doing so. BTW, this is not the case for cacert, because they do not even have a policy, so everthing is possible - different topic). However, the security level of this trusted CA is in my personal option that low that I never what its root certificate in my browser (or elsewhere), because I'm afraid of accidently accepting a certificate issued (assured) by a 12 year chinese girl agent spy or so. You can verify as much fingerprints as you like, the security level won't increased because it is limited by the weakest part in the chain; this probably isn't the question whether a RSA key has 2048 or 4096 bit but if the officiers that work in security relevant topics (such as authentication) are well trainined etc. Since I wrote such a big text and already bored everyone to dead I want to add that beside authentication of course authorisation is important. It does not help much if you know 100% that your communication peer is authentic if this is an attacker (who is authenticated but not authorised to do the particular thing). This sounds cheap, but with a today standard webbrowser and HTTPS, a DNS name is used (referenced via some X.509 CN field) as name for verification and the human is supposed to verify the the displayed URL is autorised to receive the online banking account information (or whatever). Of course, you can inspect the field values of a certificate by clicking those key or lock symbols. I've read that newer versions of firefox and other browsers will improve here (or maybe even already did :)). Hmm ... So are you suggesting that my clients would store the certificate produced by the server, the first time they connect to the server, and thereafter each time they connect to the server, they check if the certificate has changed? It depends upon what the client needs to determine. If the clients needs to know if it's talking to the same server it was talking to before, then this is the perfect way to do that. Yes, I think this is how e.g. SSH works by default (allowing manual fingerprint verification or preinstalling authentic keys to the known_hosts files) and, as far as I understand, these Windows machine key account stuff is working. As I understand, a self signed
RE: Safe signed certificate generation during server installation ?
Storing some fingerprint of a certificate or public key locally in some trusted place (such as a local file system) seems to be quite secure (should be the same level as having a CAs root certificate in a file), however, I'm not sure if this works with OpenSSL which seems to expect to be able to verifiy the whole certificate chain up to the root certificate even if intermediate certificates are locally avialable. As far as I know / understood - please correct me if I'm wrong! Remember, he's using his own server and client code. So he can disable certificate checking in OpenSSL and do his own. There are several ways to do this, but one that I've used a few times works like this: The server can use any key/certificate at all to establish the SSL connection. It doesn't matter. (Self-signed, issued by CA, persistent, temporary, makes no difference.) Set OpenSSL to accept self-signed certificates and not to check the name. After the SSL session is established but before any important data is exchanged, perform your own verification step that meets your own security requirements. Make certain that the verification includes data from the SSL handshake to prevent a MITM from substituting his own SSL session but passing the second level authentication. (SSL_get_finished/SSL_get_peer_finished) In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Storing some fingerprint of a certificate or public key locally in some trusted place (such as a local file system) seems to be quite secure (should be the same level as having a CAs root certificate in a file), however, I'm not sure if this works with OpenSSL which seems to expect to be able to verifiy the whole certificate chain up to the root certificate even if intermediate certificates are locally avialable. As far as I know / understood - please correct me if I'm wrong! Remember, he's using his own server and client code. So he can disable certificate checking in OpenSSL and do his own. There are several ways to do this, but one that I've used a few times works like this: The server can use any key/certificate at all to establish the SSL connection. It doesn't matter. (Self-signed, issued by CA, persistent, temporary, makes no difference.) Set OpenSSL to accept self-signed certificates and not to check the name. After the SSL session is established but before any important data is exchanged, perform your own verification step that meets your own security requirements. Make certain that the verification includes data from the SSL handshake to prevent a MITM from substituting his own SSL session but passing the second level authentication. (SSL_get_finished/SSL_get_peer_finished) In this second step of verification, you can exchange public keys, certificates, challenges, responses, and so on. Each side can verify what it is talking to on the other side by whatever mechanism you want. Again, the only serious potential gotcha is a MITM who might replace the single SSL session with his two (one to each end) and proxy the second step and then takeover or monitor the data connection. Ensuring that each side's SSL_get_finished matches the other side's SSL_get_peer_finished should be sufficient to prevent this. (Include these in the signed objects you exchange.) Hello David, I would like to learn more on MITM in this particular scenario. I used to believe that if a server is using a signed certificate, the MITM is not possible (Is it possible with techniques like DNS poisoning?). Looks like I missed something important. Could you point me to the information on this? Thanks, ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
Hello David, I would like to learn more on MITM in this particular scenario. I used to believe that if a server is using a signed certificate, the MITM is not possible (Is it possible with techniques like DNS poisoning?). Looks like I missed something important. Could you point me to the information on this? It's really quite simple. A signed certificate does not itself stop a MITM. What stops a MITM is the combination of two things: 1) The real server having something the MITM does not have, and 2) The client verifying that something in a way the MITM cannot fake. If you have both of those two things, you don't have to worry about a MITM. In the typical Internet/browser case, if I go to https://www.amazon.com, I am relying on my browser to make sure that the certificate presented has 'www.amazon.com' as the name the CA is vouching for and I'm relying on no CA that I trust issuing such a certificate to a MITM. So long as those two rules apply, I am fine. The case I was talking about is where you allow the server to use a self-signed certificate or for some other reason the certificate does not contain the server's name vouched for by someone you trust. In that case, you need to stop a MITM some other way. The SSL protocol won't do it for you with a self-signed certificate or a certificate not signed by a trusted CA that contains the name the client is trying to reach. Basically, in this case you can use the original SSL authentication to bootstrap a separate MITM detection step. I strongly recommend doing this in a custom application if you use SSL in a way that prevents its normal MITM detection from being effective. In this case, the OP was defeating SSL's normal MITM detection because his server certificate does not contain a name vouched for by a trusted CA. That's why I suggested an alternate means of MITM detection. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Mon, Sep 24, 2007 at 12:31:15PM -0700, David Schwartz wrote: Hello David, I would like to learn more on MITM in this particular scenario. I used to believe that if a server is using a signed certificate, the MITM is not possible (Is it possible with techniques like DNS poisoning?). Looks like I missed something important. Could you point me to the information on this? It's really quite simple. A signed certificate does not itself stop a MITM. What stops a MITM is the combination of two things: 1) The real server having something the MITM does not have, and 2) The client verifying that something in a way the MITM cannot fake. If you have both of those two things, you don't have to worry about a MITM. In the typical Internet/browser case, if I go to https://www.amazon.com, I am relying on my browser to make sure that the certificate presented has 'www.amazon.com' as the name the CA is vouching for and I'm relying on no CA that I trust issuing such a certificate to a MITM. So long as those two rules apply, I am fine. And behind the scenes that the SSL handshake is signed with the server's private key and verified by the browser with the server's public key. The case I was talking about is where you allow the server to use a self-signed certificate or for some other reason the certificate does not contain the server's name vouched for by someone you trust. In that case, you need to stop a MITM some other way. The SSL protocol won't do it for you with a self-signed certificate or a certificate not signed by a trusted CA that contains the name the client is trying to reach. SSL works just fine to prevent MITM with self-signed certs, provided the client has prior knowledge of the self-signed cert. It can then check for the right public key, or the right certificate fingerprint (more convenient via the OpenSSL API than extracting public keys, ...) Basically, in this case you can use the original SSL authentication to bootstrap a separate MITM detection step. I strongly recommend doing this in a custom application if you use SSL in a way that prevents its normal MITM detection from being effective. I strongly disagree. How does the client this separate detection step to the protocol handshake. Why ask users to invent very difficult to get right security protocols? In this case, the OP was defeating SSL's normal MITM detection because his server certificate does not contain a name vouched for by a trusted CA. That's why I suggested an alternate means of MITM detection. No, self-signed certs don't defeat MITM detection, they defeat the X.509 PKI trust model for server authentication, so authentication of the server cert needs to use a different trust model. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
Hello, Basically, in this case you can use the original SSL authentication to bootstrap a separate MITM detection step. I strongly recommend doing this in a custom application if you use SSL in a way that prevents its normal MITM detection from being effective. I strongly disagree. How does the client this separate detection step to the protocol handshake. Why ask users to invent very difficult to get right security protocols? +1, security protocols are developed over years with effort of many people (and even that may contain errors). Best regards, -- Marek Marcola [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
SSL works just fine to prevent MITM with self-signed certs, provided the client has prior knowledge of the self-signed cert. Right, but what if they don't? It can then check for the right public key, or the right certificate fingerprint (more convenient via the OpenSSL API than extracting public keys, ...) Sure, if it knows what the right public key is. Basically, in this case you can use the original SSL authentication to bootstrap a separate MITM detection step. I strongly recommend doing this in a custom application if you use SSL in a way that prevents its normal MITM detection from being effective. I strongly disagree. How does the client this separate detection step to the protocol handshake. Once the SSL handshake finishes, the client software enters a ready for secondary authentication phase. In this phase, secure data is not exchanged, but the secondary authentication can proceed. The server and client then exchange challenges and responses. The responses are signed with a key the client can verify and include the SSL finshed messages, which a MITM cannot tamper with or control. Once each side verifies the other side's response to its challenge and sees that the 'finished' values match, both the server and client can enter a normal data transfer state. Why ask users to invent very difficult to get right security protocols? If you mean end users, they just use the software. They don't care how it works, they just need it to work. We aren't talking about HTTP here, we're talking about specialized uses of SSL where the standard PKI trust model doesn't work. If you mean users of the OpenSSL library, the problem is that the standard SSL security model doesn't fit every application. In that case, you have to do some of your own security work. In this case, the OP was defeating SSL's normal MITM detection because his server certificate does not contain a name vouched for by a trusted CA. That's why I suggested an alternate means of MITM detection. No, self-signed certs don't defeat MITM detection, they defeat the X.509 PKI trust model for server authentication, so authentication of the server cert needs to use a different trust model. Whatever you want to call it. The point is, if the client can't validate the self-signed cert, you need some other way to make sure the server and client have opposite ends of the *same* SSL connection, rather than ends of two SSL connections to a MITM. A simple way to do this is to compare each sides 'finished' with the other side's 'peer finished'. A MITM cannot make the 'finished' messages match and still retain the ability to intercept or modify the data. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Mon, Sep 24, 2007 at 03:01:56PM -0700, David Schwartz wrote: SSL works just fine to prevent MITM with self-signed certs, provided the client has prior knowledge of the self-signed cert. Right, but what if they don't? Create a key management system that makes it so, or deploy a private-label CA (which is still key management, except that you sweep revocation under the rug, and pretend it is not a problem, or public revocation lists, by which point it is often easier to publish a list of valid unrevoked certs as an online service, but I digress). I strongly disagree. How does the client this separate detection step to the protocol handshake. Once the SSL handshake finishes, the client software enters a ready for secondary authentication phase. In this phase, secure data is not exchanged, but the secondary authentication can proceed. Not likely to be MITM-proof, without brilliant programmers and infallible programmers doing the work. The server and client then exchange challenges and responses. The responses are signed with a key the client can verify and include the SSL finshed messages, which a MITM cannot tamper with or control. An MITM generates a new SSL session with each side, so there is a perfectly evil SSL finish message in hand, the trick is to now securely mix this into a protocol handshake that involves some other kind of server credential, but this is difficult. Note if the process does not end up authenticating the server, MITM resistance is impossible. If the server can be authenticated, why not via its cert rather than some additional, equally difficult to manage credential? Instead of throwing away TLS and rolling your own, I would consider PSK (still in development) or any other approach that builds on security features of SSL, rather than inventing a second authentication protocol and trying to tie it into the SSL handshake. Once each side verifies the other side's response to its challenge and sees that the 'finished' values match, both the server and client can enter a normal data transfer state. It is not as simple as you describe. Why ask users to invent very difficult to get right security protocols? If you mean end users, they just use the software. No, toolkit users (programmers). If you mean users of the OpenSSL library, the problem is that the standard SSL security model doesn't fit every application. In that case, you have to do some of your own security work. This is where I strongly disagree. I have met very people who I would trust to design a security protocol (I am not one of the ones I would trust). No, self-signed certs don't defeat MITM detection, they defeat the X.509 PKI trust model for server authentication, so authentication of the server cert needs to use a different trust model. Whatever you want to call it. The point is, if the client can't validate the self-signed cert, you need some other way to make sure the server and client have opposite ends of the *same* SSL connection, rather than ends of two SSL connections to a MITM. A simple way to do this is to compare each sides 'finished' with the other side's 'peer finished'. No, the challenge is key management. TLS is just fine. If CAs don't solve key management for you, roll your own key management, but use existing protocols. I would like to see GSSAPI support in TLS (so would Microsoft and a few others). This addresses key management, without requiring secondary protocols, and ties into the dominant standard intra-mural authentication system. This would use a certificate-less cipher-suite, but the point remains that authentication should be within TLS, not an add-on. Over and out. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
Thank you very much David for your response. I doubt if self signed certificate will be a good idea, as against a signed certificate. With the approach I am proposing, the server installer itself works like a CA. Only an authorized person will have access to this installer (say admin) and can generate a signed certificate. I don't know if you're familiar with how real CAs operate, but trust me, restricting access to your installer won't provide anywhere near the security that real CAs do. Here is my understanding about a real CA. A real CA would be an agency or like, which would have the infrastructure required to sign certificate requests (say openssl toolkit, its own key pair, its own root certificate etc). In addition to this, it would have capabilities / mechanism to verify the information provided by the requester (subject) in the certificate request. Once the CA verifies that the information provided in the certificate request is correct, it would sign the request, and provide the signed certificate to the requester (subject). If I am missing anything that is important to know, I will be really happy to learn about it. Now what happens if someone changes the key and the certificate in the server? If I am using a self signed certificate, this change will not be detected. Perhaps you misunderstand what I'm proposing. If you use a self-signed certificate, the change will be detected because the certificate will now be different. I'm suggesting the client use the public key itself as the server's identity. Hmm ... So are you suggesting that my clients would store the certificate produced by the server, the first time they connect to the server, and thereafter each time they connect to the server, they check if the certificate has changed? As I understand, a self signed certificate can be verified using the public key present in the certificate iteself. So how can my client detect the change in the certificate unless they store the public key (or the certificate itself) the first time they connect to the server, and then for every successive connection attempt, check the certificate presented with this stored public key / certificate ? Am I still missing something? If I am using a CA signed certificate (which only the admin can do through the installer), any such change / modification to the server certificate will be detected as the modified certificate will not be validated at the client side (as it will not be signed). The problem is that anyone who has access to your installer can impersonate any server. Absolutely true. Whether or not this is acceptable depends upon a few factors. I would submit that if your client is a traditional program like IE or Firefox and your target network is the Internet, this is absolutely unacceptable. If your client is custom software and/or your target network is private, this might be reasonable. Right. Now, my clients are custom software and the target (as of now) is a private network. This is the reason, why I plan to use a CA signed cert instead of self signed cert at the server. What's your client software? Is it a browser or custom software? Nops. It is a custome software. If a browser, and you're expecting the client to add your CA as a trusted root, you are compelling your users to trust an awful lot to anyone who might get access to your installer, accidentally or intentionally. A leak of your installer would mean a serious security compromise to all your users. That is right. So, my server / client are custom s/w and the target network is a private network. Please bear with me as I put down the purpose behind this whole thinking, once again. 1. I will be giving my server + clients to my customers. 2. These servers will need to have their own distinct certificates. 3. As part of shipping my s/w (server + client) to the customers, I burn them on a CD and ship them. 4. If I have to generate a unique certificate for every server, myself, I would have to burn so many different CDs. In addition to that, I will have to maintain almost a complete CA system. 5. This is doable, when the number of customers is small, say 5 - 10. But I doubt how well this would scale with the increasing number of customers. So, I was thinking that embedding certificate generation capability in my installer will be good, as it can scale well. An admin at customer C1 would have complete access to the server (h/w + s/w). As it is , it would be this admin who would have prepared the cert request, if I would be issuing signed certificate. So why not allow him to create a certificate for himself ? Now the question was, how can I embed the root CA cert + associated private key in the installer, such that it can not be retrieved easily? Has anyone ever done anything like this before? Does anyone have any better approach to suggest? Thank you very much for your help. ~ Urjit DISCLAIMER == This e-mail may contain
RE: Safe signed certificate generation during server installation ?
Here is my understanding about a real CA. A real CA would be an agency or like, which would have the infrastructure required to sign certificate requests (say openssl toolkit, its own key pair, its own root certificate etc). In addition to this, it would have capabilities / mechanism to verify the information provided by the requester (subject) in the certificate request. Once the CA verifies that the information provided in the certificate request is correct, it would sign the request, and provide the signed certificate to the requester (subject). If I am missing anything that is important to know, I will be really happy to learn about it. What you're missing is the policies they employ to protect their private keys. If you don't employ anywhere near that level of security, you should definitely not be asking people to add your CA certificate to their browsers for Internet use. Whether your level of security is sufficient for non-browser programs or networks other than the Internet is a question only you can answer. But the expert consensus for browsers on the Internet is that this is not nearly sufficient security. Hmm ... So are you suggesting that my clients would store the certificate produced by the server, the first time they connect to the server, and thereafter each time they connect to the server, they check if the certificate has changed? It depends upon what the client needs to determine. If the clients needs to know if it's talking to the same server it was talking to before, then this is the perfect way to do that. As I understand, a self signed certificate can be verified using the public key present in the certificate iteself. So how can my client detect the change in the certificate unless they store the public key (or the certificate itself) the first time they connect to the server, and then for every successive connection attempt, check the certificate presented with this stored public key / certificate ? Am I still missing something? If they don't care if it's the same server each time, then what do they care about? What's the point of this entire exercise? The problem is that anyone who has access to your installer can impersonate any server. Absolutely true. Whether or not this is acceptable depends upon a few factors. I would submit that if your client is a traditional program like IE or Firefox and your target network is the Internet, this is absolutely unacceptable. If your client is custom software and/or your target network is private, this might be reasonable. Right. Now, my clients are custom software and the target (as of now) is a private network. Then you can choose any security model that accomplishes your implementation objectives. You aren't constrained by the potential issues of browsers on the Internet, credit card number theft, impersonating banks, and so on. So, my server / client are custom s/w and the target network is a private network. Please bear with me as I put down the purpose behind this whole thinking, once again. 1. I will be giving my server + clients to my customers. 2. These servers will need to have their own distinct certificates. 3. As part of shipping my s/w (server + client) to the customers, I burn them on a CD and ship them. 4. If I have to generate a unique certificate for every server, myself, I would have to burn so many different CDs. In addition to that, I will have to maintain almost a complete CA system. 5. This is doable, when the number of customers is small, say 5 - 10. But I doubt how well this would scale with the increasing number of customers. So, I was thinking that embedding certificate generation capability in my installer will be good, as it can scale well. An admin at customer C1 would have complete access to the server (h/w + s/w). As it is , it would be this admin who would have prepared the cert request, if I would be issuing signed certificate. So why not allow him to create a certificate for himself ? What are you trying to prevent? What is the point of this entire scheme? Now the question was, how can I embed the root CA cert + associated private key in the installer, such that it can not be retrieved easily? Has anyone ever done anything like this before? Does anyone have any better approach to suggest? It's hard to know without knowing what the threat model is. But I would say you could simply include several 100 certificates on the CD, each encrypted with a different key. You can then give a distinct certificate number and key to each customer and they can use that to decrypt their certificate. There is no need for the certificate to contain the server's name. That would only be needed if you needed the CA (that's you) to vouch for the server's name, which you can't do. If you only need the server to vouch for its own name, it can simply send that name. If desired, you can use a two-level scheme. It works like this: 1)
Re: Safe signed certificate generation during server installation ?
For now, my purpose is not to establish and identity of a server with the certificate. I plan to use a signed certificate, so that the client can be sure that the server indeed holds the private key associated with the public key provided by the server in its certificate. You have a non-standard security model. The standard SSL security model has the CA sign the certificate to verify that the *name* in the certificate belongs to the key in the certificate. It is almost always a mistake to try to get commodity software to enforce a non-standard security model. That is, you can't expect programs like firefox and IE to connect to SSL servers using certificates generated with a non-standard security model and get any kind of sane behavior. It sounds like you don't need a certificate at all. You just need the server to be able to prove that it own a particular private key. Presumably this is for server persistence (so I can tell I'm talking to the same server I was last time). So I think the servers should be using self-signed certificates and the clients should be configured to accept self-signed certificates (since they don't care about being able to verifyt the common name). There is no point in having a CA at all, as I understand your problem. The only point in embedding the CA in the installer and configured the clients to trust the CA would be to all the clients to trust the common name in the certificate. But clearly the clients *can't* trust the common name in the certificate. So it seems like you're trying to solve a problem that's actually a design property of your security model. I doubt if self signed certificate will be a good idea, as against a signed certificate. With the approach I am proposing, the server installer itself works like a CA. Only an authorized person will have access to this installer (say admin) and can generate a signed certificate. Now what happens if someone changes the key and the certificate in the server? If I am using a self signed certificate, this change will not be detected. If I am using a CA signed certificate (which only the admin can do through the installer), any such change / modification to the server certificate will be detected as the modified certificate will not be validated at the client side (as it will not be signed). This is the reason, why I plan to use a CA signed cert instead of self signed cert at the server. Also, I do plan to user server certificates (and client certificate also) for proving the identity, but not in this phase. DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
I doubt if self signed certificate will be a good idea, as against a signed certificate. With the approach I am proposing, the server installer itself works like a CA. Only an authorized person will have access to this installer (say admin) and can generate a signed certificate. I don't know if you're familiar with how real CAs operate, but trust me, restricting access to your installer won't provide anywhere near the security that real CAs do. Now what happens if someone changes the key and the certificate in the server? If I am using a self signed certificate, this change will not be detected. Perhaps you misunderstand what I'm proposing. If you use a self-signed certificate, the change will be detected because the certificate will now be different. I'm suggesting the client use the public key itself as the server's identity. If I am using a CA signed certificate (which only the admin can do through the installer), any such change / modification to the server certificate will be detected as the modified certificate will not be validated at the client side (as it will not be signed). The problem is that anyone who has access to your installer can impersonate any server. Whether or not this is acceptable depends upon a few factors. I would submit that if your client is a traditional program like IE or Firefox and your target network is the Internet, this is absolutely unacceptable. If your client is custom software and/or your target network is private, this might be reasonable. This is the reason, why I plan to use a CA signed cert instead of self signed cert at the server. What's your client software? Is it a browser or custom software? If a browser, and you're expecting the client to add your CA as a trusted root, you are compelling your users to trust an awful lot to anyone who might get access to your installer, accidentally or intentionally. A leak of your installer would mean a serious security compromise to all your users. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
Thank you very much for your response , David and Victor. I really appreciate it. So could someone guide me with the best practices used in such scenarios? Is there a way to securely embed the private key in the installers / CA certificate? I guess I'm confused. What purpose would a certificate serve if anyone can generate one that serves any purpose? If I can generate a certificate that says I'm the pope just by entering that into your installer, then a certificate that says I'm the pope doesn't prove I'm the pope. For now, my purpose is not to establish and identity of a server with the certificate. I plan to use a signed certificate, so that the client can be sure that the server indeed holds the private key associated with the public key provided by the server in its certificate. So what's the point of the entire exercise?! For the requirement of certificate generation on the fly (during installation) following is the scenario: A] I have a client - server application that I would be shipping to different customers. The admin at every customer will install the client and server software on different machines. For the SSL to work, the client software would require a root CA cert, and the server software would require its certificate + key. (NOTE: Only the clients in a particular customer's network will be able to access the server in that particular customer's n/w.) B] I plan to provide the required root cert + server cert to the customer to kick start the applications in the customer environment. I have a CA established at my end. The root CA cert of this CA will be used to generate server certificates (NOTE: I will not be using a CA chain. There will be only one certificate issuing authority) C] Now from the point of view of 'ease of deployment', I would like to burn the same image of my server/client software on say 10 CDs and ship them to 10 customers. But, every customer will need to have a distinct server certificate for his server installation. ( Also, it is possible that a customer may wish to run two servers on two machines in the same network. So he will need two different server certificates.) So, if I have to provide the certificates to the customer as part of my product, I would have to generate 10 distinct certificate, and one certificate to one CD. So basically I will be writing 10 distinct CD images for 10 customers. Also, I would be generating the certificates for these customers based on the information that 'they' provide to me. So considering the points above, I thought of providing the certificate generation capability as part of my installation itself. This way, I will have to burn the same image on all the 10 CDs. Also, my customers will be saved from sending me the information required to generate a certificate for them. Instead, they themselves (The admin who installs the server) can provide this information as part of installation and the certificate will be generated behind the scenes. Victor, Typically this means that the administrator has some way to authenticate to a credential enrollment system (kadmind, X.509 cert enrollment website, ...) and can interact with the system to generate the cert for the newly built host I am sorry but I am not sure I followed what you said about Could you please explain this, may be with an example scenario / real life scenario? I will highly appreciate any comments / suggestions / help tackling this scenario. Thank you. ~ Urjit DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Pvt. Ltd. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Persistent Systems Pvt. Ltd. does not accept any liability for virus infected mails. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
For now, my purpose is not to establish and identity of a server with the certificate. I plan to use a signed certificate, so that the client can be sure that the server indeed holds the private key associated with the public key provided by the server in its certificate. You have a non-standard security model. The standard SSL security model has the CA sign the certificate to verify that the *name* in the certificate belongs to the key in the certificate. It is almost always a mistake to try to get commodity software to enforce a non-standard security model. That is, you can't expect programs like firefox and IE to connect to SSL servers using certificates generated with a non-standard security model and get any kind of sane behavior. It sounds like you don't need a certificate at all. You just need the server to be able to prove that it own a particular private key. Presumably this is for server persistence (so I can tell I'm talking to the same server I was last time). So I think the servers should be using self-signed certificates and the clients should be configured to accept self-signed certificates (since they don't care about being able to verifyt the common name). There is no point in having a CA at all, as I understand your problem. The only point in embedding the CA in the installer and configured the clients to trust the CA would be to all the clients to trust the common name in the certificate. But clearly the clients *can't* trust the common name in the certificate. So it seems like you're trying to solve a problem that's actually a design property of your security model. DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
RE: Safe signed certificate generation during server installation ?
So could someone guide me with the best practices used in such scenarios? Is there a way to securely embed the private key in the installers / CA certificate? I guess I'm confused. What purpose would a certificate serve if anyone can generate one that serves any purpose? If I can generate a certificate that says I'm the pope just by entering that into your installer, then a certificate that says I'm the pope doesn't prove I'm the pope. So what's the point of the entire exercise?! DS __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Safe signed certificate generation during server installation ?
On Wed, Sep 19, 2007 at 08:01:28AM -0700, David Schwartz wrote: So could someone guide me with the best practices used in such scenarios? Is there a way to securely embed the private key in the installers / CA certificate? I guess I'm confused. What purpose would a certificate serve if anyone can generate one that serves any purpose? If I can generate a certificate that says I'm the pope just by entering that into your installer, then a certificate that says I'm the pope doesn't prove I'm the pope. So what's the point of the entire exercise?! Bootstrapping server credentials in a scalable fashion in a large environment is a tricky problem. Whether the credentials are Kerberos host keytabs, or X.509 identity certs, the best practice is to entitle the human administrator who builds the host to generate the initial host credentials. Typically this means that the administrator has some way to authenticate to a credential enrollment system (kadmind, X.509 cert enrollment website, ...) and can interact with the system to generate the cert for the newly built host. Some systems impose a higher barrier for re-issuing creds for an existing name (impersonation risk) than for obtaining creds for a never used name. This is what operating an authentication system is all about, the keys, certs, ... are just the technical bits of stale evidence of alleged past due diligence. Security derives more from getting the process right than from the cryptographic strengh of the various protocols. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
