[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

View Code

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

View Code

 author: classic_tong, date:20190914