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

[=JeffH]

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 
Internet users.

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
     attackers)


 > 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).

thanks,

=JeffH
Internet Standards and Governance Team
PayPal Information Risk Management





---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com