关于https 和 ssl握手的理解

几点说明：
1） 本文主要目的是对https&ssl的总体过程和相关知识点做一下梳理，算是自我总结。如果同时能给本文的你一点启发或帮助，那就更好了。
2） https这个过程本身非常复杂，里面涉及到的技术点也非常多，本人无力一 一展开。因此，如果有同学觉得我漏了某些点，欢迎补充。另，本文是我自己对https&ssl的个人理解，如果有理解不对的地方，十分期待和欢迎各位指出，大家一起进步。
3） 文章可能引用了其他文章中的某些图或语句，如涉及侵权，请告知

宏观上来讲，可以建立这样印象：
https = ssl + http
即对https来说，1）首先是建立ssl握手连接，前后主要分为两步，a)第一步，主要采用了非对称加密算法（如RSA）进行身份认证（主要是client对sever的身份认证，至于sever对client的身份认证原理完全一样），目的是让client安全地获得sever的公钥。什么叫“安全地获得sever的公钥”，后面会展开讲。b)第二步，采用对称加密算法，client和sever双方一起商量出一个对称加密算法（如AES,DES,3DES等）；2）待client和sever协商好了对称加密算法后，就意味着建立好了安全传输通道，我们就可以开始安全地传输http报文信息了。

首先要明确几个问题：
1， 什么叫加密，解密？
答：加密是指对明文进行编码，变成我们不能识别的密文；解码是将密文解码成明文的过程

2， 什么叫密码？什么叫密钥？他们之间什么关系？
答：这里的密码和和我们在ATM机取钱时输入的密码不是同一个概念。这里的密码实质是“密码机”（http权威指南2012版P328），密码机是一种可以产生许多许多种编码的“机器”，也就是各种各样的加密算法，密钥的实质是选择其中的一种编解码方式。大白话就是，有一个可以有许多编解码方式的机器（密码机或者说是加密算法），我们选择其中一种编解码方法（密钥），当收发双方都知道这个编解码方法时（同一密钥），就意味着可以用同样一个编解码方法来对信息进行加密解密了。

3， 加密算法中的“钥”是什么？“公钥”、“私钥”又是什么？加密算法为什么会需要“公钥”，“私钥”这些东西？
答：“钥”理解为选择一种编解码的“钥匙”。当编码方式和解码方式都是同一把“钥匙”时，我们称之为 “对称加密”，当编解码方式使用的是不同的“钥匙”时，我们称之为“非对称加密”。“公钥”、“私钥”的概念可以分两个层面来理解。a)公钥私钥是一种非对称的加密算法，即加密解密用的是不同的“钥匙”，注意两者都可以有加密解密的功能，即可以公钥加密、私钥解密，也可以私钥加密，公钥解密。b)两者身份不同，一般来说，公钥是任何人都可以知道，一般由服务器分发给客户端，服务器自己留着私钥。有一个场景，是服务器自身生成一对公私钥，然后把公钥分发给客户端，私钥自己留着，在进行消息传递的时候：客户端的消息用公钥加密，传给服务器，这个过程安全，因为中间人没有服务器的私钥，它无法解密密文；服务器用私钥加密，传给客户端，这个过程不安全，因为大家都有公钥，谁都可以解密密文。

4， https中为什么会有非对称加密和对称加密两种加密算法？他们的应用场景分别是什么？
答：首先说对称加密在对信息进行加密解密的速率上要远超非对称加密。因此我们当然首先要考虑用对称加密算法来加密解密信息。但是在client和server没有建立连接前，如何能让双方协商出用哪一种对称加密算法？？？答案是采用非对称加密的方式，也就是说用非对称加密的方式，让client和sever双方协商出一个对称加密算法出来。具体来讲，就是client先知道了sever的公钥，server保留自己的私钥，然后client产生一个”对称钥匙”，用sever的公钥把这个 “对称钥匙”加密，传给server，若中间人截获之，也没办法破解，因为只有私钥能够解开，而私钥是在server上，这样最后只有server能得知这个“对称钥匙”是什么，待server知道这个“对称钥匙”，然后两者就可以用这个“对称钥匙”进行信息的加密传输了，很完美的方案。但是等一下，我们好像漏掉了什么？client怎么能事先知道server的公钥？client怎么就知道它所获取的这个公钥一定是server的，万一是中间人的公钥的呢？那么由此，最重要的问题来了：如何能让client安全地获得server的公钥？

