这就是HTTPS我们每天接触的互联网并不是一个绝对安全的存在，在进行网络活动时，我们的个人信息有可能被恶意盗取，接收到的

不安全的HTTP

我们每天接触的互联网并不是一个绝对安全的存在，在进行网络活动时，我们的个人信息有可能被恶意盗取，接收到的内容或许被第三方修改过，正在访问的站点也可能根本就是个冒牌货。这些不安全的因素归因于HTTP协议所依赖的TCP/IP网络模型。HTTP是应用层协议，位于TCP/IP协议栈的顶层。用户数据想要送达到目标主机就需要向下依次经由传输层、网络层、数据链路层，层层封装后最终通过物理层传输二进制流至目的地。而恰恰在这些层中都未对数据进行加密处理，一旦别有用心之人获取到传输中的数据包，其中内容便唾手可得。所以，要想我们的数据变得“安全”无非两种办法，一是让“第三者”得不到，二是即便搞到手，但是看不懂。第一种方式貌似实现起来困难有点大，所以还是第二种更靠谱，对传输的数据进行特定的加密处理就能实现。

数据加密

所谓数据加密，就是将一段数据处理成无规则的数据，除非有关键的密钥，否则谁也无法得知无规则数据的真实含义。

在密码学中，用于数据加密的算法主要有两种，即 对称加密算法 和 非对称加密算法

对称加密算法

一般是通过一个算法和一个密钥（secret key）对明文（plaintext）进行处理，得到的不规则字符就是密文（ciphertext）

对称加密算法在一定程度上可以解决数据传输的安全性问题。在传输数据前对其进行对称加密，这样即使数据被第三方截获，他人也无法得知其真正的含义，但同时对目标接收方也同样是一脸懵逼。

所以客户端与服务器通信前需要协商密钥，保证只有服务器和该客户端知晓此密钥。这里的密钥也称为会话密钥，该密钥不需要存储，一旦客户端与服务器的连接关闭，密钥就会消失，即会话密钥存储于客户端和服务器的内存中，也正是因为这一点，安全性得到了很大保障。那么这个会话密钥如何安全地送达客户端呢？如果被第三方截获，那后续的数据加密传输就跟明文传输没啥区别了。所以仅仅使用对称加密算法是无法解决在协商密钥这一步存在的安全问题的。

非对称加密算法

非对称加密算法（也称公开密钥算法）不是一个算法而是一组算法，它与对称密钥算法的异同点如下：

功能不一样

对称加密算法主要用于加密解密，而非对称密钥算法可以进行加解密、密钥协商、数字签名。
密钥是一对

对称密钥算法中的密钥是一个数字，且加解密使用同一个密钥。非对称加密算法的密钥可以部分公开，密钥是一对，分为公钥和私钥，公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密。一般私钥由服务器持有且不可泄露，任何人均可持有公钥。
运算速度慢

相比于对称加密算法，非对称加密算法的运算速度要慢很多。所以非对称加密算法一般用于密钥协商或者数字签名，因为运算的数据较少。

想象一下使用非对称加密算法进行加密传输的场景，客户端从服务器处获取公钥，对传输的数据进行加密后发送给服务端，这时即使被第三方截获，由于其没有私钥也就无法理解传输的内容。但是公钥也是通过网络发送给客户端，第三方也可能获取公钥，如此一来服务器私钥加密后的内容仍可以被第三方来使用公钥解密。显然对称加密和非对称加密在密钥传输环节都存在问题，但是非对称加密至少能够保证从客户端发送给服务器的内容是“安全的”，对称加密算法的性能又比较好。如果在协商密钥时服务器发送公钥给客户端，随后客户端生成一个对称密钥，并使用公钥加密该对称密钥后发送给服务器，继而后续的数据传递过程中均使用该对称密钥进行加解密，这样就既能保证密钥的私密性又能使运算性能不至于太差。

但即使这样，也还是有漏洞。看下图：

第三方之所以能伪装成真实服务器与客户端进行通信，是因为客户端无法验证与之通信的另一方的合法性。

CA证书和CA机构

正如身份证是证明我们身份的凭证一样，服务器也需要一个类似的凭证来证实其身份和可信度。数字证书的目的就在于此。CA证书是由数字证书颁发的权威机构（CA机构）负责颁发。获取证书前，服务器需要先向CA机构提交基本信息（包括服务器自己的公钥）申请证书，CA机构审核通过后就会为其颁发证书，证书中会包含服务器在申请时提交的公钥。客户端在拿到服务器的证书后就可以根据证书中包含的服务端信息验证服务器的合法性，比如域名是否一致、证书是否过期等等，并可通过服务器公钥进行协商密钥。但是如果证书在传输过程中被第三方获取，把服务器公钥改成自己的公钥，依然可以伪装成真实服务器与客户端通信。所以需要一种方法能够保证证书不被篡改和伪造。

数字签名

数字签名是依据非对称密钥算法实现的，并且定义了两种互补的运算 —— 签名和验证。签名是对要发送的消息使用私钥加密，验证是使用公钥对加密后的消息解密，如和原消息一致则验证成功。但通常会对消息的散列值签名，因为通常散列值的长度远小于消息原文，使得签名的效率大大提高。由此，CA机构在颁发证书时会把使用CA机构私钥加密的数字签名一同发送到服务器，客户端在拿到服务器证书后，通过操作系统或浏览器内置信任的CA机构找到对应机构的公钥对数字签名进行解密，再用证书中指明的签名算法计算数字证书的签名，最后比较两个值是否一致，一致则表示证书没有被篡改。CA证书的相关信息和具体流程如下：

HTTPS

HTTPS可以被看作是基于TLS/SSL的HTTP协议。TLS/SSL协议的整体设计可分为两层，即握手层和加密层。握手层位于加密层之上，为加密层提供所需要的信息（密钥块）。对于一个HTTPS请求来说，在没有完成握手之前，消息不会传递给加密层，而一旦握手完毕，之后所有的应用层HTTP消息都将经由加密层加密。

握手层

在握手层，客户端和服务器交换一些信息，如协议版本号、随机数、密码套件等，经过协商后，由服务器确定此次连接使用的密码套件，该密码套件须双方任何。客户端通过证书确认服务器身份后，双方便可开始密钥协商，并最终协商出预备主密钥、主密钥、密钥块。密钥块后续则由加密层使用。整个协商过程需要经过多个来回才能握手成功，这也是TLS/SSL协议缓慢的原因。
加密层

加密层就是使用握手层中双方协商好的密钥块进行对称加密。

HTTPS的通信过程

第一步：客户端发起的第一次握手，此次握手过程的主要目的是从服务端获取数字签名证书，服务端在发送数字签名证书之前要先确认客户端的SSL版本、加密算法等信息。

第二步：完成第一次握手后，接着进行第二次握手。第二次握手是在客户端收到证书后发起的，主要目的是将对称加密使用的密钥发送给服务端。当然这个密钥是使用第一次握手获取的服务器公钥进行加密的。服务端收到这个加密过的密钥后使用自己的私钥进行解密。这样客户端和服务端经过二次握手后都持有了对称加密密钥。

第三步：用对称密钥对HTTP报文进行加解密。

第四步：通信完成后，断开连接。

这就是HTTPS