What happened with the session fixation bug?

[Anne & Lynn Wheeler]

James A. Donald wrote:
> PKI was designed to defeat man in the middle attacks
> based on network sniffing, or DNS hijacking, which
> turned out to be less of a threat than expected.

asymmetric cryptography has a pair of keys ... the other of the key-pair 
decodes what has been encoding by one of them. a business process was 
defined using this technology where one of the key-pair is designated as 
public ... and freely distributed and the other of the key-pair is 
designated as confidential and never divulaged. an authentication 
business process was defined using public/private business process 
called digital signature .... where a hash of a message is taken and 
encoded with the private key. the recipient can recompute the hash of 
the received message and compare it to the digital signature that has 
been decoded with the corresponding public key. this catches whether the 
message has been altered and from 3-factor authentication
http://www.garlic.com/~lynn/subpubkey.html#3factor

* something you have
* something you know
* something you are

implies "something you have" authentication ... i.e. the originator has 
access and use of the corresponding private key.

PKI was somewhat targeted at the offline email model of the early 80s; 
the relying party dials up their (electronic) post office, exchanges 
email, and hangs up. They then may be dealing with first time 
correspondance from a total stranger with no (offline or online) 
recourse for determining information about the sender. Relying parties 
could be seeded with trusted public key repository of trusted third 
party certification authorities. Stangers could be issued "certificates" 
(digitally signed by one of these certification authorities) containing 
informoation about themselves bound to their public key. Email 
recipients in the offline email days of the early 80s ... could now of 
source of information regarding first time communication from total 
strangers (sort of the "letters of credit" model from the sailing ship 
days).

we were asked to work this small client/server startup in menlo park
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

that wanted to do payments on something they called a commerce server. 
In the year we worked with them ... they moved from menlo park to 
mountain view and changed their name (trivia question ... who previously 
had the rights to their new name? also what large corporate entity was 
providing most of the funding for the commerce sever?). some topic drift 
... recent postings referencing this original e-commerce work as an 
example of service oriented architecture (SOA):
http://www.garlic.com/~lynn/2005i.html#42
http://www.garlic.com/~lynn/2005i.html#43

they had this technology called SSL which was configured at addressing 
two issues: a) is the webserver that the user had indicated to the 
browser ... the actual webserver the browser was talking to and b) 
encryption of the transmitted information.

SSL digital certificates would be issued
http://www.garlic.com/~lynn/subpubkey.html#sslcert

which would contain the domain name of the webserver bound to their 
public key. the browsers would have trusted public key repository seeded 
with the public keys of some number of trusted third party certification 
authorities. the browser SSL process would compare the domain name 
indicated by the user to the domain name in the digital certificate 
(after validating the certificate).

(at least) two (other) kinds of vulnerabilities/exploits have shown up.

1) in the name of convenience, the browsers have significantly 
obfuscated the certificate operation from the end-user. attackers have 
devised ways for the end-users to indicate incorrect webservers ... 
which the browser SSL process (if it is even invoked) will then gladly 
validate as the webserver the user indicated.

2) a perceived issue (with knowing that the webserver that a browser is 
talking to is the webserver the user indicated) were integrity issues in 
the domain name infrastructure. however, as part of doing this 
consulting with this small client/server startup ... we also had to do 
detailed end-to-end business process due dilligence on some number of 
these certification authorities. it turns out that a certification 
authority typically has to check with the authoritative agency for the 
information they are certifying. the authoritative agency for domain 
name ownership is the domain name infrastructure ... the very 
institution that there are integrity questions giving rise to the 
requirement for SSL domain name server certificates.

In the second vulnerability, the certification authority industry is 
somewhat backing a proposal that when somebody registers a domain name 
with the domain name infrastructure ... they also register their public 
key. then in future communication with the domain name infrastructure, 
they digitally sign the communication. the domain name infrastructure 
then can validate the digital signature using the (certificateless) 
public key onfile for that domain. This supposedly improves the 
integrity of the communication between the domain name owner and the 
domain name infrastructure .... mitigating some possible domain name 
hijacking exploits (where some other organization becomes recorded as 
the domain name owner).

It turns out that the certification authority industry also has an 
issue. When somebody makes an application for an SSL domain name 
certificate, they need to supply a bunch of identification information. 
This is so the certification authority can perform the expensive, 
time-consuming and error-prone identification process ... and then do 
the same with the information on file at the domain name infrastructure 
as to the owner of the domain name ... and then see if the two domain 
name owner identifications appear to match. Having an on-file public key 
for the domain name owner ... the certification authority industry can 
also require that an SSL domain name applicant, digitally sign their 
application. Then the certification authority can retrieve the onfile 
(certificateless) public key and change an expensive, error-prone, and 
time-consuming identification process into a simple and more reliable 
authentication process (by retrieving the onfile public key and 
validating the digital signature).

 From an e-commerce perspective ... the SSL process was to protect 
