* 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 List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
