Strict HTTPS feedback

[my-password-is-password]

Chrome's built in mixed content blocker seems to only block scripts and gives a warning for other types of requests.

uMatrix's strict HTTPS blocks all types of requests.

Heres Microsoft's Mixed Content test page, https://ie.microsoft.com/testdrive/browser/mixedcontent/assets/woodgrove.htm

Not reporting this as a bug just feedback after reading the wiki.

This site seems to be a better test page for comparing mixed content blocking, https://www.bennish.net/mixed-content.html

The built in blocker allows media (images, audio, video) requests.

[gorhill]

Ok good then I will keep the feature in.

[my-password-is-password]

Saw something weird happen today, theres an extension that breaks uMatrix's Strict HTTPS. The extension is called Poper Blocker, its a pop up blocker.

https://chrome.google.com/webstore/detail/poper-blocker/bkkbcggnhapdmkeljlodobbkopceiche

Test page 1: https://nda.creative-assembly.com/form/kingdom/thank-you

Poper Blocker enabled

Poper Blocker disabled

---

Test page 2: https://www.bennish.net/mixed-content.html

Poper Blocker enabled

Poper Blocker disabled

Default Flags Chrome 39.0.2171.71 m Windows XP Everything in uMatrix's Privacy tab checked

[gorhill]

Does Poper Blocker really break the pages? From what I can see, the requests through non-encrypted connection were not allowed in both cases, whether Poper Blocker was enabled or not.

Never mind, I looked more carefully. Indeed, what should have been blocked by the browser is not blocked when Poper Blocker makes the requests itself.

Going to have to look into this, kind of confused how come the requests for embedded resources end up being made by Poper Blocker.

[gorhill]

Ok looking into this now. I have a hard-time figuring how come the jQuery lib of the extension Poper Blocker end up being the one pulling resources embedded in the page. Code is minified etc.

Anyways, I am reconsidering the use of CSP to enforce Strict HTTPS. I will try to manually filter instead. Resources blocked due to not being properly https: can still show as allowed in the matrix, because they were blocked through something else than the matrix. I suppose longer term I will have to think of some visual feedback to inform users why some resources were blocked. The popup visual is getting kind of populated, not sure where I would fit this.

And it just occurred to me that a good advantage of manually filtering non-https: requests is that this would work properly in synthetic docs, like http://chromium-behind-the-scene, which is not the case currently.

[my-password-is-password]

All the images that got through were loaded using background-image: url(...) or background: url(...). The only image that got blocked correctly was http://d1ju58c4ctua8y.cloudfront.net/theme_assets/images/kingdoms/logo-450px.png which was in an <img>.

Same for test page 2. The Sexy_Ben.jpeg that was loaded was by background-image: url()

This is just an observation, I still don't understand.

When you pretty print the jquery code and put a breakpoint on the line 709, the images get blocked. Remove the breakpoint and the images load. Does timing matter?

[ghost]

I'm not sure if this would add too much complexity or feature bloat, but it would be nice if we could do Strict HTTPS per request type.

Currently I've got Strict HTTPS on by default, as I like to use the harshest blacklisting possible, but some sites I toggle it off just for a few piddly images, and expose myself to less secure JS as a result.

For example I disabled it on Super User and Apple, because of image loss.

[gorhill]

expose myself to less secure JS as a result

No, the browser will block "active" mixed content: javascript is considered active mixed content. There will be an icon in the address bar, which can be used to allow if you wish. The benefit of Strict HTTPS is to be more hardcore than the browser, as it will also block passive mixed content (good for privacy).

See for yourself: https://www.bennish.net/mixed-content.html

[ghost]

Oh, yeah I forgot about that icon.

Anyway, If a user hypothetically disabled that with the appropriate flag, would Strict HTTPS on block both Active and Passive content, or just Passive?

On 12/18/14, Raymond Hill notifications@github.com wrote:

expose myself to less secure JS as a result

No, the browser will block "active" mixed content: javascript is considered active mixed content. There will be an icon in the address bar, which can be used to allow. The benefit of Strict HTTPS is to be more hardcore than the browser, as it will also block passive mixed content.

---

Reply to this email directly or view it on GitHub: https://github.com/gorhill/uMatrix/issues/67#issuecomment-67506661

[gorhill]

would Strict HTTPS on block both Active and Passive content, or just Passive?

Both. Anything which is not https:, wss:, or data: will be blocked.

[privatebob]

Strict HTTPS doesn't seem to be blocking http links in the src of HTML5

Example: https://www.dailymotion.com/video/x2fzmkz_game-of-thrones-season-4-making-of_shortfilms In network monitor: Path: http://proxy-04.nyc.dailymotion.com/video/918/887/147788819_mp4_h264_aac_2.mp4? auth=1232432434-5675-9dfsdwen-345jlkjsdf9f7lswer080lkjljsdf6zxcyvt45b Method: GET Status: 206 Partial Content Scheme: http Type: video/mp4 Initiator: Other

(Edit: Strict HTTPS also doesn't block http requests by the flash player in an https page. It would probably be good to warn users of that fact in the help text.)

[gorhill]

Fixed in 0.9.0.0: uMatrix now blocks itself the non-secure requests, rather than relying on a CSP policy.