Golang（十）TLS 相关知识（一）基本概念原理

2022-11-23 19:30:26 浏览数 (1)

0. 前言

  • 最近参与一个基于 BitTorrent 协议的 Docker 镜像分发加速插件的开发，主要参与补充 https 协议
  • 学习了 TLS 相关知识，下面对之前的学习做一下简单总结
  • 参考文献：TLS完全指南系列文章

1. 基本原理

  • TLS 依赖两种加密技术：
    • 对称加密（symmetric encryption）
    • 非对称加密（asymmetric encryption）

1.1 对称加密

  • 加密方和解密方共享同一个秘钥 K：
代码语言：javascript复制
加密：C = E(M, K)
解密：M = D(C, K)
  • 攻击者且听到 K 后就可以作为一个中间人伪装成任意一个对象，实现中间人攻击

1.2 非对称加密

  • 非对称加密利用成对的两个秘钥：K1 和 K2，加密者使用一个加密，解密者可以利用另一个解密：
代码语言：javascript复制
加密：C = E(M, K1)
解密：M = D(C, K2)
  • 解密者生成一对秘钥，私钥保存，公钥公开
  • 但是中间人可以截获公钥，然后自己生成一对秘钥，把自己的公钥发送给加密者
  • 用自己的私钥解密加密者的信息，然后用解密者的公钥加密发送给解密者
  • 或者中间人收到解密者公钥加密的消息后，对消息破坏篡改，再发送给解密者
  • 导致解密者无法正确解析密文

1.3 数字签名

  • 光靠非对称加密很难确定信息发送方身份，因此发明了数字签名
    • 根据数字签名，接收方接收到信息之后，可以判断信息是否被破坏过，如果没有被破坏，就可以正确的解码。如果被破坏，就直接丢弃
    • 数字签名可以保证对信息的任何篡改都可以被发现，从而保证信息传输过程中的完整性
    • 数字签名是实现的关键技术就是哈希技术
  • 加密者先对将要传输的信息进行哈希，得到一串独一无二的信息摘要
    • 哈希函数往往是不可逆的，无法根据哈希后的内容推断原文；同时，不同的原文，会造成不同的哈希结果，并且结果的差异是巨大甚至毫无规律的
    • 对原文进行再细微的修改，得到的哈希后的内容都会与未经修改的原文的哈希内容大相径庭，保证消息内容不被篡改
  • 然后，加密者将信息摘要，用自己的私钥进行加密
    • 这样就保证只有加密者的公钥才能对信息摘要进行正确的解码，进而保证信息摘要一定是来自加密者
    • 加密后的信息摘要实际就是数字签名的内容
  • 最后，加密者再将数字签名附加到原文信息的后面，使用解密者公钥加密后发送给解密者
  • 解密者接收到信息之后，首先使用自己的私钥解密报文，分别获得原文和数字签名
    • 利用加密者公钥对数字签名进行解密，得到信息摘要，如果成功解码，就说明数字签名是来自加密者
  • 然后，解密者将信息原文进行哈希得到自己的信息摘要，与解码数字签名得到的信息摘要进行对比，如果相同，就说明原文信息完整，没有被篡改，反之，则确认信息被破坏了
  • 目前为止，利用公钥和私钥以及数字签名，可以保证信息传输过程中的私密性和完整性
  • 但还存在一个问题：就是公钥分发的问题，上述中间人劫持公钥的问题并没有解决
  • 这个问题就需要数字证书和 CA 来解决了

1.4 数字证书和 CA

  • 每个加密者或者接受者都有自己的私钥和公钥，如何判断对方的公钥是真实代表对方的是一个问题
  • 实际我们会引入一个第三方机构，每个人都找这个真实可信的独立的第三方，请求真伪鉴别服务
  • 第三方机构就是 CA（Certification Authorith，证书颁发机构）会给解密者创建一个数字证书
  • 用户首先产生自己的密钥对，并将公钥及部分个人身份信息传送给认证中心
  • 认证中心在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来
  • 然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息”
  • 公钥和身份信息（域名或者IP）合起来就是 CSR（certificate signing request，身份证申请）
  • 实际过程可以看做 CA 利用自己的私钥对 CSR 加密，作为数字签名
  • 然后 CSR 连同 CA 的数字签名构成数字证书，也称为 CRT（CA signed certificate）
  • 在之后的发送中加密者将数字证书附在数字签名后
  • 接收者收到后用 CA 的公钥解密获得，加密者的身份和公钥
  • 攻击者不能通过 CA 的验证，无法生成可信任的证书，解密者接受后判断数字证书包含的身份信息不是加密者，因此会拒绝
  • 当然，如果选择信任了错误的 CA，也会被攻击，通常浏览器中会内置靠谱 CA 的身份证（公钥）

1.4 信任链、根身份证和自签名

  • CA 也分为不同级别，需要逐级验证
  • 比如 CA1 不被大家信任，于是可以将身份信息和公钥发送给受信任的 CA2，获得自己的数字证书
  • CA1 在给其他人签署数字证书时，会在后面附上自己的数字证书
  • 这样接受者首先利用 CA2 的公钥验证 CA1，获得 CA1 的公钥后再验证发送者
  • 这样逐级签署数字证书，形成了一条信任链
  • 最终的根节点就是自签名证书，如 CA2 可以用自己的私钥把自己的公钥和域名加密，生成证书

1.5 应用场景：https 协议

  • 首先，浏览器向服务器发送加密请求
  • 服务器将网页加密，连同自身的数字证书发送给浏览器
  • 浏览器收到返回验证服务器身份，同时服务器也可以验证浏览器身份
    • 浏览器验证服务器是通过 TLS 身份验证实现的，服务器验证浏览器是通过输入用户名密码实现的，通常服务器不会验证浏览器身份
    • 客户端（浏览器）的“证书管理器”，有“受信任的根证书颁发机构”列表。客户端会根据这张列表，查看解开数字证书的公钥是否在列表之内
    • 如果数字证书记载的网址，与你正在浏览的网址不一致，就说明这张证书可能被冒用，浏览器会发出警告
    • 如果这张数字证书不是由受信任的机构颁发的，浏览器会发出另一种警告
    • 如果数字证书是可靠的，客户端就可以使用证书中的服务器公钥，对信息进行加密，然后与服务器交换加密信息

2. 小结

  • 本文整理了一些数字签名、数字证书的知识，之前也有了解，但是一些概念细节理解不很清晰
  • 现在做了整理，方便以后复习。也是对后面的铺垫
  • 欢迎各位批评指正

3. 参考文献

  • TLS完全指南（一）：TLS和安全通信
  • 数字签名和数字证书
  • 数字签名和数字证书究竟是什么？
数据分析 编程算法 https SSL证书

0 人点赞