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