CDR: Public Key Infrastructure: An Artifact...

[Ben Laurie]

Bram Cohen wrote:
> 
> On Sat, 18 Nov 2000 Lynn.Wheeler at firstdata.com wrote:
> 
> > note also that current SSL infrastructure is vulnerable to things like domain
> > name hijacking; aka, at least part of SSL protocol is to make sure that you
> > really are talking to the host that you think you are talking to ... i.e. the
> > SSL certificate contains host/domain name (all this, in theory because of
> > weaknesses in the domain name infrastructure) ... and when SSL goes to check
> > something in the certificate ... it is checking the hostname/domainname against
> > the hostname/domain name that the browser is using.
> >
> > However, SSL-certificate issuing CAs have to rely on the domain name
> > authoritative infrastructure with regard to issuing SSL-certificates & domain
> > name ownership issues ... this is the same authoratative infrastructure that
> > supposedly can't be relied on and justifies having a the whole SSL-certificate
> > infrastructure to begin with.
> 
> To be fair, this sort of attack is much more involved and must be planned
> much farther in advance.
> 
> > In any case, the domain name infrastructure has been looking at ways to beef up
> > the integrity of its operation ... like having public keys registered as part of
> > domain name registration. Now, if domain name infrastructure is going to use
> > public key registration as part of beefing up its integrity ... that would
> > medicate  much of the justification for the SSL-certicate infrastructure.
> 
> This would remove one of the more serious barriers to running an SSL
> site - the Verisign protection money.
> 
> The problem with all of these things is that they are still based on
> creating an association between a domain name and a key, when in fact what
> you want is an association between some abstract concept of a counterparty
> which exists in an end user's mind (like, say, amazon) and the ownership
> of a machine that user's browser is talking to.
> 
> Unless that problem is fixed, man in the middle is hardly made more
> difficult - for example, Mallory could break into some random machine on
> the net and steal it's public key, then hijack local DNS and when someone
> goes to amazon.com redirect them to amazon.hackeddomain.com, and then
> proxy to amazon.com - now even SSL says the connection is safe.

Yes, and Mallory can't read the data - so what was the point?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff