clarify and add examples/justification wrt connection termination due to tls warnings/errors

[jeff.hodges@…]

​http://www.ietf.org/mail-archive/web/websec/current/msg00045.html

Subject: Re: [websec] Some questions about HSTS
From: "Steingruebl, Andy" <asteingruebl@…>
Date: Mon, 22 Nov 2010 09:57:21 -0700 (08:57 PST)
To: Yoav Nir <ynir@…>, "'websec@…'" <websec@…>

In sections 2.4.1.1, point #9 says:

9. UAs need to prevent users from clicking-through security

warnings. Halting connection attempts in the face of secure
transport exceptions is acceptable.

What exactly are these secure transport exceptions? Expired certificates?
Mismatched FQDN? Revoked certificates? Unreachable CRL? Untrusted CA?
Self-signed?

Anything that would currently pop a browser warning for a user currently. Browsers differ slightly in how they handle OCSP, etc. In any case where a browser has already made the policy decision it should show a certificate "error", it must now abort.

Also, I don't understand why this change is needed. HSTS is supposed to stop
a very specific attack vector - a user duped into using insecure HTTP over the
(presumably secure) HTTPS.

As it is, HSTS cannot be used by servers with self-signed or corporate
certificates, for fear that user agents may not allow the user to browse.

That is correct. I personally believe, as do several of the contributors on this (and I hope I'm not speaking too much out of turn) that self-signed certificate warnings are just a punt, and an easy way for a user to make a bad security decision. If you want to support HTTPS, do it with a cert that your browser already trusts. Anything else is just a recipe for a MiTM attack. If a host advertises HSTS, it is specifically opting into this scheme, whereby all certificate warnings will cause abort, with no chance to "fool" the user into making the wrong decision.

[jeff.hodges@…]

see also....

​http://www.ietf.org/mail-archive/web/websec/current/msg00063.html

Subject: Re: [websec] Some questions about HSTS
From: Adam Barth <ietf@…>
Date: Mon, 22 Nov 2010 22:06:24 -0800
To: Yoav Nir <ynir@…>
Cc: "websec@…" <websec@…>

(text/plain)

On Mon, Nov 22, 2010 at 9:46 PM, Yoav Nir <ynir@…> wrote:

Taking both your answers together, suppose I have a web server with a corporate or self-signed certificate, which is OK, as I expect all my users to approve an exception (as it's called in Firefox). I turn on HSTS because I'm worried about them being duped by a fake server using HTTP. To me, HSTS reduces the attack surface by making them dupable only on the first ever connect. Then, as it turns out, a certain browser breaks the connection when connecting from outside the organization, because the CDP is not available. Fine, I turn off HSTS, but because the cache is untouched, the users will get intermittent connectivity problems for three more months.

I don't recommend using HSTS with self-signed certificates. In this
scenario, I'd recommend the corporation install a root certificate in
all machines owned by the corporation and then use that root
certificate to issue whatever other certificates the corporation
needs.

I agree with Marsh, that this is too much of scope creep. It makes sense for a big website like paypal, amazon or gmail to want strict enforcement on the client. But smaller websites don't have the IT department of such companies, and often let their certificates expire. In their case, having HSTS on would cause a lot of trouble on certificate expiry day.

Folks are already in for a headache if they let their certificates
expire. They'll get big nasty warnings in either case. The
difference is only whether those warnings will let the user ignore
them.

If you don't think your organization is sufficiently competent to
schedule a reminder to update its certificates, then I don't recommend
using HSTS.

The use case that I am interested in is not a big commercial website, but rather an SSL-VPN portal. These have two relevant properties: They come pre-packaged, and they're SSL-only. It is up to the customer to get a certificate, or generate a self-signed one. I would have liked to have HSTS on by default for such a product, but if that means that customers with self-signed certificates or corporate certificates get long-lasting connectivity problems, I can't justify that.

Indeed. Please don't use HSTS with self-signed certificates. HSTS is
a feature for well-maintained web sites that have a need for strong
security. The reason we designed HSTS was to differentiate between
sites that actually want strong security and sites that are using TLS
but don't have strong security needs. If you don't need strong
security, you don't need HSTS (and the additional careful
administration it requires).

Sure, I can have a configuration flag for whether or not we should have the header, but administrators tend to configure those wrong just as much as users tend to click through dangerous screens.

I don't think user agents should offer such a configuration flag.

What do the current implementations (Chrome, Firefox) do?

They do what the spec says. TLS errors on HSTS hosts are treated as
fatal errors, much like the host's DNS name not resolving. There is
no recourse except to reload the page.

Adam

###

​http://www.ietf.org/mail-archive/web/websec/current/msg00304.html

Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
From: Adam Barth <ietf@…>
Date: Tue, 29 Mar 2011 13:58:08 -0700
To: websec@…

(text/plain)

There's no coupling between HSTS and the particular algorithm a UA
uses to verify certificates. The UA is free to use whatever
verification mechanism it desires. You can remove whatever CAs you
consider sloppy from the list of trusted certificate authorities and
add in whatever other verification mechanism you like.

For example, if/when certificate verification through DNSSEC becomes
widespread, we won't need to change anything about the HSTS spec. Of
course, we'll need to change our implementations, but that's true
regardless of what the HSTS spec says.

Adam