I read through the HTTP Strict Transport Security (HSTS) Draft RFC (http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02
) and it's an odd mix. It continues - and expands on - Firefox's war
against self-signed certs - while adding to the Web exactly the same
kind of SSH-style "connection continuity" security for which self-
signed certs are completely appropriate!
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. Today, that describes *all*
standard connections, though many different extensions have been
proposed, and plug-ins implemented, to change this.
The security of such a connection, in the presence of a MITM attack,
depends entirely on the trustworthiness of the certificate chain.
There is, ex hypothesi, nothing else that drives the client's decisions.
HSTS has absolutely nothing to offer here. A MITM won't forward the
HSTS information if it finds it inconvenient to do so. Or it will
fake it.
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. After all, there
are hundreds of CA's out there and getting a signed cert is no big deal.
HSTS *does* provide protection against a *passive* "first connection"
attacker by blocking insecure connection attempts and requiring
HTTPS. (Of course, you can do that in a server today with a redirect
- and in fact that's exactly how HSTS does it.)
2. A "second connection": One where the client has retained
information from a previous connection. HSTS adds this state to the
standards: For an amount of time specified by the server on the
previous connection, a new connection to the server (well, to be more
careful, to the URI or possibly subdomains - the whole question of
whether we are talking about a server or a URI or an address gets very
complex if you try to pin it down exactly) must use HTTPS, and must
get a "clean" connection, with no warnings (e.g., the CRL must be
checkable) and no self-signed certs.
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.
But having gone this far ... the proposal then goes off into the weeds
by regulating self-signed certs for no really good reason, while
ignoring much more valuable things it *could* do. There's nothing we
can do about the MITM vulnerabilities in the first connection scenario
without solving the PKI problem - which ain't gonna happen. (HSTS
discusses the notion of pre-loading HSTS security information for some
sites along with CA lists, but itself notes that this doesn't really
solve any problems so much as rename them. Besides - once you start
on this route, why not just distribute actual site keys?)
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). 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.
Now, it's quite true that HSTS *allows* for extensions - but so does
HTTP, and so browsers. What's hard is to get something very broadly
implemented. Having the "something" be HSTS would be squandering an
opportunity. I certainly wouldn't try to include every, or even many,
possibilities - that's a way of making sure that nothing gets done.
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.
-- Jerry
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
