完全图解 HTTPS

安全基础

我们先来看下数据在互联网上数据传递可能会出现的三个比较有代表性的问题，其实后面提到的所有方法，都是围绕解决这三个问题而提出来的。

窃听

 

 

伪造

 

 

否认

 

 

对称密钥加密

假设 A 正在通过互联网向 B 发送数据，如果不对数据进行加密，数据就可能被恶意的第三者 X看到

因此，需要保密的数据需要进行加密再发送

 

 

• 用将数据进行加密，使其成为密文
• 把密文发送给 B
• B 使用密钥解密从 A 收到的密文，这样就能得到原始数据
• 因为是加密数据，即使它被恶意的第三方截获也是安全的

“对称密钥加密” 一个很重要的特点就是使用相同的密钥进行加密和解密

 

 

回到刚刚那个场景，假设 B 是没有解密钥匙的，所以 A 需要通过互联网将钥匙发送给 B

• 但是 X 也有可能看到这个钥匙
• 因此，X 也可以通过这个钥匙来解密密文

上面这个场景就会引出一个新问题，这个问题被称为 “钥匙交付问题”，那怎么解决这个问题？

公开密钥加密

为了解决上面的 “钥匙交付问题”，我们这里引入一个新的方法 —— "公开密钥加密"，下图是 “公开密钥加密” 的主要特点

 

 

• 用于加密的密钥被称为“公钥”，用于解密的密钥被称为“私钥”
• 跟 “对称密钥加密” 相比，公开密钥加密往往需要更多的时间用于加密和解密

我们来看看 “公开密钥加密” 的一整个过程

 

 

接收方 B 创建一个公钥和一个私钥，公钥被发送给 A

 

 

1. A 使用从 B 收到的公钥加密数据，将密文发送给 B
2. B 使用私钥解密从 A 接收到的密文，得到原始数据

在这个过程中

• 密文和公钥也可能被恶意第三方 X 截获
• 但是私钥是 B 保存的，X 无法获取到，自然没有办法解密密文
• 这样就很好的解决了 “钥匙交付问题”

公开密钥加密的问题

1. 加密和解密都需要耗费时间，有一种叫 “混合加密” 的方法可以解决这个问题
2. 公开密钥的可靠性

混合加密

 

 

混合密钥加密分为两个步骤

1. 通过公开密钥加密传递密钥
2. 通过速度更快的对称密钥加密方法传递数据

中间人攻击

为了更好地理解公开密钥加密的可靠性问题，我们回到传递公钥的场景

 

 

A 拿到的其实是 X 发送给他的伪造公钥，但是 A 无法察觉

 

 

最后，X 用他自己的密钥加密响应数据，并发送给 A，就这样，虽然 A、B 双方能顺利完成通信，但是恶意的第三方 X 能看到解密后的请求数据和响应数据，而 A、B 双方则毫不知情。

这种通过秘密替换公钥窃取数据的方法被称为“中间人攻击”，问题的根源在于 A 无法确认他们收到的公钥是否由 B 方创建。怎么避免中间人攻击呢？我们放到数字证书那节再探讨，接下来再讲解一点前置知识

消息鉴别码

消息鉴别码在英文中被称为 MAC，MAC 可以理解为密钥和密文组成的字符串的哈希值

 

 

消息鉴别码虽然可以解决伪造问题，但是仍然无法避免 否认 问题

数字签名

为了解决这个 否认 问题，我们接下来看看 “数字签名” 方法

 

 

数字证书

虽然上面的方法已经能避免 窃听、伪造、否认 等问题，但是现在还是没办法避免“中间人攻击”，因为我们还是没办法验证公钥的所有者，因此我们需要 “数字证书” 系统来验证公钥的所有者。

接下来，先看看数字证书申请的过程，我们将数字证书认证机构（Certificate Authority）我们称之为 CA

 

 

现在 B 已经申请到一个数字证书了，那么怎么使用数字证书来检验公钥 PB 是属于 B 呢

 

 

现在可以验证 PB 是属于 B 的，但是怎么验证 PC 是属于受信任的 CA 的呢

 

 

事实上，认证机构形成一个树形结构，高级别的权威机构为较低级别的机构创建证书，那就是说，如果要验证的话，就是一级一级向上认证，信任链条的最终是Root CA，他采用自签名，对他的签名是无条件的信任。

 

 

HTTPS

完全理解上面说的东西之后，就能够很容易理解 HTTPS，它采用的就是上面说的 “混合加密” + “数字证书” 两种技术，来保证整个通信过程的安全可靠。

HTTPS 做的事情其实就是在传输层跟应用层之间加了一层 SSL/TLS，用于对 TCP 传输内容的加密和解密

 

 

下图我们再看一下详细的工作流程