User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0 Build ID: 20160425115534 Steps to reproduce: 1) go to http://www.eaglecreek.com/ 2) scroll down the page and select an item to buy (e.g., cargo hauler duffel) 3) click ADD TO CART 4) click CHECKOUT 5) click CHECKOUT Actual results: Sometimes the green lock icon shows (i.e., everything is secure), but sometimes the lock icon is greyed out and has a yellow yield sign that says "Connection is Not Secure". (If the icon originally shows green, try hitting refresh a couple times to see if it changes to "insecure.") Expected results: I'm reporting this to Mozilla because the lock icon in Firefox sometimes shows secure and sometimes shows insecure. But on Google Chrome it ALWAYS shows as insecure (i.e., a green lock icon never shows). My relative (using Firefox) purchased an item here and there was fraud on the card as a result. I found this inconsistency in Firefox when investigating the site. So I thought I'd report it in case it's anything you guys want to look into. I tested this with a "reset" Firefox with default settings.
This looks like an issue with mixed content blocking. Tanvi can you look into this?
There must be a descriptive message in the web console whenever this icon appears. Can you post it to confirm that a mixed content load was blocked?
(In reply to Panos Astithas [:past] from comment #4) > There must be a descriptive message in the web console whenever this icon > appears. Can you post it to confirm that a mixed content load was blocked? Loading mixed (insecure) display content "http://shop.eaglecreek.com/error_404.html" on a secure page Though for me (on 46rc), I only see a secure icon initially, and it is always replaced with the 'mixed content' icon, no matter how many times I refresh. So I guess I already get the same behaviour as Chrome, effectively. It looks like the 404 page is loaded because the page tries to get both header.gif and bg_headergr.png, both of which don't exist, both of which redirect through a sequence of 404 URLs until eventually the page sends: http://shop.eaglecreek.com/error_404.html as the Location header, and that trips it off HTTPS. I see the same thing in Chrome as well. It's not clear to me why this would ever *not* display the mixed content blocking icon.
I also get "Loading mixed (insecure) display content "http://shop.eaglecreek.com/error_404.html" on a secure page[Learn More]" in the console and the mixed display content icon in the url bar. The green lock shows up at first and then quickly changes to the grey lock with yellow triangle when the mixed display content is loaded on the page. So this seems to work fine for me. Maybe if the page behavior is not consistent, sometimes it doesn't attempt to load the error page? Maybe sometimes the actual image (which may be over https) loads so the 404 request is never made?
The indicator of "secure" vs. "insecure" is strictly about whether encryption was used for the connection between the browser and the website. It doesn't make any claims about the trustworthiness or otherwise of the merchant running the website. While it is possible someone eavesdropped on the insecure parts of the connection, it seems unlikely that actual credit card or other purchase details were transmitted through the insecure portions of the website (the image which redirected to the 404 page). Having gone through the flow on the website, I only see payment info transmitted over secure channels (though of course I am human, and it is possible I missed something...). Because we do not know that the icon would be wrong in claiming the page is secure (nobody has so far managed to reproduce it showing up permanently as 'secure' at all), it isn't possible to investigate this further right now, and I'm going to remove the 'security sensitive' designation and close it as incomplete, as we do not have enough information to investigate further.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.