网络传输是怎么保证安全的

通信加密技术

不加密

• 不安全，密码等内容明文在网络中传递

简单加密（对称加密）

• 必然有一个传递秘钥的过程，此过程不安全
• 如果线下传递秘钥，代价大，不方便
• 如果线上传递秘钥，只要传递秘钥的过程被中间窃取，则后续内容都可以被第三方解密掉

非对称加密

• 技术概念
  • 一次生成公私秘钥；公钥的加密内容，无法通过公钥解密；私钥类似；只能一方加密，对方解密
  • 自己把消息用私钥加密，发送出去，对方用公钥可以解密–》此过程的网络传输可以被拦截，可以获取对外传输的内容
  • 对方把消息用公钥加密，发送过来，自己用私钥可以解密–》网络拦截没法用公钥解密，没法获取内容
• 加解密过程
  1. 将消息内容转变成 正整数m（字符串取unicode码/ascii码）
  2. 发送方算法处理，从 正整数m 计算出 正整数c
  3. 接收方算法处理，将 正整数c 计算出 正整数m
  4. 将 正整数m 按照编码号，转回成 字符串，即 原消息内容
• RSA算法
  1. 随机取两个不相等的大质数(p,q)
  2. n = p * q
  3. n 转化为二进制的总长度，称为秘钥位数，一般要求该位数达到1024，确保安全(已知被破解的最长是700+位)
  4. 通过算法计算出两个数e、d
  5. 封装（n,e）做公钥， 封装 （n,d）做私钥
• RSA 算法补充
  • 按照算法：公钥(n,e) 只能加密小于n的整数m
  • 解决办法1： 把长消息分段
  • 解决办法2： 先对称加密一次，缩短长度

https加密流程

大致流程

1. "client hello"消息：客户端通过发送"client hello"消息向服务器发起握手请求，该消息包含了客户端所支持的 TLS 版本和加密方式，以供服务器进行选择，还有一个"client random"随机字符串。
2. "server hello"消息：服务器发送"server hello"消息对客户端进行回应，该消息包含了数字证书，服务器选择的加密方式和"server random"随机字符串。
3. 验证：客户端对服务器发来的证书进行验证，确保对方的合法身份
   • 域名，证书有效期，签名 等
   • 服务器端的公钥
4. “premaster secret"字符串：客户端生成另一个随机字符串"premaster secret (预主密钥)”，用 公钥加密后发给服务器
5. 使用私钥：服务器使用私钥解密"premaster secret"。
6. 生成共享密钥：客户端和服务器均使用 client random，server random 和 premaster secret，并通过相同的算法生成相同的共享密钥 KEY。
7. 客户端就绪：客户端发送经过共享密钥 KEY加密过的"finished"信号。
8. 服务器就绪：服务器发送经过共享密钥 KEY加密过的"finished"信号。
9. 达成安全通信：握手完成，双方使用对称加密进行安全通信。

证书验证

1. 解密前的证书对象
   • 明文证书内容
     • 服务端的公钥
     • 证书的信息
     • 服务器的注册信息
   • ”数字签名“：明文证书内容，先做hash，再用CA机构的私钥做加密
2. 客户端本地事先保存了权威CA证书机构的公钥
3. 客户端用CA的公钥解密“数字签名”； 用明文里的hash算法，算hash
4. 比较 解密后的hash vs 自己计算的hash
5. 如果内容被修改，两份hash必然对不上

参考链接 https://img2018.cnblogs.com/blog/1169376/201910/1169376-20191009111543085-161187219.png

证书申请

1. 本地生成公钥/私钥
2. 提交申请信息： 域名，公钥，申请者信息
3. CA 人工审核后，返回证书

证书链

• 目的
  1. 提升颁证效率
  2. 隔离开根证书
• 使用方法概述：
  • ”每一级证书都有签名值，根证书使用自己的根CA公钥验证自己的签名，也用来验证中间证书的签名值，中间证书的公钥用来验证下一级的服务器实体证书签名值，以此构成一条信任链“
  • https://img2020.cnblogs.com/blog/1110857/202104/1110857-20210427234304719-1149954198.png
