浅析SSL/TLS协议基本运行机制

前言

  在手动搭建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 认证的配置。