You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@kudu.apache.org by "Attila Bukor (Code Review)" <ge...@cloudera.org> on 2018/08/08 16:30:28 UTC
[kudu-CR](gh-pages) [site] Add http to https redirect
Hello Mike Percy, Dan Burkert, Todd Lipcon,
I'd like you to do a code review. Please visit
http://gerrit.cloudera.org:8080/11162
to review the following change.
Change subject: [site] Add http to https redirect
......................................................................
[site] Add http to https redirect
In the latest Chrome version all pages without TLS get a "Not Secure"
tag in the address bar, so even as there's no secure information (e.g.
passwords) transmitted to kudu.apache.org, http should redirect to
https.
Change-Id: Ic5a060a419466ec4b16840347d387262ca8a4199
---
M .htaccess
1 file changed, 4 insertions(+), 0 deletions(-)
git pull ssh://gerrit.cloudera.org:29418/kudu refs/changes/62/11162/1
--
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: newchange
Gerrit-Change-Id: Ic5a060a419466ec4b16840347d387262ca8a4199
Gerrit-Change-Number: 11162
Gerrit-PatchSet: 1
Gerrit-Owner: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Mike Percy (Code Review)" <ge...@cloudera.org>.
Mike Percy has posted comments on this change. ( http://gerrit.cloudera.org:8080/11162 )
Change subject: [site] Add http to https redirect
......................................................................
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.
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.
--
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Sun, 12 Aug 2018 16:47:18 +0000
Gerrit-HasComments: No
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Attila Bukor (Code Review)" <ge...@cloudera.org>.
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Mon, 13 Aug 2018 09:43:01 +0000
Gerrit-HasComments: No
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Attila Bukor (Code Review)" <ge...@cloudera.org>.
Attila Bukor has submitted this change and it was merged. ( http://gerrit.cloudera.org:8080/11162 )
Change subject: [site] Add http to https redirect
......................................................................
[site] Add http to https redirect
In the latest Chrome version all pages without TLS get a "Not Secure"
tag in the address bar, so even as there's no secure information (e.g.
passwords) transmitted to kudu.apache.org, http should redirect to
https.
Change-Id: Ic5a060a419466ec4b16840347d387262ca8a4199
Reviewed-on: http://gerrit.cloudera.org:8080/11162
Tested-by: Attila Bukor <ab...@apache.org>
Reviewed-by: Mike Percy <mp...@apache.org>
---
M .htaccess
1 file changed, 4 insertions(+), 0 deletions(-)
Approvals:
Attila Bukor: Verified
Mike Percy: Looks good to me, approved
--
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: merged
Gerrit-Change-Id: Ic5a060a419466ec4b16840347d387262ca8a4199
Gerrit-Change-Number: 11162
Gerrit-PatchSet: 2
Gerrit-Owner: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Mike Percy (Code Review)" <ge...@cloudera.org>.
Mike Percy has posted comments on this change. ( http://gerrit.cloudera.org:8080/11162 )
Change subject: [site] Add http to https redirect
......................................................................
Patch Set 1: Code-Review+2
lgtm but I've got limited availability at the moment I don't want to be the one to deploy this.
--
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Sun, 12 Aug 2018 16:11:44 +0000
Gerrit-HasComments: No
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Attila Bukor (Code Review)" <ge...@cloudera.org>.
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: Verified+1
verified this snippet works as expected on a site I'm hosting
--
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Sat, 11 Aug 2018 09:08:20 +0000
Gerrit-HasComments: No
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Mike Percy (Code Review)" <ge...@cloudera.org>.
Mike Percy has posted comments on this change. ( http://gerrit.cloudera.org:8080/11162 )
Change subject: [site] Add http to https redirect
......................................................................
Patch Set 1: Code-Review+2
After doing some more research on this topic I agree with you that this is probably safe to do.
--
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Fri, 12 Oct 2018 21:58:47 +0000
Gerrit-HasComments: No
[kudu-CR](gh-pages) [site] Add http to https redirect
Posted by "Dan Burkert (Code Review)" <ge...@cloudera.org>.
Dan Burkert 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:
>
> > 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
Yeah I'd err on the side of not enabling HSTS at this point. Perhaps it's just my inexperience with these web technologiges, but the known cons as well as unknowns definitely outweigh the pros. It should always be possible to enable HSTS in the future.
--
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 <ab...@apache.org>
Gerrit-Reviewer: Attila Bukor <ab...@apache.org>
Gerrit-Reviewer: Dan Burkert <da...@apache.org>
Gerrit-Reviewer: Mike Percy <mp...@apache.org>
Gerrit-Reviewer: Todd Lipcon <to...@apache.org>
Gerrit-Comment-Date: Tue, 14 Aug 2018 20:58:04 +0000
Gerrit-HasComments: No