ccforward
4.【译】关于HTTPS的7大谜团
关于HTTPS的7大谜团
谜团7：HTTPS从不缓存
人们经常抱怨HTTPS内容不能被浏览器缓存，因为从安全角度看（缓存）很敏感。实际上，HTTPS缓存可以像HTTP一样使用响应头来控制。
Fiddler的开发者Eric Lawrence在他的博客里做了简单的介绍：
令很多人吃惊的是，默认情况下，所有版本的IE浏览器都会缓存HTTPS内容直到缓存失效。例如，如果一个资源发送时带的请求头中包含了
Cache-Control:max-age=600，那么，IE会将该资源缓存10分钟。HTTPS的使用对于IE的资源缓存策略没有影响。（非IE浏览器对于HTTPS内容的默认缓存行为不一样，与用户使用的浏览器版本有关）。
值得注意的一个小点是Firefox默认只会将HTTPS资源缓存在内存中。如果想将缓存放到硬盘上，需要增加Cache-Control:Public响应头。
下面的截屏展示了Firefox磁盘缓存的内容，以及在HttpWatch中看到的
Cache-Control:Public响应头。
谜团6：SSL证书很贵
随便逛逛就会发现10美元一年的SSL证书或者和一个.com域名一年的注册成本差不多。
最便宜的证书和比较贵的公司验证的选项不在一个级别，但是能够在几乎所有主流浏览器上使用。
谜团5：每个HTTPS站点都需要有自己的公共IP地址
随着IPv4地址池的耗尽，需要考虑这个问题，而且确实一个IP地址只能有一个SSL证书。然而，如果有wildcard SSL证书（通配符SSL证书）大约125美元一年，一个IP地址可以按照喜好来配置多个子域名。例如：httpwatch的官网在同一个公共IP地址上就有https://www.httpwatch.com，http://www.httpwatch.com和https://store.httpwatch.com这几个域名。
在IIS7上有一个小技巧。在添加证书后，需要查找证书，然后在证书管理器中重命名，名字以*开头。如果不这样做的话就不能为一个HTTPS绑定编辑域名：
更新：UCC(Unified Coummunications Certificate，统一通信证书)支持单个SSL证书上有多个域名，可以用于需要为多个站点而不是子域名提供HTTPS支持的情况。
更新2：SNI（Server Name Indication——服务器名称指示）允许在相同IP地址的主机上有多个不同证书的不同域名。服务器端：Apache和Nginx支持该配置，IIS不行。客户端：原文有误，实际上与浏览器版本无关，而是与系统有关。例如维基百科上提到的，windows xp系统不支持SNI。
可以使用ssldb并且禁用web服务器上较旧加密方法来测试网站对HTTPS的支持。 HTTPS Everywhere工具也可以用来收集网站升级到HTTPS的详情。
谜团4：转移服务器或者运行多台服务器时需要购买新的证书
购买证书包括下列步骤：
- 在Web服务器上创建一个CSR（SSL Certificate Signing Request，SSL证书签名请求）；
- 使用CSR购买SSL证书；
- 通过完成CSR流程来安装SSL证书。
设计这些步骤是为了确保证书能够安全的传输到web服务器，避免有人通过劫持邮件或者下载第2步包含的证书来使用证书。
因此不能在其他web服务器上使用第2步的文件。如果想要那样做，需要将证书以其他格式导出。
在IIS中可以创建一个有密码保护而且可传输的.pfx文件：
然后可以通过密码来将该文件导入其他web服务器。
谜团3：HTTPS太慢
使用HTTPS并不能为网站加速（实际上可以——看下面的内容），但是通过遵守HTTPS Performance Tuning——HTTPS性能调整博客中的建议可以避免大部分开销。
通过压缩文本内容可以减少用于加密数据的CPU资源，而且在使用现代CPU的服务器上，这些开销也不是特别显著。
为了保证HTTPS连接的安全，在TCP连接时会有额外的延迟（round-trips），发送和接受也要带上一些附加数据。不过，可以在httpwatch中看到在HTTPS连接建立以后这样的开销很小：
首次访问HTTPS站点比HTTP要慢，因为建立SSL连接需要的时间更长。下面是张使用httpwatch看到得一个HTTP站点页面加载的时间图：
以及使用HTTPS访问相同站点的时间图：
更长的连接时间使得首次页面加载速度慢了约10%。然而，浏览器建立了活跃的keep-alive HTTPS连接后，后续的页面刷新和HTTP差别非常小。
首先，使用HTTP刷新页面：
然后使用HTTPS刷新：
有可能一些用户会发现HTTPS版本的站点比HTTP站点快。如果用户开启了公司代理，在代理拦截、检查以及记录Web流量的情况下会发生这种情况。HTTPS连接通常会通过代理使用简单的TCP连接来发送，因为HTTPS流量不能被拦截。这样的安全绕过（bypassing）可以提升性能。
更新：F5的一篇博客文章挑战了认为SSL的CPU开销不再显著的说法，但是其中的大部分论据都在这篇文章被反驳了。
谜团2：使用HTTPS，任何内容都可以放到Cookie和查询串中
虽然黑客不能劫持用户在网络上的HTTP流量，或者直接读取他们的cookie和查询字符串(query string)，仍然需要确保cookie和query string不能被轻易地预测到。
例如，有一家英国的银行网站使用数值计数器作为会话的ID值：
黑客可以使用一个假账号来查看cookie的使用，并且找到其最近的值。然后尝试在浏览器中修改cookie值来劫持临近ID的会话。
查询字符串也可以通过HTTP来保护，但是仍然有其他方式来泄露它们的值。细节请查看这篇文章How Secure Are Query Strings Over HTTPS——HTTPS查询字符串有多安全。
谜团1：我的站点只有登陆需要HTTPS
这是比较普遍的观点。它所基于的理论是HTTPS会在登陆时保护用户的密码，但是登陆完成后就不再需要HTTPS了。
Firefox Firesheep扩展可以展示这种观点的谬误，以及劫持Twitter和Facebook的用户会话有多么轻松。
咖啡店的免费公共WiFi是理想的会话劫持环境，因为：
- WiFi网络一般没有加密，因此可以轻松监测所有流量。
- WiFi网络可能使用了从单个IP地址的NAT来连接到互联网。这意味着被劫持的会话看上去仍然来自原始登陆的网站地址。
有许多关于这种安全方法的实例。例如，默认Twitter的登陆页面使用了HTTPS，但是在建立会话cookie后，又切换回了HTTP：
HttpWatch会警告这些cookie是在HTTPS上建立的，但是没有使用secure标记来防止它们在HTTP上使用。
咖啡店里的人可以使用Firesheep来劫持twitter会话cookie，然后代替你发推特消息。
参考资料
英文原文--Top 7 Mythis about HTTPS SNI--Server Name Indication RFC4366--TLS Extension
SNI在概念上类似HTTP1.1的虚拟主机，它指定了在TLS握手过程开始时客户端尝试连接的主机名。SNI是一种TLS协议扩展。SNI需要客户端的支持。 SSL握手延迟以及HTTPS优化——SSL Handshaek Latency and HTTPS Optimizations
相关讨论
- SSL开销太大，不如使用混杂（
hybrid）模式
这篇文章介绍不通过全站HTTPS来增强安全的方法，即使用非加密的Cookie加上加密Cookie来实现安全。
文章标题为
slaying firesheep（屠杀firesheep），实际上firesheep可以通过修改安全脚本来防止重定向，从而使得文章所提到的安全建议失效。而且实际上这篇文章提到的建议专业术语称为security through obscurity，是最不被推崇的安全建议之一。因为其本质只是增加信息收集的难度，系统仍然是有弱点的（vulnerable）的。
- SSL开销太大
支持太大——Dispelling the new ssl myth 支持不大——Still Inexpensive
总结一下，认为开销大的原因：
- 证书管理开销
- 证书/秘钥安全性
- 失去了可见性/安全性/灵活性
针锋相对的这篇文章写得很漂亮，而且一阵见血指出了，F5其实是家卖SSL硬件的公司，它们的文章其实是在搞市场营销。呵呵。
