On 12/29/05, Dr. Stephen Henson <[EMAIL PROTECTED]> wrote: > On Thu, Dec 29, 2005, WebSpider wrote: > > > The issue I'm running into is as follows: A new node (A) is about to > > make it's first connection to an already existing node (B). The new > > node knows the IP address and port number by use of a configuration > > file. > > > > The already existing node (B) has the posession of the following data: > > > > * The public root certificate > > * The full list of all signed certificates > > * The CRL > > * It's own public certificate and private key for the certificate > > > > The new node (A) has the posession of the following data: > > > > * The public root certificate > > * It's own public certificate and private key for the certificate > > > > Some more information: > > * Both the full list of signed certificates and CRL are not available > > from any other source than the already existing node > > * The commonName field is not to be used to identify the remote host, > > since the value of the commonName field in the certificate of the > > already existing node may vary > > > > 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 ? > > > > So from your description new nodes already have the public root certificate > from some trusted means?
This is true. > That at least means that a man in the middle attack can only be performed by > an entity posessing a certificate issued by the root CA. Good thing to know, thanks ! > That leaves the possibility of a new node (A') impersonating an existing node. > To avoid that you need to be able to identify nodes securely. > > How you do that varies. For HTTPS websites for example the certificate > contains details of the host name and the CA is implicitly trusted to check > the validity of the entity claiming to represent that host name before issuing > a certificate. Right. Then I guess that is something I need to look at, since I currently cannot reliably identify a remote node, and therefore seem to be lacking the public key information to initiate secure communication. Would you happen to know other ways of identifying a remote node, other than to trust DNS? Greetings, Nils -- Simple guidelines to happiness: Work like you don't need the money, Love like your heart has never been broken and Dance like no one can see you. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
