本文为社区首发签约文章，14天内制止转载，14天后未获授权制止转载，侵权必究！
一直以来我都在逃避写HTTPS。
毕竟。
HTTPS里名词太多。概念又巨繁琐。
真实是太难解说了，能不写我尽量不写。。。。
但为了让图解网络的知识系统尽量完好些。
今日，咱们忍一忍。
咱们就从对称加密和非对称加密聊起吧。
对称加密和非对称加密
小学上课的时分，都传过小纸条吧？传纸条的时分每个拿到纸条的同学都会忍不住看一眼，毫无隐私可言。
假设班花想对我表达，又不想在传的进程中让别人发现她的情意绵绵。
就会在课间十分钟里告知我，”每个字母向左移动一位，便是我想对你说的话“。
然后在上课的时分，递出纸条，上面写了 eb tib cj。每个帮助传递纸条的同学看了之后，都暗骂“谜语人，你给我滚出哥谭镇”。
嘿嘿，你们不明白，我懂。
我拿到纸条后，将每个字母向左移动一位，得到 da sha bi。
什么话，这是什么话。
坏女人想要毁我向道之心？我果断拒绝了她的表达。
现在回想起来，感动之余，会发现，像这种，将一段咱们看得懂的信息（明文）转化为另一段咱们看不明白的信息（密文），其实便是加密。
像这种“左移”的加密方法，其实便是所谓的秘钥。而这种加密和解密用的都是同一个秘钥的加密方法，就叫对称加密。
那已然有对称加密，那就有非对称加密。
不同点在于，非对称加密，加密和解密用到的不是同一个秘钥，而是两个不相同的秘钥，分别是公钥和私钥。
公钥担任加密，私钥担任解密。公钥人人可得，私钥永远不泄露。<br>
那么问题就来了。
为什么用公钥加密，却不能用公钥解密？
这其实就触及到公钥和私钥加密的数学原理了。
说白了加密便是将一个已知的数字依据必定的规则转化变成另一个数字，以前这些数字放在一同都可读，可是经过这么一转化，就变得不可读了。
也便是说加密的实质便是 num -> x （num是已知数，x是未知数）。
比方班花操作的加一减一便是很简单的转化方法。
那咱们换个复杂的，比方求余运算。
假设现在有个求余运算公式。
5^2 mod 7 = 25 mod 7 = x
这个公式就很简单。在已知5的2次方和7的状况下，很容易得到x=4。
可是假如咱们换一下x的方位。
5^x mod 7 = 4
求x等于多少的时分，上面的等式能树立呢？
那就费事多了。
5^0 mod 7 = 1
5^1 mod 7 = 5
5^2 mod 7 = 4
5^3 mod 7 = 6
5^4 mod 7 = 2
尽管费事了一些，但仍是能反推得到x=2时等式树立。
但假如上面的模数字变得巨大无比呢？
5^x mod 56374677648 = 4
那这时分核算机只能挨个去试才干算出。正常CPU要跑好多年才干算出来，所以能够以为算不出来。
其实上面的公式便是将 5 加密成了4。假如已知x，就很容易算出等式右边的结果是4，而反过来，从4却难以反推得到出x的值是多少。因而说这样的取模算法是不可逆的。
尽管取模运算是不可逆的，可是结合欧拉定理，却能够让这个公式在必定条件下变得有点“可逆”（注意是加了引号的）。
咱们来看下是怎样做的。
咱们将x掰成两瓣，变成p和q的乘积。
原文^(p*q) mod N = 原文
假如p, q, N选取妥当，原文一波取模操作之后仍是变回原文。
知道这个没用，可是结合欧拉定理，再经过一些咱们都看不明白的推导进程，就能够将上面的公式变换成下面这样。
原文^(p) mod N = 密文
密文^(q) mod N = 原文
结合欧拉公式的核算进程咱们感兴趣能够查查。但这儿只知道定论就够了。
也便是说，知道 p就能加密，知道 q就能解密。
而这儿的p便是公钥，q便是私钥。
用公钥加密过的密文只需用私钥才干解密。
并且更妙的是。
p和q其真实公式里方位是能够交流的，所以反过来说“用私钥加密过的密文，只需公钥才干解密”，也是ok的。而这种操作，便是常说的验证数字签名。
这就像以前古装电视剧里，经常有这么个剧情，两个失散多年的亲人，各自身上带有一块碎成两瓣的玉佩。
哪天他们发现两块玉佩裂缝正好能够拼在一同，那就确认了对方便是自己失散多年的好大儿。
这两块碎玉，就有点公钥和私钥的滋味。
原理咱们知道这么多其实就够了。
看到这儿，咱们就能回答标题的问题了。
为什么用公钥加密，却不能用公钥解密？
由于大数取模运算是不可逆的，因而他人无法暴力解密。可是结合欧拉定理，咱们能够选取出适宜的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定状况下，变得有那么点“可逆”的滋味。数学原理决议了咱们用公钥加密的数据，只需私钥能解密。反过来，用私钥加密的数据，也只需公钥能解密。
从数学原理也能看出，公钥和私钥加密是安全的，但这件工作的条件是树立在”现在的核算机核算速度还不够快”这个基础上。因而，假如有一天科技变得更兴旺了，咱们变成了更高维度的科技文明，或许现在的密文就跟明文没啥区别了。
了解了对称加密和非对称秘要之后，咱们就能够聊聊HTTPS的加密原理了。
HTTPS的加密原理
假如你在公司内网里做开发，并且写的代码也只对内网提供服务。那么大约率你的服务是用的HTTP协议。
但假如哪天你想让外网的朋友们也体会下你的服务功用，那就需求将服务露出到外网，而这时分假如仍是用的HTTP协议，那信息的收发就会是明文，只需有心人士在通讯链路中恣意一个路由器那抓个包，就能看到你HTTP包里的内容，因而很不安全。
为了让明文，变成密文，咱们需求在HTTP层之上再加一层TLS层，意图便是为了做个加密。这就成了咱们常说的HTTPS。
TLS其实分为1.2和1.3版别，目前干流的仍是1.2版别，咱们以它为例，来看下HTTPS的连接是怎样树立的。
HTTPS握手进程
首先是树立TCP连接，毕竟HTTP是基于TCP的应用层协议。
在TCP成功树立完协议后，就能够开端进入HTTPS的加密流程。
总的来说。整个加密流程其实分为两阶段。
第一阶段是TLS四次握手，这一阶段主要是运用非对称加密的特性各种交流信息，最终得到一个”会话秘钥”。
第二阶段是则是在第一阶段的”会话秘钥“基础上，进行对称加密通讯。
咱们先来看下第一阶段的TLS四次握手是怎样样的。
第一次握手：
-
Client Hello：是客户端告知服务端，它支持什么样的加密协议版别，比方TLS1.2，运用什么样的加密套件，比方最常见的RSA，一起还给出一个客户端随机数。
第2次握手：
-
Server Hello：服务端告知客户端，服务器随机数 + 服务器证书 + 确认的加密协议版别（比方便是TLS1.2）。
第三次握手：
-
Client Key Exchange: 此刻客户端再生成一个随机数，叫pre_master_key。从第2次握手的服务器证书里取出服务器公钥，用公钥加密pre_master_key，发给服务器。 -
Change Cipher Spec: 客户端这边现已具有三个随机数： 客户端随机数，服务器随机数和pre_master_key，用这三个随机数进行核算得到一个”会话秘钥“。此刻客户端告诉服务端，后边会用这个会话秘钥进行对称秘要通讯。 -
Encrypted Handshake Message：客户端会把迄今为止的通讯数据内容生成一个摘要，用”会话秘钥“加密一下，发给服务器做校验，此刻客户端这边的握手流程就完毕了，因而也叫Finished报文。
第四次握手：
-
Change Cipher Spec：服务端此刻拿到客户端传来的pre_master_key（尽管被服务器公钥加密过，但服务器有私钥，能解密取得原文），集齐三个随机数，跟客户端相同，用这三个随机数经过相同的算法取得一个”会话秘钥“。此刻服务器告知客户端，后边会用这个”会话秘钥”进行加密通讯。 -
Encrypted Handshake Message：跟客户端的操作相同，将迄今为止的通讯数据内容生成一个摘要，用”会话秘钥“加密一下，发给客户端做校验，到这儿，服务端的握手流程也完毕了，因而这也叫Finished报文。
短短几回握手，里面全是细节，没有一处是多余的。
咱们一个个来解说。
由于咱们肯定现已很晕了，所以我会尽量用简短的句子，来解说下面几个问题。
HTTPS究竟是对称加密仍是非对称秘要？
都用到了。前期4次握手，实质上便是在运用非对称加密的特点，交流三个随机数。
意图便是为了最终用这三个随机数生成对称加密的”会话秘钥”。后期就一直用对称秘要的方法进行通讯。
为什么不都用非对称加密呢？
由于非对称加密慢，对称加密相对来说快一些。
第2次握手里的服务器证书是什么？怎样从里面取出公钥？
服务器证书，实质上是，被威望数字证书组织（CA）的私钥加密过的服务器公钥。
上面提到过，被私钥加密过的数据，是能够用公钥来解密的。而公钥是任何人都能够得到的。所以第2次握手的时分，客户端能够经过CA的公钥，来解密服务器证书，然后拿到藏在里面的服务器公钥。
看起来好像有点多此一举？
那么问题来了。
为什么我不能只传公钥，而要拿CA的私钥加密一次再传曩昔？
反过来想想，假如只传公钥，公钥就有或许会在传输的进程中就被黑客替换掉。然后第三次握手时客户端会拿着假公钥来加密第三个随机数 pre_master_key，黑客解密后天然就知道了最为要害的 pre_master_key。又由于第一和第二个随机数是公开的，因而就能够核算出”会话秘钥“。
所以需求有个方法证明客户端拿到的公钥是真实的服务器公钥，于是就拿CA的私钥去做一次加密变成服务器证书，这样客户端拿CA的公钥去解密，就能验证是不是真实的服务器公钥。
那么问题又又来了
怎样去取得CA的公钥？
最容易想到的是恳求CA的官网，获取公钥。但全世界要上网的人那么多，都用去恳求CA官网的话，官网肯定顶不住。
考虑到能颁发证书的CA组织可不多，因而对应的CA公钥也不多，把他们直接作为装备放到操作系统或者浏览器里，这就完美解决了上面的问题。
别人就拿不到你这三个随机数？
这三个随机数，两个来自客户端，一个来自服务端。第一次和第2次握手里的客户端随机数和服务端随机数，都是明文的。只需有心，咱们都能拿到。
但第三个随机数 pre_master_key 则不可，由于它在客户端生成后，发给服务器之前，被服务器的公钥加密过，因而只需服务器本器才干用私钥进行解密。就算被别人拿到了，没有服务器的私钥，也无法解密出原文。
为什么要用三个随机数？而不是一个或两个？
看上去第三个随机数 pre_master_key才是要害，别的两个看起来可有可无？
的确，就算没有别的两个，也并不影响加密功用。之所以还要两个随机数，是由于只需单个 pre_master_key随机性不足，屡次随机的状况下有或许出来的秘钥是相同的。但假如再引进两个随机数，就能大大添加”会话秘钥“的随机程度，然后确保每次HTTPS通讯用的会话秘钥都是不同的。
为什么第三和第四次握手还要给个摘要？
第三和第四次握手的最终都有个 Finished报文，里面是个摘要。
摘要，说白了便是对一大段文本进行一次hash操作。意图是为了确认通讯进程中数据没被篡改过。
第三次握手，客户端生成摘要，服务端验证，假如验证经过，阐明客户端生成的数据没被篡改过，服务端后边才干定心跟客户端通讯。
第四次握手，则是反过来，由服务端生成摘要，客户端来验证，验证经过了，阐明服务端是可信任的。
那么问题叒来了。
为什么要hash一次而不是直接拿原文进行对比？
这是由于原文内容过长，hash之后能够让数据变短。更短意味着更小的传输成本。
这个进程中究竟触及了几对私钥和公钥？
两对。
服务器自身的公钥和私钥：在第2次握手中，服务器将自己的公钥（藏在数字证书里）发给客户端。第三次握手顶用这个服务器公钥来加密第三个随机数 pre_master_key。服务器拿到后用自己的私钥去做解密。
CA的公钥和私钥：第2次握手中，传的数字证书里，包含了被CA的私钥加密过的服务器公钥。客户端拿到后，会用实现内置在操作系统或浏览器里的CA公钥去进行解密。
总结
- 大数取模运算是不可逆的，因而他人无法暴力解密。可是结合欧拉定理，咱们能够选取出适宜的p（公钥）, q（私钥）, N（用于取模的大数），让原本不可逆的运算在特定状况下，变得有那么点“可逆”的滋味。数学原理决议了咱们用公钥加密的数据，只需私钥能解密。反过来，用私钥加密的数据，也只需公钥能解密。
- HTTPS相当于HTTP+TLS，目前干流的是TLS1.2，基于TCP三次握手之后，再来TLS四次握手。
- TLS四次握手的进程中触及到两对私钥和公钥。分别是服务器自身的私钥和公钥，以及CA的私钥和公钥。
- TLS四次握手背起来会挺难受的，建议重视三个随机数的流向，以此作为基础去理解，大约就能记下来了。
最终
最近原创更文的阅读量稳步跌落，思前想后，夜里辗转反侧。
我有个不成熟的恳求。
离开广东好长时间了，好久没人叫我靓仔了。
咱们能够在评论区里，叫我一靓仔吗？
我这么善良质朴的愿望，能被满足吗？
假如真实叫不出口的话，能帮我点下重视和右下角的点赞+在看吗？