在很久之前，我在 划一划 HTTPS 以及 SSL/TLS 的重要知识点 提到过客户端 HTTPS 证书，之后就没后续了，不过目前还是遇到了接口问题，不得不用上了。

简介

接下来会给大家说清几个概念：HTTPS 单向认证、HTTPS 双向认证、中间人攻击。

HTTPS 单向认证与双向认证

在这两种认证场景中，主要的区别在于服务器是不是需要客户端提供证书验证，我们，在进行 TCP 三次握手成功后，就开始进行 SSL 阶段的握手了了。

SSL 握手阶段可以参考如下，此图盗自 Ssl handshake with two way authentication with certificates 。这张图里面的大致阶段是对的，只是并不是很详细，更详细的请参考 Transport Layer Security 。

Ssl handshake with two way authentication with certificates

正如如上图所示，这个过程中，主要区别就在于第三阶段1：

  • 第一阶段：协商，客户端发送 hello 消息，会包含自己能支持的最大支持的 TLS 版本，一个随机数，以及一系列建议的加密套件以及压缩方法；然后服务器在接收之后，也会发送 hello 消息，包含着根据客户端挑选过的 TLS 版本，加密套件以及压缩方法；
  • 第二阶段：服务器证书处理，服务器会将证书发送至客户端，并且紧接着就会发送一个要求发送客户端证书的请求，客户端会在这个时间根据 CA 来验证服务器的证书；
  • 第三阶段：客户端证书处理，客户端会将证书发送至服务器，服务器会根据 CA 来验证（这个 CA 可以完全是自己生成的），客户端同时会发送一个用服务器证书加密过的随机数 PreMasterSecret，然后客户端会发送一个前一个握手阶段的消息的签名来告诉服务器，客户端是的确是拥有当前证书的（有私钥），然后客户端以及服务器会根据 PreMasterSecret 以及随机数，来生成一个公共的 secret，叫做 Master secret；
  • 第四阶段：加密通信，两边开始都用 Master secret 来进行对称的加解密；

如果把第三阶段省略掉，那就变成单向认证了，所以担心加密过程开销的同学们可以稍稍省点心了，因为整个过程中，就是 SSL 握手阶段的开销会略微加大，而实际通信过程中的开销还是与单向认证一样。

中间人攻击

所谓中间人攻击，就是在双方握手阶段，由于没有用 CA 对证书进行验证造成的问题：比如你如果不在意浏览器的警告，或者被骗安装了攻击者提供的 CA 证书。攻击者可以在你与服务器建立 SSL 通信的时候，先用假的证书与你建立 SSL 通信，然后再与服务器建立 SSL 通信，这个过程中，攻击者就能拿到这个过程中所有的明文消息。

用一个非常简单的例子来说明，就是 HTTPS 抓包，比如现在你需要抓手机上的 HTTPS 请求，那么你就需要在手机上安装抓包工具提供的 CA 证书，然后配置好代理后，就可以抓到 HTTPS 的明文请求了。

我们的问题

到目前，我们知道了 HTTPS 双向认证是怎么一回事，那么它能解决我们的什么问题呢？防止有人冒充我们的客户端来请求服务器的私有资源，那么我们可以直接去验证客户端的身份，就能在很大程度上解决问题。

下面自问自答，来帮大家理清楚思路：

为什么不用自己的方式来加密呢？

相信这样的场景很常见，为了保护接口，直接跟客户端约定一个密钥，然后大家根据这个密钥来进行加密通信，这种方案在我看来很容易破解，而且一旦破解拿到密钥，你很难短时间里面通过更新客户端来更换密钥。

这种方式，做的好的能够使用公开经得起验证的加密算法，而做的差的会用私有加密算法（多个公开算法叠加套用不算私有）。这在一定程度上能够阻挡破解者，只是私有加密算法出问题的概率在遇到高价值资源的时候，就会变得非常大，简而言之，就如闭源与开源一般。

另外，还有个很尴尬的地方在于，在开发人员进行接口调试的时候，一大段密文信息将会让调试非常困难。于是，所谓的的防止破解，更多的时候都在恶心开发者自己了。

用 HTTPS 证书就不会有这个问题了，在自己电脑安装完成证书后，就能在浏览器中明文调试了。

会给服务器造成很大压力吗？

理论上，跟 HTTPS 单向的认证区别就在于多了一步验证客户端证书的过程，因此会多出 SSL 握手时的开销，具体我还没有压力测试过，但是我相信玩过 kubernetes 的应该会对此有个概念。

如果你预计会有比较大的流量，不放心，那就建议先找几台机器进行测试再决定也不迟。

客户端证书不是也有泄露的风险吗？

确实如此，如果客户端会流落在他人手里，那么在不加一层保护的前提下，确实有可能会泄露，只是你有两种方案可以一起使用来保护证书：

  1. 混淆客户端证书，让破解者无法通过简单的 strings 命令, 或者解压你的安装包就能获取到明文证书。另外，你也可以直接用 pkcs12 格式的证书，记得更换一个更强的密码；
  2. 即使证书泄露，你还可以在服务器配置一个撤销证书列表，这样，被泄露的证书就没有权限来访问了；

为何我对于客户端证书如此推崇？

我的理由主要有两点：

  1. 有着广泛的支持，操作系统本身以及各种反向代理 Nginx、Apache，网络工具 curl、wget 以及各种语言等；
  2. 加密通信是应该由通信协议本身来解决的问题，它应该与具体传输的内容解耦，所以它还能支持其它协议，比如 MQTT、AMQP 等等；

