man in the middle, SSL ... addenda 2

[Anne & Lynn Wheeler]

so the assertion in the previous post
http://www.garlic.com/~lynn/aadsm26.htm#30 man in the middle, SSL

was that sitekey as being introduced because of shortcomings in SSL countermeasures to
man-in-the-middle attacks .... however sitekey only deals with simple impersonation
and is easily defeated with a man-in-the-middle attack

in earlier post
http://www.garlic.com/~lynn/aadsm26.htm#27 man in the middle, SSL

there was reference to SSL attempting to address man-in-the-middle attacks and 
"are you really talking to the server that you think you are talking to". 
however, SSL might be better characterized as verifying that the operator of the webserver is the owner  of the corresponding domain name ... aka a digital 
certificate & pki operation  demonstrates that the operator of the webserver 
has use of the private key that corresponds to the "public key" in the digital 
certificate ... bound to the domain name. The browser than validates that the 
domain name in the URL is the same as  the domain name in the (validated) digital certificate.

one of my assertions is that problems cropped up when the public started associating
webservers with buttons that they clicked on ... significantly degrading any 
association in most of the publics' mind between URLs and the webserver. Since
the public weren't effectively associating URLs with webservers ... and the only
function provided by SSL (as countermeasure to man-in-the-middle attacks) was validating 
the correspondence between the URL and the webserver .... a widening security gap
exists between the "buttons" that the public associate with webservers and the URL,
which is the unit of validation by SSL

one conclusion is if countermeasures are introduced that don't actually
address the actual security vulnerabilities ... then they may not be able
to eliminate those security vulnerabilities.

so one countermeasure that has been introduced (to close some part of the security gap) 
is by some of the email clients which look for "buttons" in the content ... and if the 
label of the button appears to be a url/http ... it checks if the actual url/http is the 
same as the claimed url/http. if they don't match ... the email client will flag the 
email as potential problem. The simple countermeasure by attackers ... is to not use a 
http/url label for the button (i.e. just label the button something else, say the 
name of some financial institution).

Another kind of approach trying to close the gap between what the people associate with 
webservers and the actual URL used ... is to take a page out of PGP and have a list of 
"trusted" urls (or at least domain names). Browsers display the assigned trust level 
recorded for that domain name used in the URL (and then SSL verifies that the webserver 
contacted is actually the webserver for that URL). This would start to provide a mechanism  for closing the gap between what the public deals with and the part of 
the infrastructure being checked by SSL.

(at least) two problems with this approach:

1) a repository of URL trust levels is almost identical to a trusted public key repository (directly used by PGP). the repository could directly record both the 
URL, the public key  for that URL as well as the associated trust level. 
this would be another demonstration  of digital certificates being redundant 
and superfluous in an online world and would provide  the basis for a more trusted
environment than the current SSL operation .... misc. past posts mentioning
certificateless public key operation
http://www.garlic.com/~lynn/subpubkey.html#certless

2) so the new (old) attack is social engineering attempting to get people to click on 
various  buttons that change the trust level in their local trust repository. 
however, that also  exists today ... social engineering to get people to load 
certification authority digital certificates into their local (certificate 
authority public key) repository.

so number #1 doesn't eliminate all possible attacks ... however, it actually 
addresses one of the identified security vulnerabilities/attacks ... as opposed 
to supplying "fixes" for things other than what is actually broken.  

lots of past posts mentioning ssl domain name certificates .... including posts in
long thread about the certificates providing more of a feeling of "comfort", as opposed 
to actually security, integrity, trust, etc. 
http://www.garlic.com/~lynn/subpubkey.html#sslcert

note that #1, in attempt to close the gap between what the public associates with 
websites ... and what is SSL is validated for a website (i.e. some chance that the 
operator of a webserver reached by the domain name in the URL is the same as the owner 
of that domain name) ... it can actually close some of the gaps ... but in doing so, it 
increases the need for endpoints with some level of integrity ... and/or it leaves the 
end-points as possibly the weaskest link in the trust chain. also as outlined in #1, the 
possibly integrity improvement that comes from a local trust repository ... can also 
result in making digital certificates even more redundant and superfluous (doesn't 
reduce the need for public key operations ... just further reduces the need for digital 
certificates as a trust mechanism) ... this is similar to other examples where improving 
levels of trusts, also reduce the need for digital certificates as a trust mechanism ... 
misc. related posts on the subject
http://www.garlic.com/~lynn/subpubkey.html#catch22
 

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