man in the middle, SSL

[Anne & Lynn Wheeler]

James Muir wrote:
> It is my understanding that SSL is engineered to resist mitm attacks, so 
> I am suspicious of these claims.  I wondered if someone more familiar 
> with SSL/TLS could comment.
> 
> Isn't in the case that the application doing SSL on the client should 
> detect what this proxy server is doing and display a warning to the user?

My oft repeated comment about when we were asked to consult with this small
client/server startup that wanted to do payments on servers .... and had this
technology called SSL ... 
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

The browser was to check that what the person typed in ... matched the domain name
in the digital certificate that the server provided (that the server that the client
thot they were talking to was the server that they were talking to).

There was some other ancillary things that we were interested in ... that the digital 
certificate actually represented something more ... i.e. it was issued by the acquiring
financial institution that financially stood behind the merchant .... since the merchant
was already paying a lot of money to cover doing business. however, that never happened
... so the digital certificate just represents that it belongs to the owner of the domain.
this issue is somewhat touched on in this blog posting
http://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
in this blog
https://financialcryptography.com/mt/archives/000863.html

However, early on, merchant webservers found that that doing SSL for the whole shopping
experience cut their thruput by something like 80-90 percent ... so the industry fairly
quickly switched to just using SSL for the payment/checkout portion when you click on
their button. Now the URL is being provided by the server (button) ... not by the client,
as a result the effect is no longer "is the client talking to the server that the
client thinks they are talking to" ... since the server is supplying both the URL
and the digital certificate ... the result is "the server is the server that the
server claims to be" (unless it is a really dumb crook/attacker).

It isn't sufficient for their to be "ssl certificates" to be countermeasure to MITM-attack,
the security process has to include that the server is validated against something the 
client supplies ... not that the server is validated against something the server supplies
(i.e. i can prove that i am whoever i claim to be ... not that i can prove that i am who
you think i am).

This is also behind a lot of the phishing stuff ... that the attacker can claim to be
something ... and provide a field/button for you to click on ... the SSL certificate
then just proves that the server matches the URL provided by the field/button;
since the attacker supplier field/button is producing the URL ... and not the client 
... it takes advantage of the difference, for a MITM-attack ... between the opening/crack
opened by what is claimed for the button and what the URL actually is ... since only the 
URL is being validated by the SSL certificate  ... not what the client thinks is claimed 
for the field/button. some more comments in these posts:
http://www.garlic.com/~lynn/2007c.html#3 "New Universal Man-in-the-Middle Phishing Kit"?
http://www.garlic.com/~lynn/2007c.html#32 Securing financial transactions a high priority for 2007

lots of past posts mentioning MITM-attacks
http://www.garlic.com/~lynn/subintegrity.html#mitm

i.e. you have to understand the end-to-end business process (of security) ... where all
the cracks are ... and just which (of possibly large number) MITM vulnerability ...
that you have specifically created a countermeasure for.

so one of the things that we did as part of early deployment (of this stuff that has since 
come to be called electronic commerce) was go around and do some detailed end-to-end audits
of these emerging operations that were calling themselves certification authorities and
producing these things that were being called SSL domain name digital certificates.
At the time, we coined this term "certificate manufacturing" to try and differentiate
what was happening
http://www.garlic.com/~lynn/subpubkey.html#manufacture
and what was in the literature about "public key infrastructure" ... for a little topic
drift ... proposal from 1981 for a (small i) infrastructure:
http://www.garlic.com/~lynn/2006w.html#12 more secure communcation over the network

Part of the "audits" was figuring out just what it was they were doing as part of the process 
that they were calling "certification" ... as the business process supporting the technology
that produced the actual digital certificates (i.e. a credential/certificate that is a
stand-in representation of that certification they were performing). this gave rise to
a lot of comments/observations about if the domain name infrastructure actually provided
a direct, higher integrity operation ... it would obsolete any requirement for having
external certification operations (and therefor also obsolete the certificates as 
representations of those certification operations) ... lots of past posts mentioning
such catch-22 scenario
http://www.garlic.com/~lynn/subpubkey.html#catch22

For other topic drift ... a recent post/comment about the early x.500 stuff
http://www.garlic.com/~lynn/2007b.html#31 IBMLink 2000 Finding ESO levels

and recent posts with comments about early x.509 identity certificate stuff
http://www.garlic.com/~lynn/2007.html#15 SSL info
http://www.garlic.com/~lynn/2007.html#17 SSL info
http://www.garlic.com/~lynn/2007.html#34 SSL info
http://www.garlic.com/~lynn/2007.html#42 The logic of privacy
http://www.garlic.com/~lynn/2007b.html#61 Securing financial transactions a high priority for 2007
http://www.garlic.com/~lynn/2007d.html#10 The logic of privacy

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