Is there a way to do an ephemeral (i.e., unauthenticated) encryption channel before transmitting whatever certificates are to be used for authentication? I tend to look at certificate disclosure as an "information leakage" issue, that gives Eve more information than she really has any business having. Mallory, of course, can accept an incoming request, then get the certificate of the one connecting... but that is prima facie evidence of a much more malicious intent than a simple eavesdropper. (A network administrator can capture traffic on a network for troubleshooting purposes -- and thus, put him/herself into the role of Eve. It would take a truly malicious intent to intercept the connection attempt.)
More specifically, is there a way to do this in OpenSSL? :) Thanks for your time, -Kyle H On 12/30/05, David Schwartz <[EMAIL PROTECTED]> wrote: > > > How can I make the new node (A) send an encrypted request to the > > already existing node (B) while node A does not have any public > > key/certificate information about the already existing node (B), and > > still make sure that I am actually talking to B, and not some > > Man-In-The-Middle ? > > > > Thanks a bunch for any thoughts, > > Node A wants to talk to node B and not any other node, say, C. The > question > is what does "B" mean to node A? That is, what makes node B different from > node C? > > For example, when I punch in 'https://www.amazon.com', what makes the > Amazon web server different from any other is that it has a certificate from > a trusted root authority certifying that it belongs to the rightful owner of > the domain 'amazon.com'. In other words, I don't want to talk to any > computer, I want to talk to one that can prove, by reference to an authority > I trust, that it is authorized by the rightful owner of 'amazon.com'. > > When you think about why you want to reach node B in this way, and > what > makes node B different from any other node, the answer will be much easier > to give you. > > If you literally want to reach 'node B', and you trust the root CA, > just > have the root CA put 'this is node B' in the certificate. So you simply > verify that node B owns the private key corresponding to the public key in > the certificate and that the certificate contains you 'this is node B' > information. > > No other node but node B can do this, unless the root CA is > compromised. So > this reduces to having to trust the root CA. Which, if you didn't, it > wouldn't be the root. ;) > > Perhaps you misunderstand how DNS is normally used with SSL and think > that > SSL somehow makes DNS more secure. This is not so at all. DNS is only used > to find the host which we then verify *owns* the DNS name. We could just as > well verify that it owned any other sort of thing, so long as there was a > root CA we trusted to tell us who owns things of that type. > > I hope that's clear. > > DS > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
