当前位置：首页 > news >正文

HTTPS握手解析

news 来源：原创 2024/5/10 20:51:07

TLS握手过程
- HTTP 由于是明文传输，所谓的明文，就是说客户端与服务端通信的信息都是肉眼可见的，随意使用一个抓包工具都可以截获通信的内容。
- 存在的风险
  - 窃听风险，比如通信链路上可以获取通信内容，用户号容易没。
  - 篡改风险，比如强制植入垃圾广告，视觉污染，用户眼容易瞎。
  - 冒充风险，比如冒充淘宝网站，用户钱容易没。
- HTTPS 在 HTTP 与 TCP 层之间加入了 TLS 协议，来解决上述的风险。
- 如何解决的呢
  - 信息加密： HTTP 交互信息是被加密的，第三方就无法被窃取；
  - 校验机制：校验信息传输过程中是否有被第三方篡改过，如果被篡改过，则会有警告提示；
  - 身份证书：证明淘宝是真的淘宝网；
- 握手过程
  - 每一个「框」都是一个记录（record），记录是 TLS 收发数据的基本单位，类似于 TCP 里的 segment。多个记录可以组合成一个 TCP 包发送，所以通常经过「四个消息」就可以完成 TLS 握手，也就是需要 2个 RTT 的时延，然后就可以在安全的通信环境里发送 HTTP 报文，实现 HTTPS 协议。
  - HTTPS 是应用层协议，需要先完成 TCP 连接建立，然后走 TLS 握手过程后，才能建立通信安全的连接。
  - 不同的密钥交换算法，TLS 的握手过程可能会有一些区别。
  - 因为考虑到性能的问题，所以双方在加密应用信息时使用的是对称加密密钥，而对称加密密钥是不能被泄漏的，为了保证对称加密密钥的安全性，所以使用非对称加密的方式来保护对称加密密钥的协商，这个工作就是密钥交换算法负责的。
- RSA握手过程
  - 传统的 TLS 握手基本都是使用 RSA 算法来实现密钥交换的，在将 TLS 证书部署服务端时，证书文件其实就是服务端的公钥，会在 TLS 握手阶段传递给客户端，而服务端的私钥则一直留在服务端，一定要确保私钥不能被窃取。
  - 第一次握手
    - 客户端首先会发一个「Client Hello」消息，字面意思我们也能理解到，这是跟服务器「打招呼」。
    - 消息里面有客户端使用的 TLS 版本号、支持的密码套件列表，以及生成的随机数（Client Random），这个随机数会被服务端保留，它是生成对称加密密钥的材料之一
  - 第二次握手
    - 当服务端收到客户端的「Client Hello」消息后，会确认 TLS 版本号是否支持，和从密码套件列表中选择一个密码套件，以及生成随机数
    - 接着，返回「Server Hello」消息，消息里面有服务器确认的 TLS 版本号，也给出了随机数（Server Random），然后从客户端的密码套件列表选择了一个合适的密码套件
    - 密码套件基本的形式是「密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法」
    - 一般 WITH 单词前面有两个单词，第一个单词是约定密钥交换的算法，第二个单词是约定证书的验证算法。
    - 就前面这两个客户端和服务端相互「打招呼」的过程，客户端和服务端就已确认了 TLS 版本和使用的密码套件，而且你可能发现客户端和服务端都会各自生成一个随机数，并且还会把随机数传递给对方。
    - 这两个随机数是后续作为生成「会话密钥」的条件，所谓的会话密钥就是数据传输时，所使用的对称加密密钥。
    - 服务端为了证明自己的身份，会发送「Server Certificate」给客户端，这个消息里含有数字证书。
    - 服务端发了「Server Hello Done」消息，目的是告诉客户端，我已经把该给你的东西都给你了，本次打招呼完毕。
  - 客户端验证证书
    - 数字证书和CA机构
      - 一个数字证书通常包含了：
        
        公钥；
        
        持有者信息；
        
        证书认证机构（CA）的信息；
        
        CA 对这份文件的数字签名及使用的算法；
        
        证书有效期；
        
        还有一些其他额外信息；
      - 数字证书的作用
        
        是用来认证公钥持有者的身份，以防止第三方进行冒充。
      - 数字证书的来源和CA机构的
        
        为了让服务端的公钥被大家信任，服务端的证书都是由 CA （Certificate Authority，证书认证机构）签名的，CA 就是网络世界里的公安局、公证中心，具有极高的可信度，所以由它来给各个公钥签名，信任的一方签发的证书，那必然证书也是被信任的。
        
        之所以要签名，是因为签名的作用可以避免中间人在获取证书时对证书内容的篡改
      - 数字证书签发
      - 证书链
        
        证书的验证过程中还存在一个证书信任链的问题，因为我们向 CA 申请的证书一般不是根证书签发的，而是由中间证书签发的
        
        比如百度的证书
        
        操作系统里一般都会内置一些根证书
        
        为什么需要证书链这么麻烦的流程？
        
        为了确保根证书的绝对安全性，将根证书隔离地越严格越好，不然根证书如果失守了，那么整个信任链都会有问题。
  - 第三次握手
    - 客户端验证完证书后，认为可信则继续往下走
    - 客户端就会生成一个新的随机数，用服务器的 RSA 公钥加密该随机数，通过「Client Key Exchange」消息传给服务端
    - 服务端收到后，用 RSA 私钥解密，得到客户端发来的随机数
    - 客户端和服务端双方都共享了三个随机数，分别是 Client Random、Server Random、pre-master。
    - 于是，双方根据已经得到的三个随机数，生成会话密钥（Master Secret），它是对称密钥，用于对后续的 HTTP 请求/响应的数据加解密。
    - 生成完「会话密钥」后，然后客户端发一个「Change Cipher Spec」，告诉服务端开始使用加密方式发送消息。
    - 客户端再发一个「Encrypted Handshake Message（Finishd）」消息，把之前所有发送的数据做个摘要，再用会话密钥（master secret）加密一下，让服务器做个验证，验证加密通信「是否可用」和「之前握手信息是否有被中途篡改过」。
    - 「Change Cipher Spec」之前传输的 TLS 握手数据都是明文，之后都是对称密钥加密的密文。
  - 第四次握手
    - 服务器也是同样的操作，发「Change Cipher Spec」和「Encrypted Handshake Message」消息，如果双方都验证加密和解密没问题，那么握手正式完成。
- RSA算法的缺陷
  - 使用 RSA 密钥协商算法的最大问题是不支持前向保密。
  - 因为客户端传递随机数（用于生成对称加密密钥的条件之一）给服务端时使用的是公钥加密的，服务端收到后，会用私钥解密得到随机数。所以一旦服务端的私钥泄漏了，过去被第三方截获的所有 TLS 通讯密文都会被破解。
  - 为了解决这个问题，后面就出现了 ECDHE 密钥协商算法，我们现在大多数网站使用的正是 ECDHE 密钥协商算法