HTTPS 原理解读

原理解读"/>

HTTPS 原理解读

文章目录

• 1. HTTPS 解决的问题
• • • 1.1 HTTP 存在的问题
    • • 1.2.1 对称加密
      • • 1.2.1.1 对称加密的处理
        • 1.2.1.2 对称加密的密钥协商问题
      • 1.2.2 非对称加密
      • • 1.2.2.1 非对称加密的处理
        • 1.2.2.1 非对称加密的伪装服务器问题
• 2. HTTPS 的安全实现
• • • 2.1 服务器的身份认证
    • • 2.1.1 数字证书
      • 2.2.2 CA 机构
      • 2.2.3 数字签名
    • 2.2 客户端的安全识别

1. HTTPS 解决的问题

1.1 HTTP 存在的问题

要搞清楚 HTTPS 解决的问题，首先要了解 HTTP 存在什么问题。我们都知道 HTTP 是应用层的协议，位于 TCP/IP 参考模型的最上层。用户数据经过应用层、传输层、网络层、链路层的向下层层封装后经由物理层发送到目标机器，这个过程中数据都是明文传输，默认不做加密处理，所以一旦被别人抓取到数据包，就很容易泄露数据信息。此外因为数据包可能被截获，那么别有用心的人也很容易篡改其中的信息，更甚者是不法分子架设站点冒充合法网站，如果我们访问的银行网站可能就是假冒的，那存款搞不好分分钟归零

简而言之，HTTP 主要存在以下几个问题：

1. 泄密
   个人隐私、账户密码等信息可能会在传输过程中被抓包盗取
2. 篡改
   收到的数据可能被第三方修改过，或被植入广告等
3. 假冒
   访问的站点其实不是目标服务器站点，如域名劫持、钓鱼网站等

为了保护数据，必然需要对传输的数据进行加密处理。一般来说，加密算法可以分两大类，一类是对称加密算法，另一类是非对称加密算法

• 非对称加密算法
  效率不高，因为主要是大数乘法和大数取模运算，典型如 RSA、DSA
• 对称加密算法
  效率较高，主要是位运算和移位操作，典型如 DES、3DES、Blowfish、IDEA、RC4、RC5、RC6 和 AES

1.2.1 对称加密

1.2.1.1 对称加密的处理

对称加密算法的加密和解密都是用同一个密钥，它解决数据传输安全性问题的方式比较直观

例如我们在登录某个网站的时候，需要填写用户名和密码进行登录，客户端把登录的表单信息进行对称加密后再传输，这时候就算别人截获数据包，没有密钥的情况下也无法获取数据的内容，也就保证了数据安全。但是这样也存在一个问题，那就是服务器收到加密数据后同样无法获取数据内容，因为服务器也不知道解密的密钥

为了解决这个问题，客户端和服务端在通信之前可以先协商密钥。客户端可以通知服务器需要开启数据传输了，然后服务器告诉客户端以后用 zzzzz 这个密钥进行加解密，这样数据的内容就可以加密传输了

1.2.1.2 对称加密的密钥协商问题

经过以上讨论，数据内容现在是可以加密传输了，但是仔细思索会发觉，协商密钥的过程同样存在安全问题

如果第三方在客户端和服务端开始通信时就开始抓包截获数据，那么协商密钥的数据也会泄露，那后续加密传输的数据对这个第三方来说和没加密没有区别，也就是说对称加密存在密钥协商的问题

1.2.2 非对称加密

1.2.2.1 非对称加密的处理

因为对称加密存在密钥协商的问题，所以又有了非对称加密来作为解决方案，简单来说做法就是私钥由服务器自己保存，公钥发送给客户端

非对称加密算法需要一组密钥对，分别是公钥和私钥，两个密钥成对存在。公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密

客户端首先从服务端拿到公钥，然后使用公钥对请求加密发送给服务端。这样就算被第三方截获数据包，因为没有私钥无法解密发送的内容，也就确保了客户端发送到服务端数据的安全性

但是由于公钥也需要通过网络发送给客户端，同样能被第三方截获，这样服务器私钥加密后的内容依然可以被第三方截获并解密，也就是说无法保证服务端发送到客户端的数据的安全性

对称加密和非对称加密都存在密钥传输的问题，但是非对称加密可以保证客户端传输给服务端的数据安全，而对称加密算法性能又比较好。基于这些情况考虑以下做法，似乎可以比较完美地解决问题：

1. 第一次通信时服务端将公钥发送给客户端
2. 由客户端产生一个对称密钥，通过服务端的公钥加密后发送给服务端
3. 服务端收到数据后私钥解密获得对称密钥，后续和客户端交互都通过这个对称密钥进行加密传输
4. 由于第三方无法从截取的数据包中拿到对称密钥，也就无法获得客户端与服务端的交互数据内容，保证了数据安全性

