百度于 2015 年上线了全站 HTTPS 的安全搜索，默认会将 HTTP 请求跳转成 HTTPS。从今天开始，我们将会分享多篇系列文章，为大家重点介绍和解析百度的 HTTPS 最佳实践。
HTTPS 协议概述
HTTPS 可以认为是 HTTP+TLS。
HTTP 协议大家耳熟能详了，目前大部分 WEB 应用和网站都是使用 HTTP 协议传输的。
TLS 是传输层加密协议，它的前身是 SSL 协议，最早由 Netscape 公司于 1995 年发布，1999 年经过 IETF 讨论和规范后，改名为 TLS。如果没有特别说明，SSL 和 TLS 说的都是同一个协议。
HTTP 和 TLS 在协议层的位置以及 TLS 协议的组成如下图：
TLS 协议主要有五部分：应用数据层协议，握手协议，报警协议，加密消息确认协议，心跳协议。
TLS 协议本身又是由 Record 协议传输的，Record 协议的格式如上图最右所示。
目前常用的 HTTP 协议是 HTTP1.1，常用的 TLS 协议版本有如下几个：TLS1.3，TLS1.2,TLS1.1,TLS1.0 和 SSL3.0。其中 SSL3.0 由于 POODLE 攻击已经被证明不安全，但统计发现依然有不到 1% 的浏览器使用 SSL3.0。TLS1.0 也存在部分安全漏洞，比如 RC4 和 BEAST 攻击。过去由于主流 Web 浏览器和应用程序中的 TLS 实现都支持降级协商过程，导致即使服务器支持最新版本，攻击者也有机会利用较弱的协议实施攻击。因此到 2020 年，所有主流 Web 浏览器都将取消 TLS1.0 和 TLS1.1 的支持。
TLS1.2 暂时没有已知的安全漏洞，比较安全，同时有大量扩展提升速度和性能，当前被较为普遍的使用。
需要关注一点的就是 TLS1.3 是 TLS 协议一个非常重大的改革。不管是安全性还是用户访问速度都会有质的提升。TLS1.3 协议的最终版本（RFC8446）已于 2018 年 8 月 10 日发布，各主流浏览器也逐渐支持 TLS1.3。
同时 HTTP2 也于 2015 年 5 月正式定稿（RFC7540），这个由 SPDY 协议演化而来的协议相比 HTTP1.1 又是一个非常重大的变动，能够明显提升应用层数据的传输效率。
HTTPS 功能介绍
百度使用 HTTPS 协议主要是为了保护用户隐私，防止流量劫持。
HTTP 本身是明文传输的，没有经过任何安全处理。例如用户在百度搜索了一个关键字，比如“苹果手机”，中间者完全能够查看到这个信息，并且有可能打电话过来骚扰用户。也有一些用户投诉使用百度时，发现首页或者结果页面浮了一个很长很大的广告，这也肯定是中间者往页面插的广告内容。如果劫持技术比较低劣的话，用户甚至无法访问百度。
这里提到的中间者主要指一些网络节点，是用户数据在浏览器和百度服务器中间传输必须要经过的节点。比如 WIFI 热点，路由器，防火墙，反向代理，缓存服务器等。
在 HTTP 协议下，中间者可以随意嗅探用户搜索内容，窃取隐私甚至篡改网页。不过 HTTPS 是这些劫持行为的克星，能够完全有效地防御。
总体来说，HTTPS 协议提供了三个强大的功能来对抗上述的劫持行为：
1. 内容加密。浏览器到百度服务器的内容都是以加密形式传输，中间者无法直接查看原始内容；
2. 身份认证。保证用户访问的是百度服务，即使被 DNS 劫持到了第三方站点，也会提醒用户没有访问百度服务，有可能被劫持；
3. 数据完整性。防止内容被第三方冒充或者篡改。
那 HTTPS 是如何做到上述三点的呢？下面从原理角度介绍一下。
HTTPS 原理介绍
1 内容加密
加密算法一般分为两种，对称加密和非对称加密。所谓对称加密（也叫密钥加密）就是指加密和解密使用的是相同的密钥。而非对称加密（也叫公钥加密）就是指加密和解密使用了不同的密钥。
对称内容加密强度非常高，一般破解不了。但存在一个很大的问题就是无法安全地生成和保管密钥。假如客户端软件和服务器之间每次会话都使用固定的、相同的密钥加密和解密，肯定存在很大的安全隐患。如果有人从客户端获取到了对称密钥，整个内容就不存在安全性了，而且管理海量的客户端密钥也是一件很复杂的事情。
非对称加密主要用于密钥交换（也叫密钥协商），能够很好地解决这个问题。浏览器和服务器每次新建会话时都使用非对称密钥交换算法协商出对称密钥，使用这些对称密钥完成应用数据的加解密和验证，整个会话过程中的密钥只在内存中生成和保存，而且每个会话的对称密钥都不相同（除非会话复用），中间者无法窃取。
非对称密钥交换很安全，但同时也是 HTTPS 性能和速度严重降低的“罪魁祸首”。想要知道 HTTPS 为什么影响速度，为什么消耗资源，就一定要理解非对称密钥交换的整个过程。
下面重点介绍一下非对称密钥交换的数学原理及在 TLS 握手过程中的应用。
2 非对称秘钥交换
在非对称密钥交换算法出现以前，对称加密一个很大的问题就是不知道如何安全生成和保管密钥。非对称密钥交换过程主要就是为了解决这个问题，使得对称密钥的生成和使用更加安全。
密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。
常见的密钥交换算法有 RSA，ECDHE，DH，DHE 等算法。它们的特性如下：
1.RSA：算法实现简单，诞生于 1977 年，历史悠久，经过了长时间的破解测试，安全性高。缺点就是需要比较大的素数（目前常用的是 2048 位）来保证安全强度，很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
2.DH：Diffie-Hellman 密钥交换算法，诞生时间比较早（1977 年），但是 1999 年才公开。缺点是比较消耗 CPU 性能。
3.ECDHE：使用椭圆曲线（ECC）的 DH 算法，优点是能用较小的素数（256 位）实现 RSA 相同的安全等级。缺点是算法实现复杂，用于密钥交换的历史不长，没有经过长时间的安全攻击测试。
4.ECDH：不支持 PFS，安全性低，同时无法实现 False Start。
5.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 在密钥交换过程中的应用，敬请期待。
本文转载自公众号 AIOps 智能运维（ID：AI_Ops）。
原文链接：
评论