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.

all of them may have been less than expected ... the comoningly 
recognized SSL certificate issuers (that have their public key preloaded 
into common browsers) sell their certificates and have processes that 
look at whether you have a validly registered corporation. For most 
practical purposes this has been for e-commerce sites and the objective 
for the majority is protecting credit card numbers.

however, the reported exploits .... and what seem to represent a 
significantly larger ROI (fraud for effort invested) is to harvest the 
merchant transaction file (containing all the accumulated transaction 
information that would have taken months of listening to gather) ... aka 
it is much easier to let the merchant gather and organize all the 
information on behalf of the crook. slightly related posting ...
http://www.garlic.com/~lynn/2001h.html#61 Security proportional to risk

the original ssl e-commerce work
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

had the user typing in the merchant webserver URL as a HTTPS session 
from the start and then it would check the domain name in the returned 
certificate (after all the digital signature gorp) with the domain name 
typed in. this is rarely if ever happening ... the common justification 
is running SSL during the shopping experience cuts the thruput by 80-90 
percent. as a result, SSL is typically saved for the "check-out" button.

so lets say you have been redirected to a fraudulent site and don't know 
it because the SSL domain name stuff hasn't been done yet. then comes 
time to do the check-out button. if it is a fraudulent site ... and 
since the crooks would then be supplying the URL with the check-out 
button ... the crooks are likely to have obtained a valid SSL 
certificate for some domain and that domain will match whatever the 
check-out button supplies.

random past ssl certificate posts
http://www.garlic.com/~lynn/subpubkey.html#sslcert

crooks are capable of setting up valid dummy front companies ... it 
isn't a very large effort.

most of what the CA TTPs do when they are verifying stuff ... is that 
the person applying for a certificate is in some way associated with a 
valid company that they claim to be associated with.

then the CA TTPs check with the domain name infrastructure to see if the 
corporation that they just checked on ... is the same one listed as the 
owner of the subject domain name (modulo the issue that there can be a 
common company name, a DBA company name, and a legal company
name ... all for the same corporation and all completely different names 
... you sometimes will see this in credit card statements where the 
store-front name and the company name on the statement are different).

As observed, one of the things SSL was for a countermeasure for 
integrity problems in the domain name infrastructure involving domain 
name hijacking (where the mapping of the domain name to an ip-address 
was altered to be a different ip-address, potentially fraudulent website).

However, there have been more sophisticated domain name hijackings that 
have occured where both the domain name infrastructure records had both 
the name of the corporate owner as well as the ip-address altered. In 
this more sophisticated form, a crook with a perfectly valid dummy front 
corporation ... that has done the more sophisticated form of domain name 
hijacking ... could apply for a perfectly valid SSL domain name 
certificate ... and pass all the tests.

in any case, that was my perception of what we were doing with SSL ten 
years ago.

PKI is slightly different. One of the reasons that we coined the term 
"certificate manufactoring" was to try and differentiate what was 
comingly being referred to as PKI ... and what SSL domain name 
certificate stuff was actually doing.

Note that there has been a proposal to somewhat address the more complex 
form of domain name hijacking (both the company name take-over as well 
as the ip-address take-over) ... which involves having domain name 
owners register a public key when they get a domain name. Then all 
future correspondance with the domain name infrastructure is digitally 
signed ... which then can be veriefied with the onfile public key. as a 
side note ... this is a non-PKI, certificateless implementation of 
public key. In any case, with authenticated correspondance ... there 
supposedly is less chance of domain name hijacking occuring.
http://www.garlic.com/~lynn/subpubkey.html#certless

This has somewhat been supported by the CA SSL domain name certification 
industry. The have a complex, expensive, and error-prone identification 
process to try to establish a valid corporation. And even then they are 
at the mercy of whether the company name listed in the domain name 
infrastructure is actually the correct company (i.e. their whole 
infrastructure otherwise is useless).

The other advantage ... is that the Certification Authority can require 
that SSL domain name certificate applications also be digitally signed. 
Then the CA can turn an expensive, time-consuming, and error-prone 
identification process into a much simpler, cheaper, and reliable 
authentication process ... by retrieving the onfile public key from the 
domain name infrastructure for verifying the applicants digital 
signature (again note that this is a non-PKI, certificateless 
implementation that they would use as the trust basis for the whole SSL 
domain name certificate operation).

There is some slight catch22 to this for the SSL domain name certificate 
business. First off, improving the integrity of the domain name 
infrastructure for the Certification Authority industry ... would also 
improve the integrity for everybody ... somewhat mitigating one of the 
original supposed requirements for having SSL domain name certificates 
in the first place. The other is that if the SSL certification industry 
found it viable to base their trust infrastructure on the 
certificateless, onfile public keys at the domain name infrastructure... 
it might be possible that the rest of the world might find them 
acceptable also. One could imagine a slightly modified SSL process where 
the public key didn't come from a certificate ... but was an onfile 
certificateless public key retrieved directly from the domain name 
infrastructure (in much the same way the CA industry has proposed doing).

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