IRC logs for #aegir, 2017-06-06 (GMT)

2017-06-05
2017-06-07
TimeNickMessage
[10:10:39]* ybabel has quit (Ping timeout: 260 seconds)
[12:18:05]* shaneonabike has quit (Quit: Leaving.)
[13:51:55]* gusaus has quit (Quit: gusaus)
[15:46:12]* mengi has quit (Quit: Leaving.)
[16:00:19]* anto_ has joined #aegir
[17:17:17]* ybabel has joined #aegir
[17:38:57]* reaper013 has joined #aegir
[20:22:29]* reaper013 has quit (Ping timeout: 260 seconds)
[20:45:33]* reaper013 has joined #aegir
[23:40:27]* anarcat has quit (Ping timeout: 245 seconds)
[23:42:21]* anarcat has joined #aegir
[00:23:28]<anarcat>https://www.divio.com/en/blog/documentation/
[00:42:31]<bgm>heh, a page on documentation that has grey text on white background.. with random words in bold..
[00:43:45]<anarcat>eh
[00:43:55]<anarcat>i read it on an epub reader, didn't notice until now :)
[00:44:07]<anarcat>i think it makes good points on how to organize documentation, however
[00:44:10]<anarcat>which aegir could use
[00:44:42]<bgm>https question: I use provision_sts, which adds the HSTS http header when https is 'required'. It checks if d()->ssl_enabled, but with hosting_https, that becomes d()->https_enabled. Is there a recommended method for checking against that, without generating PHP notices?
[00:46:22]<bgm>i have a hard time reading because my eyes automatically skip to the closest word in bold
[00:50:37]<colan[m]>bgm: Makes sense. i would recommend implementing the same thing for hosting_https: https://gitlab.com/aegir/hosting_https/issues/35
[00:52:19]<bgm>colan[m]: yeah, i'd add to core, my only concern is that the UI would have to be more explicit, perhaps add an option for "required for ever"
[00:53:52]<colan[m]>bgm: i was initially thinking of a checkbox, but the Airship guys don't provide that choice, so maybe we shouldn't either. I am worried about locking ourselves out of things, but maybe that's not as big of a problem as I think it is. https://paragonie.com/blog/2017/03/how-we-engineered-cms-airship-be-simp...
[00:55:05]<anarcat>bgm: assuming "required" means "HSTS" is a fair assumption
[00:55:15]<anarcat>especially if you need to enable an extra module to enable HSTS
[00:55:21]<bgm>true, and imho, "sane defaults || gtfo"
[00:55:25]<anarcat>HSTS is also not "forever"
[00:55:35]<anarcat>it has a (customizable) timeframe
[00:55:43]<bgm>yeah, but usually it's set to ~ 6 months
[00:56:06]<bgm>but plain http is deprecated anyway
[00:56:18]<bgm>it should be easier to setup https than it is to setup http
[00:56:51]<anarcat>i think HTTP's deprecation is overstated
[00:57:00]<anarcat>unless we cripple HTTPS
[00:57:05]<anarcat>e.g. captive portals.
[00:57:13]<anarcat>they basically *train* people to ignore HTTPS warnings
[00:57:23]<anarcat>unless some key sites stay HTTP
[00:57:34]<anarcat>e.g. meteo.ec.gc.ca is still plaintext, and i think that's fine
[00:57:38]<colan[m]>Is there really a use case for "I want HTTPS today, but not tomorrow"? If not, then there shouldn't be a choice.
[00:57:44]<anarcat>anyways, there are all sorts of issues with HTTPS...
[00:58:25]<bgm>anarcat: https://meteo.gc.ca/
[00:58:46]<bgm>an ISP might inject advertising into plain http, or other malicious content
[00:59:43]<bgm>anyway, i think if a site/farm operator does the extra step of enabling hosting_https, which is already a few more steps than just doing nothing, we should provide sane defaults
[01:00:36]<colan[m]>is it possible to remove the entry from your browser cache?
[01:00:50]<anarcat>bgm: http://meteo.gc.ca/
[01:00:54]<anarcat>bgm: e.g. no redirection
[01:01:26]<bgm>yes, there are two ways to remove HSTS: you can set a new header to expire it in browsers, and eventually remove the header after 6 months. or in your browser you can click "forget this site" in the history.
[01:01:41]<bgm>but if you have users, that's obviously not very practical.
[01:01:46]<bgm>(the latter)
[01:02:26]<bgm>anarcat: sure.. but i don't see why they would do that.
[01:02:33]<bgm>the only reason would be to support Windows XP
[01:02:46]<bgm>on IE
[01:03:26]<colan[m]>i'm fine with either the checkbox that's by default checked, or not providing the option at all.
[01:03:27]<bgm>i have a friend who works in a hospital that still has some XP desktops. They have a special plugin that opens all links in Firefox. tech pionners, wee!
[01:03:54]<colan[m]>...and just doing it.
[01:04:01]<bgm>colan[m]: as you say, i think that "I want HTTPS today, but not tomorrow" is an edge case we don't need to worry about.
[01:04:13]<colan[m]>bgm: great, then don't make it an option.
[01:04:59]<colan[m]>I was thinking more about messing up in development, but you can remove entries from your browser, so it's fine.
[01:07:51]* reaper013 has quit (Quit: Page closed)
[01:08:02]<bgm>colan[m]: i can send a MR for hosting_https, but where should hook_provision_nginx_vhost_config() go? ./submodules/nginx_https/drush/https_nginx.drush.inc ?
[01:08:10]<bgm>(+apache)
[01:12:49]<colan[m]>bgm: maybe the base module file? i think it would apply to add servers, no?
[01:13:06]<colan[m]>er, all servers & submodules.
[01:14:14]* theMusician has joined #aegir
[01:16:48]<bgm>ok, i'll test. we can always move later
[01:17:23]<colan[m]>bgm: or maybe each server module's template file, e.g. submodules/nginx_https/drush/Provision/Config/Nginx/Https/server_https.tpl.php
[01:18:52]<colan[m]>bgm: yes, let's keep all config in one place. url for my last comment: https://gitlab.com/aegir/hosting_https/blob/master/submodules/nginx_http...
[01:19:38]<bgm>i'm having trouble with nginx though.. I thought I had this working before, but it's not adding the header. Some docs say: "Because this 'location' block contains another 'add_header' directive, we must redeclare the STS header"
[01:19:56]<colan[m]>sorry, that was for the server. vhost: https://gitlab.com/aegir/hosting_https/blob/master/submodules/nginx_http...
[01:20:06]<colan[m]>Not sure what you're running into there.
[01:20:47]<bgm>nginx+aegir location blocks add a lot of headers, so I suspect we'd have to add it in ~/config/includes/nginx_vhost_common.conf .. and that could be a problem
[01:21:06]<colan[m]>yup.
[01:27:59]<colan[m]>bgm: maybe ask memtkmcc as he's good at figuring out this stuff. one option is to reimplement all of that in the vhost if that's what happening, to get around the override problem. he's not here now, but usually responds if you mention him in the gitlab issue.
[01:29:45]<bgm>colan[m]: ok cool, i updated the issue with a recap and pinged him
[01:30:44]<colan[m]>:+1:
[01:31:00]<bgm>all this because someone posted a civicrm bot that scans sites on ssllabs.com and reported that civicrm.org was 'A', not 'A+' :)
[01:31:35]<bgm>which made me realize that all my sites lost their HSTS.. so, yay bots :)
[01:33:37]<colan[m]>bgm: thanks for tackling. have been putting it off. will help with https://gitlab.com/aegir/hosting_https/issues/38
[01:33:57]<anarcat>bgm: neat
[01:34:12]<anarcat>i have found https://observatory.mozilla.org/ to be very useful to test sites as well
[01:35:18]<colan[m]>ssllabs++
[01:35:18]<bgm>colan[m]: cool, thanks. fwiw, for ciphers and such, I use: https://github.com/coopsymbiotic/provision_symbiotic/blob/master/tpl/cus...
[01:36:22]<bgm>but, for example, I disabled TLS 1.0 a long time ago.. and it breaks older IE and Safari.. but.. well.. merg.
[01:36:49]<colan[m]>bgm: i like. feel free to merge. you've got all this great custom stuff nobody knows about. ;)
[01:36:56]<bgm>the dhparams bit is also annoying. I'm not sure if it's still required though. back in the day, ssllabs would complain about weak dh keys
[01:38:19]<bgm>colan[m]: they're just hacks, and sometimes I don't fully understand the impact, so I test on my clients :D
[01:38:53]<colan[m]>bgm: yes, but once you've tested, and know what works.... :)
[01:40:08]<anarcat>https://observatory.mozilla.org/ also calls out to the ssllabs test :)
[01:40:36]<anarcat>but it is more stringent with ciphersuites and has nice tools to generate webserver configs for different software (e.g. nginx, apache)
[01:40:51]<anarcat>https://mozilla.github.io/server-side-tls/ssl-config-generator/
[01:42:11]<colan[m]>anarcat: oh, tha's a nice feature!
[01:43:31]<anarcat>yeah!
[01:43:39]<colan[m]>on a verify, we should just inject the output of that page :)
[01:43:44]<anarcat>it's also nice that it covers stuff like CSP headers and so on
[01:44:28]<anarcat>https://observatory.mozilla.org/analyze.html?host=anarc.at
[01:44:46]<anarcat>or, more relevant: https://observatory.mozilla.org/analyze.html?host=aegirproject.org
[01:45:08]<anarcat>gets an F :p
[01:45:46]<anarcat>same with aegir.coop
[01:48:41]<colan[m]>anarcat: are you volunteering to give those sites some love? :D
[01:49:55]<colan[m]>but yeah, we shold probably HTTPS-ify those at some point.
[01:50:25]<anarcat>nope :p
[02:11:05]* theMusician has quit (Ping timeout: 240 seconds)
[02:11:32]* theMusician has joined #aegir
[02:39:13]* theMusician has quit (Quit: theMusician)
[02:57:18]* theMusician has joined #aegir
[03:54:01]* gusaus has joined #aegir
[03:59:09]* shaneonabike has joined #aegir
[04:01:03]* shaneonabike has left #aegir ()
[04:34:24]<bgm>hmm, what was the trick again, to restore views after enabling hosting_https?
[04:37:12]<colan[m]>bgm: drush @hm rr
[04:37:51]<colan[m]>that's another thing we should figure out at some point. :)
[04:38:37]<bgm>colan[m]: thanks! and indeed, although very obscure bug..
[08:31:57]* gusaus has quit (Quit: gusaus)
[09:32:36]* gusaus has joined #aegir