Jacky's blog
首页
  • 学习笔记

    • web
    • android
    • iOS
    • vue
  • 分类
  • 标签
  • 归档
收藏
  • tool
  • algo
  • python
  • java
  • server
  • growth
  • frida
  • blog
  • SP
  • more
GitHub (opens new window)

Jack Yang

编程; 随笔
首页
  • 学习笔记

    • web
    • android
    • iOS
    • vue
  • 分类
  • 标签
  • 归档
收藏
  • tool
  • algo
  • python
  • java
  • server
  • growth
  • frida
  • blog
  • SP
  • more
GitHub (opens new window)
  • https

    • prerequisite
      • 证书
      • 加密方案
    • HTTPS 协议的总体思路
      • link
      • other
      • 网络
      Jacky
      2023-04-28
      目录

      https

      # prerequisite

      # 证书

      这种由权威部门颁发的称为证书。有权威机构去认证, 这个机构叫 CA(Certificate Authority)

      证书里面有什么
      • 公钥
      • 所有者
      • 发布机构和证书有效期
      1. 创建私钥:openssl genrsa -out cliu8siteprivate.key 1024

      2. 根据这个私钥创建公钥: openssl rsa -in cliu8siteprivate.key -pubout -out cliu8sitepublic.pem

      3. 证书请求: openssl req -key cliu8siteprivate.key -new -out cliu8sitecertifiacte.req

      • req 命令用于生成证书请求(CSR)。-key 参数指定用于签署请求的私钥,-new 表示创建新的证书请求,-out 指定输出请求文件
      1. 证书的签名: openssl x509 -req -in cliu8sitecertifiacte.req -CA cacertificate.pem -CAkey caprivate.key -out cliu8sitecertificate.pem
      • 将生成的证书请求 (cliu8sitecertifiacte.req) 发送给权威证书机构(CA),CA 会用其私钥对该请求签名并生成签名后的证书
      1. 查看证书内容: openssl x509 -in cliu8sitecertificate.pem -noout -text

      # 加密方案

      为了同时兼顾安全和效率, 我们通常结合使用公钥算法和私钥算法:

      • 首先, 发送方使用对称算法对原始信息进行加密
      • 接收方通过公钥机制生成一对密钥, 一个公钥, 一个私钥
      • 接收方 将公钥发送给 发送方
      • 发送方用公钥对对称算法的密钥进行加密, 并发送给接收方
      • 接收方用私钥进行解密得到对称算法的密钥
      • 发送方再把已加密的原始信息发送给接收方
      • 接收方使用对称算法的密钥进行解密

      # HTTPS 协议的总体思路

      img

      1. Client 会发送 Client Hello 到服务器, 以明文传输 TLS 版本信息, 加密套件候选列表, 压缩算法候选列表等信息。还有个随机数, 在协商密钥的时候使用

      2. Server 返回 Server Hello 信息, 告诉客户端, 服务器选择用的协议版本, 加密套件, 压缩算法等, 还有一个随机数, 用于后续协商密钥

      3. Server 返回服务器证书, 然后说 "Server Hello Done"

      4. Client 从自己信任的 CA 仓库中, 那 CA 的证书公钥去解密外卖网站的证书。如果解密成功, 则说明外卖证书可信。这个过程可能会不断线上追溯 CA, CA 的 CA, CA 的 CA 的 CA, 反正知道一个授信的 CA, 就可以了

      5. 客户端计算 pre-master 随机数, 发送 Client key exchange, 用证书中的公钥加密, 发给服务器。服务器通过私钥解密 pre-master 随机数

      • 目前有 3 个随机数, 分别是: 自己的, 对端的, 以及刚刚生成的 pre-master 随机数.通过这 3 个随机数, 在 Clent 和 Server 端产生相同的对称密钥 master secret
      1. Client 可以说 "Change Clipher Spec" 。以后采用协商的通信密钥和加密算法进行通信, 对称密钥通信
      2. Client 发送一个 Encrypted Handshake Message,将协商好的参数, 采用协商密钥加密, 发送给 Server 用于数据与握手验证
      问题: 为什么不能只用一个 pre-master 作为之后加密的对称密钥?

      虽然只有服务器有私钥, 能够解密 pre-master 呀, 但仅用它作为 master secret 是不够安全的, 这是因为要以防客户端的 pre-master 并不是随机数的情况。所以加上另外两个随机数 client-random 以及 server-random(而这两个随机数和时间有相关性), 这样就能保证最后生成的 master secret 一定是随机数

      # link

      • 刘超《趣谈网络协议-15》
      上次更新: 2025/10/09, 23:53:03
      最近更新
      01
      npx 使用指南
      10-12
      02
      cursor
      09-28
      03
      inspect
      07-20
      更多文章>
      Theme by Vdoing | Copyright © 2019-2025 Jacky | MIT License
      • 跟随系统
      • 浅色模式
      • 深色模式
      • 阅读模式