HTTPS的七个误解(译文)

作者: 阮一峰

日期: 2011年2月13日

开发网页的时候,往往需要观察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上发言了。

(完)

珠峰培训

stuQ

留言(40条)

这么晚还更新,留个脚印,虽然不太懂

“在Twitter和Facebook上,劫持其他人的session是非常容易的..”
“它的cookie里的session值”

//这几处的session我觉得要翻译成“会话”比较合适,理由:
1.这里的session有“会话的”意思;
2.session在Web编程领域有另外一个意义,就是和cookie对应的,但存储在服务器端来保存用户的会话信息(cookie存在客户端),也就是说Web编程特指的“session”,用户是无法在客户端看到的,但是译文保留了这个词,没有翻译成“会话”,容易让联系到Web编程的“session”,引起歧义。

不错的文章,让我对HTTPS又有了新的一些认识,不过一直有个疑问,用https的谷歌搜索一些敏感词的时候,还是会出现被重置的现象,我一直在思考,既然数据经过了加密,那GFW应该是没法过滤的,但为什么会被重置?

引用Jasonwu的发言:

用https的谷歌搜索一些敏感词的时候,还是会出现被重置的现象,我一直在思考,既然数据经过了加密,那GFW应该是没法过滤的,但为什么会被重置?


URL加密不了。

又有新的认识,谢谢

黑客可以先注册一个账户,找到这个cookie,看到这个值的表示方法。然后,改动cookie,从而劫持其他人的session id。至于查询字符串,也可以通过类似方式泄漏。

我无聊的时候喜欢看一些discuz!论坛的search query,也是一样的办法~

引用Jasonwu的发言:

既然数据经过了加密,那GFW应该是没法过滤的,但为什么会被重置?

我感觉,这是因为特定屏蔽某些SSL证书。

引用笔端的发言:

2.session在Web编程领域有另外一个意义,就是和cookie对应的,但存储在服务器端来保存用户的会话信息(cookie存在客户端),也就是说Web编程特指的“session”,用户是无法在客户端看到的,但是译文保留了这个词,没有翻译成“会话”,容易让联系到Web编程的“session”,引起歧义。

session也要靠cookie实现的。

想问一下为什么最近我用ssh上https的twitter不行呢,http没问题

引用Peter Cui的发言:

URL加密不了。

URL可以加密,因为请求URL本身就存储于HTTP协议包中,请求的服务器IP是没办法隐藏的。另外https的端口默认都是443。

所以GFW只要屏蔽google指定ip的443端口就可以了。

HttpWatch 不一定是最好的,我知道的 Http Analyzer 是一个独立的程序,可以监听任意进程的 HTTP 请求,任意端口,比 Http Watch 灵活多了。

Http Analyzer 使用 Dephi 开发,但其后续版本好像有问题,我只使用 3.3.2.168 版本(Crack后的)。

另外,开源的 Wireshark 也不错,只是需要安装 Http 插件才能更好地监听 Http 请求。

学习了,理清很多以前不理解的知识

引用Peter Cui的发言:

URL加密不了。

屏蔽https请求的地址即可,不管你什么内容全部屏蔽

比如google group https就被封了

埃及把网断了(当然他是物理断开,用路由器在出口网关把所有加密地址列入黑名单,管你什么请求都可以屏蔽)

引用Peter Cui的发言:


URL加密不了。

这是最基本的要求,当然是能加密URL的

我对这方面了解很少,对网站安全也了解不多,我的博客是用的ZBLOG博客系统,每次都没人找到漏洞黑了,很囧啊。

有点意思,httpwatch值得一试!!

引用Peter Cui的发言:

URL加密不了。

还需要你自定义Hosts里的IP指向,功夫网现在会自动屏蔽谷歌的HTTPS链接,会导向错误的IP,这样即使加密也无法访问真正的谷歌搜索。你可以搜索一下 谷歌SSL重置

startssl.com的免费证书用着也不错,我用了1年多了,当然每次只能用1年,然后再重新申请就可以了。

引用Peter Cui的发言:

URL加密不了。

https里url是加密的。我倒是很好奇gfw是怎么封禁特定证书的

