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.) What does it mean ? Are you saying that programmers mistakes, lack of knowledge of X509 or SSL/TLS are worse then using undocumented, unchecked, security protocols ? Certificate validation on cryptography layer should be performed by SSL, certificate validation at application/user layer are performed by programmer. If programmer is not sure how to do this step, there are many popular opensource projects available to look at and learn how to do this (Apache, FreeSWAN, ...). If this is too tiring, he may buy a book with all this details explained. For example "Network Security with OpenSSL", chapter 5 "SSL/TLS Programming", and look at "5.1.3 Peer Authentication" with function post_connection_check() which parses certificate subject, issuer, and extensions with many comments. Almost copy-paste implementation :-) Or if he prefer Java he may buy "Beginning Cryptography with Java", go to chapter "10 SSL and TLS" and look at "Client-Side Authentication" and learn. Or he may use Google to get some example code and advises. I want to show the difference between documented/widely used protocols or good practice and undocumented/not widely used methods. Even that you "have seen serious bugs in certificate validation", how serious bugs may have security protocol implemented by inexperienced programmer which have only global information about this protocol, no documentation, no RFC, no information of good message format, no test vectors, ... ?
> > 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? But there is many implementations you can look at and learn. There are RFC that suggests how to proceed, you may look at FreeSWAN source code and config files, you may look at Cisco VPN Client/Server to learn how certificate is processed, what extension are used, what extended key usage are needed, how to select/authorize subject/issuer. In TLS there is progress too, you may look at RFC4681 "TLS User Mapping Extension", you may use OCSP to revoke compromised certificates online. >Is this ok or not? Its ok. > Everything you do has to be checked. Any time you can't do things exactly > the way everyone else does, you have this problem. But in this case all may be done with standard methods/protocols/good practice. 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]
