Stories
Slash Boxes
Comments

SoylentNews is people

posted by NCommander on Monday June 22 2015, @06:38PM   Printer-friendly
from the further-securing-soylentnews dept.

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.

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Insightful) by bradley13 on Monday June 22 2015, @07:23PM

    by bradley13 (3053) on Monday June 22 2015, @07:23PM (#199551) Homepage Journal

    As someone who manages just one website for a small company (turned https-only through .htaccess), I'll be very interested in hearing how to do it right. I expect lots of other Soylents are in similar positions: managing one of a few websites, and without the time and expertise to dig all this out ourselves.

    --
    Everyone is somebody else's weirdo.
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by DarkMorph on Monday June 22 2015, @10:09PM

    by DarkMorph (674) on Monday June 22 2015, @10:09PM (#199617)
    What exactly is the "right way" for setting up a server to be HTTPS-only? For a while I thought the popular solution was to make use of the rewrite module (speaking in terms of Apache) but then I found a replacement for that approach: the Redirect [apache.org] directive.

    You can redirect requests for / to https effectively making no request over port 80 possible to be served a document without the redirection. Also looks handy for aliasing in general alluding to the name of that module, mod_alias. HSTS sounds helpful but what about clients intentionally attempting to request a document via http?
    • (Score: 2) by NCommander on Tuesday June 23 2015, @03:58AM

      by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Tuesday June 23 2015, @03:58AM (#199722) Homepage Journal

      Our setup is a bit extreme for personal sites; we terminate SSL at our "load-balancer" which is really a glorified Linode 1024 with nginx. Here's the rule we use to bounce port 80 to 443:

      server {
              listen 80;
              listen [::]:80;
              return 301 https://$host$request_uri;
          }

      The double listen directive is required to get nginx to listen on both IPv4 and IPv6. Our cipher/TLS setup gets us an A rank, and 90s in Key Exchange and Protocol Support. I'd like to tighten it up, but it would kill basically anything older than 1-2 years old, such as Android 2.3, and pre-IE10 ..

      --
      Still always moving
    • (Score: 0) by Anonymous Coward on Tuesday June 23 2015, @06:59AM

      by Anonymous Coward on Tuesday June 23 2015, @06:59AM (#199765)

      Of course with any redirection method, the original request (including the URL you requested) first goes through the wire unencrypted. So if it is a publicly accessible document, anyone seeing the original request can just request the same document himself to see what you looked at. IIUC HSTS tries to fix that problem as much as possible server-side: As soon as you've accessed it over https once, the browser will know that the site should be accessed via https only.

      A client-side solution is the HTTPS everywhere [eff.org] extension. That's in one sense better because it prevents http even for the first contact for a site, but in another sense worse because it requires the user to be aware of the issue (and to use a browser for which the extension is available).