点击上方“蓝色字体”，选择“设为星标”
做积极的人，而不是积极废人！
my.oschina.net/u/3412738/blog/3212116:来源
vinci321:作者
首先上图
我们知道HTTP是应用层协议，它会在IP寻址，经过三次TCP握手，建立TCP连接通道后，开始传输数据。在这里，如果有人进行TCP抓包，则可以获取到传输的数据，甚至对数据进行篡改，这会造成安全问题。为了解决这个问题，HTTPS应运而生。
HTTPS 被称为 HTTP Over SSL (基于SSL加密的HTTP)，这里的SSL (Secure Socket Layer) 被称为 安全套接层，它是一种加密协议，能加密的东西很多，不止HTTP协议、还有POP3协议、SMTP协议(SMTP Over SSL)、VPN等。当然，还有 TLS (Transport Layer Security) 传输层安全，是公有加密协议，TLS只是对SSLv3做了些修改和增加，有时也一起统称为 SSL。
1，SSL 位于 协议的哪一层？
我们知道，数据的源头来源于HTTP应用层，而TCP/IP负责寻址和数据的打包封装和传输，那对数据的加密，自然就在HTTP 和 TCP/IP 之间工作了，如下图
原来的数据包
加入SSL之后的数据包
2，SSL 如何工作
当建立了TCP连接通道后，就可以开始传输HTTP头数据了，但是要用SSL对HTTP数据进行加密。既然是加密，自然涉及到一套加密体系(算法，公钥，私钥等)。但是在浏览器第一次连接服务器进行HTTPS请求的时候，客户端是没有这些加密体系的，那要怎么才能获取到？既然客户端没有，那只能从服务端获取了。所以，客户端要先从服务端获取到SSL加密体系。
如何获取呢？既然建立了TCP连接，那就通过TCP连接通道来获取了。
2.1 通过TCP连接通道，获取SSL加密体系
上图
2.1.0 客户端与服务端建立连接 (已经由TCP握手完成)。
2.1.1 客户端生成一个32位的随机数A (ClientHello.Random)，告诉接服务器，我是什么浏览器，我支持哪些SSL协议版本号，支持哪些加密算法，压缩方式，Server Name (域名，这样服务器就知道找那个域名的证书发过来，参考Nginx的Server Name)加上 文本内容“Hello”，发出 ClientHello，开始协商握手。
2.1.2 服务端收到客户端的ClientHello，知道了客户端的一些信息，比如SSL协议版本号，加密算法列表，然后和服务端自己支持的版本号和加密算法进行对比，选择出双方都能使用的协议版本号和算法，加上一个32位的随机数B(ServerHello.Random)，把这些信息，打包在一起，向客户端返回一个服务端Hello (ServerHello)，告诉客户端，我选择了哪个协议和算法。
2.1.3 随后服务器给客户端发送一个Certificate报文 (数字证书)，报文中包含服务端的公钥证书（从CA数字证书管理机构处获取，在nginx配置中相关证书的存放目录）
2.1.4 紧接着服务器给客户端发送Server Hello Done, 表示最初的协商握手过程结束。
2.1.5.0 客户端验证服务端公钥，对证书的有效期、合法性、域名是否与请求的域名一致、证书的公钥(RSA加密)等进行校验。
2.1.5 客户端校验证书等通过后，以Client Key Exchange作为回应，再次产生一个48位的随机密码串C 预主密码 (Pre-Master Secret)，
2.1.5.1 若采用RSA，会产生一个新的随机数作为Pre-Master Secret，通过2.1.4步骤中得到的证书中的公钥 或者 Server Key Exchange 消息内的临时RSA密钥，对其进行加密，发到服务器
2.1.5.2 若采用DH，证书中已包含了DH算法需要的两个整数(p, g)，直接通过算法根据已经交换的两个随机数可以算出Pre-Master Secret，
图中使用的是 ECDHE 算法，ClientKeyExchange 传递的是 DH 算法的客户端参数，如果使用的是 RSA 算法则此处应该传递 RSA加密过的 预主密钥
此时，客户端有了随机数A，随机数B，随机数Pre-Master Secret，就可以生成 Master Secret了。(参见 2.1.10)
2.1.6 客户端发送Change Cipher Spec 密钥变更说明包，该报文告知服务端，此步骤告诉服务器，之后的所有数据将使用 2.1.5步骤 生成的master secret进行加密；
2.1.7 随后客户端发送Finish报文，此报文中包含连接至今所有报文的整体校验值，用于完整性验证；
2.1.8.0 服务端使用 私钥 对 秘密消息 进行解密，得到 Pre-Master Secret；
此时，服务端有了随机数A，随机数B，随机数Pre-Master Secret，也可以生成 Master Secret了。(参见 2.1.10)
2.1.8 服务端接收到客户端发送的Change Cliper Spec报文后，同样以Change Cliper Spec报文作为回应；
2.1.9 服务端发送Finish报文给客户端，表示服务端已正确解析客户端发送的整体校验值，至此，SSL握手的过程结束。
2.1.10 客户端和服务端，都根据随机数A (ClientHello.random), 随机数B (ServerHello.random), 随机密码串C (Pre-Master Secret)三个参数，通过 PRF (Pseudo-Random Function) 算出 master secret，作为数据传输对称加密的 密钥Session Key。
master_secret = PRF(Pre_master, "master secret", ClientHello.random + ServerHello.random)
2.1.11 此后，开始使用HTTP协议，去传输使用Session Key加密过的数据。
为了解决安全和效率问题，SSL使用了对称加密（加密和解密使用同样的密钥）和非对称加密（公钥加密，私钥解密）组合的方式：使用非对称加密的方式传输对称加密中生成密钥的种子（Pre-master secret）【对应上面的2.1.5】，然后使用对称加密的方式对通信数据进行加密【对应上面的2.1.13】，既保障了密钥的安全性，也提高了加密速度。
2.2 归纳SSL五次握手，或四次
2.2.1 客户端请求建立SSL链接，并向服务端发送协议版本号、一个随机数–Client random和客户端支持的加密方法，比如RSA公钥加密，此时是明文传输。
2.2.2 服务端回复一种客户端支持的加密方法、一个随机数–Server random、授信的服务器证书和非对称加密的公钥。
2.2.3 客户端收到服务端的回复后，确认数字证书有效，然后生成新的随机数–Pre-master secret，通过服务端下发的公钥及加密方法进行加密，发送给服务器。
2.2.4 服务端收到客户端的回复，利用自己的私钥解密获得Pre-master secret，
2.2.5 服务端利用Client random、Server random和Premaster secret通过一定的算法生成HTTP链接数据传输的对称加密key – session key（包含于上面提到的master secret中），用来加密接下来的整个对话过程。
握手阶段有三点需要注意。
生成对话密钥一共需要三个随机数。
握手之后的对话使用"对话密钥"加密（对称加密），服务器的公钥和私钥只用于加密和解密"对话密钥"（非对称加密），无其他作用
服务器公钥放在服务器的数字证书之中。
可见，在整个握手阶段都不加密（也没法加密），都是明文的。因此，如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。
Master secret与session key
由于服务端和客户端都有一份相同的PreMaster secret和随机数，这个随机数将作为后面产生Master secret的种子，结合PreMaster secret，客户端和服务端将计算出同样的Master secret。
Master secret是由一系列的hash值组成的，它将作为数据加解密相关的secret的Key Material。
Master secret最终解析出来的数据如下：
其中，write MAC key，就是session secret或者说是session key。
Client write MAC key是客户端发数据的session secret，Server write MAC secret是服务端发送数据的session key。
MAC(Message Authentication Code)，是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。
证书
证书由值得信任的第三方机构颁发，用以证明服务器和客户端是实际存在的。
现在主要还是客户端去检验服务端的证书，客户端的证书还不够普及，如银行的网上银行就需要客户端证书。
HTTPS 比 HTTP 要慢 2 到 100 倍
SSL 的慢分两种。一种是指通信慢。另一种是指由于大量消耗CPU 及内存等资源，导致处理速度变慢。
和使用 HTTP 相比，网络负载可能会变慢 2 到 100 倍。除去和TCP 连接、发送 HTTP 请求 • 响应以外，还必须进行 SSL 通信，
因此整体上处理通信量不可避免会增加。另一点是 SSL 必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起 HTTP 会更多地消耗服务器和客户端的硬件资源，导致负载增强。
针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL 加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL 通信专用硬件，相对软件来讲，能够提高数倍 SSL 的计算速度。仅在 SSL 处理时发挥 SSL 加速器的功效，以分担负载。
参考及引用:
https://www.jianshu.com/p/569bf898a19a
https://blog.csdn.net/hik_zxw/java/article/details/50287625
https://www.cnblogs.com/taoshihan/p/11278548.html
https://blog.csdn.net/pzhier/article/details/86631199
完
关注公众号「前端布道师」，一起进步，一起成长！
▼ 往期精彩回顾 ▼
“在看转发”是最大的支持
3456
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
