Activating WordFence Mixed Content Over SSL

Hello,

I found out what was causing the mixed content. When you have Enable Live Traffic View checked it causes a mixed content flag in https, when you uncheck this option, everything works great in https without the mixed content.

Thank you.

Apologies for the delay in replying; it has been a busy week! Disabling the Live Traffic view how you did, is the best solution for now.

Wordfence does try to load this script using https, but when only the cart page is forced to use SSL, WordPress redirects the browser back to http for this particular script. We have a case open to resolve this in a future version of Wordfence, so that you could use the feature again.

Is this in WooCommerce, or another eCommerce plugin?

-Matt R
FB965

Hello Matt,

It’s WooCommerce. Thank you for looking in to this. It’s not a big deal now that I know what is causing it and can turn that feature off but I am sure others will be happy to see this feature back online when in use with sites that use SSL.

Thank you,

Matt

Matt,

Ok, thanks for the reply!

-Matt R

Matt, I just spent several hours attempting to resolve what appears to be the same issue on a site we built for a client. The mentioned behavior only seems to be a problem in the Mozilla Firefox and Opera browsers (on both Mac & Windows). Chrome, Safari, IE & Edge all present the page as being secure.

To be specific, Firefox & Opera are showing the dreaded “mixed active content” & “content blocked” alert messages. (FF v46.01 on Mac 10.11.4 & Windows 10.1511, Opera v37.0.2178.43 on Mac 10.11.4 & Opera v37.0.2178.41 on 64-bit Windows 10.1511)

Please advise.

Matt,

If it helps at all I suspect this has to do with how redirects are being handled in Wordfence. The JS written to the page is correct and protocal-relative but when you try and request the script directly it 302s from https to http. I’m not familiar enough with the WF codebase to say for sure but I’m wondering if it has anything to do with how/where wp_redirect() is used.

To see it in action:
curl -v https://www.[somesite].com/?wordfence_logHuman=1

General output:

< HTTP/1.1 302 Found
< Date: Tue, 19 Jul 2016 21:06:31 GMT
< Content-Type: text/html; charset=UTF-8
< Set-Cookie: wfvt_1364334534=578e96570281b; expires=Tue, 19-Jul-2016 21:36:31 GMT; Max-Age=1800; path=/; httponly
< X-Pingback: https://www.[somesite].com/xmlrpc.php
< Location: https://www.[somesite].com/?wordfence_logHuman=1

Perhaps there could be a check in WF redirects to respond with the appropriate request protocol? Looking at WF source I’m wondering if it might also make sense to use wp_safe_redirect() instead of wp_redirect().

I actually stopped using HTTPS for WordPress and switched to Really Simple SSL and it worked better than I hoped for. I think the issue was because of how the url’s were being redirected to HTTPS. Really Simple SSL did a fantastic job of detecting our server setup and adjusting the .htaccess file to handle the correct requests.

Honestly, I think WordFence was working just fine, but there was something left behind on that setting that wasn’t being converted to https by the HTTPS for WordPress plugin that I was initially using.

Now I just build all our clients sites in pure HTTPS and it’s a lot better for everyone.

Cheers!