PS：Https学习，业务接口更换。

正文

什么是HTTPS？

HTTPS的诞生源于HTTP协议传输隐私数据的不安全，为了保证这些隐私数据能加密传输，于是，网景公司设计了SSL协议用于对HTTP协议传输的数据进行加密，从而诞生了HTTPS。SSL最后的一个版本是3.0，现在我们实际使用的HTTPS都是用的TLS协议，今后TLS将会继承SSL优良血统继续为我们进行加密服务。

为什么要调整业务线为HTTPS

答案是来源于用户对安全，隐私，可用性的需求。对于使用百度众产品的庞大用户群，我们的同事每天都需要处理很多用户反馈：

• 页面出现白页or奇怪的东西。
• 返回了403的页面，但是webserver并不是我们的服务器。
• 搜索总是跳错误页/搜索什么都是 “{wd}”这个字段/想翻页却回到上一页
• 搜索url带了小尾巴,页面总要闪几次
• 页面弹窗广告

• 搜索个汽车就有人给我打电话推销4s店和保险什么的

  各种千奇百怪的情况，查来查去，很大一部分原因是有运营商/劫持商在数据的传输过程中（WIFI热点、路由器、防火墙、反向代理、缓存服务器等）修改百度的页面内容，窃听用户的搜索内容。直到我厂顺利完成全站（baidu.com域名下所有链接和主要功能都是https，而不是只有登录，支付等环节https了）HTTPS的部署后，这一情况才得以好转。总体来说，HTTPS协议提供了三个强大的功能来对抗上述的劫持行为：

• 1.内容加密：浏览器到产品线服务器的内容都是以加密形式传输，中间者无法直接查看原始内容。

• 2.身份认证：保证用户访问的是产品线服务，即使被DNS劫持到了第三方站点，也会提醒用户没有访问对应产品线服务，有可能被劫持。
• 3.数据完整性：防止内容被第三方冒充或者篡改。

HTTPS原理

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

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

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

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

对称内容加密

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

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

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

非对称内容加密

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

密钥交换算法本身非常复杂，密钥交换过程涉及到随机数生成，模指数运算，空白补齐，加密，签名等操作。
常见的密钥交换算法有 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 协议和功能的关键。

身份认证

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

• End entity：终端实体，可以是一个终端硬件或者网站。
• CA：证书签发机构。
• RA：证书注册及审核机构。比如审查申请网站或者公司的真实性。
• CRL issuer：负责证书撤销列表的发布和维护。
• Repository：负责数字证书及 CRL 内容存储和分发。
• 申请一个受信任的数字证书通常有如下流程：
  • 1.终端实体生成公私钥和证书请求。
  • 2.RA 检查实体的合法性。如果个人或者小网站，这一步不是必须的。
  • 3.CA 签发证书，发送给申请者。
  • 4.证书更新到 repository，终端后续从 repository 更新证书，查询证书状态等。

数字证书有两个作用：

• 1.身份授权。确保浏览器访问的网站是经过 CA 验证的可信任的网站。
• 2.分发公钥。每个数字证书都包含了注册者生成的公钥。在 SSL 握手时会通过 certif icate 消息传输给客户端。比如前文提到的 RSA 证书公钥加密及 ECDHE 的签名都是使用的这个公钥。

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

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

• 1.数字签名的签发。首先是使用哈希函数对待签名内容进行安全哈希，生成消息摘要，然后使用 CA 自己的私钥对消息摘要进行加密。
• 2.数字签名的校验。使用 CA 的公钥解密签名，然后使用相同的签名函数对待签名证书内容进行签名并和服务端数字签名里的签名内容进行比较，如果相同就认为校验成功。

HTTPS使用成本

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

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

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

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

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

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

参考文献

• HTTPS构建大型网站