HTTPS的加密过程
HTTPS的加密过程
HTTPS
HTTPS即加密的HTTP，HTTPS并不是一个新协议，而是HTTP+SSL（TLS）。原本HTTP先和TCP（假定传输层是TCP协议）直接通信，而加了SSL后，就变成HTTP先和SSL通信，再由SSL和TCP通信，相当于SSL被嵌在了HTTP和TCP之间。
我们首先了解几个基本概念。
-
共享密钥加密（对称密钥加密）：加密和解密同用一个密钥。加密时就必须将密钥传送给对方，那么如何安全的传输呢？
-
公开密钥加密（非对称密钥加密）：公开密钥加密使用一对非对称的密钥。一把叫做私有密钥，一把叫做公开密钥。私有密钥不能让其他任何人知道，而公开密钥则可以随意发布，任何人都可以获得。使用此加密方式，发送密文的一方使用公开密钥进行加密处理，对方收到被加密的信息后，再使用自己的私有密钥进行解密。利用这种方式，不需要发送用来解密的私有密钥，也不必担心密钥被攻击者窃听盗走。
但由于公开密钥比共享密钥要慢，所以我们就需要综合一下他们两者的优缺点，使他们共同使用，而这也是HTTPS采用的加密方式。在交换密钥阶段使用公开密钥加密方式，之后建立通信交换报文阶段则使用共享密钥加密方式。
这里就有一个问题，如何证明公开密钥本省是货真价实的公开密钥。如，正准备和某台服务器建立公开密钥加密方式下的通信时，如何证明收到的公开密钥就是原本预想的那台服务器发行的公开密钥。或许在公开密钥传输过程中，真正的公开密钥已经被攻击者替换掉了。为了解决这个问题，可以使用由数字证书认证机构（CA，Certificate Authority）和其他相关机关颁发的公开密钥证书。
接收到证书的客户端可以使用数字证书认证机构的公开密钥，对那张证书上的数字签名进行验证，一旦验证通过，客户端便可以明确两件事：
一、认证服务器的公开密钥的是真实有效的数字证书认证机构。
二、服务器的公开密钥是值得信赖的。
此处认证机关的公开密钥必须安全地转交给客户端。使用通信方式时，如何安全转交是一件很困难的事，因此，多数浏览器开发商发布版本时，会事先在内部植入常用认证机关的公开密钥。
- 服务器把自己的公开密钥登录至数字证书认证机构。
- 数字证书认证机构用自己的私有密钥向服务器的公开密码署数字签名并颁发公钥证书。
- 客户端拿到服务器的公钥证书后，使用数字签名认证机构的公开密钥，向数字证书认证机构验证公钥证书上的数字签名，以确认服务器的公开密钥的真实性。
- 使用服务器的公开密钥对报文加密后发送。
- 服务器用私有密钥对报文解密。
HTTPS的安全通信机制
可以看到工作流程，基本分为三个阶段：
- 认证服务器。浏览器内置一个受信任的CA机构列表，并保存了这些CA机构的证书。第一阶段服务器会提供经CA机构认证颁发的服务器证书，如果认证该服务器证书的CA机构，存在于浏览器的受信任CA机构列表中，并且服务器证书中的信息与当前正在访问的网站（域名等）一致，那么浏览器就认为服务端是可信的，并从服务器证书中取得服务器公钥，用于后续流程。否则，浏览器将提示用户，根据用户的选择，决定是否继续。当然，我们可以管理这个受信任CA机构列表，添加我们想要信任的CA机构，或者移除我们不信任的CA机构。
- 协商会话密钥。客户端在认证完服务器，获得服务器的公钥之后，利用该公钥与服务器进行加密通信，协商出两个会话密钥，分别是用于加密客户端往服务端发送数据的客户端会话密钥，用于加密服务端往客户端发送数据的服务端会话密钥。在已有服务器公钥，可以加密通讯的前提下，还要协商两个对称密钥的原因，是因为非对称加密相对复杂度更高，在数据传输过程中，使用对称加密，可以节省计算资源。另外，会话密钥是随机生成，每次协商都会有不一样的结果，所以安全性也比较高。
- 加密通讯。此时客户端服务器双方都有了本次通讯的会话密钥，之后传输的所有Http数据，都通过会话密钥加密。这样网路上的其它用户，将很难窃取和篡改客户端和服务端之间传输的数据，从而保证了数据的私密性和完整性。
HTTPS通信步骤
-
客户端通过发送Client Hello报文开始SSL通信（这里是在TCP的三次握手已经完成的基础上进行的）。报文中包含客户端支持的SSL的指定版本、加密组件列表（所使用的加密算法及密钥长度等）。
-
服务器可进行SSL通信时，会以Server Hello报文作为应答。和客户端一样，在报文中包含SSL版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
-
之后服务器发送Certificate报文。报文中包含公开密钥证书。
-
最后服务器发送Server Hello Done 报文通知客户端，最初阶段的SSL握手协商部分结束。
-
SSL第一次握手结束之后，客户端以Client Key Exchange报文作为回应。报文中包含通信加密中使用的一种被称为Pre-master secret的随机密码串。该报文已用步骤3中的公开密钥进行加密。
-
接着客户端继续发送Change Cipher Spec报文。该报文会提示服务器，在此报文之后的通信会采用Pre-master secret密钥加密。
-
客户端发送Finished报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
-
服务器同样发送Change Cipher Spec报文。
-
服务器同样发送Finshed报文。
-
服务器和客户端的Finished报文交换完毕之后，SSL连接就算建立完成。当然，通信会受到SSL的保护。从此处开始进行应用层协议的通信，即发送HTTP请求。
-
应用层协议通信，即发送HTTP响应。
-
最后由客户端断开连接。断开连接时，发送close_notify报文。上图做客一些省略，这步之后再发送TCP FIN报文来关闭与TCP的通信。
在以上流程中，应用层发送数据时会附加一种叫做MAC（Message Authentication Cods）的报文摘要。MAC能够查知报文是否遭到篡改从，从而保护报文的完整性。
下面是整个流程的图解。图中说明了从仅使用服务器端的公开密钥证书（服务器证书）建立HTTPS通信的整个过程。（这个图自己要好好理解一下）
SSL和TLS
HTTPS使用**SSL（Secure Socket Layer）和TLS（Transport Layer Security）**这两个协议。SSL技术最早由浏览器开发商网景通信公司率先倡导的，开发过SSL3.0之后的版本。目前主导权已转移到IETF（Internet Engineering Task Force，Internet工程任务组）的手中。
IETF以SSL3.0为基准，后又制订了TLS1.0、TLS1.1和TLS1.2。TSL是以SSL为原型开发的协议，有时会统一称该协议为SSL。当前主流版本是SSL3.0和TLS1.0。
由于SSL1.0协议在设计之初被发现出了问题，就没有实际投入使用。SSL2.0也被发现存在问题，所以很多浏览器直接废除了该协议版本。
SSL速度慢的原因
SSL的慢分为两种。一种是指通信慢。另一种是指大量消耗CPU及内存等资源，导致处理速度变慢。
和使用HTTP相比，网络负载肯可能会变慢2~100倍。除去TCP连接、发送HTTP请求/响应以外，还必须进行SSL通信，因此整体上处理通信量不可避免会增加。
另一点是SSL必须进行加密处理。在服务器和客户端都需要进行加密和解密的运算处理。因此从结果上讲，比起HTTP会更多地消耗服务器和客户端的硬件资源，导致负载增强。
针对速度变慢这一问题，并没有根本性的解决方案，我们会使用SSL加速器这种（专用服务器）硬件来改善该问题。该硬件为SSL通信专用硬件，相对软件来讲，能够提高数倍SSL的计算速度。仅在SSL处理时发挥SSL加速器的功效，以分担负载。
我们现在解释一下上面的公开加密密钥为什么慢？
我们首先要知道公开密钥加密之所以慢是因为RSA算法慢（他们之间几乎可以用相等来说明，绑定的意思），所以我们可以简单了解一下RSA算法的实现机制。
RSA算法所依赖的是对极大整数做因数分解，所以对极大整数做因数分解的难度决定了RSA算法的可靠性。今天只有短的RSA钥匙才可能被强力方式破解。但目前为止，世界上还没有任何可靠的攻击RSA算法的方式。只要其钥匙的长度足够长，用RSA加密的信息实际上是不可能被破解的。
由于进行的是大数计算，涉及到指数运算，所以速度会比较慢。这可以查看相关资料。
参考：https://blog.csdn.net/CSDN_so_nice/article/details/52451317
参考：https://www.cnblogs.com/xinzhao/p/4949344.html
参考：https://blog.csdn.net/wm_1991/article/details/51954571
————————————————
版权声明：本文为CSDN博主「金所炫我女朋友」的原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_32998153/article/details/80022489