5， 最重要的问题：如何能让client安全地获得server的公钥？
可以说，这个问题是整篇文章的最重要的问题，也是https过程之所以这么复杂的根本原因之所在。接下来，我会就这个问题展开阐述，理解了这个问题，相信你就会对https会有一种豁然的感觉。

对于问题5这个最重要的问题，我们也可以换一种说法。在只有sever、中间人、client三者的情况下，当client请求sever的公钥，结果也收到一个公钥，但是client根本不知道这个公钥到底是真的还是假的，这才是根本症结所在！！！
像下图这样，中间人将公钥掉包了，将真公钥掉包成假的，但是client傻乎乎的不知道，client以为是在跟真的sever通信，实质上是在跟中间人通信。这种情况实质上就是我们常听到的“钓鱼”（钓鱼网站）！

知道了症结，我们就可以对症下药，我们要思考一种方案，即client能够对申请到的公钥进行真伪的鉴别。是真的就跟对方建立后续的连接，是假的就不进行后续的动作。

可以发现，在只有client、sever二者的情况下，无论用何种方法，都无法将sever的公钥安全发给client，即client无法鉴定公钥的真伪！实质上，https的解决方案是引进第三方认证机构来解决这个问题。

解决思路是这样的： 第三方机构使用它的私钥对server公钥进行加密后，再传给client。client再使用第三方机构的公钥进行解密（https的最核心的部分，也是上面问题5的答案，剩下的都是讲这个思路的具体实现）。

我们先介绍 证书 和 数字签名 两个概念
server的公钥和数字签名都在证书里。典型的证书长这个样子（图片来自http权威指南）

我们重点关注标注红箭头的两项：站点的公开密钥，证书颁发者的签名。
站点的公开密钥，实质就是server端的公钥；证书颁发者的签名，签名的概念非常重要，它被设计出来的最重要最核心的目的就是让client有能力检验证书里的公钥的真伪！

生成签名大致过程是这样的：

Client验证签名的大致过程是这样的：

我们来讨论一下如果中间人尝试掉包，会发生什么：
举个例子，meituan是真正的server，而baidu是那个坏人——中间人（sorry for baidu）。baidu的目的是冒名meituan，他们两者都向CA申请了证书。

通过上面的过程，我们可以发现，只要是CA颁发的证书，客户端就一定能够验证成功；而如若对证书进行篡改，客户端就一定验证错误！如此，client就具备了验证公钥真伪的能力！！！最大的问题也就得到了解决！余下的问题，应该就迎刃而解了，如还有不明白的，大家自行谷歌！

接下来我们来捋一遍这个过程：
1） server端向CA部门（即第三方认证机构）交钱申请一个证书。在server拿到证书之后，将证书配置在server上。一个典型申请流程：

在申请的证书中，最重要的是CA用自己的私钥生成的签名
2） client端的浏览器会维护一个CA列表（列表里最重要的部分是CA的公钥）
3） client端向server端发送一个https连接请求。然后server返给client一个证书，让client来验证这个证书的真伪
4） client收到这个证书之后，根据证书上面的CA的信息，来在本地寻找相应的CA的公钥。
5） 根据第4步得到的公钥，进行签名的真伪鉴别！如为假，则无法建立连接；如为真，则表示client就拿到了真正的server端的公钥，随后就建立了非对称连接；
6） 在非对称连接的基础上，client和server商议出一个对称加密的连接，对称加密的算法一般有AES，DES，3DES几种
7） 再对称加密连接上，就可以传递http报文了。

更详细过程可以参考 https://showme.codes/2017-02-20/understand-https/，讲的很详细，推荐指数十颗星！！！

追问：
1) ssl 和 https的关系是什么？ssl握手是什么？
按照我自己的理解：
https = ssl + http
ssl = 非对称加密连接 + 对称加密连接
即https 是在ssl握手成功后，传输http报文；ssl握手包括两个过程，非对称加密连接和对称加密连接（步骤3-6）

2) 用chrome访问12306网站，经常会蹦出“您的连接不是私密”，是什么意思？原因是什么？如下：

通常来讲，CA是独立第三方机构，即与server不是一方，但是12306同时扮演了两个角色：CA 和 server。即它12306自己给自己颁发了证书，既是裁判员，又是运动员。因为不是来自于第三方的CA认证，chrome不认你（还记得我们前面讲的浏览器会维护第三方CA列表么），所以浏览器会告知用户，这个连接有问题，如上图所示！大体逻辑是这样的，详细分析这里就不表了，知乎上面分析的比较到位，大家有兴趣自己看https://www.zhihu.com/question/26161255?sort=created