一、HTTPS 危险

1.1 危险一: 网络嗅探与监听

用 wireshark 抓包时发现，路径终端 ip 的所有 http 报文都能够以明文形式被间接捕捉，包含但不限于用户名、明码、报表数据等。

• 本地 src = 10.252.18.21，天枢服务器 desc = 172.28.63.46。浏览器通过 post 形式向服务器发动申请：
  
• 服务器返回数据：
  

• 思考：不应用 https 的状况下，应该如何解决客户端输出的口令 / 提交的表单以保证数据机密性？
  前端：
  将明文数据用 md5 哈希;
  将哈希过的密文拼上一段随机生成的, 固定长度的盐;
  将上一步的后果应用后端的公钥加密并传递给后端.

  后端：
  将前端传递过去的密文用私钥解密;
  去盐。因为盐是固定长度的, 所以间接裁剪即可;
  再次随机生成一段盐;
  将第 2 步去盐后的明码拼上第 3 步生成的盐, 并作 md5 哈希;
  将第 4 步的后果和第 3 步生成的盐存入数据库；

  验证明码的时候, 后端只需将第 2 步去盐后的明码拼上从数据库中获得的盐, 作 md5 哈希后与数据库中的明码相比拟即可。

1.2 危险二：身份认证不足校验，存在中间人攻打。

1.3 危险应答措施

• 信息加密
  HTTP 交互信息是被加密的，第三方就无奈被窃取。
• 校验机制
  校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有正告提醒。
• 身份证书
  证实通信单方身份的真实性。

二、HTTPS 协定

2.1 HTTPS

HTTPS 协定是由 HTTP 加上 TLS/SSL 协定 构建的可进行加密传输、身份认证的网络协议，次要通过 数字证书、对称加密、非对称加密 等技术实现互联网数据传输加密，实现互联网传输平安爱护。

设计指标次要有三个。
（1）机密性（通过对称加密实现）：保障传输数据内容不会被第三方通晓。就像快递员传递包裹一样，都进行了封装，他人无奈获知外面装了什么。

（2）完整性（通过数字签名 / 哈希实现）：保障传输数据内容没有被第三方篡改。就像快递员尽管不晓得包裹里装了什么货色，但他有可能中途掉包，数据完整性就是指如果被掉包，咱们能轻松发现并拒收。

（3）可靠性（通过非对称加密实现）：保障传输数据内容只会被指定有权限的通信方收到。就像咱们邮寄包裹时，尽管是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错中央，通过身份校验来确保送对了中央。

2.2 SSL

Secure Socket Layer，安全套接字协定，用以保障在 Internet 上数据传输的平安，利用数据加密技术，保障传输数据的机密性、完整性、可靠性。

SSL 是一个不依赖于平台和使用程序的协定，位于 TCP/IP 协定与各种应用层协定之间，为数据通信进步平安反对。

SSL 协定次要分为两层：

（1）SSL 握手协定层：包含 SSL 握手协定（SSL HandShake Protocol）、SSL 明码参数批改协定（SSL Change Cipher Spec Protocol）和 SSL 告警协定（SSL Alert Protocol）。握手层的这些协定用于 SSL 治理信息的替换，容许利用协定传送数据之间互相验证，协商加密算法和生成密钥等。

（2）SSL 记录协定层：为高层协定提供根本的平安服务。SSL 纪录协定针对 HTTP 协定进行了特地的设计，使得超文本的传输协定 HTTP 可能在 SSL 运行。纪录封装各种高层协定，具体实施压缩解压缩、加密解密、计算和校验 MAC 等与平安无关的操作。

2.3 TLS

TLS（Transport Layer Security，传输层平安协定）建设在 SSL 3.0 协定标准之上，是 SSL 3.0 的后续版本。与 SSL 次要的区别在于反对的加密算法不同。
TLS 对于安全性的改良：

1）对于音讯认证应用密钥散列法：TLS 应用“音讯认证代码的密钥散列法”（HMAC），当记录在凋谢的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0 还提供键控音讯认证，但 HMAC 比 SSLv3.0 应用的（音讯认证代码）MAC 性能更平安。

2）加强的伪随机性能（PRF）：PRF 生成密钥数据。在 TLS 中，HMAC 定义 PRF。PRF 应用两种散列算法保障其安全性。如果任一算法裸露了，只有第二种算法未裸露，则数据依然是平安的。

3）改良的已实现音讯验证：TLS 和 SSLv3.0 都对两个端点提供已实现的音讯，该音讯认证替换的音讯没有被变更。然而，TLS 将此已实现音讯基于 PRF 和 HMAC 值之上，这也比 SSLv3.0 更平安。

4）统一证书解决：与 SSLv3.0 不同，TLS 试图指定必须在 TLS 之间实现替换的证书类型。

5）特定警报音讯：TLS 提供更多的特定和附加警报，以批示任一会话端点检测到的问题。TLS 还对何时应该发送某些警报进行记录。

三、加解密算法

3.1 非对称加密

3.1.1 特点

加密密钥≠解密密钥，公钥和私钥之间存在数学上的配对关系。

公钥：公开的，用于加密或者验签。应用公钥加密的数据，只能应用对应私钥解密
私钥：机密的，用户解密或者签名。应用私钥签名的数据，能够应用对应的公钥验签。

3.1.2 加密机制

公钥明码：公钥加密失去密文，私钥解密失去明文音讯。

数字签名
)：私钥加密生成签名，公钥解密验证签名

TLS 罕用非对称加密、密钥协商算法：

