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: 5, Informative) by NCommander on Monday August 08 2016, @03:51PM

    by NCommander (2) Subscriber Badge <michael@casadevall.pro> on Monday August 08 2016, @03:51PM (#385335) Homepage Journal

    Off-hand, here's what I've run into on multiple systems:

      * journald corruption on a semi-regular basis
          * Recovery is non-trivial and generally requires deletion of the db files
          * Can happen almost without fail on some machines on a hard restart
      * bad service start announcements; i.e. I can do systemctl *unit* start, and get a false start notice for example
          * Which requires a trip to journald to see what happened
      * journalctl sucks if you're trying to search for something and doesn't handle rotation cleanly.
          * which means if you've got a service which is non-chatty, you could see weeks or older log messages
      * No ease of seperation between standard out logs, and stderr.
          * No way to filter on stderr output only.
      * Unit files don't fail on typo. If you somehow manage to type Userr=nobody, it will silently run your process as root and not even pop a warning
            * Related. I've seen systemd race with nss_{ldap|hesiod}, where it tries to enumerate users before the network goes up, and craps itself or simply ignores the User= settings. Unaware if its fixed.
      * No easy way to parse in a unit-specific config. With both upstart and sysvinit, I could put a file in /etc/defaults, and load that into the unit to successfully seperate how I want to start a daemon and how to configure it. For example, varnish's setup has to go right into the unit file. This becomes problematic when ubuntu updates varnish and I have to manually merge the units together.
      * (Ubuntu specific) - service X action doesn't print success/fail messages. Plenty of scripts still depend on the old symantics
      * Historically: very very buggy, and I've had deadlocks.
            * At least with recent CentOS, this hasn't been a real issue, but I don't like it when the "massive daemon everything needs" goes belly up
      * cgroups are required (problematic in some virtualization scenarios; not an issue for KVM/Xen. Big issue with LXC).
      * Actively hostile upstream with no concern for any usecases beyond theirs.

    That's off the top of my head. I can go more indepth if need be.

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

    Total Score:   5  
  • (Score: 1, Informative) by Anonymous Coward on Monday August 08 2016, @07:27PM

    by Anonymous Coward on Monday August 08 2016, @07:27PM (#385426)

    Gentoo is still free of systemd. I've been using it for Linux based fileservers and routers sucessfully for years.