Re: [websec] Certificate Pinning via HSTS

[Tom Ritter <[e-mail]>]

I echo Marsh's question.  Does a x509 Key Fingerprint include
basicConstraints?  I couldn't imagine a scenario where an attacker could get
his own cert signed by a leaf cert of a website - but I also couldn't
imagine New York getting hit by an earthquake ;)

Other observations:

I find the Revocation section very confusingly written.

> "In the event of a mismatch, clients must check whatever revocation
mechanism is available and attempt to discover whether the certificate with
the mismatching fingerprint has been revoked."

What is the definition of mismatch?  I interpreted it as no cert in the
chain contains a fingerprint which matches one of the fingerprints in the
pin list (supplied via prior pinned directive, or preloaded list).
Therefore all certificates in the chain supplied by the site are
mismatching.  But seeing if they are revoked is useless, I want to check the
pinned list to see if any in the pin list is revoked, so I can reevaluate
the pinned list and possibly downgrade the site to 'Known HSTS Host'.  But
the pin list only contains fingerprints - how do I check if a cert is
revoked by fingerprint?


The "Interactions With Built-in HSTS Lists" section is does not cover UA
updates.  Should a UA update with new pin information overwrite pin
information previously validly supplied by a site?


Finally, I'm of the opinion that all SSL Certificate information should be
exposed as javascript properties by browser.  That's a bit out of scope, so
I'll dial it back and say while we're working on HSTS, HSTS information
should be exposed as a read-only javascript property.  It doesn't need to be
structured, the entire contents of the header is sufficient, similar to
document.cookie.  This would allow at least two more (optional) defensive
practices:

1) Plugin/Extension/Greasemonkey authors could produce something like
HTTPSEverywhere or NoScript that could preload pins in a method similar to
preloaded pins in a UA.  If a site sent a pin list that didn't match the
preloaded pin list, the extension could show a warning, error, or some
alert.  Although similar to preloaded pins, this would not require a UA to
do work, nor would it require a UA to supply a user interface to bulk-load
pins.

2) Site authors could include checks in javascript to check their pinned
list.  While this *is* an arms race, and any javascript that is already
being middled by an attacker *could* be rewritten - in practice, javascript
can be sufficently obfuscated to raise the barrier to exploitation (see
gmail's javascript for example).

-tom