How do I figure out which parts of a web page are encrypted and which aren't?

Question

I'm working on a webserver that I didn't totally set up and I'm trying to figure out which parts of a web page are being sent encrypted and which aren't. Firefox tells me that parts of the page are encrypted, but I want to know what, specifically, is encrypted.

Answer 1

The problem is not always bad links in your page.

If you link to iresources at an external site using https://, and then the external site does its own HTTP redirect to non-SSL pages, that will break the SSL lock on your page.

BUT, when you viewing the source or the information in the media tab, you will not see any http://, becuase your page is properly using only https:// links.

As suggested above, the firebug Net tab will show this and any other problems. Follow these steps:

1. Install Firebug add-on into firefox if you don't already have it, and restart FF when prompted.
2. Open Firebug (F12 or the little insect menu to the right of your search box).
3. In firebug, choose the "Net" tab. Hit "Enable" (text link) to turn it on
4. Refresh your problem page without using the cache by hitting Ctrl-Shift-R (or Command-shift-R in OSX). You will see the "Net" tab in firefox fill up with a list of each HTTP request made.
5. Once the page is done loading, hover your mouse over the left colum of each HTTP request shown in the net tab. A tooltip will appear showing you the actual link used. it will be easy to spot any that are http:// instead of https://.
6. If any of your links resulted in an HTTP redirect, you will see "301 Moved Permanently" in the HTTP status column, and another HTTP request will be just below for the new location. If the problem was due to an external redirect, that's where the evidence will be - the new location's request will be HTTP.
7. If your problem is due to redirections from an external site, you will see "301 Moved permanently" status codes for the requests that point them to their new location.
8. Exapnd any of those 301 relocations with the plus sign at the left, and review the response headers to see what is going on. the Location: header will tell you the new location the external server is requesting browsers use.
9. Make note of this info in the redirect, then send a friendly polite email to the external site in question and ask them to remove the https:// -> http:// redirects for you. Explain how it's breaking the SSL on your site, and ideally include a link to the page that is broken if possible, so that they can see the error for themselves. (this will spur faster action than if you just tell them about the error).

Here is sample output from Firebug for the the external redirect issue.. In my case I found a page calling https:// data feeds was getting the feeds rewritten by the external server to http://.

I've renamed my site to "mysite.example.com" and the external site to "external.example.com", but otherwise left the heders intact. The request headers are shown at the bottom, below the response headers. Note that I"m requesting an https:// link from my site, but getting redirected to an http:// link, which is what was breaking my SSL lock:

Response Headers  
Server  nginx/0.8.54
Date    Fri, 07 Oct 2011 17:35:16 GMT
Content-Type    text/html
Content-Length  185
Connection  keep-alive
Location    http://external.example.com/embed/?key=t6Qu2&width=940&height=300&interval=week&baseAtZero=false

Request Headers
Host    external.example.com
User-Agent  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20100101 Firefox/7.0.1
Accept  */*
Accept-Language en-gb,en;q=0.5
Accept-Encoding gzip, deflate
Accept-Charset  ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection  keep-alive
Referer https://mysite.example.com/real-time-data
Cookie  JSESSIONID=B33FF1C1F1B732E7F05A547A9CB76ED3
Pragma  no-cache
Cache-Control   no-cache

So, the important thing to note is that in the Response Headers (above), you are seeing a Location: that starts with http://, not https://. Your browser will take this into account when figuring out if the lock is valid or not, and report only partially encrypted content! (This is actually an important browser security feature to alert users to a potential XSRF and/or phishing attacks).

The solution in this case is not something you can fix on your site - you have to ask the external site to stop their redirect to http. Often this was done on their side for convenience, without realizing this consequence, and a well written, polite email can get it fixed.