4 ms·

There are two fixes for this: * Pages can send the Strict-Transport-Security header to tell the client that future visits to them should be HTTPS-only * Pages

by cbr 10y ago

There are two fixes for this: * Pages can send the Strict-Transport-Security header to tell the client that future visits to them should be HTTPS-only * Pages that send that header can also ask to be included in a list that ships with the browser to handle the first-time visitor case: https://hstspreload.appspot.com/ https://hstspreload.appspot.com/

byuu 10y ago
This can also be dangerous. If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all. Not even to display to the user, "sorry, we're having some technical issues, please check back later", with all the login stuff disabled (and the site using secure cookies by default anyway, so they won't leak in HTTP mode.) It is really difficult for the average user to clear HSTS/HPKP data. You can't just clear your history, you have to go to about:permissions or chrome://net-internals#hsts to do that. Maybe that's the experience you want. But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Public key pinning is even more dangerous. Not the least of which because there are no longer two free providers of SSL certificates for your backup cert. This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. The domain could have a new TXT record of "TLS=Always" that you could flip on or off as needed. The TTL on that could be 3600 seconds instead of 4+ days for a bad OCSP response, or the suggested (by SSL Labs) 6+ months for an HSTS response.
- pfg 10y ago
  > But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Are you making the argument that a business would want the ability to turn off HTTPS enforcement temporarily in case something like the GlobalSign thing happens? Because I think that's a terrible idea. They should just switch to a different CA, or get the CA to sign a certificate that's not impacted by that issue (which I believe GlobalSign offered). Even excluding Let's Encrypt, the price tag for that is < $10 and it's done in a matter of minutes (and only getting better with ACME). Since we're talking about businesses here, better yet: Have a backup certificate from a different CA ready. This is really no different than all the other things you'll need to do to run a reliable service (like have more than one web server). It's not like one CA screwing up means your domain is dead until they've resolved the issue. Same thing goes for HPKP, since a backup pin is required. Your argument is also not specific to HSTS/HPKP - you're basically saying that HTTPS in general is dangerous for a business because of this. If your site offers HTTPS without HSTS and without redirecting to HTTPS by default, you'd still have users who bookmark HTTPS links, or search engines indexing those links and all of those would also fail, with no way for you to fix it other than switching CAs. > This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. I don't want to get into yet another DNSSEC discussion (that's what we have @tptacek for, anyway), but I don't see a huge difference here. Switching CAs can be done in less time than the TTL you're suggesting. Practically speaking, if you want to factor in "time to find a new CA" or something like that, I'd argue that most people won't run their own DNSSEC infrastructure and rather use something like Cloudflare, so the same "time to find a new <foo>" principle would apply here if they've messed up in a way that takes a long time to resolve.
- blfr 10y ago
  If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all That's only true for somewhat carelessly configured HPKP. With HSTS you can use any valid certificate. So all you need is obtain a certificate from another vendor. With Let's Encrypt, this will take you fifteen minutes tops. A careful administrator deploying HPKP would probably pin a key they have securely stored somewhere and, should a disaster strike, go out and buy a certificate for that pinned key. Again, that would take an hour at a cost probably lower than his lunch.

by cbr 10y ago

byuu 10y ago

This can also be dangerous. If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all. Not even to display to the user, "sorry, we're having some technical issues, please check back later", with all the login stuff disabled (and the site using secure cookies by default anyway, so they won't leak in HTTP mode.) It is really difficult for the average user to clear HSTS/HPKP data. You can't just clear your history, you have to go to about:permissions or chrome://net-internals#hsts to do that. Maybe that's the experience you want. But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Public key pinning is even more dangerous. Not the least of which because there are no longer two free providers of SSL certificates for your backup cert. This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. The domain could have a new TXT record of "TLS=Always" that you could flip on or off as needed. The TTL on that could be 3600 seconds instead of 4+ days for a bad OCSP response, or the suggested (by SSL Labs) 6+ months for an HSTS response.

pfg 10y ago
> But I think it'd be a tough sell to any business to have their users presented with a certificate error message for up to four days because Globalsign screwed up. Are you making the argument that a business would want the ability to turn off HTTPS enforcement temporarily in case something like the GlobalSign thing happens? Because I think that's a terrible idea. They should just switch to a different CA, or get the CA to sign a certificate that's not impacted by that issue (which I believe GlobalSign offered). Even excluding Let's Encrypt, the price tag for that is < $10 and it's done in a matter of minutes (and only getting better with ACME). Since we're talking about businesses here, better yet: Have a backup certificate from a different CA ready. This is really no different than all the other things you'll need to do to run a reliable service (like have more than one web server). It's not like one CA screwing up means your domain is dead until they've resolved the issue. Same thing goes for HPKP, since a backup pin is required. Your argument is also not specific to HSTS/HPKP - you're basically saying that HTTPS in general is dangerous for a business because of this. If your site offers HTTPS without HSTS and without redirecting to HTTPS by default, you'd still have users who bookmark HTTPS links, or search engines indexing those links and all of those would also fail, with no way for you to fix it other than switching CAs. > This is yet another problem that could be solved with DNS signing -- both the risks of HSTS and HPKP would be gone. I don't want to get into yet another DNSSEC discussion (that's what we have @tptacek for, anyway), but I don't see a huge difference here. Switching CAs can be done in less time than the TTL you're suggesting. Practically speaking, if you want to factor in "time to find a new CA" or something like that, I'd argue that most people won't run their own DNSSEC infrastructure and rather use something like Cloudflare, so the same "time to find a new <foo>" principle would apply here if they've messed up in a way that takes a long time to resolve.
blfr 10y ago
If Globalsign starts sending bad OCSP data again, or your browser vendor blacklists your CA due to bad behavior from the CA (no fault of your own), you'll end up with a site that now can't be accessed at all That's only true for somewhat carelessly configured HPKP. With HSTS you can use any valid certificate. So all you need is obtain a certificate from another vendor. With Let's Encrypt, this will take you fifteen minutes tops. A careful administrator deploying HPKP would probably pin a key they have securely stored somewhere and, should a disaster strike, go out and buy a certificate for that pinned key. Again, that would take an hour at a cost probably lower than his lunch.