HTTPS & SSL

HTTPS

HTTPS是在HTTP协议和TCP协议之间套了一层TLS/SSL协议

HTTP默认端口为80，HTTPS默认端口为443

TLS/SSL

TLS/SSL 的功能实现主要依赖于三类基本算法：散列函数 Hash、对称加密和非对称加密，其利用非对称加密实现身份认证和密钥协商，对称加密算法采用协商的密钥对数据加密，基于散列函数验证信息的完整性。

前置知识

散列函数 Hash

常见的有 MD5、SHA1、SHA256，该类函数特点是函数单向不可逆、对输入非常敏感、输出长度固定，针对数据的任何修改都会改变散列函数的结果，用于防止信息篡改并验证数据的完整性。在信息传输过程中，散列函数不能单独实现信息防篡改，因为明文传输，中间人可以修改信息之后重新计算信息摘要，因此需要对传输的信息以及信息摘要进行加密。

对称加密

常见的有 AES-CBC、DES、3DES、AES-GCM 等，信息的加密和解密用相同的密钥，掌握密钥才能获取信息。在对称加密中，信息安全的基础是保证密钥的安全。

非对称加密

即常见的 RSA 算法，还包括 ECC、DH 等算法，算法特点是，密钥成对出现，一般称为公钥(公开)和私钥(保密)。因此掌握公钥的不同客户端之间不能互相解密信息，只能和掌握私钥的服务器进行加密通信。服务器持有私钥可以实现一对多的通信，而客户端可以用公钥来验证服务器发送的数字签名。服务器只需要维持一个私钥就能够和多个客户端进行加密通信，但该算法的计算复杂，加密速度慢。

对称加密与非对称加密 的不同

对称加密中，明文和密文都被认为是符号的组合，加密和解密的过程是把这些符号的次序打乱或用一个符号代替另一个符号。

非对称加密中，明文和密文被作为整数来对待，明文在加密前必须先编码形成整数（或整数的集合），而这个整数（或整数的集合）在解密后必须经过解码才能还原成报文。

1. 明文 → 通过编码 → 加密前的整数

2. 加密前的整数 → 通过加密 → 加密后的整数（密文）

3. 传输密文

4. 加密后的整数（密文）→ 通过解密 → 加密前的整数

5. 加密前的整数 → 通过解码 → 明文

非对称加密的数学计算比对称加密

1. 对称密钥加密术的基础是共享密钥
2. 不对称密钥加密术的基础是个人密钥
3. 在对称密钥加密术中，符号被置换或替代
4. 在非对称密钥加密术中，被处理的都是数值

总结

结合三类算法的特点，TLS/SSL 的基本工作方式是，客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥，然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。

保证报文的完整性和鉴别

报文摘要：报文鉴别码MAC(message authentication code)

把报文和密钥的组合h(K+M)一起通过散列函数加密得到MAC

应用场景：对称加密

数字签名

使用了密钥+公钥的方案

1. 签署人把报文通过私钥使用签名算法来生成签名
2. 传输报文和签名
3. 验证人把报文和签名通过公钥使用验证算法来验证真假

应用场景：报文短的非对称加密

报文摘要+数字签名

1. 报文通过散列函数生成摘要
2. 签署人把摘要通过私钥使用签名算法来生成签名
3. 传输报文和签名
4. 验证人把报文和签名通过公钥使用验证算法来验证真假

应用场景：报文长的非对称加密

PKI & CA

TCP-IP协议族第4版 - P733

CA（Certification authority）认证管理机构

• 基本功能

  • 签发数字证书
  • CA自己密钥的管理
  • 接受证书申请，审核申请者身份
  • 证书管理
  • 提供证书和证书状态的查询

每个CA本身有一套公钥和私钥，私钥必须妥善管理，确保其具备高度的机密性，防止其被伪造而颠覆CA的权威性。

CA通常采用层次的签名架构。这意味着一个公钥可能会被一个父密钥签名，而这个父密钥可能会被一个祖父密钥签名，依次类推。最终，一个证书颁发机构会拥有一个或多个根证书，许多下属的证书都会依赖根证书来建立信任。

在实践中，系统往往要求公钥操作应当拥有知名 CA 的根证书。这些根证书是在配置时安装的 (例如，微软公司的 Intemet ExpIorer 浏览器、 Mozilia 公司的 Firefox 浏览器以及 Google 公司的 Chrome 浏览器都能够访问一个预先配置的根证书数据库)。

具体实现

TCP-IP协议族第4版 - P748

功能

• 分片
• 压缩（可选）

• 报文完整性

  • 使用密钥散列函数来创建MAC

