X.509 / PKI, PGP, and IBE Secure Email Technologies

[Anne & Lynn Wheeler]

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 majordomo at metzdowd.com