[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