Using crypto against Phishing, Spoofing and Spamming...
Anne & Lynn Wheeler
lynn at garlic.com
Sun Jul 18 11:51:46 EDT 2004
At 05:55 PM 7/17/2004, Eric Rescorla wrote:
>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 majordomo at metzdowd.com
More information about the cryptography
mailing list