什么是 HTTPS？有什么好处？为什么要使用 HTTPS？

Question

准确的说，HTTPS 不是一种协议，而是 HTTP 和 SSL 两种技术的组合，HTTP 本身所有的数据都是不加密的。

SSL ( Secure Socket Layer ) ，有时也称为 TLS ( Transport Layer Security ) ，是介于传输层和应用层的拓展层，可以将应用层数据加密后送入传输层。因此，使用了 SSL 传输的 HTTP 报文整体 都是被加密的。

真的安全吗？

为什么 HTTPS 比 HTTP 安全？下面来逐步分析其加密过程。

对称加密算法

对称加密算法：又称单钥加密，是指加密和解密使用相同的密钥。

因为 HTTP 所有数据都没有被加密，一旦中间人拦截到客户端请求，就可以看到具体的报文内容。如果客户端和服务端约定好同一密钥进行通信，则中间人无法破解。

但是服务端在通信之前不知道客户端的密钥， 如何安全地进行密钥传递 就是接下来要解决的问题。

非对称加密算法

非对称加密算法：又称双钥加密，包括公钥和私钥。公钥/私钥一一对应，有一把公钥就必然有一把与之对应的、独一无二的私钥，反之亦成立。公钥可以解开私钥加密的信息，反之亦成立；

借助非对称加密算法，服务端生成自己的密钥对，私钥自己保存，公钥对外公开。

这样的话，客户端就可以使用服务端返回的公钥来加密自己的密钥 ( 对称加密算法 ) 发送给服务端。即使中间人拦截，由于能解密公钥的私钥只有服务端才有，所以不能解密，保证了数据传输的安全。

那么问题来了，任何人都可以生成一对公钥/私钥，如果中间人在拦截请求时，把自己的公钥返回给客户端，客户端不能分辨出公钥的拥有者，只会按照之前的逻辑，使用接收到的公钥去加密自己的密钥来和服务端通信。

由于客户端使用中间人的公钥进行加密，所以中间人可以使用自己的私钥对客户端的请求进行解密，拿到请求的所有内容，然后再用服务端的公钥对请求进行加密并转发给服务端。整个过程“天衣无缝”，你几乎觉察不到中间人的存在，但是你的信息已经实实在在地被盗取了。

如果 客户端能辨别服务端公钥真伪 ，那么我们的信息又安全了。

数字证书

CA ( Certification Authority ) 是认证机构的国际通称，它是对数字证书的申请者发放、管理、取消数字证书的机构。CA 的作用是检查证书持有者身份的合法性，并签发证书，以防证书被伪造或篡改。

服务端将自己的公钥以及相关注册信息发送给 CA 申请认证，来获得数字证书，其中就包含了服务端的公钥。这样服务端就可以返回数字证书给客户端，因为通过了国际权威机构的认证，数字证书 将持有者的公钥和持有者的身份绑定起来 ，我们这次可以放心地使用公钥去和服务端进行通信了。

这时候中间人又出来搞事情了，我能伪造公钥，我难道不能伪造证书吗？证书没有加密，那我把证书中的公钥换成我自己 ( 中间人 ) 的不就得了？

可以，没毛病。不过中间者还是 SOMETIME NAIVE，CA 比他们不知道高到哪里去了，自然有应对 证书被篡改 的办法。

数字签名

CA 首先对证书进行 HASH，拿到摘要后使用 CA 的私钥对其加密，并把加密后的结果 ( 签名 ) 附在证书后面，这个过程就叫 数字签名 。客户端拿到证书后，会使用 CA 的公钥对签名解密，然后把证书 HASH 后跟解密后的结果进行对比，一致的话说明确实是 原厂出品 ，不一致的话说明 被纂改过 ，直接丢掉。

这次中间人发现没招了，即使修改了证书，由于没有 CA 的私钥，就不能对证书的 HASH 结果进行加密，这个 数字签名 改不了是不会有客户端认的。正打算放弃时，他忽然想到，CA 的公钥这里貌似可以做文章，如果能伪造 CA 的公钥，那么就可以伪造证书，从而摧毁这套 信任链 体系。

那客户端怎么保证 CA 的公钥 ( 或者说用于验证证书签名的公钥 ) 的可靠性？

证书链

其实，一个证书的公钥是放在他上一级证书，只要能保证他上一级证书可靠，我们就能保证本级证书可靠。

以此类推，每级证书都是使用上一级证书的非对称密钥进行签名和验证的，我们称这一系列证书的关系为 证书链 。而在证书链的最顶层的是 根证书 ，那根证书的可靠性是由谁保证的？

根证书是由他自己进行签名和验证的，我们又称他为 自签名根证书 。他的可靠性是不需要被证明的，或者说需要使用者去证明。

所以，只要我们系统中安装了一个机构的自签名根证书，就代表信任该证书下的所有证书。一旦根证书出了问题，我们的整个 证书体系的安全 就不再可信。

证书撤销

证书吊销列表 ( Certificate Revocation List，CRL ) ，一个被签署的列表，它指定了一套证书发布者认为无效的证书。

