towards https everywhere and strict transport security (was: Has there been a change in US banking regulations recently?)

[Jerry Leichter]

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 majordomo at metzdowd.com