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 <[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: Tue, 14 Aug 2018 20:58:04 +0000
Gerrit-HasComments: No

Reply via email to