4. 只不过https基于tls连接

TLS握手

这一段非常硬核, 因为 TLSv1.2基于EC Diffee-Hellman算法

因此TLS的握手过程基本上也是在实现这个算法

我当时也是脑抽了, 坚持要把TLS握手过程啃完

你可以不用看跳过的

Phase-1

• ClientHello: 客户端先打招呼, 主要目的是沟通一下TLS版本, 提供一个客户端随机字符串, 以及加密要使用的套件, 备选方案有AES-128-GCM/CHACHA-20...(有点眼熟呢?)

• ServerHello: 服务端也打招呼, 确认一下TLS版本,在我们的例子里(以及你在大多数现实生活中的例子里), 基本上客户端都会说最低支持TLS1.0, 然后服务端选择使用TLS1.2 . 然后服务端也生成一个随机字符串, 并挑了一种加密方式, 在我们的例子里最后挑了AES-128-GCM

• Certificate: 一通假寒暄过后要开始干正事了, 首先服务端会把自己的证书发来, 然后客户端要验证一下证书的真伪, 防止假冒的(证书的真伪验证我们已经在上一节讲过了)

• Server Key Exchange: 开始秘钥参数交换, 我们要使用一种叫ECDHE的算法, 从服务端开始, 生成服务端的秘钥, 把秘钥生成的参数发过去

• Client Key Exchange: 紧接着是客户端, 它也要生成自己客户端的秘钥, 于是也把参数发过去

到这里我们称呼他为第一阶段, 需要记一下, 我们把证书已经发给了客户端, 同时我们彼此互相交换了 随机字符串 + 秘钥参数, 因为双方都有客户端+服务端秘钥参数, 双方都能计算出一个Pre-Master秘钥

Ok我们已经接近最后一步了, 还记得那俩随机字符串吗? 我们还没用上呢, 现在两个人都拿着PreMaster, 也都知道双方的随机字符串, 现在计算正式的会话秘钥-MasterSecret

Phase-2

• Change Cipher Spec & Encrypted Handshake Msg

  • 现在服务器跟客户端两个人自己算出了自己这边的MasterSecret, 但是都是自己算出来的, 也不确定到底对不对,因此双方会最后发一个Encrypted Handshake来校验一下自己算出来的秘钥对不对

  • TLS握手过程结束, 从下一个请求开始, 双方开始使用秘钥加密通讯内容

之后呢?

我们可以看到TLS握手有好多个步骤, 但是被塞进了四个TCP-RTT里面 (即一个RTT会发好几个包), 这样就是四轮, 加上tcp的三个RTT的握手, 光是实现https就用了 7个RTT, 但是我们获得了一个经过加密的, 安全的, 可以直接拿来用的 TLS 链接对象(基于TCP):

• 如果没有TLS握手/TLS协议, 我们直接把HTTP协议放在TCP上

• 有了TLS之后, 我们把HTTP放在TLS链接对象上.

也就是说HTTP报文整体, 成了TLS的正文部分, 你的HTTPS报文会先发到对方的443端口上. 由443端口的服务负责解密TLS报文正文, 并把TLS报头抽走, 使这条消息变成一个纯粹的HTTP报文, 最后由你的网页后端服务负责处理