against credit card information havesting for use in fraudulent 
transactions. However, the major vulnerability/exploit before SSL and 
after the introduction of SSL ... wasn't against credit card information 
in flight ... but against huge repositories of credit card information
(information at rest). It was much easier for the crooks to steal the 
information already collected in huge repositories than go to the effort 
of evesdropping the information inflight and creating their own 
repositories (fraud return-on-investment, much bigger benefit in 
stealing large repositories of already collected and organized 
information). related reference regarding security proportional to risk
http://www.garlic.com/~lynn/2001h.html#61

the financial standards working group, x9a10 was given the task of 
preserving the integrity of the financial infrastructure for all retail 
payments (as well as some number of other requirements) for x9.59 standard
http://www.garlic.com/~lynn/index.html#x959

so some earlier work on PKI-oriented protection for retail payments 
involved digitally signed transaction oriented protocol with attached 
digital certificates.

in the early 90s, there was some work on x.509 identity certificates. 
however, there was some issues with ceritifcation authorities predicting 
exactly what information might be needed by unknown future relying 
parties ... and so there was some direction to grossly overload these 
certificates with excessive amounts of personal information. In the 
mid-90s, some number of institutions were starting to realize that such 
overloaded repositories of excessive personal information representing 
significant liability and privacy issues. As a result you saw some 
retrenchment to relying-party-only certificates
http://www.garlic.com/~lynn/subpubkey.html#rpo

these were digital certificates that basically contained some kind of 
database record locator (like an account number) bound to a public key 
(the database record contained all the real information). however, it 
became trivial to demonstrate that such relying-party-only certificates 
were redundant and superfluous. This was, in part because they violated 
the original design point for certificates ... the relying party not 
having any other recourse to the necessary information. By definition if 
all the information was in a relying-party's database ... then by 
definition the certificate was redundant and superfluous.

in this later part of the mid-90s payment scene, these 
relying-party-only certificates were on the order of 4k-12k bytes. It 
turns out that a typical retail payment message is 60-80 bytes. Not only 
were the stale, static, relying-party-only certificates redundant and 
superfluous ... but they also would contribute to enormous payload bloat 
(on the order of one hundred times).

the other problem with the relying-party-only, redundant and 
superfluous, stale, staic, enormous payload-bloat digital certificate 
based infrastructure ... were that they effectively were targeted only 
at protecting credit card information "in-flight" ... something that SSL 
was already doing. They were providing no countermeasure for the major 
vulnerability to the data "at rest". the information at rest was still 
vulnerable (and was the major exploit already with or w/o SSL)

So one of the things in the x9a10 financial standards working group was 
to do a treat and vulnerability analysis ... and design something that 
could preserve the integrity of the financial infrastructure for all 
retail payments (credit, debit, stored-value, online, offline, pos, etc).

X9A10 defined a light-weight digitally signed transaction that wouldn't 
contribute to the enormous payload bloat of the stale, static, redundant 
and superfluous certificate-based infrastructures.

Another issue was the analysis demonstrated that the major treat and 
vulnerability was to the data at rest. So for X9.59, a business rule was 
defined ... for account numbers used for X9.59 transactions ... only 
correctly verified digitally signed transactions (authenticated) could 
be authorized.

An x9.59 transaction was digitally signed, and the relying party could 
use an on-file public key to validate the digital signature .... showing 
the transaction wasn't modified in transit and providing "something you 
have" authentication as to the originator (they had access and use of 
the corresponding private key). furthermore, evesdropping of the 
transaction in flight ... and/or harvesting the large transaction 
databases (information at rest) wouldn't yield information for the crook 
to perform a fraudulent transaction. the current exploits where 
knowledge from an existing transaction is sufficient to generate 
fraudulent transaction has gone away ... for vulnerabilities involving 
both "data in flight" as well as "data at rest".

The issue wasn't that SSL being designed to protect data-in-flight ... 
the issue was that the major threat/vulnerability has been to 
"data-at-rest" ... so to some extent, SSL (and the various other 
countermeasures to "data-in-flight" vulnerabilities) wasn't responding 
to the major threats. To some extent, e-commerce/internet was opening a 
theoritical, new vulnerabilities ("data-in-flight") compared to the 
non-internet world ... and so SSL was somewhat theoritically 
demonstrating that e-commerce/internet use wouldn't make the situation 
any worse.

Recent studies have indicated that at least 77% of the id theft exploits 
have involved insiders (supporting the long standing premise that the 
majority of fraud is by insiders). The introduction of e-commerce and 
internet have introduced new avenues for attacking data-at-rest by 
outsiders. As a result, e-commerce/internet potential threats to 
data-at-rest has contributed to obfuscating responsible insiders in 
cases of exploits against data-at-rest.


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