towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)
Jeff.Hodges at KingsMountain.com
Tue Aug 24 19:00:24 EDT 2010
Hi Jerry, thanks for your review and thoughts on the HSTS spec.
first, overall context-setting -- HSTS is spec'd and implemented as it
(presently) is in order to get near-term traction -- i.e. browser
implementation. (it is likely to be in Firefox 4, and is already in Chrome, and
was first implemented in the NoScript extension). If we can get the other major
browsers to also support it, we believe that it will be a Good Thing for
It is possible that the present HSTS site policy signaling will be supplanted
down the road in a further refinement cycle leveraging other emerging
technologies, e.g. DNSSEC, as Jakob indicated.
Also, note that HSTS is presently specific to HTTP. One could imagine
expressing a more generic "STS" policy for an entire site -- i.e. "connect to
me only using 'secure means' no matter which protocol you're using, and here's
metadata explaining what that means on a per-supported protocol/service basis."
But that is for a future design cycle.
> Consider the scenarios:
> 1. "First connection" to an HSTS server. Here "first connection"
> means that client is approaching this server with no pre-existing
> security context - either it's never connected before, or it's stored
> no information that will influence security decisions on its part,
> from the previous connections, if any. ... <snip>
> Because HSTS forbids self-signed certs, no legitimate server will
> present a combination of a self-signed cert and an HSTS header. No
> intelligent MITM will do so either. It will either suppress the HSTS
> header - or, more likely, use a perfectly legitimate cert signed by a
> perfectly legitimate CA that the client will accept. ...
Yes, the spec notes this as the "Bootstrap MITM Vulnerability" in security
considerations. UA Implementation advice is notes that a means to address this
is through some sort of pre-loaded list, a la the cert root store. Chrome has
implemented such, for example.
This is where DNSSEC-assured DNS-based functionality may play a key role.
> 2. A "second connection": [ client MUST connect via TLS with no
> cert errors/warnings, otherwise fail connection with no user recourse ]
> So what does HSTS actually add? I'd say three things:
> - Standardization of, and requirement for, HTTP to HTTPS redirects;
> - Standardization of, and requirement for, clients to retain security
> information about previous connections, per server/URI/domain;
> - The notion of a "time to live" for that security information, set
> by the server.
We feel it additionally adds:
* Standardization of, and facilitation of, expression of
(a particular) site security policy -- at the direction
of the site administrators
* protection of users from "click-through insecurity" (i.e. active MITM
> But having gone this far ... the proposal then goes off into the weeds
> by regulating self-signed certs for no really good reason,
We feel that absent additional assurance, e.g. via DNSSEC, it is better overall
given our target audience (sites wishing to enable users to safely conduct
ecommerce with them) to disallow self-signed certs.
If some site wishes both to employ HSTS (they don't have to, its an opt-in sort
of thing), and have a very cheap cert, they can get a domain-validated (DV)
cert for less than $10/yr from any number of CAs that are also (for better or
worse) embedded in the major browsers' trust anchor cert store. That's the
trade-off we've explicitly made (for now).
> But why not let the server say "On subsequent connections, only accept
> a cert with this fingerprint" (SSH connection) or "only accept a cert
> signed by this CA" (sites don't change CA's often, and the time limit
> means they can do so as long as they plan ahead) or "only accept certs
> signed by CA's based in the following country" (like Soghoian and
> Stamm's work).
Note that this is a draft spec. There's various bells'n'whistles we've thought
about adding -- eg declaration to "lock" the policy to a cert from a given CA,
declaration to accept EV cert(s) only -- which we're going to discuss in the
working group as the spec matures. However, there /is/ the concern of getting
the spec finalized and working towards uniform implementation across browsers.
> Why a "require this CA" together with a self-signed
> cert shouldn't be allowed is beyond me - I can't see any situation in
> which it's weaker than the current HSTS proposal.
because absent some form of 3d party assurance, the HSTS policy is simply
declaring the site itself as the CA, the site has signed the cert, and the
entity wielding such a cert could be simply be a MITM, e.g the pwn'd router at
your coffeeshop or hotel. And then the user clicks thru the cert warnings, and
is pwn'd. unless there's something I'm missing.
As you intimated, this is AFAWK possible today via nefarious CAs that are
browser-recognized trust anchors. That's why we've thought about the additional
policy declarations noted above.
> By being able to say: For any connections to this server/URI/set of
> domains for the next n seconds, accept only HTTPS connections with
> certs signed by the following CA's (*including* self-signed certs!) -
> now, that would be useful.
We think the self-signed cert thing isn't really useful until the scenario is
something like, e.g...
For any connections to this server/URI/set of
domains for the next n seconds, make only error-free HTTPS connections with
certs signed by the following CA's, or EV certs, or self-signed certs that map
to DNSSEC-secured domain(s).
Internet Standards and Governance Team
PayPal Information Risk Management
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
More information about the cryptography