Attila Bukor has posted comments on this change. ( http://gerrit.cloudera.org:8080/11162 )
Change subject: [site] Add http to https redirect ...................................................................... Patch Set 1: > Patch Set 1: Code-Review-1 > > I know I was the one that suggested this approach, however after doing more > research I think it's the wrong way to do it. There is a good article by > Google about how to enable HTTPS @ > https://developers.google.com/web/fundamentals/security/encrypt-in-transit/enable-https > > In the section of that article titled "Turn on Strict Transport Security and > secure cookies" they recommend using HSTS > <https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security> instead of a > 301 redirect, and in the section "Redirect HTTP to HTTPS" they recommend > using <link rel="canonical" href="https://...";> tags in the page header to > gently redirect search engines to using https. The HSTS approach is definitely something I'd like to look into, but as it's something that's hard to go back once enabled (we need to wait until max-age secnods), I thought this should be added as a next step once we are reasonably certain it's working fine for everyone (we can ask around on Slack and the mailing lists maybe). As for the canonical link approach, it's nice to have for search engines, but it doesn't actually redirect, so 301 still should be used here. The Google article you linked seems inconsistent about this point too, maybe it has been updated at some point, but they failed to update all references: "This defeats attacks such as SSL Stripping, and also avoids the round-trip cost of the 301 redirect that we enabled in Redirect HTTP to HTTPS." <- it talks about 301 redirect instead of the canonical link tag. The HSTS RFC itself says a permanent redirect such as response code 301 SHOULD be used when the request is made over a non-secure HTTP transport[1]. It also says the STS header MUST NOT be included on such requests, only on HTTPS. > > Sending a hard 301 redirect from http seems undesirable because it locks out > clients that can't speak https, whereas the above approaches are both > backward-and forward-compatible. You're right that it might lock out some clients with the current settings. According to Qualys SSL Labs tests, there's a protocol mismatch with IE 10 and earlier, Android 4.3 and earlier, and Safari 6.0.4 and earlier[2]. Do we have any data on whether we have any visitors using any of these browsers? I'd assume it would be near impossible to use any modern websites with them, so I'm not sure whether we need to take them into consideration. I imagine enabling old cipher suites/protocols they understand would result in a very low grade on this report. Anyway, if we want to make kudu.apache.org accessible on these old browsers, I believe TLS 1.0, and RSA with 3DES should be enabled instead of allowing everyone else to access the page over non-secure HTTP. [1] https://tools.ietf.org/html/rfc6797#section-7.2 [2] https://www.ssllabs.com/ssltest/analyze.html?d=kudu.apache.org&s=40.79.78.1&latest -- To view, visit http://gerrit.cloudera.org:8080/11162 To unsubscribe, visit http://gerrit.cloudera.org:8080/settings Gerrit-Project: kudu Gerrit-Branch: gh-pages Gerrit-MessageType: comment Gerrit-Change-Id: Ic5a060a419466ec4b16840347d387262ca8a4199 Gerrit-Change-Number: 11162 Gerrit-PatchSet: 1 Gerrit-Owner: Attila Bukor <[email protected]> Gerrit-Reviewer: Attila Bukor <[email protected]> Gerrit-Reviewer: Dan Burkert <[email protected]> Gerrit-Reviewer: Mike Percy <[email protected]> Gerrit-Reviewer: Todd Lipcon <[email protected]> Gerrit-Comment-Date: Mon, 13 Aug 2018 09:43:01 +0000 Gerrit-HasComments: No
