Re: fyi: Strict Transport Security specification

On Sat, Sep 19, 2009 at 7:59 PM, =JeffH <Jeff.Hodges@kingsmountain.com> wrote:
> Hi,
>
> We wish to bring the following draft specification to your attention..
>
>     Strict Transport Security (STS)
> <http://lists.w3.org/Archives/Public/www-archive/2009Sep/att-0051/draft-hodges-
> strict-transport-sec-05.plain.html>

(replying to WHATWG post since I wasn't subscribed here, sorry if this
breaks threading)

This sounds great.  It will hopefully close a significant hole in
HTTPS.  I have some comments, but please bear in mind that I'm a web
developer, and  only having a basic working user-level knowledge of
how SSL works (I haven't read the RFCs, etc.).

Is it true that UAs MUST NOT note a server as a Known STS Server if
the Strict-Transport-Security header was received over an unsecured
request, or there were underlying secure transport errors?  I don't
see that stated explicitly, but it seems like it should be a
requirement so that MITMs can't trick browsers into noting a site as
an STS Server when it's only available unsecured.

"Underlying secure transport error" could use definition -- I'd
imagine it would include, among other things, an unrecognized root
certificate, an expired or revoked certificate, etc., but perhaps it
could be made clearer.  Or do other relevant specs already define this
term?

If a secure transport error occurs when connecting to a Known STS
Server, there needs to be *some* way for *some* users to ignore it --
it might be necessary for the site's administrator to debug the
problem, at least.  I don't think it's realistic to expect absolutely
*no* way to disable STS.  But perhaps it would be sufficient to just
force users to use wget or something in such a case; that will always
be an option.

A general concern with the prohibition on users overriding errors:
this kind of feature (which is designed to break sites in some cases)
can suffer from a "race to the bottom" situation where sites deploy it
before it's ready, don't test adequately, and then break when browsers
implement it.  Then the browsers are forced not to implement it so
they don't break the sites.  I don't know what the best way to handle
this possibility is, but maybe it's something to keep in mind.

With respect to self-signed certs: why don't you allow the header to
optionally specify the signature of a certificate that be present
somewhere in the certification chain?  I might be using incorrect
terminology here -- I mean that I could say "only accept the public
key with SHA1 hash xxx or anything signed by it directly or
indirectly".  That would allow self-signed sites to work somewhat more
securely than handing out the key manually to users -- they'd follow
an SSH-style model of "warning on the first view, die horribly if the
certificate changes unexpectedly".  It would also mean that other
sites could greatly narrow attack surface, since an attacker would
have to forge a particular certificate instead of being able to
compromise any trusted CA.  At its tightest, this would allow the
connection to fail unrecoverably if the private key changes at all,
much like how the OpenSSH client works.

Regarding the Issue in section 10: it seems to me that the long-term
solution to this would be something like DNSSEC, right?  If an STS
requirement could be put in a secure DNS record, possibly along with
the public key itself, then you would have no bootstrap problem at
all.  I don't see any other way to avoid the problem even in principle
as long as a MITM could forge DNS.

Regarding "STS could be used to mount certain forms of DoS attacks,
where attackers set fake STS headers on legitimate sites available
only insecurely (e.g. social network service sites, wikis, etc.)": how
is this possible if the STS header is only respected from legitimate
secure connections?  The attacker would have to forge a legitimate
certificate for the domain in question for this to work, no?

In Design Decision Notes, "errornous" should be "erroneous".

Overall, though, if this gets implemented and deployed by major
commerce sites, it will make me feel a lot safer using HTTPS over an
untrusted connection.

Received on Monday, 21 September 2009 15:31:44 UTC