81e846f5568962a96b77facfad2da8fa
说人话的 HTTPS 协议简述——密码学与 TLS 协议结构篇

最近在整理TLS协议相关的知识内容,最大的感触就是:中文资料大部分都已经过期,并且内容大多晦涩难懂不说,还有很多错漏。实际阅读资料,大部分还是英文资料为主,对于英语渣的我而言,阅读体验十分艰辛。加上TLS1.3协议已经从草稿,发展到开始有实际应用。但是啃RFC英文协议实在是太痛苦了。我想试试能不能用通俗化的一些表达,让理解HTTPS这个过程更加无痛。

HTTPS协议最大的两个主体,一个是非对称的秘钥协商部分(Handshake),另一个是对称加密信息的部分(Record)。其中Record部分说简单也简单,毕竟对称加密大家都熟悉,但说难也实在是难,想理解透彻需要大量密码学基础,光是各种密码学证明的过程就非常艰深了——至少对我来说,这部分我只能做到知其然不知其所以然。

但是Handshake部分则有趣得多,Client和Server双端,如何在不安全的前提下,协商秘钥、交换秘钥,然后建立一条加密的、安全的连接,这个过程的设计十分精妙。无论是经典的2-RTT Handshake,还是TLS1.3上优化的1-RTT Handshake,整个流程的设计思想更加值得学习。当然其中也会有很多艰深的部分,我个人目前的原则是——只看密码学证明的结论,至于一大长串的数学证明过程暂时理解不了,就只能暂时不求甚解

本文会分成三个章节,大致目录如下:

  • 密码学基础与HTTPS结构
    • 密码学目的
    • 常见名词解释
    • Hash
    • MAC
    • DH秘钥协商思想
    • 前向安全
    • TLS协议分层结构
  • 秘钥交换协议
    • 经典2-RTT协商过程
    • Session Ticket机制的1-RTT复用过程
  • TLS1.3的优化

    • 1-RTT Handshake
    • 0-RTT Handshake

    第一章要给后文打个基础,因为很多密码学的算法和名词如果事先并没有接触过的话,后文看Handshake部分很容易一脸“黑人问号”。
    第二章主要会讲解经典的TLS1.2协议上,Handshake的实现流程,这也是目前仍在广泛应用的协议。包括3个随机数,3个KEY,以及单向认证与双向认证等内容。这一章也是我能找到的中文Blog里出错地方最多的地方,三个随机数,三个key,在很多文章里都讲错了。大概这篇应该是最长的一章。
    第三章会结合TLS1.2的内容,讲一下TLS1.3协议上的修改,目前来看,TLS1.3属于未来已来的阶段。各个公司(比如腾讯mmtls)已经结合自己业务特点,做了基于TLS1.3协议的加密封装。重点仍然放在Handshake部分,主要会介绍1-RTT ECDH和 0-RTT-ECDH-ECDHE的Handshake。 最后会介绍一些有价值的博文和资料。

密码学基础

密码学目的

密码学主要目的大体分为:

  • 加密 ( Encryption) : 阻止攻击者读取你的数据
  • 认证 ( Authentication):阻止攻击者在不被发现的情况下改动你的数据
  • 识别 (Identification):阻止攻击者假装你

需要说明的是,加密并不绝对禁止数据拦截,只是保证拦截到的数据无法解密。但这也就牵扯到前向安全这一问题,后文会具体讲解这个问题的来源。

密码学名词

  • plaintext 数据原文,未加密部分
  • ciphertext 数据密文,攻击者可能得到的数据
  • key 用于转换原文与密文,一般来说需要多个Key
  • 对称密码学 转换原文与密文时使用同一个Key
  • 非对称密码学 转换原文与密文时使用不同的key

虽然显得比较废话,但是这部分已经熟悉的朋友可以当做温习。

密码学基础

HASH

一个理想的hash函数H(x)是一个函数映射,把任意长度的输入映射成n-bit的输出, 并且需要保证:

  1. 抵抗碰撞
  2. 单向

哈希的抵抗碰撞是指:如果暴力破解,需要2的n/2次方单位时间,使两个input的哈希相同。
单向是指:已知一个哈希值,需要用2的n次方单位时间,逆向找一个input,使它的哈希与已知哈希相同。
应该是说哈希这个过程是半公开的过程。知道H(x),就可以计算y的H(y)。

top Created with Sketch.