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