Now, my threat model mostly includes (1), does not really include (3), and I'm careful not to do things that leave me susceptible to (2), so SSL does in fact protect against the attacks in my threat model. I know a number of other people with similar threat models. Accordingly, I think the claim that "secure browsing is not secure" rather overstates the case.
there sort of two parts of SSL .... I believe the original justification was based on perceived integrity issues with the domain name infrastructure and various kinds of hijacking attacks. the client got back a certificate, verified the integrity of the certificate (from a table of certificate authority public keys), verified that it appeared to originate from the certificate owner and then compared the certificate domain name string with the domain name used in the URL. once that was done, there was key-exchange to protect the contents of the transmission.
the catch22 was that the domain name infrastructure is also the authoritative agency as to the owner of the domain name. the SSL domain name certification authorities have this horrendously, error prone and expensive problem of getting sufficient identification information from the certificate applicant and attempting to match it with the identification information carried by the domain name infrastructure as to the owner of the domain name.
so the first issue is that the integrity of the domain name infrastructure could be attacked with a domain name hijack ... then the attacker applies for a certificate .... and the identification provided the certification authority and the identification on file with the domain name infrastructure compare ... and the attacker gets a valid certificate.
so the certification authorities came up with a proposal to have domain name registers .... also supply a public key at the time of registration. then future communication with the domain name owner is digital signed ... which the domain name infrastructure can verify with the public key on file. this is a countermeasure against domain name hijacking (improving the integrity of the domain name infrastructure and rising the trust that certification authorities can place in the authoritative agency). the other issue is that the certification authorities can use the public key on file with the domain name infrastructure to turn an expensive, and error-prone identification process into a much simpler and KISS authentication process .... aka domain name certificate applicants digitally sign their requests ... which are then verified with the public key on file at the domain name infrastructure.
the two issues then are that with increased domain name infrastructure trust ... 1) it should reduce the demand for domain name SSL certificates (motivated by integrity concerns about the domain name infrastructure) and 2) it could eliminate the need for domain name SSL certificates .... since all clients could possibly also use the public keys on file with the domain name infrastructure (in lieu of needing to get public keys from certificates).
So now to the key-exchange issue protecting credit-card numbers from evesdropping and harvesting. The issue is that the crooks tend to go after the best fraud ROI (return on investment). The claim is that it is so much more profitable to harvest the merchant transaction file .... that until that barn door is closed .... the crooks have little incentive to go after credit card numbers by evesdropping packets in flight. There have been some assertions that there has been no known cases of picking up account numbers from packet evesdropping .... even where SSL or any other encryption is being used to protect data in-flight. Part of the issue is that evesdropping packets takes a lot more work ... and provides much less return than going after the merchant transaction file. Other scenarios have also been end-point attacks ... where password files are harvested and/or viruses are installed at end-points to harvest information .... as opposed to doing anything with data in-flight.
So, it could be claimed that there is some question about what is cause and what is effect i.e. are the end-point attacks because everything is encrypted .... or are the end-point attacks occurring because they are so much more profitable and easier. Given that there are significant amounts of non-encrypted traffic ... then the claim could be made that the crooks are getting so much more from end-point attacks ... and until that is addressed ... that attacks on data in flight is somewhat academic (since there is so little evidence about fraud happening from data in flight attacks). The other argument has traditional been that 90 percent of fraud has been insiders, typically also associated with various kinds of end-point attacks (rather than any kind of outsider attack on data in flight). There was some recent study that at least 77 percent of the identity theft has involved insiders. This would also indicate that the end-points are the primary points of attack .... and that data-in-flight attacks are of primarily of academic interests ... not particularly contributing to fraud, even when no encryption or protection is involved.
One might even assert that the attention paid to data-in-flight attacks is actually counterproductive ... distracting attention from the much more serious and significant end-point attack fraud .... which has always been the major problem.
--
Anne & Lynn Wheeler http://www.garlic.com/~lynn/
--------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
