Re: Public Key Infrastructure: An Artifact...
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.
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.
Furthermore, if a higher integrity domain name infrastructure included public
keys in the domain name record ... clients could request a real-time, trusted
copy of the public key as a adjunct to host-name lookup. This would further
eliminate the requirement for any certificate involvement in the majority of the
existing SSL transaction operation (i.e. client gets the public key at the same
time hostname resolution is done ... the client can trust a real-time
host/domain name because of the improvement in the domain name infrastructure
integrity ... and at the same time it can trust a real-time publickey for the
same host/domain).
Bram Cohen
Lynn.Wheeler@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.
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.
How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol.
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.
Medicate? What?
Furthermore, if a higher integrity domain name infrastructure included public keys in the domain name record ... clients could request a real-time, trusted copy of the public key as a adjunct to host-name lookup. This would further eliminate the requirement for any certificate involvement in the majority of the existing SSL transaction operation (i.e. client gets the public key at the same time hostname resolution is done ... the client can trust a real-time host/domain name because of the improvement in the domain name infrastructure integrity ... and at the same time it can trust a real-time publickey for the same host/domain).
And the benefit of that (apart from lock-in) would be what? 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
On Sat, 18 Nov 2000, Ben Laurie wrote:
Lynn.Wheeler@firstdata.com wrote:
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.
How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol.
As opposed to the spurious revenue stream for Verisign? -Bram Cohen
Bram Cohen wrote:
On Sat, 18 Nov 2000, Ben Laurie wrote:
Lynn.Wheeler@firstdata.com wrote:
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.
How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol.
As opposed to the spurious revenue stream for Verisign?
Like I said: how does that help? Moving spurious revenue streams around gets us nowhere. 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
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
How on Earth does that help? The key is already strongly linked to the domain name - registering it with NetSol (for example) does nothing interesting except to create another spurious revenue stream for NetSol.
As opposed to the spurious revenue stream for Verisign?
Like I said: how does that help? Moving spurious revenue streams around gets us nowhere.
There are multiple domain name registrars - there is only one Verisign. -Bram Cohen
On Sat, 18 Nov 2000 Lynn.Wheeler@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. -Bram Cohen
Bram Cohen wrote:
On Sat, 18 Nov 2000 Lynn.Wheeler@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
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
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?
Yes he can - he's presenting the key for hackeddomain.com, which he stole, so he's quite capable of reading requests sent for it. -Bram Cohen
Bram Cohen wrote:
On Sat, 18 Nov 2000, Ben Laurie wrote:
Bram Cohen wrote:
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?
Yes he can - he's presenting the key for hackeddomain.com, which he stole, so he's quite capable of reading requests sent for it.
Apologies, yes, you are correct, I misunderstood. But isn't this what Lynn was suggesting in the first place? 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
participants (3)
-
Ben Laurie -
Bram Cohen -
Lynn.Wheeler＠firstdata.com