Weblog entry #388 for simonw
See all weblog entries made by simonw.
#388
SSL Mixed content detection
Posted by simonw on Sat 21 Aug 2010 at 23:35
The last two times I've investigate the SSL mixed content warning on websites we manage it has been produced in error, one a browser bug, one a browser plug-in bug. But this would be so much easier if the browsers would list what they perceive as non-SSL content, or even the first item of non-SSL content.
Does any browser do that?
Does any browser do that?
Comments on this Entry
> Hmmm, so you are saying it has never been an HTML coding error at all? Not even in the DOM presented to the browser?
No, I'm saying not the last two times, before that I think they all were simple coding errors either HTML or Javascript. However since it is all under SVN those aren't quite so painful to find as it is easier to answer the question of "what changed?", if the tools don't immediately show the problem (they usually do).
I'm guessing the browser plug-in counts as a Javascript DOM error, but since it is part of the plug-in and not part of the "offending" page it wasn't obvious. What went on in the other one is a mystery known only to Microsoft.
The main give away with the bugs was they were both browser specific, one IE8, one Firefox, and that we can use the browsers with a proxy, so we could easily see non-local HTTP and HTTPS traffic. Tools to reveal HTTP requests in IE8 almost universally failed, one helpfully at the point the problem manifested itself.
No, I'm saying not the last two times, before that I think they all were simple coding errors either HTML or Javascript. However since it is all under SVN those aren't quite so painful to find as it is easier to answer the question of "what changed?", if the tools don't immediately show the problem (they usually do).
I'm guessing the browser plug-in counts as a Javascript DOM error, but since it is part of the plug-in and not part of the "offending" page it wasn't obvious. What went on in the other one is a mystery known only to Microsoft.
The main give away with the bugs was they were both browser specific, one IE8, one Firefox, and that we can use the browsers with a proxy, so we could easily see non-local HTTP and HTTPS traffic. Tools to reveal HTTP requests in IE8 almost universally failed, one helpfully at the point the problem manifested itself.
[ Parent | Reply to this comment ]
Posted by sneex (66.177.xx.xx) on Wed 25 Aug 2010 at 13:56
[ Send Message | View sneex's Scratchpad | View Weblogs ]
[ Send Message | View sneex's Scratchpad | View Weblogs ]
Ah, IE LOL :) I don't use IE much and the last time I was looking at DOM/IE tools I think it was this: http://www.debugbar.com/?langage=en (free for personal use) but you may want to double check other IE DOM tools (I can't believe Microsoft-centric companies don't have such a beast.)
Also, more as a note to anyone new to Firefox/DOM plug stuff: Those plug-ins (downloaded as .XPI files) can be simply renamed to .zip files and all the source code is viewable using a regular text editor.
Also, more as a note to anyone new to Firefox/DOM plug stuff: Those plug-ins (downloaded as .XPI files) can be simply renamed to .zip files and all the source code is viewable using a regular text editor.
[ Parent | Reply to this comment ]
[ Send Message | View sneex's Scratchpad | View Weblogs ]
For me, about 5 times since 2007, SSL in secure mix has always happened in the HTML rendered as sent by whatever server I was using (usually Apache2 via Debian) -- but I can forgive the web designers because they were trying neat-o tricks using PHP/Perl rendering [x]html/css stuff :P So it was easy for them to get confused. Oh, one time it was because a particular bank I was using had a proxied Ad sent mixed in with their log-in page LOL! But in the end it was a badly coded HTML page.
http://youve-reached-the.endoftheinternet.org/
[ Parent | Reply to this comment ]