SSL, client certs, and MITM (was WYTM?)

[Anne & Lynn Wheeler]

At 05:42 PM 10/22/2003 -0400, Tom Otvos wrote:

>Absolutely true.  If the "only" effect of a MITM is loss of privacy, then 
>that is certainly a
>lower-priority item to fix than some quick cash scheme.  So the "threat 
>model" needs to clearly
>define who the bad guys are, and what their motivations are.  But then 
>again, if I am the victim of
>a MITM attack, even if the bad guy did not financially gain directly from 
>the attack (as in, getting
>my money or something for free), I would consider "loss of privacy" a 
>significant thing. What if an
>attacker were paid by someone (indirect financial gain) to ruin me by 
>buying a bunch of stock on
>margin?  Maybe not the best example, but you get the idea.  It is not an 
>attack that affects
>millions of people, but to the person involved, it is pretty 
>serious.  Shouldn't the "server" in
>this case help mitigate this type of attack?


ok, the original SSL domain name certificate for what became electronic 
commerce was

1) am I really talking to the server that I think I'm talking to
2) encrypted session.

so the attack in #1 was plausably some impersonation ... either MITM or 
straight impersonation. The issue was that there was a perceived 
vulnerability in the domain name infrastructure that somebody could 
contaminate the domain name look up and get the ip-address for the client 
redirected to the impersonater.

The SSL domain name certificates carry the original domain name .... the 
client validates the domain name certificate with one of the public keys in 
the browser CA table ... and then validates that the server that it is 
communicating with can sign/encrypt something with the private key that 
corresponds to the public key carried in the certificate ... and then the 
client compares the domain name in the certificate with the URL that the 
browser used.  In theory, if all of that works .... then it is highly 
unlikely that the client is talking to the wrong ip-address (since it 
should be the ip-address of the server that corresponds to the server).

So what are the subsequent problems:

1) the original idea was that the whole shopping experience was protected 
by the SSL domain name certificate .... preventing MITM & impersonation 
attacks. However, it was found that SSL overhead was way to expensive and 
so the servers dropped back to just using it for encryption of the shopping 
experience. This means that the client ... does all their shopping ... with 
the real server or the imposter ... and then clicks on a button to check 
out that drops the client into SSL for the credit card number. The problem 
is that if it is an imposter ... the button likely carries a URL for which 
the imposter has a valid certificate for.

or

2) the original concern was possible ip-address hijacking in the domain 
name infrastructure .... so the correct domain name maps to the wrong ip 
address .... and the client goes to an imposter (whether or not the 
imposter needs to do an actual MITM or not). The problem is that when 
somebody approaches a CA for a certificate .... the CA has to contact the 
domain name system as to the true owner of the domain name. It turns out 
that integrity issues in the domain name infrastructure not only can result 
in ip-address take-over .... but also domain name take-over. The imposter 
exploits integrity flaws in the domain name infrastructure and does a 
domain name take-over .... approaches a CA for a SSL domain name 
certificate ... and the CA issues it ... because the domain name 
infrastructure claims it is the true owner.


So somewhat from the CA industry ... there is a proposal that people 
register a public key in the domain name database when they obtain a domain 
name. After that ... all communication is digitally signed and validated 
with the database entry public key (notice this is certificate-less). This 
has the attribute of improving the integrity of the domain name 
infrastructure ... so the CA industry can trust the domain name 
infrastructure integrity so the rest of the world can trust the SSL comain 
name certificates?

This has the opportunity for simplifying the  SSL domain name certificate 
requesting process. The entity requesting the SSL domain name certificate 
.... digitally signs the request (certificate-less of course). The CA 
validates the SSL domain name certificate request by retrieving the valid 
owner's public key from the domain name infrastructure database to 
authenticate the request. This is a lot more efficient and has less 
vulnerabilities than the current infrastructure.

The current infrastructure has some identification of the domain name owner 
recorded in the domain name infrastructure database. When an entity 
requests a SSL domain name certificate ... they provide additional 
identification to the CA. The CA now has to retrieve the information from 
the domain name infrastructure database and map it to some real world 
identification. They then have to take the requester's information and also 
map it to some real world identification. They then have to try and see if 
the two real word identifications match. The recording of the public key 
for certificate-less authentication ... not only improves the integrity of 
the domain name infrastructure (so that it can be better trusted by the CA 
industry) .... but it can also convert a very error prone identification 
process for certificates into a simple authentication process.

So now we have the catch-22 clinker for the CA industry (since they are 
somewhat sponsoring this whole idea)

1) if the certificate-less public key process improves the integrity of the 
domain name infrastructure, then one can claim that the integrity concerns 
about the domain name infrastructure are lessoned and therefor the 
perceived requirement for SSL domain name certificates is lessoned

2) if the CA industry can use the registered public key for 
certificate-less authentication regarding domain name related operations 
... then presumably the rest of the world can also ... which would further 
eliminate justifications for SSL domain name certificates (i don't need to 
get the server's public key from a certificate .... I could get it from a 
dynamic, trusted, information distribution utility ... the domain name 
infrastructure).


as before ... misc SSL domain name certificate related posts:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

the following also have some references to domain name hijacking events (as 
opposed to ip-address hijacking):
http://www.garlic.com/~lynn/subpubkey.html#fraud

--
Anne & Lynn Wheeler    http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm
  

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com