当我们从服务端拿到数字证书时，会根据证书上的 CRL 分发点 从指定的 URL 下载 CRL 来检查证书的有效性，CRL 包含了其 下一次 的更新日期。

Q&A

客户端通过证书拿到服务端的公钥后，为什么不采用 双钥加密 ，而转用 单钥加密 ？

这是个好问题。确实，如果客户端拿到服务端公钥的时候，生成自己的公钥/私钥，然后把自己的公钥发给服务端，采用 两对 密钥进行通信也是可以的。

但是 ， 非对称算法 在性能上比 对称算法 要慢太多。

采用 对称算法 已经能确保整个通信的安全，其加密/解密带来的消耗可以忽略不计，而且理论上来说 对称算法 比 非对称算法 甚至更难破解。

CA 为什么不使用自己的私钥直接对证书加密，而采用 数字签名 的方式？

其实这个问题跟上一个类似，因为 非对称加密 的方式效率低下，比起加密原信息，不如去加密他的 HASH 来得划算，其实这两种给我们带来的作用是等效的，都能防止证书被篡改。

为什么不可以直接用 根证书 去给其他所有证书签名，而要设计 证书链 的概念？

这个问题一开始也困扰我很久，我就不阐述我 错误 的思路了，只提醒大家一点： 两个父子证书间的映射关系是放在子证书，而不是父证书 。

如果直接使用根证书去给各服务端签署证书，那根证书的密钥就不是足够安全的，毕竟签署的过程不是手动进行，而是放在服务端进行的。一旦有人攻破 CA 的服务器，拿到根证书的密钥，那他就可以伪造根证书，该 CA 下的所有证书都不可信了。

所以，为了保证根证书的绝对安全，根证书的私钥都被保存在离线的 金库 中。他一般被定期拿出来确保相关密码设备的正常工作，签署证书吊销列表，以及签署新的二级证书。

那么二级证书就可以用来做 在线签名 ，即使二级证书的私钥被盗 ( 可能性很小 ) ，只要根证书是安全的，那么我就可以去更新证书的吊销列表，来让被盗的二级证书失效。

为什么要有多个二级证书？我们可以使用不同的证书去做不同的事情，例如 A 来签署保证邮件安全的证书，B 来签署 SSL 证书。毕竟 多线程 更高效，各自负责自己的业务场景，一定程度上也能分散风险 ( 我是这么想的，不一定对 ) 。

缺点

HTTPS 相比于 HTTP 更加安全自不必说，那他都有哪些缺点呢？

建立连接

HTTP 使用 TCP 三次握手建立连接，客户端和服务端需要交换 3 个包。 HTTPS 除了 TCP 的三个包，还需要加上 SSL 握手需要的 9 个包，一共是 12 个包。

这样的话，HTTPS 在建立连接阶段比 HTTP 多花费的时间包括了多出的网络延时和 SSL 本身加密/解密的开销。

为了避免重新握手而造成的访问效率低下，这时候引入了 Session ID 的概念。出于某种原因，如果对话中断且在 短时间内 重连，只要客户端给出之前的 Session ID ，且服务器有这个 Session ID 的记录，双方就可以重新使用已有的 对称密钥 ，而不必重新生成一把。

上述方式可以缓解单个连接的性能问题，但对于并发访问用户数极多的大型网站，如果频繁的重建 SSL 的 Session ID ，对于服务器性能的影响将会是致命的。这时可以考虑在 Web 服务前配置 [SSL Termination Proxy] ( https://en.wikipedia.org/wiki/TLS_termination_proxy ) ，来将 SSL 处理转移到另一起机器以减少主服务器的负载。

通信阶段

当 SSL 建立连接后，之后的加密方式会使用客户端传输的 对称加密算法 。相对前面 SSL 建立连接时的非对称加密方式，对称加密方式对 CPU 的负荷基本可以忽略不记。

总而言之

HTTPS 相比 HTTP 在建立连接阶段确实会有性能的影响，但建立连接之后的通信速度跟 HTTP 差别不大。

好在 HTTPS 提供了 Session ID 这种优化的方式，再加上服务端如果能够进行恰当的配置和优化，相对于 HTTPS 带来的安全性，给客户端以及服务端造成体验上和性能上 微小 的损失都是值得的。

参考

• 密码学笔记
• HTTPS 要比 HTTP 多用多少服务器资源？
• 深入揭秘 HTTPS 安全问题&连接建立全过程
• 怎么保证「CA 的公钥」是真实的？
• TLS 过程中，为何不用证书提供的公钥加密数据或者加密私钥，而要设计秘钥交换流程呢？
• 证书链-Digital Certificates
• What’s in a certificate chain and why?
• SSL certificate chain verification

扩展

• 为什么 12306 页面的 HTTPS 会被划红线？
• Charles 如何抓取 HTTPS 数据包的？
• 网上流传的所谓「支付宝偷偷添加根证书，将造成安全隐患」的说法是否正确？