https

Https 协议简介

Why https

更加严肃的场景中，就存在很多的安全风险。例如，你要下单做一次支付，如果还是使用普通的 HTTP 协议，那你很可能会被黑客盯上。

你向银行付款，但是这个网络包被截获了，于是在服务器回复你之前，黑客先假装自己就是银行，然后给你回复一个假的消息说：“密码拿来。”如果这时候你真把银行卡密码发给它，那你就真的上套了。

加密

那怎么解决这个问题呢？当然一般的思路就是加密。加密分为两种方式：

• 一种是对称加密，

在对称加密算法中，加密和解密使用的 密钥 是相同的。也就是说，加密和解密使用的是同一个密钥。因此，对称加密算法要保证安全性的话，密钥要做好保密。只能让使用的人知道，不能对外公开。

• 一种是非对称加密。

在非对称加密算法中，加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥，另一把是作为谁都不能给的私钥。公钥加密的信息，只有私钥才能解密。私钥加密的信息，只有公钥才能解密。

结论：非对称加密主要用于传输辅助对称加密的秘钥，而真正的双方大数据量的通信都是通过对称加密进行了。

性能：对称加密 > 非对称加密

对称加密

假设你和银行约定了一个密钥，你发送请求的时候用这个密钥进行加密，银行用同样的密钥进行解密。这样就算中间的黑客截获了你的请求，但是它没有密钥，还是破解不了。

这看起来很完美，但是中间有个问题，你们两个怎么来约定这个密钥呢？如果这个密钥在互联网上传输，也是很有可能让黑客截获的。黑客一旦截获这个秘钥，它可以佯作不知，静静地等着你们两个交互。这时候你们之间互通的任何消息，它都能截获并且查看，就等密码发出来。

我们在谍战剧里面经常看到这样的场景，就是特工破译的密码会有个密码本，截获无线电台，通过密码本就能将原文破解出来。怎么把密码本给对方呢？只能通过线下传输。当然你们接头的时候，也会先约定一个口号。口号对了才能给密码本，那么 交换密码本的时候，口号怎么约定，这也是一个问题。

好像是个死循环。

非对称加密

非对称加密的私钥放在银行这里，不会在互联网上传输，这样就能保证这个秘钥的私密性。但是，对应私钥的公钥，是可以在互联网上随意传播的，只要银行网站把这个公钥给你，你们就可以愉快地互通了。

黑客也可以模拟发送消息给银行，因为它也有银行网站的公钥。

为了解决这个问题，看来一对公钥私钥是不够的，客户端也需要有自己的公钥和私钥，并且客户端要把自己的公钥，给银行网站。

数字证书，第三方 CA 担保

非对称加密问题：

• 如何将不对称加密的公钥给对方呢？
• 怎么鉴别别人给你的公钥是对的。会不会有人冒充，发给你一个它的公钥。

就需要权威部门的介入了，这个由权威部门颁发的称为证书（Certificate）。

证书里面有什么：当然应该有公钥，这是最重要的；还有证书的所有者，证书的发布机构和证书的有效期。

这个证书是怎么生成的呢？会不会有人假冒权威机构颁发证书呢？就像有假身份证、假户口本一样。生成证书需要发起一个证书请求，然后将这个请求发给一个权威机构去认证，这个权威机构我们称为 CA（ Certificate Authority）。

权威机构会证书卡一个章，我们称为签名算法：

问题又来了，那怎么签名才能保证是真的权威机构签名的呢？当然只有用只掌握在权威机构手里的东西签名了才行，这就是 CA 的私钥。

CA：hash(公钥) = ‘abcdefghijk’

签名算法大概是这样工作的：一般是对信息做一个 Hash 计算，得到一个 Hash 值，这个过程是不可逆的，也就是说无法通过 Hash 值得出原来的信息内容。在把信息发送出去时，把这个 Hash 值加密（CA有用自己的私钥）后，作为一个签名和信息一起发出去。

？私钥加密过后的信息  签名和信息 随着证书一起颁发出来，怎么校验？？？

• CA 机构公钥：操作系统里面，操作系统 “所有” CA的公钥都内置了。
• 签名： Hash 值
• 公钥的信息 ：hash（公钥的信息）= hash 值

CA 用自己的私钥给银行网站的公钥签名，就相当于担保人。

这下好了，你不会从银行网站上得到一个公钥，而是会得到一个证书，这个证书有个发布机构 CA，你只要得到这个发布机构 CA 的公钥，去解密银行网站证书的签名，如果解密成功了，Hash 也对的上，就说明这个银行网站的公钥没有啥问题。

CA 也会更牛的 CA 给它签名，直至 root CA

HTTPS 的工作模式

我们可以知道，非对称加密在性能上不如对称加密，那是否能将两者结合起来呢？例如，公钥私钥主要用于传输对称加密的秘钥，而真正的双方大数据量的通信都是通过对称加密进行的。

• 由于是 HTTPS，客户端会发送 Client Hello 消息到服务器，以明文传输 TLS 版本信息、加密套件候选列表、压缩算法候选列表等信息。另外，还会有一个随机数，在协商对称密钥的时候使用。
• Server Hello 消息, 告诉客户端，服务器选择使用的协议版本、加密套件、压缩算法等，还有一个随机数，用于后续的密钥协商。
• 银行网站会给你一个服务器端的证书
• 从自己信任的 CA 仓库中，拿 CA 的证书里面的公钥去解密银行网站的证书。如果能够成功，则说明银行网站是可信的。这个过程中，你可能会不断往上追溯 CA、CA 的 CA、CA 的 CA 的 CA，反正直到一个授信的 CA，就可以了。
• 证书验证完毕之后，觉得这个银行网站可信，于是客户端计算产生随机数字 Pre-master，用证书中的公钥加密，再发送给服务器，服务器可以通过私钥解密出来。
• 到目前为止，无论是客户端还是服务器，都有了三个随机数，分别是：自己的、对端的，以及刚生成的 Pre-Master 随机数。通过这三个随机数，可以在客户端和服务器产生相同的对称密钥。
• 有了对称密钥
• 当双方握手结束之后，就可以通过对称密钥进行加密传输了。