---

总结来说，就是先通过非对称密钥加密对称密钥来完成密钥协商，然后使用对称密钥加密实际的数据

1.2.2.1 非对称加密的伪装服务器问题

经过以上分析，第三方似乎已经无法从截获的数据包中获得有效信息了。但是就像屏幕对面网恋的美少女实际可能是抠脚大叔一样，第三方也许根本没有必要去做截取数据包的操作。因为它可以把自己伪装成服务器，然后作为中间商存在于客户端和服务端之间，将客户端用户的信息榨得一干二净。也就是说，这种方式还是无法解决 HTTP 中的假冒问题

2. HTTPS 的安全实现

如上文所述，我们知道 HTTP 中无法保证正在和客户端通信的服务器就是目标服务器，也就是说整个通信安全的问题就在于服务端的身份验证。基于此，HTTPS 的解决方案大致分为了两个部分：

1. 服务器的身份认证
2. 客户端对服务端的身份验证

2.1 服务器的身份认证

2.1.1 数字证书

上一节主要分析到了 HTTP 中服务器伪装的问题，这种情况该怎么解决呢？

首先考虑现实中类似的情况，假如我们要确认一个陌生人的身份，首先当然是和他沟通一些基本信息，比如听他自己介绍他是谁，他从哪里来，他要到哪里去。但是这些信息并不一定可靠，因为别有用心的人会撒谎，比如诈骗人员从来不会透露自己的真实信息。那我们怎么去确认这个人的身份？读者可以想象一下警察叔叔是怎么干的，没错，就是查身份证

身份证是一个人的身份标识，基本上不存在两个人的身份证是一样的，那么身份证就可以唯一标识一个人。另外因为身份证是国家机关颁发、无法伪造的，所以只需要去相关系统输入编号查询就能查到相关信息，非常容易验证真假

同理，服务器为了让客户端能够验证自己确实就是目标服务器，也需要一张类似身份证的东西，这个东西就是数字证书

数字证书比较关键的信息如下：

1. 发证机构
2. 证书持有者
3. 证书的有效期
4. 证书持有者的域名
5. 证书持有者的公钥
6. 签名算法
   …

如上所述，身份证是由权威机构颁发的，并且是无法伪造的，很容易验证真假。那么想要让别人能够验证数字证书的真假，数字证书肯定不能是服务器自己生成的，必须由所有人共同认可的组织颁发，这种组织就是 CA 机构

2.2.2 CA 机构

CA 机构就是数字证书颁发的权威机构，负责颁发证书以及验证证书的合法性。如果服务器需要成为有身份的服务器，就需要向 CA 机构提交申请，申请一张数字证书。当然，这不是免费的

服务器向 CA 机构提交申请，需要提交站点的必要信息，如域名、公钥等等，CA 审批完成就可以给服务器颁发证书。需要注意的是，证书虽然颁发了，但是也有可能在传输过程中被篡改，如果第三方截获到数字证书后把公钥改成自己的，那同样无法保证数据安全，这就需要数字签名来防止篡改伪造了

2.2.3 数字签名

数字签名是证书防伪的一种重要手段，CA 机构在给服务器颁发证书的时候，会根据生成的证书采用指定的签名算法计算出一个证书摘要，并且会使用 CA 机构自己的私钥对其进行加密，完成后将这个加密后的摘要作为数字签名与数字证书一起交给服务器

数字签名防止篡改的基本思路是，拿到证书的客户端使用证书上声明的签名算法对证书进行计算，计算得到的摘要与服务端给过来的证书摘要不一致，则认为证书被篡改了

2.2 客户端的安全识别

HTTPS 的通信流程可以分为以下几个步骤：

1. 客户端向服务端发起请求
2. 服务器在与客户端第一次通信的时候，会将数字证书和数字签名出示给客户端
3. 客户端拿到数字证书和数字签名后，先通过操作系统或者浏览器内置信任的 CA 机构找到证书对应 CA 机构的公钥，使用该公钥对数字签名进行解密。如果是第三方伪造的签名，因为第三方拿不到 CA 机构的私钥对摘要进行加密，那么持有公钥的客户端也就无法完成解密，这就防止了伪造
4. 如果数字签名解密成功，则客户端采用证书上声明的签名算法自行计算数字证书的摘要。如果计算出的摘要与服务器发来的摘要一致，则证书是没有被篡改过的，这样就防止了篡改
5. 数字签名验证通过，客户端会继续验证数字证书的合法性，如证书上的域名是否与当前访问的域名一致、证书是否过期等等
6. 完成服务器的身份验证后，客户端会生成对称密钥，并使用证书上服务器的公钥完成对称密钥的加密，然后将其发送给服务器
7. 服务器使用私钥解密数据，获得对称密钥，这样就完成了密钥的协商，之后双方使用这个对称密钥进行加密通信即可