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: 4, Informative) by paulej72 on Monday June 22 2015, @09:05PM

    by paulej72 (58) on Monday June 22 2015, @09:05PM (#199589) Journal

    We have mobile device support on the todo list. There are some things that need cleaned up in the UI first for the normal site before I start tackling the mobile css.

    --
    Team Leader for SN Development
    Starting Score:    1  point
    Moderation   +2  
       Informative=2, Total=2
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1, Interesting) by Anonymous Coward on Tuesday June 23 2015, @07:04AM

    by Anonymous Coward on Tuesday June 23 2015, @07:04AM (#199766)

    How exactly do you plan to support mobile devices? I hope not with separate URLs.

    • (Score: 2) by paulej72 on Tuesday June 23 2015, @01:11PM

      by paulej72 (58) on Tuesday June 23 2015, @01:11PM (#199858) Journal

      No not separate urls. I was thinking of a setting that gets saved as a cookie that will send out a different set of css files. This way a user can select the version of the site based on device. The switching between these would be in an easily accessible place on the front page, possibly in the footer so it is available everywhere.

      I currently hate auto switching UIs as I as a user then cannot set the mode I want. My phone is high enough resolution to show a normal desktop site and I prefer that to some the over simplified mobile sites.

      --
      Team Leader for SN Development
      • (Score: 0) by Anonymous Coward on Tuesday June 23 2015, @04:16PM

        by Anonymous Coward on Tuesday June 23 2015, @04:16PM (#199956)

        That sounds great. However you could do a combination of auto-selection for users not having that cookie set, and cookie selection for users with that cookie. That way there's a good chance that users will get the right version for their system right out of the box, but they still have the option to set it the way they want if the auto selected version doesn't fit their way (no matter what you do, you have to decide on a version to show if there's not yet a cookie set). Also, it would keep the site cookie free for anonymous users who agree with the automatically chosen version. A cookie would only be set for those who explicitly request the other version.