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.
我正在开发一个我没有完全设置的网络服务器,我正在试图弄清楚网页的哪些部分是加密的,哪些不是。 Firefox告诉我页面的某些部分是加密的,但我想知道具体是加密的。
7 个解决方案
#1
9
For each element loaded in page, check their scheme:
对于页面中加载的每个元素,请检查其方案:
- it starts with HTTPS: it is encrypted.
- it starts with HTTP: it's not encrypted.
它以HTTPS开头:它是加密的。
它以HTTP开头:它没有加密。
(you can see a relatively complete list on firefox by right-clicking on the page and selecting "View Page Info" then the "medias"tab.
(通过右键单击页面并选择“查看页面信息”,然后选择“媒体”选项卡,您可以在Firefox上看到相对完整的列表。
EDIT: FF only shows images and multimedia elements. They are also javascript files & CSS ones which have to be checked. And Firebug is a good tool to find what you need.
编辑:FF仅显示图像和多媒体元素。它们也是必须要检查的javascript文件和CSS。 Firebug是一个很好的工具,可以找到你需要的东西。
#2
11
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.
如果使用https://链接到外部站点的iresources,然后外部站点将自己的HTTP重定向到非SSL页面,则会破坏页面上的SSL锁定。
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.
但是,当您在媒体选项卡中查看源或信息时,您将看不到任何http://,因为您的页面仅使用https://链接正确。
As suggested above, the firebug Net tab will show this and any other problems. Follow these steps:
如上所述,firebug Net选项卡将显示此问题和任何其他问题。跟着这些步骤:
- Install Firebug add-on into firefox if you don't already have it, and restart FF when prompted.
- Open Firebug (F12 or the little insect menu to the right of your search box).
- In firebug, choose the "Net" tab. Hit "Enable" (text link) to turn it on
- 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.
- 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://.
- 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.
- 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.
- 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.
- 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).
如果您还没有Firebug附加组件,请将其安装到Firefox中,并在出现提示时重新启动FF。
打开Firebug(F12或搜索框右侧的小昆虫菜单)。
在firebug中,选择“Net”选项卡。点击“启用”(文本链接)将其打开
通过按Ctrl-Shift-R(或OSX中的Command-shift-R)来刷新问题页面而不使用缓存。您将看到firefox中的“Net”选项卡填满了每个HTTP请求的列表。
页面加载完成后,将鼠标悬停在网络选项卡中显示的每个HTTP请求的左列上。将出现一个工具提示,显示实际使用的链接。很容易发现任何http://而不是https://。
如果您的任何链接导致HTTP重定向,您将在HTTP状态列中看到“301 Moved Permanently”,另一个HTTP请求将在新位置的下方。如果问题是由外部重定向引起的,那就是证据的位置 - 新位置的请求将是HTTP。
如果您的问题是由外部网站的重定向引起的,您会看到“301永久移动”状态代码,指出将其指向新位置的请求。
使用左侧的加号对这些301重定位中的任何一个进行扩展,并查看响应标头以查看发生了什么。 Location:标题将告诉您外部服务器请求浏览器使用的新位置。
在重定向中记下此信息,然后向相关外部网站发送友好礼貌的电子邮件,并要求他们为您删除https:// - > http://重定向。解释它是如何破坏您网站上的SSL的,并且理想情况下包括指向可能损坏的页面的链接,以便他们可以自己查看错误。 (这会比你刚刚告诉他们有关错误的动作更快)。
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://.
以下是来自Firebug的外部重定向问题的示例输出。在我的情况下,我发现一个页面调用https://数据源正在将外部服务器重写的提要转换为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:
我已将我的网站重命名为“mysite.example.com”,将外部网站重命名为“external.example.com”,但除此之外保留了heders完好无损。请求标头显示在响应标头下方的底部。请注意,我正在从我的网站请求https://链接,但是被重定向到http://链接,这就是我的SSL锁定:
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).
因此,需要注意的重要一点是,在响应标题(上面)中,您看到的是一个位置:以http://开头,而不是https://。在确定锁是否有效时,您的浏览器会考虑到这一点,并仅报告部分加密的内容! (这实际上是一个重要的浏览器安全功能,可以提醒用户注意潜在的XSRF和/或网络钓鱼攻击)。
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.
在这种情况下,解决方案不是您可以在您的网站上修复的解决方案 - 您必须要求外部网站停止重定向到http。为了方便起见,这通常是在他们身边完成的,没有意识到这种后果,并且写得很好的礼貌电子邮件可以解决它。
#3
2
Some elements may not list http or https, in this case whichever was used for the page will be used for these items, i.e. if the page request is under SSL then these images will come encrypted while if the page request is not under SSL then these will come unencrypted. Fiddler in Internet Explorer may also be useful in tracking down some of this information.
某些元素可能不会列出http或https,在这种情况下,用于页面的任何一个都将用于这些项目,即如果页面请求是在SSL下,那么这些图像将加密,而如果页面请求不在SSL下,那么这些将是未加密的。 Internet Explorer中的Fiddler也可用于跟踪部分此类信息。
#4
1
Sniff the packets - that'll tell you really quick. WireShark is a good program for such a task.
嗅闻数据包 - 这会很快告诉你。 WireShark是完成此类任务的好程序。
#5
1
Can firebug do this?
萤火虫可以这样做吗?
Edit: Looks like firebug will also do this using the "Net" panel, which also gives you some other interesting statistics.
编辑:看起来firebug也会使用“Net”面板执行此操作,该面板还为您提供了一些其他有趣的统计信息。
#6
0
The best tool I have found for detecting http links on a https connection is Fiddler. It's also great for many other troubleshooting efforts.
我发现用于检测https连接上的http链接的最佳工具是Fiddler。它对许多其他故障排除工作也很有用。
#7
0
I use FF plugin HTTPFox for this.
我为此使用FF插件HTTPFox。
#1
9
For each element loaded in page, check their scheme:
对于页面中加载的每个元素,请检查其方案:
- it starts with HTTPS: it is encrypted.
- it starts with HTTP: it's not encrypted.
它以HTTPS开头:它是加密的。
它以HTTP开头:它没有加密。
(you can see a relatively complete list on firefox by right-clicking on the page and selecting "View Page Info" then the "medias"tab.
(通过右键单击页面并选择“查看页面信息”,然后选择“媒体”选项卡,您可以在Firefox上看到相对完整的列表。
EDIT: FF only shows images and multimedia elements. They are also javascript files & CSS ones which have to be checked. And Firebug is a good tool to find what you need.
编辑:FF仅显示图像和多媒体元素。它们也是必须要检查的javascript文件和CSS。 Firebug是一个很好的工具,可以找到你需要的东西。
#2
11
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.
如果使用https://链接到外部站点的iresources,然后外部站点将自己的HTTP重定向到非SSL页面,则会破坏页面上的SSL锁定。
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.
但是,当您在媒体选项卡中查看源或信息时,您将看不到任何http://,因为您的页面仅使用https://链接正确。
As suggested above, the firebug Net tab will show this and any other problems. Follow these steps:
如上所述,firebug Net选项卡将显示此问题和任何其他问题。跟着这些步骤:
- Install Firebug add-on into firefox if you don't already have it, and restart FF when prompted.
- Open Firebug (F12 or the little insect menu to the right of your search box).
- In firebug, choose the "Net" tab. Hit "Enable" (text link) to turn it on
- 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.
- 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://.
- 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.
- 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.
- 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.
- 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).
如果您还没有Firebug附加组件,请将其安装到Firefox中,并在出现提示时重新启动FF。
打开Firebug(F12或搜索框右侧的小昆虫菜单)。
在firebug中,选择“Net”选项卡。点击“启用”(文本链接)将其打开
通过按Ctrl-Shift-R(或OSX中的Command-shift-R)来刷新问题页面而不使用缓存。您将看到firefox中的“Net”选项卡填满了每个HTTP请求的列表。
页面加载完成后,将鼠标悬停在网络选项卡中显示的每个HTTP请求的左列上。将出现一个工具提示,显示实际使用的链接。很容易发现任何http://而不是https://。
如果您的任何链接导致HTTP重定向,您将在HTTP状态列中看到“301 Moved Permanently”,另一个HTTP请求将在新位置的下方。如果问题是由外部重定向引起的,那就是证据的位置 - 新位置的请求将是HTTP。
如果您的问题是由外部网站的重定向引起的,您会看到“301永久移动”状态代码,指出将其指向新位置的请求。
使用左侧的加号对这些301重定位中的任何一个进行扩展,并查看响应标头以查看发生了什么。 Location:标题将告诉您外部服务器请求浏览器使用的新位置。
在重定向中记下此信息,然后向相关外部网站发送友好礼貌的电子邮件,并要求他们为您删除https:// - > http://重定向。解释它是如何破坏您网站上的SSL的,并且理想情况下包括指向可能损坏的页面的链接,以便他们可以自己查看错误。 (这会比你刚刚告诉他们有关错误的动作更快)。
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://.
以下是来自Firebug的外部重定向问题的示例输出。在我的情况下,我发现一个页面调用https://数据源正在将外部服务器重写的提要转换为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:
我已将我的网站重命名为“mysite.example.com”,将外部网站重命名为“external.example.com”,但除此之外保留了heders完好无损。请求标头显示在响应标头下方的底部。请注意,我正在从我的网站请求https://链接,但是被重定向到http://链接,这就是我的SSL锁定:
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).
因此,需要注意的重要一点是,在响应标题(上面)中,您看到的是一个位置:以http://开头,而不是https://。在确定锁是否有效时,您的浏览器会考虑到这一点,并仅报告部分加密的内容! (这实际上是一个重要的浏览器安全功能,可以提醒用户注意潜在的XSRF和/或网络钓鱼攻击)。
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.
在这种情况下,解决方案不是您可以在您的网站上修复的解决方案 - 您必须要求外部网站停止重定向到http。为了方便起见,这通常是在他们身边完成的,没有意识到这种后果,并且写得很好的礼貌电子邮件可以解决它。
#3
2
Some elements may not list http or https, in this case whichever was used for the page will be used for these items, i.e. if the page request is under SSL then these images will come encrypted while if the page request is not under SSL then these will come unencrypted. Fiddler in Internet Explorer may also be useful in tracking down some of this information.
某些元素可能不会列出http或https,在这种情况下,用于页面的任何一个都将用于这些项目,即如果页面请求是在SSL下,那么这些图像将加密,而如果页面请求不在SSL下,那么这些将是未加密的。 Internet Explorer中的Fiddler也可用于跟踪部分此类信息。
#4
1
Sniff the packets - that'll tell you really quick. WireShark is a good program for such a task.
嗅闻数据包 - 这会很快告诉你。 WireShark是完成此类任务的好程序。
#5
1
Can firebug do this?
萤火虫可以这样做吗?
Edit: Looks like firebug will also do this using the "Net" panel, which also gives you some other interesting statistics.
编辑:看起来firebug也会使用“Net”面板执行此操作,该面板还为您提供了一些其他有趣的统计信息。
#6
0
The best tool I have found for detecting http links on a https connection is Fiddler. It's also great for many other troubleshooting efforts.
我发现用于检测https连接上的http链接的最佳工具是Fiddler。它对许多其他故障排除工作也很有用。
#7
0
I use FF plugin HTTPFox for this.
我为此使用FF插件HTTPFox。