HTTPS，TLS原理分析

简单介绍

Tansport Layer Security
TLS 已经逐渐取代 SSL
可以简单理解：HTTPS = HTTP + SSL/TLS
TLS运行在TCP之上，HTTP之下，传输层协议，负责HTTP内容的安全传输
TLS流程在TCP三次握手建立连接后开始

TLS协议结构

wireshark中

TLS主要分为两层，底层的是TLS记录协议，主要负责使用对称密码对消息进行加密。

• 上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。
• 握手协议 (HandShake) 负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。
• 密码规格变更协议（Change Cipher Spec）负责向通信对象传递信号, Change Cipher Spec出现后TLS被加密，握手即将完成
• 警告协议（Alert）负责在发生错误的时候将错误传达给对方
• 应用数据协议 (ApplicationData) 负责将TLS承载的应用数据传达给通信对象的协议。

TLS流程（TLS1.2）

两种流程：

RSA简要流程

1. 服务器a生成公钥pk跟私钥sk，公钥公开任何人都可以获得，私钥保密
2. 客户端b获取a的公钥，然后生成一个随机数做会话秘钥，用a的公钥进行加密发送给a
3. a得到加密后的信息，用自己的私钥解密，得到会话秘钥
4. 双方使用会话秘钥加密会话内容进行通信

下面主要介绍ECDHE流程

强烈推荐看这个学习 https://tls12.xargs.org

客户端发送
ClientHello
用于初始化会话消息，该消息主要包含如下信息：
Version Number: 客户端发送它所支持的最高 SSL/TLS 版本
Randomly Generated Data：一个 32 字节的客户端随机数，该随机数被服务端生成通信用的对称密钥（master secret）
Session Identification ：session ID 被客户 端用于恢复之前的会话
Cipher Suite: 客户端发送它所支持的加密套件列表

服务端发送
ServerHello
该消息主要包含如下信息：

• Version Number：服务端发送双发所支持的最高的 SSL/TLS 版本
• Randomly Generated Data：一个 32 字节的服务端随机数，被客户端用于生成通信用的对称密钥（master secret）
• Session Identification：用于会话恢复
• Cipher Suite: 服务端发送双发支持的最安全的加密套件

ServerCertificate：服务端下发SSL证书，客户端用该证书验证服务端的身份
ServerKeyExchange：这个消息是可选的，该消息主要用来传递双方协商密钥的参数
ClientCertificateRequest：这个消息也是可选的，只有当服务端也需要验证客户端身份会用到（双向验证）
ServerHelloDone：告知客户端服务端这边握手相关的消息发送完毕，等待客户端响应

客户端发送
ClientCertificate：如果服务端发送了ClientCertificateRequest消息，那么客户端会发送该消息给服务端，包含自己的证书信息，供服务端进行客户端身份认证
ClientKeyExchange：根据协商的密钥算法不同，该消息的内容会不同，该消息主要包含密钥协商的参数
CertificateVerify：该消息只有在ClientCertificate消息发送时才发送。客户端通过自己的私钥签名从开始到现在的所有发送过的消息，然后服务端会用客户端的公钥验证这个签名
ChangeCipherSpec：通知对方此消息以后会以之前协商的密钥加密发送数据
Finished：客户端计算生成对称密钥，然后使用该对称密钥加密之前所有收发握手消息的 Hash 值，发送给服务器，服务器将用相同的会话密钥（使用相同方法生成）解密此消息，校验其中的Hash 值。该消息是 SSL 握手协议记录层加密的第一条消息

服务端发送
ChangeCipherSpec：通知对方此消息以后会以之前协商的密钥加密发送数据
Finished：服务器使用对称密钥加密（生成方式与客户端相同）之前所发送的所有握手消息的hash值，发送给客户端去校验

CA证书，信任链

CA(Certificate Authority)，即证书认证机构

证书=明文+公钥+签名；
签名：使用散列函数计算公开的明文信息的信息摘要，然后用私钥对信息摘要进行加密，得到的密文即签名
证书的合法性依赖签名的合法性，即依赖非对称算法

证书验证：客户端从服务器获取到证书a后，根据其提供的颁发者信息找到上级证书b(根证书或者中间证书)，使用b的公钥解密a的签名，将解密后的内容与证书的信息摘要对比，如果一致，说明证书a确实是由上级证书b颁发的，如果证书b可信，那么证书a也可信，或者说合法。
根证书：CA机构自己签名自己颁发的证书，没有上级，作为信任链的顶层颁发下层证书，保证下层证书的合法性，通常存放在系统的CA信任仓库内，放入该仓库的证书被认为是可信的。

证书的签发过程：

• 服务方 S 向第三方机构CA提交公钥、组织信息、个人信息(域名)等信息并申请认证；
• CA 通过线上、线下等多种手段验证申请者提供信息的真实性，如组织是否存在、企业是否合法，是否拥有域名的所有权等；
• 如信息审核通过，CA 会向申请者签发认证文件-证书。

密钥协商

1. 客户端连上服务端
2. 服务端发送 CA 证书给客户端
3. 客户端验证该证书的可靠性
4. 客户端从 CA 证书中取出公钥
5. 客户端生成一个随机密钥 k，并用这个公钥加密得到 k’
6. 客户端把 k’ 发送给服务端
7. 服务端收到 k’ 后用自己的私钥解密得到 k
8. 此时双方都得到了密钥 k，协商完成。

ECDHE 算法

DH算法 -- > ECDH算法 -- > DHE 和 ECDHE算法（前向保密）

DH 算法：
总体的思想为
对于公式
A = G ^ a % P
B = G ^ b % P
其中G，P为公开的常数。当已知a时，可以推算出A；反之，当已知A时，几乎无法推算出a。
映射到加密算法中，a为私钥，A为公钥
并且以下两个表达式的计算结果相等
B ^ a % P = A ^ b % P

DH 依赖的是——求解“离散对数问题”的困难。

ECDH 依赖的是——求解“椭圆曲线离散对数问题”的困难。

中间人攻击（MITM）与防范

HTTP是明文，中间人只需要劫持客户端流量并直接解析便可获取HTTP明文信息，然后伪装成客户端转发或者篡改后发给目标服务器，服务器后续也将流量发到中间人这里，整个过程中无声无息的加入了第三方。

HTTPS大多数时候是单向认证，即客户端只验证服务器身份，服务器不验证客户端。
首先说明HTTPS由于SSL/TLS协议的引入和证书认证机制，中间人无法在没有获取客户端信任的情况下获取明文。
中间人劫持了流量，获取了服务器证书和公钥

1. 如果将其转发给客户端，由于不知道服务器私钥，中间人无法解密客户端发给服务器的加密数据。
2. 若想能够解密客户端的流量，就必须有对应的私钥，换一种思路，如果中间人用自己的证书伪装服务器证书，也不行，伪造的证书在客户端的CA仓库内没有对应的根，根据tls协议，客户端会发出带有“Certificate Unknown”的Alert信息并中断Tcp连接。

所以，如果在客户端的CA仓库内放入伪造证书的根证书，即意味着客户端信任中间人，此时https通信可以建立，并且中间人可以解密所有数据。

防范
固定证书（app常用）
双向认证

抓包工具推荐

wireshark
reqable

参考

HTTPS 和 SSL/TLS 协议：密钥交换（密钥协商）算法及其原理
图解TLS
TLS握手以及协议详解
TLS1.2握手流程分析（RSA，ECDHE），和TLS1.3区别