Exclusion (listing), non-effective when a server redirects to HTTPS

[grahamperrin]

With HTTPZ 0.11.3 disabled:

• http://helpx.adobe.com/flash-player.html redirects to HTTPS.

With the extension enabled:

• http://helpx.adobe.com/flash-player.html redirects to HTTPS
• the page action dialogue states that redirection was performed by HTTPZ
• opting to add an exclusion does result in a listing at about:addons but the listed exclusion is not effective.

A minor UX issue, I reckon.

[claustromaniac]

This is actually the intended behavior, and is not an issue.

Without HTTPZ

• The browser sends an unencrypted request over HTTP, to which the server replies with an unencrypted response with a status code 301 (AKA Moved Permanently), with the following headers:

HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: https://helpx.adobe.com/flash-player.html
Date: Sat, 07 Dec 2019 00:00:00 GMT
Connection: keep-alive

• This asks the browser to redirect the request to https://helpx.adobe.com/flash-player.html, by starting a new request.

With HTTPZ

• Before the browser starts the unencrypted network request to http://helpx.adobe.com/flash-player.html, HTTPZ redirects that request to HTTPS locally, before it gets sent. As a result, the initial unencrypted request is skipped, which is good, because unencrypted headers can contain sensitive information, and they can be sniffed.

---

Servers that redirect to HTTPS do not support HTTP. Excluding them is not only useless and unnecessary, it's detrimental. The problem is HTTPZ has no way to know what protocols are supported by a server before trying. If that were possible, I'd be able to make it so HTTPZ knows not to offer to exclude sites when a server does not support HTTP.

[grahamperrin]

Thanks, that makes sense.

So, just treat the exclusion (the listing) as negligible in cases such as this?

---

For this particular page, in reality I can't imagine anyone aiming to prefer HTTP. Online references to the non-secure address for the page must be vanishingly rare.

I chose to test an http:// link to Adobe's page only because its https:// address featured in https://github.com/EFForg/https-everywhere/issues/18726 … seemed like a :upside_down_face: thing to do. As if neither of us has anything better to do at a weekend.

[claustromaniac]

So, just treat the exclusion (the listing) as negligible in cases such as this?

I'm thinking I can let users know that the exclusions are not working because of external factors... I was going to wait until I implement the toolbar icon for that (#43), but now that I significantly changed how the page action works, this should be easier.

Sounds like an enhancement.

[grahamperrin]

Thanks 👍

I had to stare at it a few times before I got it, because I was testing more than one thing at once (following a www/nspluginwrapper routine).

The presence of insecure passive content is not due to partial effectiveness of exclusion from redirection to HTTPS. The insecure content results from a click on Adobe's Check Now button.

---

Also reminding myself, not all add-ons are disabled by safe mode. https://bugzilla.mozilla.org/show_bug.cgi?id=492271#c14 under Mozilla bug 492271 - "All Add-ons have been disabled in safe mode" is misleading in safe mode