SoylentNews is people
SoylentNews
As I get through my remaining TODO items (such as restoring our second webfront, hydrogen to production), I find myself needing advice on a few final items: implementing HTTP Strict Transport Security and HTTP Public Key Pinning. Although simple in theory, both these options have complications that I want feedback from.
HSTS
For those not familiar with HSTS, it essentially says that this site ONLY uses HTTPS, and to never attempt a plain HTTP connection. This primarily helps in preventing HTTPS stripping attacks. The downside is once enabled, we won't be able to disable HTTPS for any reason; web browsers will refuse to open a HTTP-only connection, and the site will break for most captive proxies (this is incidentally the reason that if you're behind a captive proxy, and try to go to Facebook or Twitter, the connection fails with the usual SSL error page in Firefox and Chrome). Furthermore, we will not be able to implement the 'includeSubdomains' option at this time as several our of sites use self-signed certificates. We'll be replacing these with real SSL certificates or a wildcard certificate in the near future to allow this.
HPKP
HTTP Public Key Pinning on the other hand, works to solve the age-old problem that any CA can sign any site. By pinning the SSL public key, we can indicate to browsers that an SSL connection to us is only valid if the certificate is both signed by a CA, and that the public key is one we control (and paired with our private key). Other SSL certificates will be rejected since they will not have the same 2048-bit key we use. The CA chain-of-trust is reduced to the first connection to the site post-pinning. The browser will cache the HPKP header and remember the pins until they expire. The downside to this is it both complicates key management, and will break the site if someone tries to access it behind a SSL proxy. For those unfamiliar with SSL proxies, they are (usually) hardware devices preloaded with a valid intermediate SSL certificate, which dynamically generates a "valid" SSL certificate for any HTTPS connection, and allows the operator to decrypt any encrypted traffic passed through it in such a matter that is almost invisible to end-users. I'm not sure how common such devices are, but once HPKP is enabled, SSL proxies will cease to function unless a corporate administrator disables HPKP support in the browser.
What I want to know from the community is the following:
- Have you deployed HSTS/HPKP to any sites you administrator?
- What, if any gotchas did you run into?
- Have your users reported any unusual breakage or such?
Finally, for those wondering 'why bother', beside its obvious purposes, I want SoylentNews to be an example of a website done right; IPv6 support, strong SSL support, etc. We want to be an example other sites mimic, and as such, embrace technologies that protect the user from Man In The Middle, and such.
(Score: 1) by darkengine on Monday June 22 2015, @08:33PM
DNSSEC is, IMO, broken [sockpuppet.org], and a solution looking for a problem.
Use the backup key you were required by the standard to specify.
Add the preload header to your site and put yourself on the HSTS preload list.
(Score: 2) by NCommander on Tuesday June 23 2015, @03:43AM
I've read that post, and quite a bit of other DNSSEC rants that I honestly don't agree with. sockpuppet.org conflates the issue that DNSSEC is a replacement for the authentication properities in TLS. The argument on DNSSEC being government PKI proves that they don't understand what DNSSEC is. (arguably, KANE is, but I'll address that in a moment)
It's not. DNSSEC does one thing; it prevents DNS records from being spoofed via cache-poisoning attacks, or implementing a MITM attack via DNS (if you've got an ISP that redirects NXDOMAIN issues to a search page, you've been DNS MITMed). I fully admit the design of DNSSEC is rather clunky, but given the design of DNS, I'm not sure any replacement would look different. DNSCurve doesn't solve the issue because it requires the private key be installed on *every* root server; the IETF postiion is made very clear in this YouTube video [youtube.com]. DNSSEC allows the private key to be stored separately from the DNS server, which is a requirement for signing the roots.
DNSSEC can't stop nation-state attacks; not a lot can, nor was it designed to. Even taking in account that a nation-state could get the DNSSEC root signing keys (and I question if they realistically can without it being discovered), said nation-state would have difficulty since they'd have to rebuild the entire TLD to modify a record. There are easier ways to crack an egg. Furthermore, as I've said in other posts, nothing stops the NSA or other TLAs from getting a warrant and imaging our servers, or wiretapping the last-mile connections in the Linode data center which are unencyrpted (which due to practical reasons is difficult to fix).
When we sign soylentnews.org, to successfully impersonate us, you'd have to do all of the following:
* - only valid if a user has previously visited SN
I fully believe a nation-state could succeed at doing this, though it wouldn't be trivial. However, most attackers have much less resources; our biggest threat is a disgruntled user who wants to steal credentials of someone else, or an admin, and wreck havoc on the site.
Returning to the issue with KANE, its the only part of that rant that is semi-based in truth. KANE is essentially SSL pinning on a DNS level, against the certificate vs. the actual key. I consider that designed flawed, but its better than nothing. If KANE is used, then the cert chain is pinned in addition to HPKP and HSTS requirements. This stackexchange post has a LOT of good information on the subject, and where I found that YouTube video [stackexchange.com].
The problem most people don't get is security will never be perfect. A targeted attack against any site is incredibly hard to beat, and I'm fairly sure that if someone put their mind to it, they could break SoylentNews. However, which each layer of security added, attacks get harder and harder, to the point that most attackers will likely go for a softer target if its not specifically targetted at you. For example, for over a year, we used a very old version of Apache because that's what the site was dependent on. There are likely Day 0s out there against Apache 1.3 that are unpublished. I setup AppArmor to secure the Apache instance so even if you could achieve remote code execution, there wasn't a lot you could do with it.
Of course, then someone could break AppArmor, then you're running as the slash user. Then you need to elevate to root, and then figure out how to break further into our network. Each layer makes an attack harder and harder. There is no magic bullet, or magic unicorn when it comes to security. Its layering on enough armor that when that attack comes, *something* will stop it. And DNSSEC, HSTS, and HPKP is another layer of armor.
Still always moving