名词解释

1. 对称加密

只有一个秘钥A，秘钥A同时用于加密和解密

2. 非对称加密

两个秘钥，一个公钥A和一个私钥a，A加密的需要a解密，a加密的需要A解密

3. 数字签名

发送者可以理解server 接受者理解为client

定义：（前提是接受者已经知道发送者的公钥，有可能发送者是知名机构，公钥可查）发送者将发送的内容先hash得出hash码，再将hash码使用发送者自己的私钥加密，接着将私钥加密后hash码附在发送者的要发送的内容里面；这样接收者接收到消息（消息内容包含纯内容消息+私钥加密后的hash码）之后，先用发送者的公钥解密消息中的加密hash码得出hash码,再将内容消息进行hash后得出的hash码和解密得出的hash码进行比对，如果一样则说明消息内容没有被修改过，并且确实是Bob发送的。
作用：主要为了验证消息内容没有被修改过

4. 数字证书

发送者可以理解server 接受者理解为client

定义：上述第三步数字签名中的接受者有发送者的公钥，但是接受者不知道这个公钥是不是可靠的，所以要求发送者找权威机构给出证明，发送者将自己的公钥和相关信息给CA认证机构，做公钥认证；CA机构用它自己的私钥对发送者的公钥和相关信息进行加密，生成数字证书，将数字证书给发送者。后面发送者会将内容+数字签名+数字证书一起发送给接受者，接受者收到之后先用CA的公钥对解密数字证书得到发送者的可靠公钥，拿到可靠公钥之后就可以进行数字签名的解密了，相当于第三步数字签名
作用：主要保证发送者的公钥是否是靠谱的

https秘钥交换过程

详解见：浪里行舟大佬

1.Client发起一个HTTPS（比如https://juejin.cn/user/4283353031252967）的请求，根据RFC2818的规定，Client知道需要连接Server的443（默认）端口。
2.Server把事先配置好的公钥证书（public key certificate）返回给客户端。
3.Client验证公钥证书：比如是否在有效期内，证书的用途是不是匹配Client请求的站点，是不是在CRL吊销列表里面，它的上一级证书是否有效，这是一个递归的过程，直到验证到根证书（操作系统内置的Root证书或者Client内置的Root证书）。如果验证通过则继续，不通过则显示警告信息。
4.Client使用伪随机数生成器生成加密所使用的对称密钥，然后用证书的公钥加密这个对称密钥，发给Server。
5.Server使用自己的私钥（private key）解密这个消息，得到对称密钥。至此，Client和Server双方都持有了相同的对称密钥。
6.Server使用对称密钥加密“明文内容A”，发送给Client。
7.Client使用对称密钥解密响应的密文，得到“明文内容A”。
8.Client再次发起HTTPS的请求，使用对称密钥加密请求的“明文内容B”，然后Server使用对称密钥解密密文，得到“明文内容B”。

问题点

1. 为什么制作数字签名时需要hash一次？

因为对内容进行hash算法之后得到的是一个定长的hash码（（比如用md5算法hash后可以得到固定的128位的值）），接受者用私钥解密出来的也得到的是hash码，再用hash算法对消息内容进行hash得出新的hash码，这样只需要比较解密出来的hash码和hash内容出来的两个定长hash码就可以；这样做比起没有hash，直接加密和解密消息内容性能更好。（结合上面名词解释中的数字签名看）

2. 为什么客户端有CA机构的公钥？

因为CA是权威机构，一般计算机会内嵌CA机构的公钥。

操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了。实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。另外，不知你们是否遇到过网站访问不了、提示要安装证书的情况？这里安装的就是跟证书。说明浏览器不认给这个网站颁发证书的机构，那么没有该机构的根证书，你就得手动下载安装（风险自己承担XD）。安装该机构的根证书后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了

3. 客户端收到的数字证书会不会被中间攻击者掉包了？

假设有另一个网站B也拿到了CA机构认证的证书，它想搞垮网站A，想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，会导致上文提到的漏洞。其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了

4. 中间人有可能篡改该证书吗？

假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。

5. HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗？

这也是我当时的困惑之一，显然每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？用session就行。服务器会为每个浏览器（或客户端软件）维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！