kubernetes里的mTLS

缕梦菲烟 2022-11-17 发布于广东

展开全文

两台主机通信的时候，如果是通过明文的方式通信的话两者之间的数据很容易被截获，两台主机要安全通信，需要在这两者之间实现数据的加密。主要涉及到对称加密、非对称加密、哈希函数。

对称加密

所谓对称加密，即加密和解密使用相同的密钥，这个密钥可以理解为就是密码。

这里A用一个对称加密密钥haha001加密了一个数据，然后把加密之后的数据发送给B之后，因为是加密数据，所以B是打不开的。所以A需要把密码告诉B才行，但是如何告诉B密钥是haha001呢？这是一个问题，因为这个过程很可能被别人监测到。

非对称加密

对于非对称加密算法来说，包括了2个密钥一个是公钥，一个是私钥。公钥是可以公开的，私钥需要保护好。对于非对称加密来说主要作用有两个，一是数据加密，二是数字签名。

数据加密

上图里锁的图标表示公钥，钥匙的图标表示私钥。

第一步：B把公钥发送给A
第二步：A用B的公钥加密数据
第三步：A把加密后的数据发送给B
第四步：B用自己的私钥对加密数据进行解密。
因为别人获取不到B的私钥，所以在第三步里即使数据被截获了也解密不了，因为只有B的私钥才能解密。

如果把对称加密和非对称加密结合使用的话，这样利用非对称加密就可以解决了前面对称加密算法中，对称密钥不方便传输的问题了。

第一步：B把公钥发送给A。
第二步：A用B的公钥加密对称加密的密钥haha001。
第三步：A把加密后的密钥发送给B
第四步：B用自己的私钥解密A发送过来的数据，得到对称加密的密钥haha001。
第五步：B用haha001解密A发送过来的对称加密的数据。
这样A用对称加密的数据发送给B之后，B也能顺利的打开了。这种方式看起来安全，但其实很容易受到中间人攻击，因为在第一步里我们假设的是A获取的就是B的公钥，而不是别人冒充的。
下面我们看一下中间人攻击的过程，这里假设C是坏人即中间人。
第一步：B把公钥发送给A，但C把原本发送给A的公钥截获了，此时C有了B的公钥。
第二步：C把自己的公钥发送给A，但是宣称是“B的公钥”，A不明真相，以为就是B的公钥
第三步：A用"B的公钥"(其实是C的公钥)加密对称加密的密钥
第四步：把加密后的对称加密的密钥发送给B，但是这个又被C截获了。因为实际用的是C的公钥加密的，所以C用自己的私钥是能够解密的。此时C获取了对称加密的密钥haha001。
第五步：C用B的公钥加密对称加密密钥haha001，之后发送给B。
第六步：B用自己的私钥解密数据，得到对称密钥haha001。
到现在为止，A和B以为他们之间是直接沟通的，但是这当中有个中间人C也获取了对称加密的密钥。
第七步：A把用对称加密后的数据发送给B，但也被C截获了。因为C知道了对称加密密钥，所以C是能看到数据里的内容并做修改的。
第八步：C再次用对称密钥haha001加密数据之后转发给B
第九步：B用对称密钥haha001解密数据。

整个过程A和B都以为他们是直接通信的，殊不知这中间所有的数据都被C看到了，这就是中间人攻击。那么如何解决这个问题呢？我们先了解数字签名。

数字签名

数字签名是私钥加密数据，公钥解密数据，先看下图。

第1步：B先把公钥发送给A，

第2步：B然后用哈希函数对所要传输的数据求得哈希值hash1。哈希函数的特点的是输入不定长的值总是能得到定长的值。比如：

root@vms61:~# wc -c /etc/hosts
291 /etc/hosts
root@vms61:~# wc -c /etc/services 
19183 /etc/services
root@vms61:~# 
root@vms61:~# 
root@vms61:~# md5sum /etc/hosts
219ebb29a192b6e41af2dc98865df58e  /etc/hosts
root@vms61:~# md5sum /etc/services 
567c100888518c1163b3462993de7d47  /etc/services
root@vms61:~#

第3步：B会用自己的私钥对哈希值hash1进行加密。
第4步：B把原始数据和加密后的哈希值发送给A。
第5步：A先用B的公钥把收到的加密后的哈希值hash1解密，得到hash1，这个hash1和第2步生成的hash1是一样的。
第6步：B会对收到的数据data求得哈希值hash2。
第7步：B对比hash1和hash2来判断data在传输过程中是不是被修改过。如果两个hash值是一样的话，就说明数据data在传输过程中是没有被修改的，如果两个哈希值不一样说明数据在传输过程中被修改过。

这里会带来两个问题：

第一：这里也会遇到中间人攻击的问题，即第1步的公钥被C截获了，然后把自己的公钥发送给了A。在第四步里，数据data和hash1被C截获，然后C修改了data的数据，然后求得哈希值之后用自己的私钥做数据签名。
其实所有的中间人攻击的根本问题在于
第二，即使没有中间人攻击，B的密钥对跟B这个主体之间没有必然的联系，因为B可以随时删除掉自己的密钥对，然后重新生成。

证书中心

在互联网上存在一种权威机构叫做证书中心（简称CA），一个前提就是我们都要信任CA。

前面讲中间人攻击的主要原因就是A获取B的公钥可能是假冒的，所以A不会信任别人发给他的公钥的，且B也知道他直接把他自己生成的公钥发给别人，别人也不信任，所以B不会再生成公钥了。

第一步：B会用自己的私钥生成一个证书请求文件（类似于申请书）
第二步：B把证书请求文件发送到CA去申请证书。
第三步：CA会审核B的身份，之后会颁发证书给B。这个证书其实就是公钥，只是上面有了CA的数字签名，以证明这个证书是CA颁发的。这一步解决了“数字签名”部分B和他的密钥对之间没有必然联系的问题，因为这里有CA来证明这个密钥对就是B的，B不可抵赖。
第四步：B会把证书发送给A，说这是我的证书并且上面有CA的数字签名，不会被别人伪冒。
第五步：A是持怀疑态度的，到底是不是真的是由CA颁发的，还是别人伪冒的呢？所以A要验证这个证书的真伪性。此时A需要CA的公钥（像浏览器里都内置了权威CA的公钥的），然后会用权威CA的公钥验证 B证书的公钥上的数字签名。

之后A会用B的证书加密对称加密算法的密钥发送给B，B用私钥解密。这样A和B之间就可以安全的传输数据了，整个过程叫做TLS（传输层安全）。
这里只有A验证了B的证书的合法性，所以叫做单向TLS。如果A也有自己的私钥及CA颁发的证书，那么除了A要验证B证书的合法性之外，B也要验证A证书的合法性，即两边互相验证，这个就叫做mTLS（mutual TLS，双向TLS）了。