Re: [TLS] [certid] fyi: paper on compelled, certificate creation attack and applicable appliance

[Marsh Ray <[e-mail]>]

On 3/24/2010 11:14 PM, ArkanoiD wrote:
> Well, that's quite obvious that PKI in the "big internet" as we know
> it is just a card house

True, but there are lots of card houses in compsec in the sense that
flipping just one bit the right way results in a complete compromise.

Predicting whether or not that single bit logic will prove to be robust
or fragile in actual deployed systems is an art form that designers are
still learning. This is as much a social-political-economic-human issue
as a technical one.

I don't see what the big worry is about a CA being "compromised" by some
government. It looks to me like many of the trusted roots installed by
typical software are pseudo-governmental entities (e.g., post offices)
in the first place.

http://support.apple.com/kb/HT3580
> Below is a list of trusted root certificates which are pre-installed
> with the iPhone 3.0 software.
> Subject Name
>      Country Name                 : US
>      Organization Name            : U.S. Government

There's nothing subversive about that, it's totally out in the open.

> if *ANY* CA we trust get compromised or mailicious, it is all
> flawed.

>From the perspective of the https server, that understates it a bit.

Because the https server cannot independently prove the absence of a
mitm, he must rely on the client to do a good job of this.

Thus, the web server ends up transitively trusting _every_ trusted root
cert in _every_ client which connects.

Remember the README for PGP?

  Trusting a key is not the same as trusting the key's owner. Trust is
  not necessarily transferable; I have a friend who I trust not to lie.
  He's a gullible person who trusts the President not to lie. That
  doesn't mean I trust the President not to lie. This is just common
  sense. If I trust Alice's signature on a key, and Alice trusts
  Charlie's signature on a key, that does not imply that I have to
  trust Charlie's signature on a key.
     -- Philip Zimmerman

Transitive trust in this case has brought about the near-complete failure
of the original mission of PKI in ssl (allowing you to shop online).

The only reason that the world isn't up-in-arms about it is that 59% of
PCs are pwned by malware already, making the slightly more complicated
mitm attack unnecessary.

However, there are important uses of SSL/TLS other than end user web
browsers. These are probably better off with just the minimal number of
trusted roots on the clients. But if you're going to the trouble of
reconfiguring your clients anyway, why not just set up your own private CA?

IMHO, the $B+ certificate industry needs to work harder at improving
their actual effective security value than it currently does if they
want the world to continue fund their existence.

> There is nothing we can do besides examining chain of trust manually
> and watching for certificate changes.

We could implement our protocols such that the remote peer is required
to satisfy multiple chains of trust.

When a chain is only as strong as its weakest link, it's best to have
several of them (in a redundant configuration).

> The TOFU technology described
> there is quite obvious, i always wondered why ssh has it and browsers
> do not.

In theory, SSH's approach is inferior to SSL's PKI. In practice it's not
inferior only to the extent that the user is good at scrutinizing the
new keys he gets presented.

If you want that behavior in a web browser, just delete all your trusted
root certs and add a persistent explicit trust whenever you see a cert
the first time. (I have tried this in Firefox)

- Marsh