• 保密

  • 原始数据（可选压缩）和MAC一起用对称加密算法加密

• 组帧

  • 先在被加密的有效载荷上添加一个首部，然后再把这个有效载荷传递给可靠的运输层协议（如HTTP）

四个协议

• 记录协议

  • 是一个载体，它运载来自其他三个协议的报文以及来自应用层的数据

• 握手协议

  • 为记录协议提供安全参数
  • 它要建立加密集并提供密钥和安全参数
  • 负责客户对服务器的鉴别以及服务器对客户的鉴别（如有必要）

• 改变加密规约协议

  • 用于通知各项加密用密钥/参数已准备好

• 告警协议

  • 用于报告异常状态

握手协议

• 阶段I：

  • 确定要使用的SSL版本、加密算法、压缩方法以及用于密钥生成的两个随机数

• 阶段II：

  • 服务器密钥的交换和鉴别（用于鉴别服务器身份）

• 阶段III：

  • 客户端密钥的交换和鉴别（用于鉴别客户端身份）
  • 客户端和服务器都掌握了一个前主密

阶段III 的设计是用来鉴别客户端的

• 阶段IV：

  • 互相发送报文以更改加密规约（从非对称加密改成对称加密），并结束握手协议

改变加密规约协议

理解中...

TCP-IP协议族第4版 - P752

告警协议

SSL通过告警协议来报告差错和异常状态。它只使用了一个报文，这个报文描述了问题及其严重程度（warning/error）

记录协议

运载来自上一层（其他三个协议）的报文，这个报文经过分片和压缩（可选）处理，再用协商后的散列算法来计算得到MAC，并将其添加到压缩后的报文。这个压缩后的分片与MAC一起经过协商后的加密算法的加密。最后在加密的报文上加上SSL首部。

加密参数的生成（报文完整性和保密性）

为了实现报文的完整性和保密性，SSL需要四个密钥和两个IV（初始向量）

客户端和服务器各需要一个用于报文鉴定的密钥、一个用于加密的密钥以及一个IV

（SSL要求两个方向的密钥各不相同）

1. 客户端和服务器先交换两个随机数，分别由对方生成
2. 使用预先定义的密钥交换算法来交换一个前主密（pre-master secret）
3. 前主密通过应用两个散列函数（SHA-1和MD5）生成主密（master secret）

1. 通过应用同一组散列函数以及在主密的前面附加不同常量的办法，可以从这个主密中产生变长的密钥材料

1. 并从足够长的密钥材料中提取六个不同的密钥/参数

整个建立的过程（以HTTPS为例，HTTPS一般只要求服务器提供证书）

1. 客户端：Client Hello 报文（客户端支持的SSL版本、加密算法、密钥长度、客户端生成的随机数）
2. 服务器：Server Hello 报文（筛选后的SSL版本、加密算法、密钥长度、服务器生成的随机数）

1. 商定好了接下来要使用的加密组件
2. 交换了随机数，双方都有了随机数s、随机数c
3. 握手协议I 阶段结束

1. 服务器：Certificate 报文（包含公钥的证书）
2. 服务器：Server Hello Done 报文
3. 客户端：向CA确定证书有效性
4. 客户端：Client Key Exchange 报文（合法性验证通过之后，客户端计算产生随机数字 Pre-master，并用证书公钥加密，发送给服务器。）
5. 客户端：通过随机数s、随机数c、前主密生成接下来的对称密钥
6. 服务器：用私钥解密后得到前主密，通过随机数s、随机数c、前主密生成接下来的对称密钥

1. 完成了服务器密钥的交换和鉴别
2. 握手协议II 阶段结束

1. 客户端向服务器发送客户端的公钥，服务器鉴定客户端身份
2. 服务器生成前主密给客户端

HTTPS一般不要求客户端提供证书

1. 完成了客户端密钥的交换和鉴别
2. 双方各掌握了一个前主密
3. 握手协议III 阶段结束

1. 客户端：Change Cipher Spec 报文（通知服务器后续的通信都采用协商的通信密钥和加密算法进行加密通信。）
2. 客户端：Finished 报文（结合之前所有通信参数的 hash 值与其它相关信息生成一段数据，采用协商密钥 session secret 与算法进行加密，然后发送给服务器用于数据与握手验证。）
3. 服务器：Change Cipher Spec 报文
4. 服务器：Finished 报文

1. 互相发送报文以更改加密规约（从非对称加密改成对称加密？），并结束握手协议
2. 握手协议IV 阶段结束

参考资料

• TLS/SSL 工作原理及握手过程详解
• TCP-IP协议族(第4版).pdf
• 图解HTTP.pdf