man in the middle, SSL ... addenda

[Anne & Lynn Wheeler]

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 the domain name infrastructure) and the 2) encryption only slightly put internet transactions on same playing field vis-a-vis the non-internet transactions ... and did nothing to address the major vulnerabilities (at least with regard to the fraud related to the kind of transactions that might happen over the internet ... whether the actually fraudulent transactions occurred over the internet or not).

So after working on the stuff currently called electronic commerce ... we did some stuff in the x9a10 financial standard working group ... which in the mid-90s had been given the requirement to preserve the integrity of the financial infrastructure for all retail payments (ALL as in ALL ... and not just internet). the result was x9.59 financial standard
http://www.garlic.com/~lynn/x959.html#x959
http://www.garlic.com/~lynn/subpubkey.html#x959

in the security PAIN acronym

P ... privacy (sometimes CAIN and confidentiality)
A ... authentication
I ... integrity
N .... non-repudiation

SSL was being used for privacy/confidentiality attempting to prevent leakage of the account number.
The x9a10 working group observation was that the account number was needed in large number of different business processes ... and couldn't just be simply kept hidden. This somewhat resulted in my periodically repeated comment that the planet could be buried under miles of encryption and still not prevent account number leakage. This is because the account number is required (unencrypted) in a large number of different places.

So effectively ... x9.59 standard could be described as substituting "authentication" and "integrity" for "privacy/confidentiality" in order to preserve the integrity of the financial infrastructure. X9.59 transactions can be exposed all over the place ... during transmission over the internet, security breaches involving transactions logs ... etc ... and the attackers still wouldn't be able to use the information to perform fraudulent transactions. It was no longer necessary to hide (encrypt) the account number and/or the transactions to prevent fraud ... the information could be widely publicly exposed and the crooks wouldn't be able to use the information for fraudulent transactions. 

In that sense ... x9.59 eliminates one of the primary uses of SSL for hiding electronic commerce transactions (hiding transactions) and some suggested improvements in the domain name infrastructure integrity eliminates most of the rest ... i.e. MITM-attacks.

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