[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