Re: man in the middle, SSL ... addenda 2
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
Re: man in the middle, SSL ... addenda
re: http://www.garlic.com/~lynn/aadsm26.htm#26 man in the middle, SSL basically digital certificates were designed as the electronic equivalent for offline distribution of information ... paradigm left over from the letters of credit and letters of introduction out of the sailing ship days (and earlier). as things moved into the online age ... certification authorities and digital certificates moved into generic low-value/no-value market segment. this is the difference between a generic employee badge for door entry ... that is identical for all employees ... vis-a-vis doing stuff specific and tailored to each employee. this is somewhat the x.509 identity certificate example mentioned in the original post ... from the early 90s ... overloaded with personal information and paradigm that promoted repeatedly spaying the identity certificates all over the world. by the mid-90s, it was starting to dawn that such a paradigm wasn't such a good idea ... and there was retrenchment to relying-party-only certificates http://www.garlic.com/~lynn/subpubkey.html#rpo which basically only contained public key and some sort of record location (which contains the real information). however, in the payment sector ... even these truncated relying-party-only certificates still represented enormous payload and processing bloat http://www.garlic.com/~lynn/subpubkey.html#bloat especially when it was trivial to demonstrate that you could have the public key along with all the other necessary information in the designated record ... and that the digital certificate was redundant and superfluous. This is also somewhat the scenario raised in the domain name infrastructure for on-file public keys creating a significant catch-22 for the ssl domain name certification authority industry http://www.garlic.com/~lynn/subpubkey.html#catch22 ... just upgrade the existing domain name infrastructure with on-file public keys (a requirement also suggested by the ssl domain name certification authority industry) ... but that can quickly result in a certificate-free, public key infrastructure http://www.garlic.com/~lynn/subpubkey.html#certless also the reference from 1981 http://www.garlic.com/~lynn/2006w.html#12 more secure communication over the network i.e. for the most part now ... SSL is just be using to prove that you have some valid domain name ... and the domain name you claim is the domain name you have ... this is somewhat equivalent to the low-value door badge readers to simply check are you some valid employee ... w/o regard to any higher value scenario requiring specific detail about which valid employee. so one of the points i repeated raise is that while digital certificates (as representation of some certification) is part of an offline paradigm construct ... and in the migration of the world to online environment ... digital certificates have attempted to find place in the no-value/low-value market niches ... that as soon as there is some online component (like record locater) ... it then becomes trivial to show that such digital certificates become redundant and superfluous. so SSL domain name infrastructure was originally primarily to address what came to be called electronic commerce (and still may be the primary use) for: 1) is the browser actually talking to the webserver that the person thinks it is talking to and 2) hide (encrypt) the account number during transmission over the internet. there have been some number of technical implementation vulnerabilities with respect to SSL and things like MITM-attacks ... but the big business process issue was that the deployment fairly early changed from is the browser actually talking to the webserver the person thinks it is talking to ... to the browser is talking to the webserver that the webserver claims to be (since the same webserver was supplying both the URL and the digital certificate confirming the webserver supplied URL). The second feature of ssl (encrypting to hide transmitted account numbers) was somewhat to put transactions flying over the anarchy of the world-wide Internet ... on level play field with the transactions that flew over dedicated telephone wires. However, the major vulnerability during that period ... and continuing today ... wasn't evesdropping the transaction during public transmission ... but vulnerabilities at the end-points which SSL does nothing to address. The end-point webservers somewhat increased vulnerabilities (compared to non-internet implementations) since a lot of the transaction logs became exposed to attacks from the internet. This matter is slightly debatable since the long term studies ... continuing up thru at least recently is that seventy percent of the resulting fraudulent transactions involve some sort of insider. So 1) the resulting major deployments of SSL negating much of the original countermeasure against MITM-attacks (related to integrity issues in
