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 [EMAIL PROTECTED]
