http协议安全篇

2021-06-11

HTTPS 是什么？SSL/TLS 又是什么？
1. HTTPS 解决的问题
  通常认为，如果通信过程具备了四个特性，就可以认为是“安全”的，这四个特性是：机密性、完整性，身份认证和不可否认。
2. SSL/TSL 运行在HTTP下层，TCP上层
  TLS 由 记录协议、握手协议、警告协议、变更密码规范协议、扩展协议等几个子协议组成，综合使用了对称加密、非对称加密、身份认证等许多密码学前沿技术。
3. 密码组件
  1
  ECDHE-RSA-AES256-GCM-SHA384
密钥交换算法 + 签名算法 + 对称加密算法 + 摘要算法 “握手时使用 ECDHE 算法进行密钥交换，用 RSA 签名和身份认证，握手后的通信使用 AES 对称算法，密钥长度 256 位，分组模式是 GCM，摘要算法 SHA384 用于消息认证和产生随机数
1. OpenSSL 它是一个著名的开源密码学程序库和工具包,几乎支持所有公开的加密算法和协议，已经成为事实的标准，许多应用软件都会使用它作为底层来实现TLS 功能
固若金汤的根本（上）：对称密钥加密与非对称密钥加密
1. 对称加密
  对称加密”很好理解，就是指加密和解密时使用的密钥都是同一个，是“对称”的。只要保证了密钥的安全，那整个通信过程就可以说具有了机密性。
  RC4、DES、3DES、AES、ChaCha20，目前只有 AES、ChaCha20 比较安全
2. 加密分组模式
  对称算法还有一个“分组模式”的概念，它可以让算法用固定长度的密钥加密任意长度的明文，把小秘密（即密钥）转化为大秘密（即密文）
  
  最新的分组模式被称为 AEAD（Authenticated Encryption with Associated Data），在加密的同时增加了认证的功能，常用的是·GCM、CCM 和 Poly1305。
  
  比如，AES128-GCM，意思是密钥长度为 128 位的 AES 算法，使用的分组模式是 GCM；ChaCha20-Poly1305 的意思是 ChaCha20 算法，使用的分组模式是 Poly1305。
3. 非对称性
  你或许会说：“把密钥再加密一下发过去就好了”，但传输“加密密钥的密钥”又成了新问题。这就像是“鸡生蛋、蛋生鸡”，可以无限递归下去。只用对称加密算法，是绝对无法解决密钥交换的问题的。于是产生来了非对称密钥
  
  公钥和私钥有个特别的“单向”性，虽然都可以用来加密解密，但公钥加密后只能用私钥解密，反过来，私钥加密后也只能用公钥解密。
  比如 DH、DSA、RSA、ECC 等。 RSA 最出名
4. 混合加密
  1. 对称加密没有“密钥交换”的问题，对称加密运算速递慢
