[ipsec][crypto] ike/ipsec与tls的认证机制比较

前言

接上篇：[ipsec][crypto] 有点不同的数字证书到底是什么

本篇内容主要是上一篇内容的延伸。抽象的从概念上理解了证书是什么之后，我们接下来

从实践的角度出发，以IKEv2和TLS两个协议为例子，熟悉一下数字证书认证在协议上的实现。

author: classic_tong, date:20190914

一 IKE

我是利用strongswan来搭建的这样的实验环境的。协商双方配置为使用证书的方式。

为此我自签名了一个根证书，并为IKE双方各自签名了其证书。

生成自签名的证书的方法可以见：[ipsec][strongswan] 用strongswan pki工具生成自签名证书

1.1 strongswan的配置

生成好证书，并安放到指定位置后，使用类似如下的配置：

connections {
        net-net {
                remote_addrs = 192.168.8.103
                local {
                        auth = pubkey
                        certs = t129Cert.pem
                }
                remote {
                        auth = pubkey
                        id = "C=CH, O=t9, CN=t9.tong.localhost"
                }

这里，我们可以看到，id的配置，就是证书中的subject。（情回顾上一篇文章中的内容，明确的建立了用户与名字之间的逻辑链条）

1.2 协商过程分析

首先，参考[ipsec] 特别硬核的ike/ipsec NAT穿越机制分析的第一章，请在理解了IKE交互的前提下，继续后续内容。

见下图，我们能见到，认证过程发生在第二次交互中。ike双方发送了自己的名字，和对方的名字，以及认证消息（通过私钥加密的内容，为了给对方认证，对方会通过

证书中的公钥解密，以此确认我方的身份合法）

author: classic_tong, date:20190914

我方用私钥加密的内容，已经在rfc中提前约定好。所以对方清楚解密后的内容应该是什么样子，才是正确的。大概内容就是上一个我方发送的数据包（也就是第一个通信数据包）。

响应端用户认证的内容是第二个通信数据包。

具体的内容见：https://tools.ietf.org/html/rfc7296#section-2.15

1.3 预共享秘钥的认证

顺便提及一下，预共享秘钥方式的认证。基本原理是一样的。只是在认证消息的计算过程中，加入了预共享秘钥信息。以此是无共享秘钥的人，我方计算出

数字签名的认证数据段。详见rfc：https://tools.ietf.org/html/rfc7296#section-2.15

除此之外，通信数据中的id信息也略有不同，见截图：

author: classic_tong, date:20190914

二 TLS

TLS的认证稍微有点复杂。我们先来说名字部分，如上一篇所述，名字是通过URL和证书中的SAN关联的。用户在浏览器中输入的域名必须在证书的SAN字段中存在。

才能通过用户到名字的逻辑链验证。然后，接下来说下一部分。先来看一下tls的信令交互图：

我们可以看见，server在验证client时，client分别发送了证书和证书verify数据给server用来验证，但是我们并没有看到server发送专门用来做认证

的消息段。原因是这样的，TLS的身份认证机制包含在里秘钥交互的机制中一同完成。

参考：https://security.stackexchange.com/questions/139176/details-of-tls-certificate-verification

https://tools.ietf.org/html/rfc5246#section-7.4.9

分RSA秘钥协商和DH秘钥协商两种情况来讨论。（我们是站在一般的https浏览应用来思考这个问题的，所以，这里只存在client验证server的单项讨论）

1. 使用RSA秘钥协商时，client会使用公钥加密一组私有内容发送给server来做秘钥协商。如果server没有私钥。协商结果一点是不一致的，最后client发送

过去的finish（11）消息将无法被正确解密，server也无法伪装出一个可以被正确解密的finished（13）消息发送回来。

In RSA key exchange, the client generates a random sequence of bytes and performs RSA encryption using the public key from the server's certificate. Then the client sends the resulting ciphertext to the server and expects the server to decrypt it (using the private key corresponding to the public key from the certificate) and use the random value in a KDF, together with other values, to generate symmetric keys and send a Finished message encrypted with the resulting symmetric keys. The client verifies the Finished message. The server can only succeed in generating the expected symmetric keys by decryption RSA encrypted message. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.2

2. 使用DH时，server用私钥对消息（4）做了数字签名，client可以用公钥进行验证。

In DHE/ECDHE key exchange with PFS, the server signs its ephemeral key using the private key corresponding to the public key in the certificate and sends this in ServerKeyExchange. The client verifies the signature using the public key from the certificate. https://tools.ietf.org/html/rfc5246#appendix-F.1.1.3

author: classic_tong, date:20190914