• 证书链验证过程
  1. 一次性获得整个证书链
  2. 用本地的CA公钥，解密“根证书”的签名；再对明文证书内容做hash, 对比解密值与hash值
  3. 用本地的CA公钥，解密“中间证书”的签名；再对明文证书内容做hash, 对比解密值与hash值
  4. 取出”中间证书“内容里的公钥，解密“服务器证书”的签名；再对明文证书内容做hash, 对比解密值与hash值
  5. 取出”服务器证书“内容里的公钥，即 服务器的公钥，流程结束

证书安全

• 还有什么风险
  1. 私钥泄露
  2. 主动信任了不可靠的证书
  3. 重复签发
     • 黑客自己生成一份公私钥，用公钥注册一个签名，域名是google
     • 当用户请求google时，黑客拦截请求，返回自己申请的证书
     • 用户验证证书通过，以为目标是真的google
     • 用户与黑客建立SSL连接，发起若干请求；中间人再跟真实的google建立SSL
     • 就可以 窃取/篡改 通信内容
• 案例
  1. 存在证书提供商被黑客攻破的历史记录，黑客拿到网站证书，就可以做截获/篡改双方通信内容
  2. 法国/美国情报局故意伪造证书窃取数据
• 怎么安全起来
  • 证书透明度 计划
    • 生成证书时，同时生成一份唯一id；用区块链的方式全网广播
    • 全网都可以审计证书签发
    • google 基于此，提供了一个查询服务，供浏览器查询某证书是否伪造

SSL 远程登录

结论: 如果首次连接时有中间人，没法保证安全

• 步骤
  1. 客户端发送登录请求
  2. 服务端返回公钥
  3. 客户端用公钥加密 登录的用户名/密码
  4. 服务端验证，返回私钥加密后的内容
  5. 客户端用公钥解密
• 说明：
  一般在步骤2的时候，会出现如下内容。

The authenticity of host 'host (1.1.1.1.1)' can't be established.
　　    RSA key fingerprint is 98:2e:d7:e0:de:9f:ac:67:28:c2:42:2d:37:16:58:4d.
　　    Are you sure you want to continue connecting (yes/no)?

• 这个内容里的中间一段就是远程机器的公钥，需要人工校验改公钥是否匹配
• 因为这里是会被篡改的，

总结： 通信安全演进过程说明

1. 明文传输
    - 可以窃听，可以中间人修改
2. 对称加密
    - 通信过程安全
    - 但是有一个前提：第一次通信时”传递秘钥“过程没有被窃听
3. 非对称加密
    - 双方对外广播公钥；发送消息时，用对方的公钥加密；接受消息时，用自己的私钥解密
    - 不足：可以防窃听，不能防冒充；发消息时只需要接收方公钥，没有提供发送方自己身份证明的环节
4. 数字签名
    - Bob向Alice发送消息时，用自己的私钥对消息内容计算出一个”签名“，该签名只有用Bob的公钥才能解析出来
    - Alice收到消息后，先用Bob的公钥解析签名，能成功就是真的Bob
    - 遗留问题
        1. 签名的计算消耗较大
5. 内容摘要
    - 对消息内容，先计算出一个摘要（Hash等方式）
    - 对 较简介，且无实际含义的"摘要"，计算”签名“
    - 接收方：
        1. 取出”签名“，公钥解密 计算出”摘要1“
        2. 去除明文的”正文“，hash计算出”摘要2“
        3. 比较两份摘要，相同则数据正常
    - 遗留问题
        1. 需要有一个明文的正文；可以防篡改，不能防窃听了 
        2. 三方可以广播自己的公钥，冒充真正的Bob的公钥   
6. 数字证书
    - 通过公认的机构来登记注册 公钥 - 身份 的关系
    - 证书颁布机构（CA）将 Alice的注册信息 用CA的私钥进行签名，”注册信息“+“签名”整理成一个”证书“
    - 网络通信时，先传递证书，证书内容签名解析成功，且与发送方信息匹配，则表示对方是真实的目标
    - CA的公钥被广泛保存在各个浏览器、操作系统的基础文件里，不需要网路传递