TLS/X509和双向认证

小军的求知笔记

无论是在微服务开发还是使用kubernetes的过程中，我们都会经常用到TLS协议来保证客户端和服务端之间的安全通信！

接下来的故事解释了TLS和X509证书要解决的问题。

最近，我不得不在MySQL主、备服务器之间设置双向TLS身份认证，这让我第一次有机会真正地设置和运行CA，并实现双向身份认证。

这是个非常不错的经历，我想在这里总结并扩展一下我学到的一些东西。首先声明：这并不是为了100%准确地反映规范而写的。相反，为了抽象在某些地方做了简化。希望在提及术语的地方有链接，可以找到更具体的含义。

数据安全问题

在定义计算机如何通信时，可以合理地假设信息将从一台计算机直接发送到另一台计算机。如下图计算机“Alice”向计算机“Bob”发送一个访问网站的请求:

计算机之间如何通信

然而，实际情况并非如此。两台电脑直接连接在一起是极其少见的；通常，中间有许多计算机(通常称为“路由器”或“防火墙”或任何数量的其他类似设备”)。它看起来更像:

计算机实际通信情况

这给计算机Alice和Bob带来了一个问题。首先，他们不能确定Alice和Bob之间的计算机没有记录正在说什么，如果Alice向计算机“Bob”发送一条消息，“Bob”不能确定看似由计算机“Alice”发送的消息，实际上真的是由“Alice”发送的，也不能确定收到的消息是未经串改的。
幸运的是，有一种机制可以解决这个问题。

TLS（传输层安全协议）

为了解决上面的问题，自1996年以来，传输层安全协议(TLS)及其前身安全套接字层(SSL)就已经存在。如前所述，有两组问题需要解决:

确保数据转发过程不被读取

为了确保数据不被位于网络连接中间的计算机读取，发送数据需要加密。加密是对信息进行编码的过程，只有那些应该能够阅读和理解它的人才能阅读和理解它。为了来回传递信息，两台计算机需要决定如何对数据进行加解密，以便只有它们能理解，而中间的计算机不能。

接着上面的例子，为了和Bob安全发送数据，Alice需要知道一些加密数据的方法，而且只有Bob可以解密。这是一个鸡和蛋的问题；如何共享这个加密方法，仍然是一个难题。解决方案在于一个名为“公钥加密”的过程。

不需要深入了解内部是如何工作的，只需知道Bob有一个用来编解码信息的密钥。Bob的密钥分成两部分:

公共部分：用于加密数据；
私有部分：用于解码数据；
这就允许Bob将这个密钥的公共部分发送给Alice，Alice可以使用它来编码和发送只有Bob可以读取的信息。这些密钥也称为“密钥”一个公钥和一个私钥。

第一步，Alice需要请求Bob的公钥。这个过程被称为非对称加密，看起来像这样:

Alice和Bob之间的计算机无法解码公匙加密的信息

但是，这个过程有一个缺点：不能实现Bob向Alice发送只有Alice能读到的消息。为了回复Alice的消息，Bob需要一个只有Alice能理解的密钥。

Alice知道她可以发送只有Bob能解码的信息。所以，她可以利用这一点向Bob发送一些秘密信息，这些信息可以被Alice和Bob用来对彼此之间的信息进行加密。

该秘密信息就是对称密钥。这个密钥在Alice和Bob之间共享，可以用来解码任何一方发送的消息。这就实现了两种方式的加密连接。

上图中：Alice首先拿到Bob的公钥，然后通过公钥加密向Bob发送对称加密的密匙，之后就使用对称密匙加密要发送的信息。这里非对称加密的过程，目的是为了安全地共享后面要用的对称加密密匙。因此、不用担心是否有人在监听他们的连接。只有Alice和Bob有用于解码这些消息的对称密钥!

但是，这个过程有一个缺陷：我们如何确保Bob就是Bob?

确认Bob是本人（服务端身份验证）

在上述例子中，我们知道Alice通过计算机网络与Bob对话。然而，如果其中一台计算机突然开始假装是Bob，会发生什么?

如果Alice事先不认识Bob，那么她不可能知道“Bob”就是“Bob”。Alice会和任何假装是Bob的人建立一个加密连接。确实，虽然这里没有显示，对Bob来说中间的一个计算机可以伪装成Alice，而对Alice来说它可以是Bob！这就是所谓的“中间人攻击”。

然而，TLS标准有一部分是设计用来解决这个问题的。具体来说，当Alice第一次向Bob表示她想通过一个加密连接开始对话时，她不仅要求Bob提供公钥，而且要求他提供一个证明他是谁的证书(X.509证书)。然后，Alice向一个称为“证书权威机构”的可信顾问咨询Bob是否合法，并根据权威机构的认证决定是否继续通信。

通过CA验证Bob身份

如果证书不是由权威机构担保的，那么Alice将简单地拒绝连接。

证书未通过CA的验证结束连接

确认Alice是本人（客户端身份验证）

对Alice来说，现在通信是愉快的，而且相当安全。她知道与她交谈的Bob是真正的Bob，只有她和Bob可以看到发送的信息。然而，Bob不能保证Alice的身份。
每个连接都有两个方面：

客户端：上面的例子指的是Alice，她先发起消息。
服务点：上面的例子指的是Bob，向客户端返回消息。

验证服务端身份是一个非常常见的操作。的确，当你浏览这篇文章时，很可能你的浏览器就验证了你看到的博客网站就是它声称的那个博客网站。验证Alice身份实际上是一个不太常见的操作，但通常称为“Mutual TLS authentication”，因为Alice和Bob都需要验证。

考虑这样一个场景，Bob希望从Alice那里得到一些敏感的数据，可能是医疗数据或类似的数据。然后Bob会处理这些数据然后对Alice的情况做出诊断。在这种情况下，Bob肯定想确定Alice是真实的Alice，而不是编造假的诊断数据!

幸运的是，前面提到的TLS标准可以很容易地扩展为包括对Alice和Bob相同的验证过程:

现在，Alice和Bob都能保证他们就是他们所联系的那个人(由他们的证书权威机构担保)，并且连接是加密的，这个连接可以说是非常安全的。

总结：

传输层安全性协议(Transport Layer Security, TLS)和X.509证书在第一次遇到时看起来像是很神奇的东西，以某种方式提供安全性，但不清楚具体如何提供安全性或为什么提供安全性。在使用了几次并进行必要的调试之后，让所有内容正确地通信就变得更简单了。希望这篇文章能够让你对理解HTTPS连接变得更加简单。

继续滑动看下一个