【学习笔记】TLS/SSL握手之Records

TLS / SSL会话是由记录（Records）所组成，有4种records
- Handshake
- Alert
- Change Cipher Spec
- Application Data
Handshake和Alert Records被分为子类型（Subtypes）：
- Handshake：Client Hello
- Handshake：Server Hello
- Alert：Handshake Failure
- 还有许多其他子类型...本篇不一一赘述
SSL会话举例
- 下图即TLS会话 -- 一连串不同记录的交换
  - 我们知道，TLS会话的前2个消息是Client Hello和Server Hello；Client Hello是一个握手协议记录，子类型是Client Hello
  - 这些记录的目的：防止TLS会话受限于IP数据大小
  - 有时，一条记录通过单个数据包发送
  - 有时，多条记录也会通过单个数据包发送
  - 也有些时候，一条记录会通过多个数据包发送
  - 记录不受 IP 数据包（datagram）长度的限制
每个记录都以记录头（Record Header）开始
- 分为4个部分：Record Type；SSLTLS Version；Record Length；Record Payload
- Record Type
  - Change Cipher Spec
    - 表明发送者已准备好安全通话所需的一切
      - 密码套件和会话密钥
    - 由Client和Server独立发送
      - CCS之后发送的所有内容都是加密的
    - Record Payload是二进制的0000 0001
      - Length：1 byte
  - Alert - 一方发送给另一方的信息通知
    - 内容包含2部分：
      - Severity（严重程度）
        01 - Waring - 会话继续
        02 - Fatal（致命的） - 会话终止
      - Description
        通知详细信息（描述是什么导致了警告）
    - Sent unencrypted
      - 除非是在Change Cipher Spec之后发送（因为每个在CCS之后发送的都是加密的）
  - Handshake
    - TLS/SSL协议信息
    - 归类为子类型（Sub-Types）
    - Sent unencrypted
      - 除了特定领域的特定子类型
  - Application Data
    - 由 SSL/TLS 保护的批量数据
      - Confidentiality → Symmetric Encryption
      - Integrity，Authentication → M.A.C
    - TLS计算出下面两者的M.A.C
      - Record Header，记录头
      - Plaintext Data，明文数据
    - TLS加密
      - Plaintext Data
      - MAC Digest
      - Padding
    - 发生的顺序非常重要，TLS执行MAC-then-Encrypt，先计算MAC，再加密
      - 解密后才能检测到密文的修改
      - No Integrity on Padding（因为Padding不包含在MAC内，意味着别人可以修改数据包里的Padding，而接收方检测不到）
      - 产生不良后果
        Solution：Use AEAD Ciphers（其好处是同时做MAC和加密）
    - AEAD （Authentication Encryption with Associated Data）do MAC-and-Encrypt
      - AE = Integrity + Encryption
      - AD = Integrity Only
    - TLS 1.3 - all ciphers are AEAD
    - TLS 1.2 - AES-GCM，ChaCha20-Ploy1305
    - AEAD是未来