[08:39:24] 10netops, 10Operations, 10monitoring, 10Patch-For-Review, 10User-fgiunchedi: Evaluate LibreNMS' Graphite backend - https://phabricator.wikimedia.org/T171167#3533020 (10akosiaris) >>! In T171167#3531227, @fgiunchedi wrote: > Both issues have been fixed upstream! Pending deployment of latest version of lib... [11:22:01] nice httpd changes in trunk: https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslpolicysection [11:22:52] and also https://httpd.apache.org/docs/trunk/mod/mod_ssl.html#sslpolicy (easier and less configurable) [12:03:58] looks good indeed [12:13:25] it'll be interesting to see how updates to these default policies trickle into installed servers, but that sounds in fact useful [12:18:06] atm they are taken from the Mozilla best practices and hardcoded in mod_ssl files [12:18:09] https://github.com/apache/httpd/commit/de3a4027cb3539c2a912915635d3e6d5a8fe3962#diff-dc18309bae02731ab9222ffcac8ae63fR523 [12:18:51] but anybody can define a section and include/share it [12:19:10] so basically new updates will flow httpd's releases [12:19:12] yeah, that's what I mean. it'll be interesting to see whether there's outcry if the policy sets change in a new upstream release (which people would realise during an update) [12:19:46] "I upgraded Debian and now old Androids no longer work!!1!" [12:19:55] hahha okok got it :D [12:20:30] I think people will complain for sure, but better that than super old policies allowing SHA1/RC4 and friends :D [12:25:38] yeah, it's a nice feature, I agree [12:59:36] an aggressive default is probably better, given how the history of these things has played out [12:59:49] let people that really legitimatelly need old compatibility learn about it and explicitly configure it [13:00:41] +1 [13:01:33] most people don't know what they need [13:02:43] and usually copy/paste from blog X and check that https://www.ssllabs.com/ gives the A+ green light [13:03:52] is there another way? ;) [13:04:48] just comparing the different advices is quite hard [13:07:39] feel free to comment on wikimedia.es tls setup btw [13:14:12] I completely agree, I meant that the copy/paste way usually leads to people not reading anything contained in them and forget about them :) [13:14:22] (the ssl settings) [13:33:43] Platonides: the wikimedia.es setup doesn't look like it has any big problems in a quick ssllabs scan. But if we're nitpicking/commenting, I can do lots of that of course :) [13:35:01] 1. The RSA cert and DHE keys are both 4096-bit. There's no real proven benefit past 2048-bit, and it slows down the client and the server considerably and causes more data transfer on connection setup, etc. [13:36:27] 2. While the HTTP (port 80) setup does seem to 301 redirecto to HTTPS, there are some non-HTTPS redirects being served over HTTPS commonly, too. e.g. fetching https://www.wikimedia.es/ gives a 301 to http://www.wikimedia.es/wiki/Portada which then gives a 301 back to https://www.wikimedia.es/wiki/Portada [13:36:44] so this puts an insecure step in the midst of the common redirect chain, allowing interception/manipulation [13:38:20] 3. [H]STS issues - currently emitting an HSTS header with a 6month max-age (good!) - but could up that to 1-2 years, add the "preload" attribute, and then submit the domain(s) to https://hstspreload.org/ for further protection (at the cost of making your HTTPS transition even more irrevocable) [13:39:26] 4. No DNS CAA record - it looks like you're using LetsEncrypt. If you set up a CAA record in your DNS authorizing only them, it will prevent other legitimate CAs from issuing certs for your domains (e.g. if someone tries to scam them and pretend they're you) [13:39:40] https://sslmate.com/labs/caa/ <- generates the DNS records [13:41:42] 5. Ciphersuite ordering - I'm not sure what's going on there, it's hard to infer how it's configured server-side from what testing shows. But it seems "off" - some clients who could be using ECDHE are using DHE instead, some clients that could be using GCM ciphers are using CBC instead, etc. [13:42:54] I wouldn't necessarily recommend copying our config here, as ours is very customized to the point that it requires ongoing maintenance and observation (it's not a fire+forget setup) [13:43:08] but even starting from one of the ciphersuite strings in https://wiki.mozilla.org/Security/Server_Side_TLS might work out better [18:10:43] anyone seen the question from an Amazon dev in #-ops? [18:14:59] hmm [18:29:13] 10netops, 10Operations, 10monitoring, 10Patch-For-Review, 10User-fgiunchedi: Evaluate LibreNMS' Graphite backend - https://phabricator.wikimedia.org/T171167#3534026 (10ayounsi) Those changes should land in the august release of LibreNMS (https://github.com/librenms/librenms/releases), most likely due nex...