问题
- 数字签名的作用是什么？
- 为什么 HTTPS 是安全的
- CA存在的动机是什么
- 客户端的公钥的都是一致的吗？
概述
这一节我们将要讲HTTPS,为什么说HTTPS是安全的，而HTTP是不安全的呢，这其中的原理是如何保护数据安全的。
场景一
假如服务端和客户端使用的是对称加密我们来看一下会出现什么情况？
这样子有个问题黑客E利用假装是正常用户与服务端通信，获取到密钥，然后在中途截取到其他客户端和服务端的通信（例如 A 和 B 之间的通信）那么就可能获取到他们之间的信息。 所以这种模式是不安全的。要是有一种方式可以让客户端和服务端之间的通信密钥是他们自身独有就好了，这样即使黑客拿到消息后也无法解析出来。
场景二
假如服务端和客户端使用的是非对称加密的方式，假设如今客户端已经安全地获取到了服务端的公钥，客户端用公钥加密消息给服务端，黑客E 拿到消息后发现自己没有私钥于是没办法解开消息，这是没问题的。服务端收到消息后，用私钥加密消息，发给客户端，当中途给黑客E 截取了，由于服务端的公钥的公开的，黑客E 同样可以利用公钥解开服务端给客户端的消息。
场景三
我们暂时不考虑消息传输过程是否安全，假设是安全的，我们先考虑消息的完整性，即传输过程中是否给人修改过。 这就是数字证书和数据摘要的运用了。
先说数字证书
hash对于学java的应该比较熟悉，这东西可以用来作用唯一标识。一旦内容改变了一点hash值就会不同。
然后经过私钥加密生成数字摘要，然后附在内容底下发给客户端。
当客户端收到消息解密后再对消息进行hash，对比发来的消息的hash值是否一致，不一致说明消息被人修改了。
场景四
假如服务端发送给客户端过程中公钥G给人篡改了呢？黑客E拿到公钥G后，生成一个私钥PRH和公钥PUG，发了个假的公钥给客户端，然后客户端利用这个假公钥发送消息给黑客E(又被截取了)，此时黑客E可以利用手头的PRH 就可以解开又 PUG 加密的消息，然后在利用G加密消息发送给服务端。这样黑客E就充当两者之间的窃听者，可以窃取和修改两者之间的消息。所以公钥能否安全地送到客户端手上成了关键，于是就引入了第三方
就像我们平时，要证明一个人的身份，派出所成了最好的证明场所，前提是那个人要提前在派出所有记录，HTTPS 也是同样的道理，于是有了CA机构。
HTTPS
为了使公钥可以安全地发送到客户端的手上，HTTPS引入了第三方验证机构，在最初的时候服务端首先会把自己的公钥发给CA , CA用自己的私钥对服务端的公钥还有其他信息进行加密，然后生成数字证书，发送给服务端。
然后证明发给客户端，客户端如果是使用浏览器,浏览器本身会配置信任的CA机构，浏览器首先会去CA机构拿到CA的公钥，然后利用CA的公钥解开经过CA加密的服务端公钥，当然这个地方还有验证一下信息，包括证书是否过期等等。当确定该证书确实来自于服务端，且没被修改过后。
客户端生成一个用于对称加密的密钥，并用服务端给的公钥进行加密，发送给服务端，服务端收到该秘钥就利用该秘钥加密信息发给客户端，之后它们的消息都是通过该秘钥进行互相发送消息。
补充
非对称加密通俗解释
用不同的钥匙加密解密，公钥可以公开，私钥需要不能公开，需要安全保存
RSA 公钥和私钥的特性
- 私钥公钥成对出现
- 私钥公钥都可以进行加密和解密
- 用公钥加密的数据只能用对应的私钥解密，而用私钥加密的数据只能用对应的公钥才可以解密。
公钥和私钥都可以用来加密和解密，但是用途不同 ：
- 私钥用于签名，公钥用于验证签名，对应着数字签名
- 公钥用于加密，私钥用于加密
数字签名
保证信息没有被人篡改。简单来说，签名主要包含两个过程：摘要和非对称加密，首先对需要签名的数据做摘要（类似于常见的 MD5）后得到摘要结果，然后通过签名者的私钥对摘要结果进行非对称加密即可得到签名结果。
CA是什么，为了解决什么问题
解决公钥分发问题的一个独立的权威的第三方机构。为了验证收到的公钥是否是真实有效的。
总结
由此可以知道HTTP开始是使用了非对称加密，当公钥被安全地送到客户端手上的时候，客户端发送对称加密的秘钥，两者之间开始对称加密。