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