Ben Laurie wrote: > Eh? It surely does stop MitM attacks - the problem is that there's > little value in doing so for various reasons, such as no strong binding > between domain name and owner, UI that doesn't make it clear which > domain you are going to, or homograph attacks.
it stops the MITM attacks where the client supplies a URL and the server supplies a certificate that corresponds to the URL. the original issue is that a MITM might have redirected the connection from the client to a bogus site ... or an intermediate site that then impersonated the real site. the infrastructure issue was that the merchants decided that SSL was too high an overhead and stopped using SSL for the main connection where the client supplied the URL. they allowed the client supplied URL connection to be done w/o a URL. then later ... the website provided a click button for checkout/pay ... which supplied a URL and then they also supplied a certificate that matches the URL that they provided. this situation could either be a completely bogus site ... or even a mitm-attack ... which just did a pure passthru of all traffic going in each way .... except for the pay/checkout button. for the pay/checkout button, the mitm substituted their own URL & certificate. everything else passes thru as usual ... except the mitm is having two ssl session ... the mitm to "real" server session and the mitm to the client session. the mitm to "real" server uses the "real" server's certificate ... the mitm to client server users the mitm certificate. since the mitm supplied the URL to the client as part of the click operation ... the mitm can control that the actual URL invoked by the client matches the certitificate used by the mitm. the e-commerce use for pay/checkout scenario is one of the major uses for SSL on the internet today ... and the way that the infastructure has come to use SSL no longer prevents the mitm-attack with the attacker can supply both the URL and the certificate. the issue for preventing mitm-attacks ... you need the client to supply the URL and have the SSL process validate the other end of that connection (with a server provided ssl domain name certificate ... or at least a trusted, supplied public key associated with the URL). when the attacker provides both the URL and a trusted public key ... what is being prevented. there is another problem, somewhat the week binding between domain name and domain name owner. the issue is that many of the certification authorities aren't the authoritative agency for the information they are certifying. much of the original justification for SSL related to mitm attacks was various integrity issues in the domain name infrastructure. the process tends to be that a domain name owner registers some amount of identification information for their domain name ownership with the domain name infrastructure. the certification authorities then require that SSL domain name certificate applicants also provide some amount of identification information. then the certification authorities attempt to do the expensive, time-consuming, and error-prone process of matching the supplied identification information for the SSL domain name certificate with the identificaiton information on file with the domain name infrastructure for the domain name. as part of various integrity issues related to that process, there has been a proposal, somewhat backed by the ssl domain name certification authority industry that domain name owners also register a public key with the domain name infrastructure (in addition to identificaiton information). then future communcation can be digitally signed and verified with the onfile public key. also the ssl domain name certification authority industry can require that ssl domain name certificate applications be digitally signed. then the certification authority can replace the expensive, time-consuming, and error-prone identification matching process with a much less-expensive and efficient authentication process by doing a real-time retrieval of the on-file publickey from the domain name infrastructure for verifying the digital signature (in lieu of doing a real-time retrieval of the on-file identificaiton information for the expensive, time-consuming and error-prone identification matching). the two catch22 issues here are 1) improving the overall integrity issues of the domain name infrastructure lessons the original justification for ssl domain name certificates 2) if the certification authority industry can rely on real-time retrieval of publickeys from the domain name infrastructure as the base, TRUST ROOT for all of their operations ... it is possible that other people in the world might also be able to do real-time retrieval of publickeys as a substitute to relying on SSL domain name certificates misc, numerous past postings mentioning SSL and ssl domain name certificates http://www.garlic.com/~lynn/subpubkey.html#sslcert --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]