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: 4, Interesting) by Anonymous Coward on Tuesday June 23 2015, @02:43AM
Because what you visit, when you visit it, how long you linger on it, where you came from before you visited it, where you go after you visit it are all interesting to bad apples/actors like StaSi/NSA and other pond scum.
What you do on your pipe is your business, not theirs, not mine, not anyone else's.
Sure, with this solution, I still get to see you visited soylentnews.org but I don't see what you visit inside of sn.org. Because that's NONE OF MY BUSINESS...
Sadly, may actors in the world try to make it their business to see what you do so they can target you for whatever they want: manipulation, social engineering, echo chamber, etc... It is time to fight back against this invasion of privacy. (Imagine your precious founding fathers retiring to the idea that "you know, these Brits and their taxes... We've gotten used to it... let's not rock the boat too much"...
But hey, call me a tin-foil hatter... I don't care! Unfortunately, in practice, I've been proven correct on many occasions and those calling me a tin-foil hatter have been shown incorrect...
(Score: 2) by NCommander on Tuesday June 23 2015, @03:49AM
^- AC is correct on all counts.
As current web technologies go, as far as I'm aware, only I2P and Tor can protect against actually seeing what you browse due to the design of TCP/IP, and its pretty trivial to see if a user is using tor if you're watching network traffic so even that doesn't help as much as one would think. We've already done what we could on this front by implementing a tor hidden service for the site. Tor users will likely always be a minority, so we need to take steps to help the majority who aren't aware of tor or are unwilling or unable to use it.
Still always moving
(Score: 0) by Anonymous Coward on Tuesday June 23 2015, @09:45AM
but I don't see what you visit inside of sn.org.
You'd have to do a lot better to hide that information. An attacker only needs to look at the size of the response to know what you're looking at. There's lots of ongoing research on uncovering information about the contents of encrypted communication without decrypting it.
Still, encrypt everything. It makes snooping more difficult.