Hacker News new | ask | show | jobs
by tedunangst 3443 days ago
Well, it doesn't have to be an attack per se. Maybe the client's clock is wrong, which actually happens a lot. Or admin error replacing the cert on the server. There are of course lots of ways admin error can take down a server, but https adds some fun possibilities that are easier to trigger and harder to recover from.
2 comments
Godel_unicode 3443 days ago
Bonus points for client clock error. If I had a nickel for every time...

The best is when it's a timezone issue and the distant end responds with "I have 0 drift, must be a problem on your end". Crypto is hard, time is hard. Crypto which relies on time...

link
pfg 3442 days ago
I mean, sure, there's more things that can go wrong once you add TLS to the stack. At the same time, there are so many other guns to shoot yourself in the foot with, so why is that we should draw the complexity trade-off line between HTTP and HTTPS? HTTPS seems to be good enough for 50% of all page loads nowadays. There's no active attack scenario here (which I agree would be a concern for critical services!), and for every possible TLS server or client issue, there are a multitude of other server, network or browser issues that could have a similar effect.
link
Godel_unicode 3442 days ago
The point of this thread has been that adding additional complexity, whatever its form, makes services more fragile. You might not be aware of this, but there was recently a Treasury CA delegated from the Federal Common Policy root CA whose cert expired. This caused every system downstream to have to go through and update their CA bundles. There was significant pain because systems with hsts enabled trying to connect to web services with the wrong cert bundle caused exactly the type of outage we've been discussing. This is not a hypothetical, there were systems with days/weeks of downtime caused by (mostly) human error. The fact that other things can go wrong too does not mean that things going wrong because of HTTPS isn't a problem. It's a trade-off, like everything in security.

Managing certs is work. People get it wrong sometimes. Mandatory hsts means no "just click allow" safety net. This decision takes away the ability to accept that risk for systems where availability is more important.

link
tedunangst 3442 days ago
If I screw up max connections or keep alive or some such in nginx.conf I can revert that change with downtime limited to the duration of the bad change. Screw up HPKP with a bad cert roll and you can't just revert. Users will be bifurcated into before and after groups, and you can't fix that without waiting it out.
link
konklone 3442 days ago
Very true. HPKP is not part of this change, and if you look at GSA's guidance on HPKP, it's cognizant of this risk:

https://https.cio.gov/certificates/#http-public-key-pinning

link
pfg 3442 days ago
Oh, HPKP is definitely something you'll want to think about hard before committing to. Getting a publicly-trusted certificate from any of the myriad of CAs out there, on the other hand, is no rocket science.
link