一、HTTPS风险
1.1 风险一: 网络嗅探与监听
用wireshark抓包时发现，途径终端ip的所有http报文都可以以明文方式被直接捕获，包括但不限于用户名、密码、报表数据等。
-
本地src = 10.252.18.21，天枢服务器desc = 172.28.63.46。浏览器通过post方式向服务器发起请求：
image.png -
服务器返回数据：
image.png -
思考：不使用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 具体步骤
-
客户端发起请求，与服务器建立TCP连接（三次握手）
image.png - TLS第一次握手
（1）客户端->服务器 Client Hello
消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，支持的压缩算法，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一。
image.png
注：TLS支持的所有加密算法: Transport Layer Security (TLS) Parameters (iana.org)
（2）服务器→客户端 ACK - 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
目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。
-
客户端验证证书，验证原理如本文3.1-加密机制-数字签名。
image.png
image.png
image.png 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 握手数据都是明文，之后都是对称密钥加密的密文。
- TLS第四次握手
服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。
- 用会话密钥加解密请求与响应
4.3 其他
1.为什么公钥存储在客户端，私钥存储在服务器？
（1）请求是由客户端向特定服务器发起的，客户端只希望特定的服务器能解密，因此https设计成只有持有特定私钥的服务器才能解密的机制。
（2）私钥存储在用户物理机器上，每次请求用户都要输私钥（响应不过来）；私钥存储在浏览器cookie上，容易泄露、被iframe读取；还有一种口令密钥协商的情况（不适合C-S http请求的应用场景）
（3）密码学角度上来说，私钥加密的数据，一定能被公钥解密。无法满足信息的机密性。
2.为什么要用随机数进行对称加密？
保证会话的前向安全性。即使本次会话的会话密钥泄露，也不会影响之前会话的秘密泄露。
