Stories
Slash Boxes
Comments

SoylentNews is people

Meta
posted by NCommander on Monday August 08 2016, @12:00PM   Printer-friendly
from the now-with-a+-scores dept.

So after an extended period of inactivity, I've finally decided to jump back into working on SoylentNews and rehash (the code that powers the site). As such, I've decided to scratch some long-standing itches. The first (and easiest) to deploy was HSTS to SoylentNews. What is HSTS you may ask?

HSTS stands for HTTP Strict Transport Security and is a special HTTP header that signifies that a site should only be connected to over HTTPS and causes the browser to automatically load encrypted versions of a website should it see a regular URL. We've forbid non-SSL connections to SN for over a year, but without HSTS in place, a man-in-the-middle downgrade attack was possible by intercepting the initial insecure page load.

One of the big views I have towards SoylentNews is we should be representative of "best practices" on the internet. To that end, we deployed IPv6 publicly last year, and went HTTPS-by-default not long after that. Deploying HSTS continues this trend, and I'm working towards implementing other good ideas that rarely seem to see the light of day.

Check past the break for more technical details.

[Continues...]

As part of prepping for HSTS deployment, I went through every site in our public DNS records, and made sure they all have valid SSL certificates, and are redirecting to HTTPS by default. Much to my embarrassment, I found that several of our public facing sites lacked SSL support at all, or had self-signed certificates and broken SSL configurations. This has been rectified.

Let this be a lesson to everyone. While protecting your "main site" is always a good idea, make sure when going through and securing your infrastructure that you check every public IP and public hostname to make sure something didn't slip through the gaps. If you're running SSLLabs against your website, I highly recommend you scan all the subjectAlternativeNames listed in your certificate. Apache and nginx can provide different SSL options for different VHosts, and its very important to make sure all of them have a sane and consistent configuration.

Right now, HSTS is deployed only on the main site, without "includeSubdomains". The reason for this is I wanted to make sure I didn't miss any non-SSL capable sites, and I'm still working on getting our CentOS 6.7 box up to best-practices (unfortunately, the version of Apache it ships with is rather dated and doesn't support OSCP stapling. I'll be fixing this, but just haven't gotten around to it yet).

Once I've fixed that, and am happy with the state of the site, SN, and her subdomains will be submitted for inclusion into browser preload lists. I'll run an article when that submission happens and when we're accepted. I hope to have another article this week on backend tinkering and proposed site updates.

Until then, happy hacking!
~ NCommander

 
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 NCommander on Monday August 08 2016, @03:43PM

    by NCommander (2) Subscriber Badge <mcasadevall@soylentnews.org> on Monday August 08 2016, @03:43PM (#385331) Homepage Journal

    HSTS isn't a magic bullet. Neither is HPKP. Trust on first use already has plenty of inherent problems with it but its a lot better than what it could be. If you're using the site as a "regular" use, it will protect you from the coffee shop MITN, esp if preload is active (which it will be. Just haven't gotten there). It also prevents accidental downgrade (aka, I accidently post a http vs https) link. The supercookie point you bring up is moot because if you simply connect to https://soylentnews.org [soylentnews.org] (which is the official URL), you'll never create a HTTP hop. The only reason we're running the port 80 service at all is browsers will always try that first if you don't specify the protocol.

    Security is not a binary thing. Its something you improve and harden, and the goal is make your site hard enough to attack that nothing short of a targetted effort will do so. In the case of targetted attacks, well, my belief is nothing will stop a dedicated gunman between him and his target if he doesn't care about anything else.

    --
    Still always moving
    Starting Score:    1  point
    Moderation   +1  
       Insightful=1, Total=1
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 1, Interesting) by Anonymous Coward on Monday August 08 2016, @05:12PM

    by Anonymous Coward on Monday August 08 2016, @05:12PM (#385368)

    The supercookie thing is not a thing about soylentnews, but something that HSTS-enabled browsers make possible to (for example) malicious ad tracking networks. Soylentnews choosing to enable (or not enable) HSTS is irrelevant to the privacy issues. Website operators may as well enable HSTS because it's not their problem to deal with, but browser users should disable HSTS because of the privacy implications. Enabling "private browsing" basically does disable it, because this feature necessarily has to wipe the HSTS database clean for each session.

    Here's a simplified implementation of the tracking issue:

    • The browser requests a document from your server.
    • You generate a unique ID for the visitor.
    • You include an img tag in the response, referencing an image on an external http://unique-id.example.org [example.org] subdomain controlled by you. Any kind of external reference will work, but images are a good choice because as far as I know no current browser blocks mixed http/https images by default.
    • The first time anyone accesses the unique subdomain via HTTP, you send an HTTPS redirect and HSTS header. That browser records this subdomain in its HSTS database. On all subsequent connections, you do not redirect. In all cases, send appropriate headers to prevent browser caching of the response.
    • On subsequent documents you send (to anyone), you can include the same img tag in the response. If it is the same browser as last time (which recorded the subdomain in HSTS database), the browser will connect via HTTPS and you (the server operator) know this. All other browsers will only connect via HTTP. This enables you to quite reliably track the HSTS-enabled browser over time.

    Sending millions of image tags in every document is not practical so some kind of probablistic approach (e.g., bloom filters) is probably necessary. While not required for successful tracking, this is all made even easier and more reliable if you can get the client browser to execute javascript code that you supply.

  • (Score: 2) by bob_super on Monday August 08 2016, @05:55PM

    by bob_super (1357) on Monday August 08 2016, @05:55PM (#385390)

    > Security is not a binary thing.

    Actually, it kinda is:
      - if (machine always fully isolated from world) safe = 1;
      - Else safe = 0;

    Security tends to be a PEBKAC issue, with silly users actually wanting both machines that are ON, and the ability to connect to it. Then, you're squarely in the "else" case...