SoylentNews is people
SoylentNews
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
(Score: 2) by Marand on Wednesday August 10 2016, @05:37AM
You do realize I'm a Debian Developer in addition to an Ubuntu Core Dev, right?. Anyway, my point is sysvinit has issues, and was due for either update and replacement. I thought upstart good replacement for technical reasons. The primary reason it didn't get adopted by Debian was political most over Canonical's copyright assignment policy; I remember it came up several times on d-private.
Had no idea about you being a DD, since I only saw mention of Canonical work in the other comment. You're as anonymous as anybody else here to me. :p
And yeah, the copyright assignment thing sucked, I recall there being some grumpiness over it in the past, so that's not surprising at all. What I meant though was that in the open discussions about the future of Debian's default init, upstart+systemd people (including some devs on both sides) seemed keen on shutting down any attempt to suggest anything else. People were determined to make it a two-party vote, and once that happened Upstart lost to politics like you said.
As for the sysvinit thing, I'm aware it's a script-based hack and has its issues, but it still does the job mentioned, so I took your statement as a literal "it can't do this thing it does". It's not hard to imagine someone would miss a change like that in a completely different distro, so I took the remark at face value. Just a communication error there: you were being more literal in referring to init itself while I was interpreting it more broadly.
Also, thanks for the answer about the server selection. I'm with you on the general aversion to Redhat-derived distros, and preferring Debian-based distros for stability and the upgrade process. It's why I've stuck with Debian since around 2000, and why I keep ending up coming back to it after experimenting with other options occasionally. I've mentioned it here before, but my primary OS is a Debian install that started on 2.2 (potato) and has been dist-upgraded through the years, with migrations to new hardware, new disks, and even updated in-place from 32bit to 64bit. I don't know any other OS or distro that I could have done this with. I probably should just reinstall it one day, but it amuses me to keep it going instead of starting fresh at this point. :)
Vaguely related distro talk: I keep intending to spend time with NixOS. I already get a lot of use out of Nix as a secondary package manager and really like its (admittely weird as hell) filesystem layout and philosophies, so it's on my radar but I haven't gotten around to it. It starts out with systemd though, bleck. Does seem to have other options (sysv, upstart, runit) but I have no idea how much trouble it would be to switch out.
At this point, my take on systemd is I'm mostly avoiding it for now. sysvinit and the patchwork of hacks on top of it may not be the way to go long-term (I agree about it being due for update or replacement, I just think it all happened a bit prematurely, at least for Debian), but I'd still rather use it than systemd right now. Like you said, if it were just a desktop thing, it wouldn't be such a big deal. I haven't had any problems with the "higher" parts of systemd; it's not really any better or worse than dealing with, say, HAL was in that regard. (I remember HAL being a nightmare at times early on...)
It's just that I don't want systemd as my init, so I stick to systemd-shim and running anything else underneath. The init just happens to be sysv because that's what Debian used before and it just worked, but it's not like I'm not open to alternatives. Just preferably alternatives that aren't systemd's init. Hopefully by the time I don't have a choice any more, Poettering and Sievers will have gotten bored and moved on so others can clean house. It mostly worked for Pulseaudio like that, at least...
On a related note, have you ever used runit for anything? It sounds interesting but I've never gotten around to spending time with it. I've only heard of one distro (Void Linux) using it by default [voidlinux.eu], but their page on how it works is intriguing. It also appears you can even use it alongside another init in case you only want to manage certain services with it, which sounds like it could be appealing.