On Fri, Jun 29, 2012 at 8:10 AM, Steingruebl, Andy <[email protected]> wrote: >> The point of "this is testing" is the opposite: people who can't talk to >> you because you've configured HSTS in a way inconsistent with your >> actual site posture. >> -Ekr > > Can you give us an example of how/where you think this could occur and how it > is distinct from other ways you could using existing technology kill your > site? > > As an admittedly snarky example you could easily public a bad A record in DNS > and you'd never see any traffic at all, but there isn't a "test new A record > flag" or "test new MX server" flag in the DNS. > > We assume that as part of deploying HSTS people do some basic checks like > make sure their website actually responds over HTTPS and generates webserver > logs, and they know which domain they are publishing HSTS records for. > > Some specifics would help me a lot to understand the concerns.
The primary concern is that HSTS is intended to have a very long lifetime and that is a security tradeoff, not just an operational cost tradeoff like DNS TTL. It's not so much with existing HSTS as with something like draft-evans-palmer-hsts-pinning. Consider the case where I operate a site that load balances between two certs, A and B but I inadvertantly advertise a pin for A only. If I understand S 2.1 correctly, any client who goes to A will get pinned and any client who goes to B will reject the pin (regardless of whether it's served.) If the client comes back and gets B later, they will reject the cert. This is not easy to detect with the kind of testing you describe. -Ekr _______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
