nixos/nginx: add strictTransportSecurity options #350302
Conversation
This is pretty easy for the user to set themselves, but it's a recommended security setting so making it more discoverable / encouraged seems like a good thing.
|
|
||
| includeSubdomains = mkOption { | ||
| type = types.bool; | ||
| default = true; |
There was a problem hiding this comment.
I am not sure this should be on by default, it is a footgun unless you are really prepared. Lots of cases of random sub‐subdomains with internal test deployments or services that aren’t ready for it.
(Haven’t done a thorough review of the rest of the PR yet.)
There was a problem hiding this comment.
sure, done :)
tbh my attitude was "enableACME is so easy these days" but yeah I guess non-public uses have the potential to be trickier
There was a problem hiding this comment.
Yeah, the problem is that it‘s easy if you have one single NixOS machine serving your entire domain hierarchy, and it‘s easy if you have a trillion machines that are all behind consistent HTTPS frontend stuff proxying everything to your highly‐structured web scale enterprise backends, but there‘s a wide range of setups between those where you just don‘t have complete visibility and control into everything going on under *.mycorp.com. Intranet, legacy SaaS, a random appliance you can‘t update, … there’s a big gap between “this web server on this domain can reliably do HTTPS” and “absolutely nothing under this hierarchy exists that cannot reliably do HTTPS in every single context”, and with HSTS it’s easy to screw up painfully. Of course people should set it if they can.
Will try to take a more detailed look at this PR in the next few days if nobody beats me to it, feel free to ping if I forget.
For more-or-less the same reasons that HSTS defaults false: accidentally enabling it when you didn't intend to can be really annoying.
|
Something else I considered: config warnings or assertions. I didn't add any because they seem kind of obnoxious if they ever have false positives, they're mostly kind of obvious instead of something subtle that could trip people up, and trusting the user to know what they're doing seems good, at least when they don't have an easy option to say "shut up, I know what I'm doing". But here are the ones I considered:
|
|
whoever reviews this: is it OK to just tag a random apache-httpd reviewer (or reviewers) to ask if they want the same to be added there? (which also prompts the question: should we be sharing code between the two / plus maybe caddy / others as well? my guess is that code sharing usually isn't helpful and it doesn't make sense to bother doing it for those few cases where it would work, but idk the idea of having all webserver configs look ~ the same is cool) |
ofborg
bot
added
10.rebuild-darwin: 1-10
10.rebuild-darwin: 1
10.rebuild-linux: 1-10
labels
Let me know if this needs a changelog entry, I wasn't sure whether it was significant enough.
This is my first nontrivial nixpkgs PR, so sorry about any mess :) I didn't
nixfmtthese modules because it would change a lot more than what I touched.Things done
nix.conf? (See Nix manual)sandbox = relaxedsandbox = truenix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage./result/bin/)Add a 👍 reaction to pull requests you find important.