开发网页的时候，往往需要观察HTTP通信。
我使用的工具主要有两个，在Firefox中是Firebug，在IE中是Fiddler。但是，一直听别人说，付费软件HttpWatch是这方面最好的工具。
前几天，HttpWatch的官方网志刊登了一篇好文章，澄清了一些HTTPS协议容易产生误解的地方。学习之后，我增长了不少网页加密通信的知识。
我觉得这篇文章很实用，值得留作参考，就翻译了出来。
==============================================
HTTPS的七个误解
原文网址：http://blog.httpwatch.com/2011/01/28/top-7-myths-about-https/
译者：阮一峰
误解七：HTTPS无法缓存
许多人以为，出于安全考虑，浏览器不会在本地保存HTTPS缓存。实际上，只要在HTTP头中使用特定命令，HTTPS是可以缓存的。
微软的IE项目经理Eric Lawrence写道：
"说来也许令人震惊，只要HTTP头允许这样做，所有版本的IE都缓存HTTPS内容。比如，如果头命令是Cache-Control: max-age=600，那么这个网页就将被IE缓存10分钟。IE的缓存策略，与是否使用HTTPS协议无关。（其他浏览器在这方面的行为不一致，取决于你使用的版本，所以这里不加以讨论。）"
Firefox默认只在内存中缓存HTTPS。但是，只要头命令中有Cache-Control: Public，缓存就会被写到硬盘上。下面的图片显示，Firefox的硬盘缓存中有HTTPS内容，头命令正是Cache-Control:Public。
误解六：SSL证书很贵
如果你在网上搜一下，就会发现很多便宜的SSL证书，大概10美元一年，这和一个.com域名的年费差不多。而且事实上，还能找到免费的SSL证书。
在效力上，便宜的证书当然会比大机构颁发的证书差一点，但是几乎所有的主流浏览器都接受这些证书。
误解五：HTTPS站点必须有独享的IP地址
由于IPv4将要分配完毕，所以很多人关心这个问题。每个IP地址只能安装一张SSL证书，这是毫无疑问的。但是，如果你使用子域名通配符SSL证书（wildcard SSL certificate，价格大约是每年125美元），就能在一个IP地址上部署多个HTTPS子域名。比如，https://www.httpwatch.com和https://store.httpwatch.com，就共享同一个IP地址。
另外，UCC（统一通信证书，Unified Communications Certificate）支持一张证书同时匹配多个站点，可以是完全不同的域名。SNI（服务器名称指示，Server Name Indication）允许一个IP地址上多个域名安装多张证书。服务器端，Apache和Nginx支持该技术，IIS不支持；客户端，IE 7+、Firefox 2.0+、Chrome 6+、Safari 2.1+和Opera 8.0+支持。
误解四：转移服务器时要购买新证书
部署SSL证书，需要这样几步：
1. 在你的服务器上，生成一个CSR文件（SSL证书请求文件，SSL Certificate Signing Request）。
2. 使用CSR文件，购买SSL证书。
3. 安装SSL证书。
这些步骤都经过精心设计，保证传输的安全，防止有人截取或非法获得证书。结果就是，你在第二步得到的证书不能用在另一台服务器上。如果你需要这样做，就必须以其他格式输出证书。
比如，IIS的做法是生成一个可以转移的.pfx文件，并加以密码保护。
将这个文件传入其他服务器，将可以继续使用原来的SSL证书了。
误解三：HTTPS太慢
使用HTTPS不会使你的网站变得更快（实际上有可能，请看下文），但是有一些技巧可以大大减少额外开销。
首先，只要压缩文本内容，就会降低解码耗用的CPU资源。不过，对于当代CPU来说，这点开销不值一提。
其次，建立HTTPS连接，要求额外的TCP往返，因此会新增一些发送和接收的字节。但是，从下图可以看到，新增的字节是很少的。
第一次打开网页的时候，HTTPS协议会比HTTP协议慢一点，这是因为读取和验证SSL证书的时间。下面是一张HTTP网页打开时间的瀑布图。
同一张网页使用HTTPS协议之后，打开时间变长了。
建立连接的部分，大约慢了10%。但是，一旦有效的HTTPS连接建立起来，再刷新网页，两种协议几乎没有区别。先是HTTP协议的刷新表现：
然后是HTTPS协议：
某些用户可能发现，HTTPS比HTTP更快一点。这会发生在一些大公司的内部局域网，因为通常情况下，公司的网关会截取并分析所有的网络通信。但是，当它遇到HTTPS连接时，它就只能直接放行，因为HTTPS无法被解读。正是因为少了这个解读的过程，所以HTTPS变得比较快。
误解二：有了HTTPS，Cookie和查询字符串就安全了
虽然无法直接从HTTPS数据中读取Cookie和查询字符串，但是你仍然需要使它们的值变得难以预测。
比如，曾经有一家英国银行，直接使用顺序排列的数值表示session id:
黑客可以先注册一个账户，找到这个cookie，看到这个值的表示方法。然后，改动cookie，从而劫持其他人的session id。至于查询字符串，也可以通过类似方式泄漏。
误解一：只有注册登录页，才需要HTTPS
这种想法很普遍。人们觉得，HTTPS可以保护用户的密码，此外就不需要了。Firefox浏览器新插件Firesheep，证明了这种想法是错的。我们可以看到，在Twitter和Facebook上，劫持其他人的session是非常容易的。
咖啡馆的免费WiFi，就是一个很理想的劫持环境，因为两个原因：
1. 这种WiFi通常不会加密，所以很容易监控所有流量。
2. WiFi通常使用NAT进行外网和内网的地址转换，所有内网客户端都共享一个外网地址。这意味着，被劫持的session，看上去很像来自原来的登录者。
以Twitter为例，它的登录页使用了HTTPS，但是登录以后，其他页面就变成了HTTP。这时，它的cookie里的session值就暴露了。
也就是说，这些cookie是在HTTPS环境下建立的，但是却在HTTP环境下传输。如果有人劫持到这些cookie，那他就能以你的身份在Twitter上发言了。
（完）
IVAN 说：
这么晚还更新，留个脚印，虽然不太懂
2011年2月13日 21:55 | # | 引用
笔端 说：
“在Twitter和Facebook上，劫持其他人的session是非常容易的..”
“它的cookie里的session值”
//这几处的session我觉得要翻译成“会话”比较合适，理由：
1.这里的session有“会话的”意思；
2.session在Web编程领域有另外一个意义，就是和cookie对应的，但存储在服务器端来保存用户的会话信息（cookie存在客户端），也就是说Web编程特指的“session”，用户是无法在客户端看到的，但是译文保留了这个词，没有翻译成“会话”，容易让联系到Web编程的“session”，引起歧义。
2011年2月13日 22:35 | # | 引用
Jasonwu 说：
不错的文章，让我对HTTPS又有了新的一些认识，不过一直有个疑问，用https的谷歌搜索一些敏感词的时候，还是会出现被重置的现象，我一直在思考，既然数据经过了加密，那GFW应该是没法过滤的，但为什么会被重置？
2011年2月13日 23:10 | # | 引用
Peter Cui 说：
URL加密不了。
2011年2月13日 23:35 | # | 引用
三桂 说：
又有新的认识,谢谢
2011年2月14日 00:56 | # | 引用
hourglass 说：
我无聊的时候喜欢看一些discuz!论坛的search query，也是一样的办法~
2011年2月14日 09:19 | # | 引用
Ruan YiFeng 说：
我感觉，这是因为特定屏蔽某些SSL证书。
session也要靠cookie实现的。
2011年2月14日 09:30 | # | 引用
Joshua 说：
想问一下为什么最近我用ssh上https的twitter不行呢，http没问题
2011年2月14日 09:53 | # | 引用
Bingo 说：
URL可以加密，因为请求URL本身就存储于HTTP协议包中，请求的服务器IP是没办法隐藏的。另外https的端口默认都是443。
所以GFW只要屏蔽google指定ip的443端口就可以了。
2011年2月14日 10:55 | # | 引用
Lewis 说：
HttpWatch 不一定是最好的，我知道的 Http Analyzer 是一个独立的程序，可以监听任意进程的 HTTP 请求，任意端口，比 Http Watch 灵活多了。
Http Analyzer 使用 Dephi 开发，但其后续版本好像有问题，我只使用 3.3.2.168 版本（Crack后的）。
另外，开源的 Wireshark 也不错，只是需要安装 Http 插件才能更好地监听 Http 请求。
2011年2月14日 11:29 | # | 引用
muxueqz 说：
学习了，理清很多以前不理解的知识
2011年2月14日 16:27 | # | 引用
ssdt 说：
屏蔽https请求的地址即可，不管你什么内容全部屏蔽
比如google group https就被封了
埃及把网断了（当然他是物理断开，用路由器在出口网关把所有加密地址列入黑名单，管你什么请求都可以屏蔽）
2011年2月15日 01:38 | # | 引用
yegle 说：
这是最基本的要求，当然是能加密URL的
2011年2月15日 13:27 | # | 引用
肖俊 说：
我对这方面了解很少，对网站安全也了解不多，我的博客是用的ZBLOG博客系统，每次都没人找到漏洞黑了，很囧啊。
2011年2月16日 11:50 | # | 引用
vvvvvv 说：
有点意思，httpwatch值得一试！！
2011年2月18日 12:04 | # | 引用
CLE 说：
还需要你自定义Hosts里的IP指向，功夫网现在会自动屏蔽谷歌的HTTPS链接，会导向错误的IP，这样即使加密也无法访问真正的谷歌搜索。你可以搜索一下 谷歌SSL重置
2011年2月19日 23:34 | # | 引用
吴鹏(AlphaWu) 说：
startssl.com的免费证书用着也不错,我用了1年多了，当然每次只能用1年，然后再重新申请就可以了。
2011年2月21日 21:59 | # | 引用
yaker 说：
https里url是加密的。我倒是很好奇gfw是怎么封禁特定证书的
2011年2月24日 02:35 | # | 引用
shalongbus 说：
2011年3月11日 08:27 | # | 引用
南 靖男 说：
肯定没，否则这个SSL证书体系都要做更改。
上面很多人已经说了，直接简单干掉443和IP而已。
2011年3月12日 22:42 | # | 引用
唏嘘一世 说：
我这里访问google的账户设置，经常是无法打开，也不提示连接重置，也不提示连接超时，只是一直加载，但什么都不显示。
很奇怪，是不是https在天朝无法使用？
2011年3月13日 19:51 | # | 引用
Vaporz 说：
读您的文章很舒服，连“搜一下”和“免费”这样的词都有超链接，说明您是站在了读者的角度在考虑，今天在亚马逊上买了您的《黑客与画家》，刚刚到手，正准备好好读一读，您的翻译一定差不了！获得知识的同时，就当是对您的一种支持~~
2012年5月11日 21:32 | # | 引用
北极 说：
最好的工具必然是wireshark
2012年7月 2日 15:46 | # | 引用
mrwind 说：
2013年2月 2日 07:37 | # | 引用
rideordie 说：
请问，如果父域名用了SSL，那么子域名也会走https吗？
具体环境：nginx，一个ip，其中两个端口走两个web app，两个端口都有SSL证书。
www.abc.com - x.x.x.x:443
www.kk.abc.com - x.x.x.x:9000
www.def.com - x.x.x.x:8080
这样可行吗
2013年2月 5日 23:17 | # | 引用
camelwoo 说：
我怎么觉得证书是对域名的，不是针对IP的呢。因为在申请证书时并没有IP相关的信息，只有域名。
2013年3月22日 11:29 | # | 引用
xx 说：
有Google私钥？呵呵 怎么可能
2013年5月10日 16:53 | # | 引用
techon 说：
不错，学习一下，另外推荐一篇翻译文章
HTTPS连接最初的若干毫秒
http://www.infoq.com/cn/articles/HTTPS-Connection-Jeff-Moser
2013年5月12日 00:52 | # | 引用
Nestle Caau 说：
我想问,如果我打开了一个http网址,需要填登录帐号密码,然后将这个帐号密码发送到指定的https,请问这样的请求安全吗?如果调转,也安全吗?
2013年7月30日 14:54 | # | 引用
滿月 说：
我比較在意的是SESSION算法原本就是在瀏覽器的httponly級別添加一個難以偽造的字串作為會話的標識，以解決HTTP只能面向請求響應的問題。所以上文說的SESSION不安全，一個是因為會話標識符未使用對應算法生成造成的，另一個倒是使用HTTP作傳輸時會被監聽到數據，從而從HEADER中找出會話標識符。個人不太懂網路概念，這種情況一般是出現在最近一層GATEWAY被劫持的情況下才會發現麼？還是說只有在一個VLAN裏就可以隨意支持其他機器的GATEWAY目的地？
2013年8月18日 07:47 | # | 引用
1 说：
5555555555555555
2013年10月 8日 10:51 | # | 引用
米饭 说：
为什么我找了一下午没有找到一个免费或偏便宜的SSL 证书，国内代理的更是高的离谱，大大能不能推荐个
2013年10月14日 20:52 | # | 引用
chaogu 说：
一般证书都是绑定域名的，很少绑定IP。
2013年11月 6日 00:16 | # | 引用
joker 说：
想知道https中cookie是如何表示的，找到了这篇文章，受益不少
2013年12月24日 16:52 | # | 引用
哈哈 说：
我们掌握着量子计算机。别说是2048位的密钥，就是2048^2048位的密钥，也不过是只消耗我们0.000001秒的时间就解开了，所以呢，我们不需要掌握google的私钥。哈哈。
2014年2月21日 18:28 | # | 引用
xx 说：
GFW 能截断 HTTPS 连接是因为，建立 HTTPS 连接的第一步是请求 Google 发证书过来：发一个 HTTP 数据包到 Google 的 IP 地址，里面写着 443 端口，方滨兴一看，封。
2014年6月16日 02:45 | # | 引用
紫金山下 说：
有没有办法在服务器上将https请求直接重定向为http，不进行SSL协商？
2014年11月 7日 17:29 | # | 引用
zhangdong 说：
看评论有人提到黑客与画家，几年前看过，特意又打开看了下，翻译者真的是博主大神！
最近关于https的知识又读了博主的好几篇文章，是大神啊，收藏了！
2016年8月26日 16:49 | # | 引用
wei 说：
最后一条不错，之前没有意识到
2016年10月 9日 02:11 | # | 引用
欣欣 说：
来看博主旧文
2017年6月11日 01:53 | # | 引用
ｓｗａｎｇ 说：
已经成功在 一个ｉｐ地址上 安装四个 证书， 关键是绑定端口的问题 有的 证书提供商 允许绑定端口
2017年10月25日 12:31 | # | 引用
G 说：
误解五： "每个IP地址只能安装一张SSL证书，这是毫无疑问的。"
sni是什么?
2018年4月20日 08:53 | # | 引用
zhiwenxuan 说：
误解六，“在效力上，便宜的证书当然会比大机构颁发的证书差一点”中的“效力”应该是打错了吧？正确应该是“效率”？
2018年11月23日 11:42 | # | 引用
minyang 说：
我想知道，怎么用客户端或者说js来让浏览器生成CSR已经需要匹配的Key????
2019年7月 3日 20:44 | # | 引用