James A. Donald wrote:
PKI was designed to defeat man in the middle attacks based on network sniffing, or DNS hijacking, which turned out to be less of a threat than expected.
all of them may have been less than expected ... the comoningly recognized SSL certificate issuers (that have their public key preloaded into common browsers) sell their certificates and have processes that look at whether you have a validly registered corporation. For most practical purposes this has been for e-commerce sites and the objective for the majority is protecting credit card numbers. however, the reported exploits .... and what seem to represent a significantly larger ROI (fraud for effort invested) is to harvest the merchant transaction file (containing all the accumulated transaction information that would have taken months of listening to gather) ... aka it is much easier to let the merchant gather and organize all the information on behalf of the crook. slightly related posting ... http://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk the original ssl e-commerce work http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn3 had the user typing in the merchant webserver URL as a HTTPS session from the start and then it would check the domain name in the returned certificate (after all the digital signature gorp) with the domain name typed in. this is rarely if ever happening ... the common justification is running SSL during the shopping experience cuts the thruput by 80-90 percent. as a result, SSL is typically saved for the "check-out" button. so lets say you have been redirected to a fraudulent site and don't know it because the SSL domain name stuff hasn't been done yet. then comes time to do the check-out button. if it is a fraudulent site ... and since the crooks would then be supplying the URL with the check-out button ... the crooks are likely to have obtained a valid SSL certificate for some domain and that domain will match whatever the check-out button supplies. random past ssl certificate posts http://www.garlic.com/~lynn/subpubkey.html#sslcert crooks are capable of setting up valid dummy front companies ... it isn't a very large effort. most of what the CA TTPs do when they are verifying stuff ... is that the person applying for a certificate is in some way associated with a valid company that they claim to be associated with. then the CA TTPs check with the domain name infrastructure to see if the corporation that they just checked on ... is the same one listed as the owner of the subject domain name (modulo the issue that there can be a common company name, a DBA company name, and a legal company name ... all for the same corporation and all completely different names ... you sometimes will see this in credit card statements where the store-front name and the company name on the statement are different). As observed, one of the things SSL was for a countermeasure for integrity problems in the domain name infrastructure involving domain name hijacking (where the mapping of the domain name to an ip-address was altered to be a different ip-address, potentially fraudulent website). However, there have been more sophisticated domain name hijackings that have occured where both the domain name infrastructure records had both the name of the corporate owner as well as the ip-address altered. In this more sophisticated form, a crook with a perfectly valid dummy front corporation ... that has done the more sophisticated form of domain name hijacking ... could apply for a perfectly valid SSL domain name certificate ... and pass all the tests. in any case, that was my perception of what we were doing with SSL ten years ago. PKI is slightly different. One of the reasons that we coined the term "certificate manufactoring" was to try and differentiate what was comingly being referred to as PKI ... and what SSL domain name certificate stuff was actually doing. Note that there has been a proposal to somewhat address the more complex form of domain name hijacking (both the company name take-over as well as the ip-address take-over) ... which involves having domain name owners register a public key when they get a domain name. Then all future correspondance with the domain name infrastructure is digitally signed ... which then can be veriefied with the onfile public key. as a side note ... this is a non-PKI, certificateless implementation of public key. In any case, with authenticated correspondance ... there supposedly is less chance of domain name hijacking occuring. http://www.garlic.com/~lynn/subpubkey.html#certless This has somewhat been supported by the CA SSL domain name certification industry. The have a complex, expensive, and error-prone identification process to try to establish a valid corporation. And even then they are at the mercy of whether the company name listed in the domain name infrastructure is actually the correct company (i.e. their whole infrastructure otherwise is useless). The other advantage ... is that the Certification Authority can require that SSL domain name certificate applications also be digitally signed. Then the CA can turn an expensive, time-consuming, and error-prone identification process into a much simpler, cheaper, and reliable authentication process ... by retrieving the onfile public key from the domain name infrastructure for verifying the applicants digital signature (again note that this is a non-PKI, certificateless implementation that they would use as the trust basis for the whole SSL domain name certificate operation). There is some slight catch22 to this for the SSL domain name certificate business. First off, improving the integrity of the domain name infrastructure for the Certification Authority industry ... would also improve the integrity for everybody ... somewhat mitigating one of the original supposed requirements for having SSL domain name certificates in the first place. The other is that if the SSL certification industry found it viable to base their trust infrastructure on the certificateless, onfile public keys at the domain name infrastructure... it might be possible that the rest of the world might find them acceptable also. One could imagine a slightly modified SSL process where the public key didn't come from a certificate ... but was an onfile certificateless public key retrieved directly from the domain name infrastructure (in much the same way the CA industry has proposed doing). --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com