5. https
  [ngix 配置 https 证书] (https://www.cnblogs.com/tugenhua0707/p/10927722.html)
6. 加密算法中“密钥”的名字很形象，你能试着用现实中的锁和钥匙来比喻一下吗？
  假设 a 持有私钥，b 持有公钥，然后他们用一个加了锁的盒子进行通信。
  1. a 把信件放到盒子里，然后用一排连接为锁链的锁将盒子锁起来，然后寄给 b。只要公钥能解开其中一个锁，那对方就能拿到信件。（可能换成能识别具有某些特征密码的密码锁的比喻会更好一些）
  2. b 用公钥开锁拿到了信件，然后他写了一封回信，同样放到盒子里，然后挂上一个只有私钥才能打开的锁，寄给 a。
  3. 只有 a 有有对应的钥匙（私钥），于是 a 拿到了回信。
7. 私钥加密公钥解密有什么作用
  因为私钥只能由一个人秘密持有，所以它加密的数据谁都可以解密，没有私密性，但这就是它的价值所在，可以证明这个数据就是私钥持有人发布的，可以用来做身份认证
固若金汤的根本（下）：数字签名
1. 完整性认证 - 摘要算法
  1. 它能够把任意长度的数据“压缩”成固定长度、而且独一无二的“摘要”字符串，就好像是给这段数据生成了一个数字“指纹”，不可逆
  2. MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1） TLS 推荐使用的是 SHA-1 的后继者：SHA-2
  3. 真正的完整性必须要建立在机密性之上，在混合加密系统里用会话密钥加密消息和摘要，这样黑客无法得知明文，也就没有办法动手脚了
2. 身份认证 - 数字签名
  1. 这个东西就是非对称加密里的“私钥”，使用私钥再加上摘要算法，就能够实现“数字签名”，同时实现“身份认证”和“不可否认”
3. 数字证书和 CA
  1. 公钥的发布者 -可信的 CA
  2. CA 对公钥的签名认证也是有格式的，不是简单地把公钥绑定在持有者身份上就完事了，还要包含序列号、用途、颁发者、有效时间等等，把这些打成一个包再签名，完整地证明公钥关联的各种信息，形成“数字证书”（Certificate）
  3. 知名的CA DigiCert、VeriSign、Entrust、Let’s Encrypt 它们签发的证书分 DV、OV、EV 三种，区别在于可信程度。DV 是最低的，只是域名级别的可信，背后是谁不知道。EV 是最高的，经过了法律和审计的严格核查，可以证明网站拥有者的身份（在浏览器地址栏会显示出公司的名字，例如 Apple、GitHub 的网站）
  4. CA 证书上有（极客时间公钥，极客时间信息，CA的数字签名）
4. 到底这个非对称加密是一个有公钥一个有私钥，还是都有公私钥？
  取决于是双向认证还是单向认证。如果是单向认证，也就是目前大多数的用法，只发送服务器的公钥，验证服务器的身份。
  如果是双向认证，那么服务器和客户端都要发送各自的公钥，互相验证对方的身份，一个常见的场景就是网银的U盾
5. 为什么公钥能够建立信任链，用对称加密算法里的对称密钥行不行呢？
  非对称加密算法需要公开公钥从而让客户端能解密。如果用对称加密，加密秘钥公开，就达不到加密效果了

信任始于握手： TLS1.2 特性解析
1. TLS 协议组成
  1. 记录协议
  2. 警报协议
  3. 握手协议
  4. 更密码规范协议
2. TLS握手流程
  ECDHE
  1. 浏览器向服务器发送对称加密套件列表、非对称加密套件列表和随机数 client-random
  2. 服务器保存随机数client-random,选择对称加密和非对称加密的套件，然后生成随机数service-random和 CA
    向浏览器发送选择的加密套件，service-random和公钥
  3. 浏览器CA验证提取保存公钥，并生成随机数pre-master,然后利用公钥对 pre-master 加密，并向服务器发送加密后的数据；
  4. 最后服务器拿出自己的私钥，解密出 pre-master 数据，并返回确认消息。
  5. 服务器和浏览器就有了共同的 client-random、service-random 和 pre-master，然后服务器和浏览器会使用这三组随机数生成对称密钥，因为服务器和浏览器使用同一套方法来生成密钥，所以最终生成的密钥也是相同的
  6. 客户端发一个Change Cipher Spec，然后再发一个Finished消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证
  7. 服务器也是同样的操作，发Change Cipher Spec和Finished消息，双方都验证加密解密 OK，握手正式结束
3. https 安全表现在哪些方面
  保密性：靠混合加密解决，非对称加密实现对称加密秘钥传递，对称加密实现内容加密。
  完整性：靠摘要算法解决。
  身份认证：靠数字证书解决，数字证书因为CA机构的信任变成一个完整信任链条，从而实现通过数字证书证明了对方真实身份，但注意身份真实也可能是挂羊头卖狗肉，是一个坏人，所以，有了CRL、OCSP，还有终止信任。
  不可否认：靠数字签名解决，内容摘要算法得到摘要，私钥加密摘要，对方使用对应公钥解密，得到摘要，再和自己得到的服务器提供的原文摘要对比，一致说明这个内容就是原服务器提供的，由证书说明了服务器的身份
4. 总结 TLS 的握手过程
啥是ECHDEH

总结下TLS的握手过程：
第一阶段：C/S两端共享Client Random、Server Random 和 Server Params信息
客户端—>服务器：
客户端的版本号、支持的密码套件，还有一个随机数（Client Random）

服务端—>客户端：
客户端的版本号、选择的客户端列表的密码套件如：TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、随机数随机数（Server Random）

服务端—>客户端：
服务端证书（Server Certificate）

服务端--->客户端：
发送`Server Key Exchange`类型的请求，携带椭圆曲线的公钥（Server Params）用以实现密钥交换算法，另附私钥签名


服务端--->客户端：
发送完毕


第二阶段：证书验证

前验条件：客户端证书链逐级验证、证书公钥验证签名，服务端身份验证成功（证书合法）

客户端--->服务端
发送`Client Key Exchange`类型的请求，携带椭圆曲线的公钥（Client Params）用以实现秘钥交换算法


第三阶段：主密钥生成

客户端、服务端分别使用Client Params、Server Params通过`ECDHE`算法计算出随机值pre-master，然后用
Client Random、Server Random 和 Pre-Master三个值作为原材料，用`PRF`伪随机数函数（利用密码套件的摘要算法再次强化结果
值maser secert的随机性）计算出主密钥`Master Secret`，

主密钥并不是会话秘钥，还会再用PRF扩展出更多的密钥，比如客户端发送用的会话密钥（client_write_key）、服务器发送用的会话密钥（server_write_key）


客户端--->服务端:
客户端发一个“`Change Cipher Spec`”，然后再发一个“Finished”消息，把之前所有发送的数据做个摘要，再加密一下，让服务器做个验证.

服务端--->客户端：
服务器也是同样的操作，发“`Change Cipher Spec`”和“Finished”消息，双方都验证加密解密 OK，握手正式结束

更好更快的握手：TLS1.3 特性解析
1. 2018年 TLS1.3,改进的主要目标是 兼容,安全 与性能
2. 强化安全
  1. TLS1.3 里只保留了 AES、ChaCha20 对称加密算法，分组模式只能用 AEAD 的 GCM、CCM 和 Poly1305，摘要算法只能用 SHA256、SHA384，密钥交换算法只有 ECDHE 和 DHE，椭圆曲线也被“砍”到只剩 P-256 和 x25519 等 5 种。
    公有5个密码套件
  2. TSL 握手， TLS1.3 要锁了以前的 ‘HELLO’，删除了 key-EXchange消息,把握手时间减少到了“1-RTT”，效率提高了一倍。在发送‘Client Hello’ 时候，把椭圆参数都带上了
  3. TLS1.3 也简化了握手过程，完全握手只需要一个消息往返，提升了性能。
3. TLS1.3 里的密码套件没有指定密钥交换算法和签名算法，那么在握手的时候会不会有问题呢？
  1、TLS1.3精简了加密算法，通过support_groups、key_share、signature_algorithms这些参数就能判断出密钥交换算法和签名算法，不用在cipher suite中协商了
4. 结合上一讲的 RSA 握手过程，解释一下为什么 RSA 密钥交换不具有“前向安全”。
  2、RSA握手时，client key exchage会使用RSA公钥加密pre master后传给服务端，一旦私钥被破解，那么之前的信息都会被破译，根本原因还是在于RSA的这一对公钥私钥并不是临时的。
  
  而 ECDHE 算法在每次握手时都会生成一对临时的公钥和私钥，每次通信的密钥对都是不同的，也就是“一次一密”，即使黑客花大力气破解了这一次的会话密钥，也只是这次通信被攻击，之前的历史消息不会受到影响，仍然是安全的

TLS1.3 的握手过程与 TLS1.2 的“False Start”有什么异同？
相同点：都在未收到Finished确认消息时就已经向对方发送加密信息了，不同点：TLS1.3 服务器将change cipher spec合并到了hello中

连接太慢怎么办：HTTPS 的优化
1. 原因分析
  1. HTTPS 连接大致可以划分为两个部分，
    第一个是建立连接时候的非对称加密握手, 第二个是握手后的对称加密报文传输
    由于目前流行的 AES、ChaCha20 性能都很好，还有硬件优化，报文传输的性能损耗可以说是非常地小，小到几乎可以忽略不计了。所以，通常所说的“HTTPS 连接慢”指的就是刚开始建立连接的那段时间
    HTTPS 比 HTTP 增加了一个 TLS 握手的步骤，这个步骤最长可以话费2个消息往返，2-RTT
    1. 产生用于密钥交换的临时公私钥对（ECDHE）
    2. 验证证书时访问 CA 获取 CRL 或者 OCSP；
    3. 非对称加密解密处理“Pre-Master”。
2. 有哪些优化方面
  1. 硬件优化
  2. 更快的 CPU
  3. SSL加速服务器：SSL加速器可以使用现成的CPU,但大多数是使用ASIC和RISC板卡来完成最艰难的计算工作。器带来了极大的运算压力。 ssl加速卡可以完全卸载服务器的SSL运算负担,降低数据服务的运营成本
  4. 软件优化：软件升级
    1. Linux 内核由 2.x 升级到 4.x，把 Nginx 由 1.16 升级到 1.18，把 OpenSSL 由 1.0.1 升级到 1.1.0/1.1.1。
  5. 软件优化：协议优化
    1. tls 1.2 - tls 1.3 它大幅度简化了握手的过程，完全握手只要 1-RTT，而且更加安全
  6. 证书优化, 这里就有两个优化点，一个是证书传输，一个是证书验证。
    1. 补丁”，叫“OCSP Stapling”（OCSP 装订），它可以让服务器预先访问 CA 获取 OCSP( OCSP Stapling ) 响应，然后在握手时随着证书一起发给客户端，免去了客户端连接 CA 服务器查询的时间
  7. 会话复用
    1. 第一种叫“Session ID”，就是客户端和服务器首次连接后各自保存一个会话的 ID 号，内存里存储主密钥和其他相关的信息。当客户端再次连接时发一个 ID 过来，服务器就在内存里找，找到就直接用主密钥恢复会话状态，跳过证书验证和密钥交换，只用一个消息往返就可以建立安全通信。缺点：服务器必须保存每个客户的会话数据，对于拥有百万、千万级别用户的网址来说存储增加服务器的负担
    2. 会话票证
      它有点类似 HTTP 的 Cookie，存储的责任由服务器转移到了客户端，服务器加密会话信息，用“New Session Ticket”消息发给客户端，让客户端保存。重连的时候，客户端使用扩展“session_ticket”发送“Ticket”而不是“Session ID”，服务器解密后验证有效期，就可以恢复会话，开始加密通信
我们应该迁移到 HTTPS吗？
1. 手动申请 CA 证书