HTTP和HTTPS#

• HTTP 协议（HyperText Transfer Protocol，超文本传输协议）：是客户端浏览器或其他程序与Web服务器之间的应用层通信协议
• HTTPS 协议（HyperText Transfer Protocol over Secure Socket Layer）：可以理解为HTTP+SSL/TLS， 即 HTTP 下加入 SSL 层，HTTPS 的安全基础是 SSL，因此加密的详细内容就需要 SSL，用于安全的 HTTP 数据传输

SSL和TLS#

• SSL（Secure Socket Layer，==安全套接字层==）：1994年为 Netscape 所研发，SSL 协议位于 ==TCP/IP 协议与各种应用层协议之间==，为数据通讯提供安全支持
• TLS（Transport Layer Security，==传输层安全==）：其前身是 SSL，它最初的几个版本（SSL 1.0、SSL 2.0、SSL 3.0）由网景公司开发，1999年从 3.1 开始被 IETF 标准化并改名

通信内容的保密性#

• 首先，理解 HTTPS 中的加解密、秘钥、公钥、私钥、对称加密、非对称加密
• 简单来说，加解密就是一个函数，而秘钥则就是这个函数的参数。比如定义一个简单的加密函数，f(x) = x + b，x 就是输入的明文，而 b 就是秘钥；解密函数就是加密函数的反函数，也就是 g(x) = x - b。当不知道 b 的时候，就算看到密文也猜不出真实内容，这样就实现加解密。这种加解密都用同一个秘钥，就叫做对称加密
• 在真实网络环境中，通信双方不可能进行直接沟通来定义秘钥 b，所以这就需要用到非对称加密算法了，这种算法有公钥和私钥一对钥匙，公钥是所有人都能获取到的钥匙，私钥则是服务器私自保存的钥匙。非对称加密算法中公钥加密的内容只能用私钥解密，私钥加密的内容则只有公钥才能解密
• 非对称加密算法实现信息交换的基本过程：甲方生成一对秘钥并将其中的一把作为公用秘钥（公钥）向其他方公开；得到该公用秘钥的乙方使用该秘钥对信息进行加密后再发送给甲方；甲方再用自己保存的另一把专用秘钥（私钥）对加密后的信息进行解密
• 对称加密算法在加密和解密时使用的是同一个秘钥；而非对称加密算法需要两个秘钥来进行加密和解密，这两个秘钥就是公开密钥（公钥）和私有秘钥（私钥）
• 如果甲方也想要回应乙方消息呢？如果甲方用私钥来进行信息加密，所有人都知道公钥，而公钥可以解私钥的加密，也就意味着所有人都可以解密甲方回应的信息。解决方案：利用非对称加密算法加密出一个对称秘钥给甲方，甲方用他的私钥读取对称秘钥，然后就可以用对称秘钥来做对称加密，双方便可以愉快的通信啦
• 这个理解一下呢就是，a生成一个公钥和一个私钥，自己保留着私钥，将公钥发送给B，然后呢，B生成一个对称密钥，通过这个公钥进行加密发送给a，那么这个加密过的对称密钥只有a通过私钥才能解密，而其他的人就算是窃取到了这个信息也没有办法进行解密，那么a在对这个对称密钥进行解密之后呢，再向B发送数据的时候呢，不止通过他自己的私钥加密一次，还要通过这个对称密钥加密一次，这个信息向b发送过程中就算被窃取了，窃取的人最多只能通过a的公钥解密一次，没有b的对称密钥，信息还是加密的

通信双方身份的真实性#

• 证书机制可以判定通信双方的真实性。证书机制是链式颁发的，HTTPS 体系中所谓的根 CA 就是最权威的机构。在 HTTPS 证书体系里面，根证书是操作系统/浏览器自带的，我们可以相信这些机构认证的证书
• 判定证书真假具体来说就是先将证书用哈希算法提取摘要，然后对摘要进行加密的过程。（注意：证书是有期限的，所以即使是真证书也可能会过期）

通信内容的完整性#

• 先用哈希算法提取内容摘要，然后对摘要进行加密生成数字签名，验证数字签名就可以判断出通信内容的完整性了

具体过程#

1. Client Hello#

• 首先由客户端发起了一个打招呼的包：ClientHello，通过抓包我们可以看到TLS层的内容：