TLS 罕用签名算法：

ECDSA 具体：https://zhuanlan.zhihu.com/p/66794410

ECC（ECDSA）与 RSA 相比，有以下的长处：
a. 雷同密钥长度下，平安性能更高，如 160 位 ECC 曾经与 1024 位 RSA、DSA 有雷同的平安强度。
b. 计算量小，处理速度快，在私钥的处理速度上（解密和签名），ECC 远 比 RSA、DSA 快得多。
c. 存储空间占用小 ECC 的密钥尺寸和零碎参数与 RSA、DSA 相比要小得多，所以占用的存储空间小得多。
d. 带宽要求低使得 ECC 具备宽泛得利用前景。

留神：不要抉择 1024bit 及以下的 RSA 算法做 HTTPS 的加密，倡议应用 2048bit 以上的 RSA。ECDHE+AESGCM 最先选，目前没有已知破绽。

3.2 对称加密

3.2.1 特点

加密密钥 = 解密密钥。
TLS 罕用对称加密算法：AES，次要有四种操作解决，别离是密钥加法层(也叫轮密钥加，英文 Add Round Key)、字节代换层(SubByte)、行位移层(Shift Rows)、列混同层(Mix Column)。

四、HTTPS 通信流程

4.1 概览

4.2 具体步骤

1. 客户端发动申请，与服务器建设 TCP 连贯（三次握手）
   
2. TLS 第一次握手
   （1）客户端 -> 服务器 Client Hello
   音讯外面有客户端应用的 TLS 版本号、反对的明码套件列表，反对的压缩算法，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的资料之一。
   
   注：TLS 反对的所有加密算法: Transport Layer Security (TLS) Parameters (iana.org)
   （2）服务器→客户端 ACK
3. TLS 第二次握手
   （1）服务器 -> 客户端 Server Hello

当服务端会确认 TLS 版本号是否反对，和从明码套件列表中抉择一个明码套件，以及生成随机数（Server Random）。

接着，返回「Server Hello」音讯，音讯外面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），而后从客户端的明码套件列表抉择了一个适合的明码套件。

能够看到，服务端抉择的明码套件是“Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256”。

这个明码套件看起来真让人头晕，好一大串，然而其实它是有固定格局和标准的。根本的模式是「密钥替换算法 + 签名算法 + 对称加密算法 + 摘要算法」，个别 WITH 单词后面有两个单词，第一个单词是约定密钥替换的算法，第二个单词是约定证书的验证算法。比方方才的明码套件的意思就是：

因为 WITH 单词只有一个 RSA，则阐明握手时密钥替换算法和签名算法都是应用 RSA；
握手后的通信应用 AES 对称算法，密钥长度 128 位，分组模式是 GCM；
摘要算法 SHA256 用于音讯认证和产生随机数；

就后面这两个客户端和服务端互相「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和应用的明码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。

那这个随机数有啥用呢？其实这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所应用的对称加密密钥。

注：配置 https 时，加密套件的安全性:

ECDHE+AESGCM 最先选，目前没有已知破绽。
PFS ciphersuite 优先，其中 ECDHE 优先于 DHE
SHA256 优先于 SHA1。齐全禁用 MD5。
AES 128 优先于 AES 256。这个问题有一些探讨。
在向后兼容模式中，AES 优先于 3DES。
齐全禁止 RC4。3DES 只用于兼容老版本。

（2）服务器 -> 客户端 Server Certificate
服务端为了证实本人的身份，会发送「Server Certificate」给客户端，这个音讯里含有数字证书。

（3）服务器→客户端 Server Hello Done
目标是通知客户端，我曾经把该给你的货色都给你了，本次打招呼结束。

4. 客户端验证证书，验证原理如本文 3.1- 加密机制 - 数字签名。
   
   
   
5. TLS 第三次握手

客户端验证完证书后，认为可信则持续往下走。接着，客户端就会生成一个新的随机数 (pre-master)，用服务器的 RSA 公钥加密该随机数，通过「Change Cipher Key Exchange」音讯传给服务端。

服务端收到后，用 RSA 私钥解密，失去客户端发来的随机数 (pre-master)。

至此，客户端和服务端单方都共享了三个随机数，别离是 Client Random、Server Random、pre-master。

于是，单方依据曾经失去的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 申请 / 响应的数据加解密。

生成完会话密钥后，而后客户端发一个「Change Cipher Spec」，通知服务端开始应用加密形式发送音讯。

而后，客户端再发一个「Encrypted Handshake Message（Finishd）」音讯，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信是否可用和之前握手信息是否有被中途篡改过。

能够发现，「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。

6. TLS 第四次握手

服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」音讯，如果单方都验证加密和解密没问题，那么握手正式实现。

7. 用会话密钥加解密申请与响应

4.3 其余

1. 为什么公钥存储在客户端，私钥存储在服务器？

（1）申请是由客户端向特定服务器发动的，客户端只心愿特定的服务器能解密，因而 https 设计成只有持有特定私钥的服务器能力解密的机制。

（2）私钥存储在用户物理机器上，每次申请用户都要输私钥（响应不过去）；私钥存储在浏览器 cookie 上，容易泄露、被 iframe 读取；还有一种口令密钥协商的状况（不适宜 C -S http 申请的利用场景）

（3）密码学角度上来说，私钥加密的数据，肯定能被公钥解密。无奈满足信息的机密性。

2. 为什么要用随机数进行对称加密？

保障会话的前向安全性。即便本次会话的会话密钥泄露，也不会影响之前会话的机密泄露。