[cryptography] wont CA hackers CA pin also? and other musings (Re: PKI "fixes" that don't fix PKI (part III))

Adam Back adam at cypherspace.org
Sat Sep 10 06:16:35 EDT 2011

So I hear CA pinning mentioned a bit as a probable way forward, but I didnt
see anyone define it on this list, so from web search what I can find is
that certificate holder can define the CAs that are allowed to issue certs
for its domain.  Maybe a bit analogous to SPF for email.  (Anyone have a
detailed reference, has it been implemented as a proof of concept or is it a
concept only at this stage?)

OK so if Alice already visited a site example.com before a diginotar like
incident, and they had already pinned their site to thawte or verisign only
being valid issuers fair enough - when the diginotar version of example.com
comes out Alice's browser wont be fooled.

But what about Bob - he first goes to example.com, there is some form of
tcp hijack/DNS poison/ARP poison etc depending on the context and he first
sees example.com issued by diginotar.  Worse the diginotar hacker can pin
the example.com to diginotar, which might take some shaking.

I am lacking the information about the mechanism for pinning, but the above
are my thoughts.

I liked Moxie Marlinspike's recent proposal to rely p2p on other users for
second and third opinions about what is the valid cert for a given site. 
Its a sort of distributed version of SSH self-signed but first come first
served certificate cacheing in the client with warnings if a site changes.

I had proposed something similar about a decade ago internally at Zero
Knowledge Systems for the freedom network because it seemed to me it was
unwise for everyone to trust a central ZKS operated CA (which we had), and
relying on external CAs was bad.  (Freedom network was composed of nodes
operated by multiple independent operators, with some financial profit share
incentivization from ZKS based on bandwidth used as the model).

Also what about DNS security as thats finally winding up is there an obvious
way to use its model, or is that basically equally doomed relying on the
same underlying cert model?

And just while I am here there was a paper that proposed a firefox plugin
that would cache certs and warn if one changed unexpectedly.  Savy users
would then notice the warning before clicking through, and post the evidence
on relevant security lists.  However the plugin seems to be vaporware and no
one ever implemented or at least released such a thing which seems rather
odd in the last years SSL/PKI environment.  We could really use such a thing
around now, I'd install it for sure.

And less related but I am at it I am also astounded that seemingly many
banks STILL year+ later from my straw poll of about 20 of their sign in
sites are still running with SSL server version/config that is vulnerable to
SSL-splicing attack.  Its completely undetectable to the client as he never
even sees the first segment fo the hacker to site request before the
renegotiation.  I've been checking them every few months, and if I recall
still about 1/2 of them are vulnerable.  That doesnt seem hypothetical to me
- you'd think the mobsters bankrolling for pay hacking, malware etc would be
seizing that one before the window closed, and the banks would be keen to
close the window but apparently they barely care!


On Sat, Sep 10, 2011 at 08:46:24AM +1000, Ian G wrote:
>On 09/09/2011, at 9:11, Lucky Green <shamrock at cypherpunks.to> wrote:
>> o What do I mean by the "SSL system"?
>I've taken to using TLS for the protocol, SSL in the wider context including PKI/certs, and "secure browsing" for the headline or flagship application.
>(imho, we can safely ignore any criticism on semantics, the critic is more interested in derailing opposition than thinking about fixing the system.)
>> o Increase the granularity of trust of CAs in the root store
>> We have this already in the form of regular vs. EV certificates. ...
>Trust grades can be compared to AAA+ bond ratings. They are useful until they are not, and then the house of straw is blown away. Typically, "compliance" investors follow them, and in good times they may be better than nothing.
>Smarter investors look to brand. E.g., who here cannot order this list:
>     Bundesbank, Buffet, IMF, Soros, UST.
>> Moreover, assigning grades of trust breaks a design assumption of the
>> SSL system that a CA is either trusted or not.
>Does anyone believe this still design assumption still stands? If so, what does trust mean, and how does it effect the user? What does the user get if it isn't? DigiNotar's trust means what?
>Users don't trust CAs, they don't have a choice. Relying parties are instructed in RPAs not to. Meta-CAs do not, they verify instead.
>It's probably safe to say that certificates are a compliance thing not a choice (trust) thing.
>> This likely will lead to
>> unintended consequences.
>It has :)
>> This is not to say that browsers should not consider risk analysis logic
>> improvements, such as if a cert for a site has been seen before, if the
>> site suddenly switched CA providers ...
>My guess is that what is now called CA Pinning is likely to be direction forward.
>> o Do away with trusted CAs and switch to self-signed certs
>> This proposal largely fails to meet the most basic SSL design
>> requirement to allow Joe Browser user to connect to a site with which
>> Joe has no prior relationship and feel reasonably confident that he is
>> talking to that site without MITM.
>It's curious to ponder where that design requirement came from. Historically, we were not bombarded with confirmatory evidence. Quite the contrary, in that the threats seem to be: server hacking, app-level MITMs, and MITBs.
>Indeed, is there a need to keep the old assumptions so concrete, when the threat model is elsewhere? Are there better results available?
>> There is a reason why many SSL
>> servers pay for a certificate.
>> That said, one could envision an entirely different system in which each
>> SSL certificate seen by a browser is sent up to the browser vendor
>> checking for consistency.
>Or, anyone.
>> The first few visitors to a website would be
>> exposed to a higher risk, but the many subsequent visitors would be
>> quite safe. Overall, such a system would likely be safe enough to meet
>> the design goal for Internet users to be able to send their credit card
>> information over the network with fraud rates due to interception being
>> on par or lower than card present transactions.
>Sorry, that doesn't work. Afaik, there is practically zero evidence of Internet interception of credit cards.  Compared to other forms, it would be so low, they dont even have the answers.
>> Yet this is not fixing
>> PKI. This is throwing PKI overboard and designing an entirely different
>> system from the ground up.
>I'd not be so sure, but maybe it's another semantics skirmish? We still have certs in place, we just check them out in different ways.
>cryptography mailing list
>cryptography at randombit.net

More information about the cryptography mailing list