is-on-https and insecure redirects

[brendankenny]

I believe this is the current summary. Please comment if I'm getting something wrong.

If an HTTP URL is tested in the CLI, even if it redirects to an HTTPS URL it will fail the is-on-https audit because the first request is insecure. It's arguable that this is correct (the first site indeed wasn't on HTTPS), but it can be an issue for automated testing where the redirect isn't necessarily material to what's being tested, and clearly the site is on HTTPS as soon as it's redirected. Additionally a human might notice the current log message warning of the redirect (or a debugString), but an automated system won't.

This is complicated by the fact that this is really only an issue in the CLI, since if testing in the extension or in DevTools the redirect would have already happened before hitting the "Perform an Audit" button and the is-on-https check would pass.

Steps we're currently proposing:

• relax is-on-https to allow a network-based redirect from an insecure origin to a secure one. This would include 30x redirects and HSTS-based ones, but not Javascript based ones. Add a debugString in this case that warns that, while passing, the first request was insecure.

  • any other types of redirects allowed?
  • can the insecure redirect be any of the redirects? e.g. if the redirects go HTTPS -> HTTP -> HTTPS

• add a "susceptible to a downgrade attack" audit (in Best Practices) that would warn when testing a site that passes the new is-on-https but passed through an insecure URL and suggests HSTS

• We've discussed for some time having a prominent warning area in the LH report for top level issues affecting what Lighthouse can measure (for, e.g. warning that the LH run was done with headless, which will skew perf numbers). A warning could be put here in case of insecure redirects, e.g. the same as the debugString above or the warning that's currently sent to the logger ("The URL provided should be on HTTPS. Performance stats will be skewed redirecting from HTTP to HTTPS.") - Way to surface non-critical errors in the report #1512

• redirects-http needs to move to checking schemes, not schemeIsCryptographic HTTP redirects to HTTPS audit doesn't work on android #2363

Importantly, the warning is good to let humans know that something weird is going on with their test (e.g. they misentered the URL as HTTP), while the new downgrade audit is good to let machines (e.g. the HTTP Archive) know that something is still not ideal even while is-on-https is passing.

[brendankenny]

An area in the report for warnings is apparently already filed: #1512

[igrigorik]

relax is-on-https to allow a network-based redirect from an insecure origin to a secure one. This would include 30x redirects and HSTS-based ones, but not Javascript based ones.

Why not JavaScript? The net effect (and exposure) is the same.

[paulirish]

@brendankenny if it works for you, I think we may want to punt this issue to next sprint so minification can take priority. what do you think?