理解HTTPS及其加密原理

HTTPS是以安全为目标的 HTTP 通道，即 HTTP 的安全版。

为什么需要 HTTPS？
当我们往服务器发送比较隐私的数据(比如说你的银行卡，身份证)时，如果使用 HTTP 进行通信。那么安全性将得不到保障。
首先数据在传输的过程中，数据可能被中间人抓包拿到，那么数据就会被中间人窃取。
其次数据被中间人拿到后，中间人可能对数据进行修改或者替换，然后发往服务器。
最后服务器收到数据后，也无法确定数据有没有被修改或替换，当然，如果服务器也无法判断数据就真的是来源于客户端。

HTTP 存在三个弊端：
无法保证消息的保密性；
无法保证消息的完整性和准确性；
无法保证消息来源的可靠性。
HTTPS 就是为了解决上述问题应运而生的。

一、HTTPS 基本概念
1.对称加密与非对称加密
为了保证消息的保密性，就需要用到加密和解密。加解密算法目前主流的分为对称加密和非对称加密。

（1）对称加密(共享密匙加密)：客户端和服务器公用一个密匙用来对消息加解密。
客户端和服务器约定好一个加密的密匙；客户端在发消息前用该密匙对消息加密，发送给服务器后，服务器再用该密匙进行解密拿到消息。

优点：
解决了 HTTP 中消息保密性的问题。

缺点：
虽然保证了消息保密性，但是因为客户端和服务器共享一个密匙，这样就使得密匙特别容易泄露；因为密匙泄露风险较高，所以很难保证消息来源的可靠性、消息的完整性和准确性。

（2）非对称加密(公有密匙加密)：客户端和服务端均拥有一个公匙和一个私匙。公匙可对外暴露，私匙仅自己可见。
使用公匙加密的消息，只有对应的私匙才能解开；相反，使用私匙加密的消息，只有公匙才能解开。
这样客户端在发送消息前，先用服务器的公匙对消息进行加密，服务器收到后再用自己的私匙进行解密。

优点：

• 解决了 HTTP 中消息保密性问题，使得私匙泄露的风险降低；
• 因为公匙加密的消息只有对应的私匙才能解开，所以较大程度上保证了消息的来源性及消息的准确性和完整性。

缺点：

• 非对称加密时需使用到接收方的公匙对消息进行加密，但公匙不是保密的，任何人都可拿到，中间人也可以。
  中间人可做两件事：一是中间人可在客户端与服务器交换公匙时，将客户端的公匙替换成自己的，这样服务器拿到的公匙将不是客户端的，而是服务器的，服务器也无法判断公匙来源的正确性；
  二是中间人可以不替换公匙，但他可以截获客户端发来的消息，进行篡改，然后用服务器的公匙加密再发往服务器，服务器将收到错误的消息。
• 非对称加密的性能相对于对称加密来说会慢上几倍甚至几百倍，比较消耗系统资源。正因如此，HTTPS 将两种加密结合了起来。
  
  

2.数字证书与数字签名
为解决非对称加密中公匙来源的不安全性，可使用数字证书和数字签名来解决。

（1）数字证书的申请

• 用来颁发数字证书的一些专门的权威机构，称其为认证中心(CA)；
• 我们(服务器)可以向这些 CA 来申请数字证书。申请的过程大致是：自己本地先生成一对密匙，然后拿着自己的公匙及其他信息(如企业名称)去 CA 申请数字证书；
• CA 在拿到这些信息后，会选择一种单向 Hash 算法(如常见的 MD5)对这些信息进行加密，加密后的东西称之为摘要；
• 单向 Hash 算法有一种特点是单向不可逆，只要原始内容有一点变化，加密后的数据都将会是千差万别(有很小的可能性会重复)，这样就防止了信息被篡改；
• 生成摘要后，CA 会用自己的私匙对摘要进行加密，摘要加密后的数据称为数字签名；
• 最后，CA 将会把我们的申请信息(包含服务器的公匙)和数字签名整合在一起，由此生成数字证书，然后 CA 将数字证书传递给我们。

（2）数字证书如何起作用
服务器在获取到数字证书后，服务器会将数字证书发送给客户端，客户端需用 CA 的公匙解密数字证书并验证数字证书的合法性。
Q：如何拿到 CA 的公匙?
A：我们的电脑和浏览器中已经内置了一部分权威机构的根证书，这些根证书中包含了 CA 的公匙。

• 之所以是根证书，是因为认证中心是分层级的，即有顶级认证中心，也有下面各个子级的认证中心，是一个树状结构，计算机中内置的是最顶级机构的根证书，根证书的公匙在子级也是适用的。
• 客户端用 CA 的公匙解密数字证书，若解密成功则说明证书来源于合法的认证机构；解密成功后，客户端就拿到了摘要。
• 此时，客户端会按照和 CA 一样的 Hash 算法将申请信息生成一份摘要，并和解密出来的那份做对比，如果相同则说明内容完整，没有被篡改。
• 最后，客户端安全的从证书中拿到服务器的公匙就可以和服务器进行安全的非对称加密通信了。服务器想获得客户端的公匙也可以通过相同方式。

下图用图解的方式说明一般的证书申请及其使用过程：

二、HTTPS原理
HTTPS 没有采用单一的技术去实现，而是根据他们的特点，充分的将这些技术整合进去，以达到性能与安全最大化。
这套整合的技术称之为 SSL(安全套接层)，因此 HTTPS 并非是一项新的协议，它只是在 HTTP 上披了一层加密的外壳。

HTTPS 的建立，先看一下流程图：

把 HTTPS 从建立到断开分为 6 个阶段，12 个过程。
下面对 12 个过程做解释：

• 客户端通过发送 Client Hello 报文开始 SSL 通信。报文中包含客户端支持的 SSL 的指定版本、加密组件列表(所使用的加密算法及密匙长度等)。
• 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
• 服务器发送证书报文。报文中包含公开密匙证书。
• 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
• SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密匙进行加密。
• 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密匙加密。
• 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
• 服务器同样发送 Change Cipher Spec 报文。
• 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
• 应用层协议通信，即发送 HTTP 响应。
• 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。

另外，在以上流程图中，应用层发送数据时会附加一种叫做 MAC的报文摘要。MAC 能够查知报文是否遭到篡改，从而保证报文的完整性。

用图解进行说明：

总结：HTTPS 先利用数字证书保证服务器端的公匙可安全无误的到达客户端；再用非对称加密安全的传递共享密匙；最后用共享密匙安全的交换数据。

三、HTTPS的使用
Q：HTTPS 那么的安全，是不是我们在什么场景下都要去使用 HTTPS 进行通信呢?
A：答案是否定的。

1.HTTPS 虽提供了消息安全传输的通道，但每次消息的加解密十分耗时，消耗系统资源。
因此除非在一些对安全性比较高的场景下，比如银行系统，购物系统中必须要使用HTTPS 进行通信，其他一些对安全性要求不高的场景，没必要使用 HTTPS。

2.使用 HTTPS 需要使用到数字证书，但一般权威机构颁发的数字证书都是收费的，而且价格也是不菲的。
因此对于一些个人网站来讲，若对安全性要求不高，没必要使用 HTTPS。