引用yaker的发言:

https里url是加密的。我倒是很好奇gfw是怎么封禁特定证书的

GFW手里应该有Google证书的私钥

引用shalongbus的发言:


GFW手里应该有Google证书的私钥


肯定没,否则这个SSL证书体系都要做更改。
上面很多人已经说了,直接简单干掉443和IP而已。

我这里访问google的账户设置,经常是无法打开,也不提示连接重置,也不提示连接超时,只是一直加载,但什么都不显示。
很奇怪,是不是https在天朝无法使用?

读您的文章很舒服,连“搜一下”和“免费”这样的词都有超链接,说明您是站在了读者的角度在考虑,今天在亚马逊上买了您的《黑客与画家》,刚刚到手,正准备好好读一读,您的翻译一定差不了!获得知识的同时,就当是对您的一种支持~~

最好的工具必然是wireshark

引用Joshua的发言:

想问一下为什么最近我用ssh上https的twitter不行呢,http没问题

如果这个SSH代理是别人的,有可能你遭到中间人攻击,https被强制用http代替。参见http://netsecurity.51cto.com/art/201211/365437.htm

请问,如果父域名用了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

这样可行吗

我怎么觉得证书是对域名的,不是针对IP的呢。因为在申请证书时并没有IP相关的信息,只有域名。

引用shalongbus的发言:


GFW手里应该有Google证书的私钥


有Google私钥?呵呵 怎么可能

不错,学习一下,另外推荐一篇翻译文章
HTTPS连接最初的若干毫秒
http://www.infoq.com/cn/articles/HTTPS-Connection-Jeff-Moser

我想问,如果我打开了一个http网址,需要填登录帐号密码,然后将这个帐号密码发送到指定的https,请问这样的请求安全吗?如果调转,也安全吗?

引用笔端的发言:

“在Twitter和Facebook上,劫持其他人的session是非常容易的..”
“它的cookie里的session值”

//这几处的session我觉得要翻译成“会话”比较合适,理由:
1.这里的session有“会话的”意思;
2.session在Web编程领域有另外一个意义,就是和cookie对应的,但存储在服务器端来保存用户的会话信息(cookie存在客户端),也就是说Web编程特指的“session”,用户是无法在客户端看到的,但是译文保留了这个词,没有翻译成“会话”,容易让联系到Web编程的“session”,引起歧义。

我比較在意的是SESSION算法原本就是在瀏覽器的httponly級別添加一個難以偽造的字串作為會話的標識,以解決HTTP只能面向請求響應的問題。所以上文說的SESSION不安全,一個是因為會話標識符未使用對應算法生成造成的,另一個倒是使用HTTP作傳輸時會被監聽到數據,從而從HEADER中找出會話標識符。個人不太懂網路概念,這種情況一般是出現在最近一層GATEWAY被劫持的情況下才會發現麼?還是說只有在一個VLAN裏就可以隨意支持其他機器的GATEWAY目的地?

5555555555555555

为什么我找了一下午没有找到一个免费或偏便宜的SSL 证书,国内代理的更是高的离谱,大大能不能推荐个

一般证书都是绑定域名的,很少绑定IP。

想知道https中cookie是如何表示的,找到了这篇文章,受益不少

我们掌握着量子计算机。别说是2048位的密钥,就是2048^2048位的密钥,也不过是只消耗我们0.000001秒的时间就解开了,所以呢,我们不需要掌握google的私钥。哈哈。

GFW 能截断 HTTPS 连接是因为,建立 HTTPS 连接的第一步是请求 Google 发证书过来:发一个 HTTP 数据包到 Google 的 IP 地址,里面写着 443 端口,方滨兴一看,封。

有没有办法在服务器上将https请求直接重定向为http,不进行SSL协商?

看评论有人提到黑客与画家,几年前看过,特意又打开看了下,翻译者真的是博主大神!
最近关于https的知识又读了博主的好几篇文章,是大神啊,收藏了!

最后一条不错,之前没有意识到

来看博主旧文

我要发表看法

«-必填

«-必填,不公开

«-我信任你,不会填写广告链接