前言 |
在手动搭建kubernetes集群的时候,涉及到了TLS认证的配置,其步骤较为繁琐,如果不清楚TLS背后的流程和原理的话,会遇到各种各样千奇百怪的问题。
本文会简要介绍SSL/TLS协议的运行机制,帮助我们理解kubernetes集群的配置,具体配置步骤会在后文中总结。
概述 |
TLS(Transport Layer Security,传输层安全协议),其前身为 SSL (Secure Sockets Layer,安全套接层)是一种安全协议,目的是为互联网通信,提供安全及数据完整性保障。最早是网景公司(Netscape)于1994年推出 HTTPS 协议,用 SSL进行加密。后来IETF将 SSL 标准化,成为 TLS ,现在TLS 已经成为互联网中保密通信的工业标准。
我们知道,HTTP协议本身是不对数据加密的,也就是通过明文传输,如果有人恶意抓取网络数据包,很容易获取个人信息。因此在访问对安全性要求比较高的网站,比如银行,都是使用HTTPS协议,而非HTTP协议。
TLS协议工作于传输层,与应用层协议独立无关。高层的应用层协议(HTTP、FTP、Telnet等等)能透明的创建于TLS协议之上。例如,邮件传输也可以通过TLS进行加密。
准备 |
在了解TLS认证过程之前,先来准备一些基础的密码学知识。
对称密钥加密:
通信双方使用相同的密钥,这就要求密钥的传输非常安全,一旦密钥在传输中被拦截,加密失败。谍战片中情报人员手中的密码本就可以看做是对称密钥。非对称密钥加密(也叫公开密钥加密):
两个密钥:一个是公开密钥,另一个是私有密钥;一个用来加密,另一个用来解密;非对称加密则容许加密公钥随便散布,解密的私钥不发往任何用户,只在单方保管;即使公钥在网上被截获,如果没有与其匹配的私钥,也无法解密,非常适合在互联网上使用。
但是,由于公钥加密在计算上相对复杂,性能不如对称加密,因此通常情况下使用公钥加密来传输对称密钥,使用对称密钥来加密传输大量的主体数据。
过程 |
TLS工作流程整体上可以分为两步:
客户端和服务器端进行“握手”,身份验证通过后分别生成对称密钥
客户端使用对称密钥加密,服务端使用对称密钥解密,双方通过“对称密钥”进行加密通信。
TCP建立连接的时候,进行三次“握手”,TLS在通信之前也需要进行“握手”,可以分为四步,全部为明文通信。
一:客户端向服务器发送TLS协议的版本号、一个随机数A、以及所支持的加密算法(如RSA)
二:服务器确认是否支持客户端发送的TLS协议版本,同时给出数字证书(包含服务器的公钥)以及一个随机数B。
三:客户端验证数字证书有效后,生成一个新随机数C,并且使用证书中的公钥加密此随机数,最后将加密后的随机数发送到服务器。
四:服务器使用自己的私钥解密被加密后的随机数C,使用加密算法对随机数A、B、C进行加密,生成对称密钥。客户端使用同样的加密算法生成与服务器相同的对称密钥。
这样一来,对称密钥的传输就变得相对安全。对称密钥通过随机数A、B、C一起生成,A、B使用明文传输,可以被截取,但是C使用服务器的公钥加密,只要私钥没有泄露(私钥不通过网络传输),理论上使用TLS加密的通信是相对安全的(破解成本可能远远超过消息本身的价值)。
数字证书 |
上面提到客户端是通过服务器发送的数字证书来验证服务器的身份,进而确定公钥未被串改。那么客户端又如何验证数字证书的可靠性,这就不得不提到 公开密钥基础建设(Public Key Infrastructure,PKI)。网上看到“介绍信”的例子比较形象,非常适合说明数字证书的认证过程。
- 普通介绍信
假定A公司的张三先生去B公司公干,但是B公司没有人认识张三先生,常用的办法是带公司开的一张介绍信,在信中说:兹有张三先生前往贵公司办理业务,请给予接洽……云云。然后在信上敲上A公司的公章。
张三先生到了 B 公司后,把介绍信递给 B 公司的前台李四小姐。李小姐一看介绍信上有 A 公司的公章,而且 A 公司是经常和 B 公司有业务往来的(B公司有A公司的公章样本),这位李小姐就相信张先生不是歹人了。
看到这里,大家可能会有个疑问:
如果有人伪造了一个A公司的公章去B公司怎么办?
这时候就需要给A公司的公章加一些防伪技术。不法分子王二麻子拿着刚办的假证明去B公司找前台李四小姐要客户资料,李四小姐一验证公章,发现是伪造的,就按下了桌子底下的警报铃。
- 中介机构的介绍信
与B公司有业务往来的公司非常多,不仅仅是A一家,而每个公司的公章都不同,前台就必须能够辨别这所有的公章,非常麻烦。于是有家中介公司CA,发现“代理公章”有非常大的市场,专门提供代理公章的服务。
这样A公司的业务再去B公司,就需要带两个介绍信:一个分别含有A公司和CA公司两个公章,表明CA公司信任A公司。另一个和之前的普通介绍信相同。
如此一来,B公司的前台只需要认识CA公司的公章就可以了,B公司信任CA公司,CA公司信任A公司,B公司同样可以信任A公司,形成一条信任链。只要根证书可以信赖,根证书签署的下属证书同样也可以信赖。
这里的CA公司即数字证书认证机构(Certificate Authority,CA),是负责发放和管理数字证书的权威机构,是受公众信任的第三方。数字证书的签发使用的也是非对称密钥加密方式,CA使用手中的私钥为证书客户签署证书,公众则使用CA的公钥去验证证书客户手中的证书是否为CA签署。
- 认证的大致过程
服务器向客户端发送CA给自己签署的数字证书,包含两部分。
一:证书基本信息 C
证书签发者:
证书用途:
服务器的公钥
证书有效期
其他信息
二:加密后的证书信息 S,先对以上证书内容进行hash计算,得到一个hash值 H,然后CA使用自己的私钥对期hash值进行加密。P + S 就是所说的数字证书了。
客户端收到数字证书后,使用相同的hash算法对证书中的 C 部分进行计算得到 H1 ,然后使用 CA 公布的公钥对 S 解密得到 H,最后对比 H1 与 H 是否一致。一致说明证书可信,反之证书被篡改过。
小结 |
简单的梳理一下 TLS 认证的流程,总结了一些基础的密码学知识,后面会使用CloudFlare的开源工具集CFSSL来完成kubernetes集群双向 TLS 认证的配置。