• 有两个点我们需要关注的就是Client传输了一个随机数和21个Cipher Suites，我们详细解释一下这两个点：

  • Client Random：客户端随机数
    • 在之前的原理中我们有讲到HTTPs握手的主要目的就是得出对称加密的主密钥。这个密钥单独由某一方生成都不太合适，应为并不是每个主机都能产生完全的随机数，如果只是由某一方生成，很可能会产生比较弱的随机数，容易被猜测，导致加密密钥被破解。所以我们在过程中会涉及到三个随机数，并且后续可以看到Server端也会参与到随机数的生成，从而使“随机数”更接近真实的随机，保证安全
  • Cipher Suites：密码套件
    • 在之前的知识铺垫中我们知道HTTPS的加密过程需要用到的密码技术主要有：
      • 对称加密
      • 非对称加密
      • 摘要算法
      • 数字签名
    • 一种算法分类中有很多的选择，例如对称加密就有AES_256_GCM, AES_128_CBC等，非对称加密也有RAS和ECDSA，他们的安全强度和性能都各有侧重
    • 那在后续的连接中，针对算法的多种选择，本次会话使用哪种组合呢？这些算法的组合就是我们说的Cipher Suites------==密码套件==
    • 看一个具体的Cipher Suite： Cipher Suite 客户端提供了许多这样的组合，表示客户端支持这些组合，供服务端进行选择，每种组合的安全和性能各有差异，服务器结合自身情况尽心选择

2. Server Hello#

• 服务器收到了客户端的招呼请求之后，做出了Server Hello的回应，这里面有三个很重要的内容：
• Server端随机数从Client Hello发送的Cipher Suites中选择一个自己支持的Cipher Suite服务器自己的==CA证书==
• 这一步服务器提供了必要的信息给客户端，证书用于验证自己的身份，以便确保公钥安全的交到用户手中，并且提供自己生成的==随机数==，和==选定的Cipher Suite==，让客户端继续进行后续步骤

3. Client Key Exchange#

• 前两个打招呼的报文实际上都是明文传输的，因为在建立连接之前双方都没有密钥，无法使用加密传输的。而前文有提到的两个随机数(Client Random和Server Random)都有被截获的风险，如果中间人获取到我们的随机数，再根据同样的算法进行计算，不是就可以得到我们最终生成的对称密钥了吗？
• 显然我们不可能让坏人轻易得逞，原因就在于第三步的Client Key Exchange中的==第三个随机数==，我们通常称之为==预主密钥(Pre Master)==
• 客户端在收到了服务器返回的消息之后，首先会用存放在本地的根证书对服务器证书进行==验证==，验证通过便会认为服务器证书中的公钥是可信的，取出来备用。 接下来客户端会生成第三个随机数，为了把这第三个随机数安全的交给服务器，我们需要对他进行加密，这时的情况跟第一次Client Hello时有所不同，因为我们已经有了可以信任的服务器公钥
• 客户端根据服务器返回的Cipher Suite使用确定的算法和公钥对第三个随机数进行加密传输。这时候只有服务器的私钥可以解密获取这第三个随机数，从而保证了主密钥的安全
• 在这一步里，客户端还做了一些小动作，由于客户端现在已经抢先服务端计算出了主密钥，而当这条Client Key Exchange信息到达服务端时，服务端应该也能正确的计算出主密钥，所以客户端先用主密钥对之前握手的信息做了摘要和签名以供服务端计算出主密钥之后当场进行验证，这是双方第一次使用对称加密的主密钥进行加密

4. Server Change Cipher Spec#

• 走到这一步，服务端会先用自己的私钥解密，获取到客户端传来的第三个随机数（预主密钥），接着通过相同的算法计算出主密钥。服务端对上一步客户端做的小动作进行验签，这是服务端第一次使用对称加密主密钥，如果验签成功说明我们双方的主密钥计算成功，是安全的。 接着服务端做了最后的回应：
• Change Cipher Spec，告诉客户端，我准备好了，后续咱们就用主密钥加密沟通，你懂的。对我们握手的信息用主密钥进行签名，你验证一下。至此，整个HTTPs的握手完成

结合起来HTTPS通信流程如下#

• 大致步骤：
  1. 客户端发送 Client Hello 报文开始 SSL 通信，报文中包含 SSL 版本、可用算法列表、秘钥长度等
  2. 服务器支持 SSL 通信时，会以 Server Hello 报文作为应答，报文中同样包括 SSL 版本以及加密算法配置，也就是协商加解密算法。 然后服务器会发送 Certificate 报文，也就是将证书发送给客户端
  3. 客户端发送 Client Key Exchange 报文，使用3中的证书公钥加密 Pre-master secret 随机密码串，后续就以这个密码来做对称加密进行通信
  4. 服务器使用私钥解密成功后返回一个响应提示 SSL 通信环境已经搭建好了
  5. 然后就是常规的 HTTP C/S 通信
• 根据前文所述，步骤2和步骤5都会使用摘要和签名算法来保证传递的证书和通信不被篡改。通过这个流程可以看出，HTTPS 的核心在于==加密==，尤其是非对称加密算法被多次使用来传送关键信息