大多数没有选择客户端证书的，我认为是因为对它不够了解，或者说它的强大显得过于简单，导致很多人都没有什么安全感，尤其是领导没有什么安全感，但是请大家不妨想想现在有谁能够简单破解 HTTPS 请求内容呢？基于 RSA 加密的通信，是我们现代互联网的安全基础，没有谁能够轻易破解。

如何实现2、3

目前大部分方案都是拿 OpenSSL + Nginx 来举例的（随便搜索都是一大堆），那我就把 OpenSSL 换成更简单好用的 CFSSL 。

安装

多种方式可选，比如最简单的就是直接去下载已经编译好的工具：cfssl/releases 。

我目前使用的是 v1.5.0 版本的，大版本前提下，命令应该不会相差太多。

CA 证书

生成 CA 默认配置：

1
cfssl print-defaults config > ca-config.json

这里面的内容需要略加修改，下面给出一个我修改的例子，因为今天只需要客户端证书，因此 profiles 里面只留下了 client，signing.default.expiry 表示签发证书的默认过期时间，时间比较短，而另一个 signing.profiles.client.expiry 则比较长，8760h 就表示一年了。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    "signing": {
        "default": {
            "expiry": "168h"
        },
        "profiles": {
            "client": {
                "expiry": "8760h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            }
        }
    }
}

然后是生成 CA 证书申请：

1
cfssl print-defaults csr > ca-csr.json

也需要根据自己的情况修改，这里需要注意下 key，v1.5.0 下面默认是 ecdsa-256 ，而我改成了 rsa-2048，只是为了说明方便，以及兼容性。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
{
    "CN": "Awesome Inc",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Guangdong",
            "L": "Shenzhen",
            "O": "Awesome Inc",
            "OU": "Tech Dept"
        }
    ]
}

然后就可以生成 CA 证书了：

1
cfssl gencert -initca ca-csr.json | cfssljson -bare ca -

在当前目录下，会生成三个文件：

  • ca-key.pem CA 密钥
  • ca.csr CA 证书请求
  • ca.pem CA 证书

客户端证书

接下来就开始生产客户端证书，与上面是类似的：

1
cfssl print-defaults csr > client.json

照例给出 client.json 的修改样例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
{
    "CN": "xizhibei",
    "hosts": [""],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "ST": "Guangdong",
            "L": "Shenzhen",
            "O": "Awesome Inc",
            "OU": "Tech Dept"
        }
    ]
}
1
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client

命令行中会出现如下的日志：

2021/02/03 15:21:09 [INFO] generate received request
2021/02/03 15:21:09 [INFO] received CSR
2021/02/03 15:21:09 [INFO] generating key: rsa-2048
2021/02/03 15:21:10 [INFO] encoded CSR
2021/02/03 15:21:10 [INFO] signed certificate with serial number 657128885698804019594922156238712961504332210277

然后生成了三个文件：

  • xizhibei-key.pem
  • xizhibei.csr
  • xizhibei.pem

撤销证书

当证书发布出去后，在有效期之前，它是一直有效的，但是如果我们想让它提前失效（比如泄露的情况下），那么就需要用到撤销证书。

比如，我们要撤销上面刚刚生成的证书，需要先将序列号写入撤销证书序列号列表，然后来生成撤销证书：

1
2
echo 657128885698804019594922156238712961504332210277 >> crl-serials.txt
cfssl gencrl crl-serials.txt ca.pem ca-key.pem| base64 -D | openssl crl -inform DER -out ca-crl.pem

然后替换已有的撤销证书即可。

好了，到目前为止，证书部分基本上就搞定了，相对 OpenSSL 来说是不是很简单？

配置 Nginx

将上面生成的 ca.pem 以及 ca-crl.pem 放在 /etc/nginx/certs/client_ca 中，然后在 server 中如下配置（这里假设你已经开启了 HTTPS，并且配置好了服务端的证书）：

1
2
3
ssl_client_certificate /etc/nginx/certs/client_ca/ca.pem;
ssl_crl /etc/nginx/certs/client_ca/ca-crl.pem;
ssl_verify_client on;

更新 Nginx：

1
nginx -s reload

这里留给你一个思考题，为什么这里只需要配置一个 CA 证书就可以了？

客户端证书的安装

如果你在配置好 nginx 后，直接用浏览器请求网站，那么你就会看到一个 HTTP 400 错误，告诉你需要提供证书。

nginx 400 bad request

本地安装证书很简单，直接鼠标双击证书就能够安装，如果是 Mac，记得在 Keychain 中配置始终信任。

另外，为了方便发送证书给他人使用，建议打包成 pkcs12 格式的证书，还能设置密码。

1
2
3
openssl pkcs12 -export -clcerts \
    -CApath . -inkey xizhibei-key.pem -in xizhibei.pem \
    -certfile ca.pem -passout pass:strong-password -out xizhibei.p12

Ref

  1. Transport Layer Security
  2. Generate self-signed certificates
  3. kubernetes-the-hard-way

首发于 Github issues: https://github.com/xizhibei/blog/issues/159 ，欢迎 Star 以及 Watch

本文采用 署名-非商业性使用-相同方式共享（BY-NC-SA）进行许可
作者：习之北 (@xizhibei)
原链接：https://blog.xizhibei.me/zh-cn/2021/02/03/https-two-way-authentication-with-certificates/