CODEWITHSUNDEEP
google-chromehttpsweb-inspector
Christian
Christian

Reputation: 612

Warnings about "Insecure elements" on some HTTPS sites in Chrome but no such elements can be found

I recently installed Pi-Hole and use it as primary DNS. It works great, the ads disappeared and the Pi's log files are filling up with blocked stuff.

But I've noticed that since I started using the pi hole some sites seem to have trouble with HTTPS on my desktop PC. Although I don't think it's a pi hole problem since it's working without a problem on my Chromebook which uses the exact same browser extensions as my primary PC.

Twitter for example

Twitter with the Pi hole

The chain seems to be OK

Cert chain

The first thing I checked was the console but it only says that it couldn't load the HTTPS versions of some trackers and analytics which is fine because the Pi doesn't listen on Port 443.

console warnings

I even installed Fiddler (recommended on Stackoverflow) to check if there is unencrypted data transferred from twitter.com or the Pi but noting is unencrypted

Fiddler screenshot

And here is where it gets really odd: Chrome is the only browser that has a problem (IE and Edge are having no such warnings) and most HTTPS sites are working just fine with Chrome.

Sites with the error

Sites without the error

Yes I already checked for malicious browser extensions or viruses on the Device

Has anyone of you experienced a similar problem or know a way where I can find what's bugging Chrome?

Upvotes: 0

Views: 2706

Answers (1)

Barry Pollard
Barry Pollard

Reputation: 45950

Managed to figure this one out eventually after seeing same issue at work (behind a proxy).

For an EV certificate, as well as the usual checks (that the certificate matches the domain, has not expired, and links up to a CA certificate trusted by the computer), Chrome also insists on a live check that the certificate hasn't been revoked. This is done though a process called CRL or OCSP but basically requires a network call to the cert provider to allow this to happen.

Twitter, most online banks and www.sofort.com all use EV certs so require these checks. Facebook, Reddit and most other sites do not use EV certs so do don't need these checks.

Now you'd like to think that the CRL/OCSP check would use the same proxy as used for internet browsing through the web browser but turns out this is not the case and a separate process called WinHTTP is used for that and this has a different proxy setting.

You can run the below command in a DOS prompt and I'm guessing it will show no proxy:

C:\>netsh winhttp show proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

If so, and you've no longer direct access to the internet, except via your proxy then you should be able to set that using this command (assuming your proxy runs on port 8080 on proxyserver): 

C:\>netsh winhttp set proxy proxyserver:8080

Current WinHTTP proxy settings:

    Proxy Server(s) :  proxyserver:8080
    Bypass List     :  (none)

And then it should work. I couldn't get this to work as we use an authenticated proxy and it's a bit more complicated here but in theory it should work.

To reset this use the following:

C:\>netsh winhttp reset proxy

Current WinHTTP proxy settings:

    Direct access (no proxy server).

Now there's a question as to whether it should show this as red, insecure and, to me, it definitely shouldn't show that confusing "insecure content" message as that's wrong. Looks like Chrome Canary has improved the messaging around this, so hopefully that will make it into the main relase now. Though it still shows it as grey (i.e. worse than non-EV) which is arguable as to whether that's right or not.

More detail here: https://code.google.com/p/chromium/issues/detail?id=583021

Upvotes: 3

Related Questions