The Classic Tong's Cave

前言

接上篇：[ipsec][crypto] 有點(diǎn)不同的數(shù)字證書到底是什么

本篇內(nèi)容主要是上一篇內(nèi)容的延伸。抽象的從概念上理解了證書是什么之后，我們接下來

從實(shí)踐的角度出發(fā)，以IKEv2和TLS兩個(gè)協(xié)議為例子，熟悉一下數(shù)字證書認(rèn)證在協(xié)議上的實(shí)現(xiàn)。

author: classic_tong, date:20190914

一 IKE

我是利用strongswan來搭建的這樣的實(shí)驗(yàn)環(huán)境的。協(xié)商雙方配置為使用證書的方式。

為此我自簽名了一個(gè)根證書，并為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。（情回顧上一篇文章中的內(nèi)容，明確的建立了用戶與名字之間的邏輯鏈條）

1.2 協(xié)商過程分析

首先，參考[ipsec] 特別硬核的ike/ipsec NAT穿越機(jī)制分析 的第一章，請(qǐng)?jiān)诶斫饬薎KE交互的前提下，繼續(xù)后續(xù)內(nèi)容。

見下圖，我們能見到，認(rèn)證過程發(fā)生在第二次交互中。ike雙方發(fā)送了自己的名字，和對(duì)方的名字，以及認(rèn)證消息（通過私鑰加密的內(nèi)容，為了給對(duì)方認(rèn)證，對(duì)方會(huì)通過

證書中的公鑰解密，以此確認(rèn)我方的身份合法）

author: classic_tong, date:20190914 

我方用私鑰加密的內(nèi)容，已經(jīng)在rfc中提前約定好。所以對(duì)方清楚解密后的內(nèi)容應(yīng)該是什么樣子，才是正確的。大概內(nèi)容就是上一個(gè)我方發(fā)送的數(shù)據(jù)包（也就是第一個(gè)通信數(shù)據(jù)包）。

響應(yīng)端用戶認(rèn)證的內(nèi)容是第二個(gè)通信數(shù)據(jù)包。

具體的內(nèi)容見：https://tools.ietf.org/html/rfc7296#section-2.15

 1.3 預(yù)共享秘鑰的認(rèn)證

順便提及一下，預(yù)共享秘鑰方式的認(rèn)證。基本原理是一樣的。只是在認(rèn)證消息的計(jì)算過程中，加入了預(yù)共享秘鑰信息。以此是無共享秘鑰的人，我方計(jì)算出

數(shù)字簽名的認(rèn)證數(shù)據(jù)段。詳見rfc：https://tools.ietf.org/html/rfc7296#section-2.15

 除此之外，通信數(shù)據(jù)中的id信息也略有不同，見截圖：

 author: classic_tong, date:20190914

二 TLS

TLS的認(rèn)證稍微有點(diǎn)復(fù)雜。我們先來說名字部分，如上一篇所述，名字是通過URL和證書中的SAN關(guān)聯(lián)的。用戶在瀏覽器中輸入的域名必須在證書的SAN字段中存在。

才能通過用戶到名字的邏輯鏈驗(yàn)證。然后，接下來說下一部分。先來看一下tls的信令交互圖：

我們可以看見，server在驗(yàn)證client時(shí)，client分別發(fā)送了證書和證書verify數(shù)據(jù)給server用來驗(yàn)證，但是我們并沒有看到server發(fā)送專門用來做認(rèn)證

的消息段。原因是這樣的，TLS的身份認(rèn)證機(jī)制包含在里秘鑰交互的機(jī)制中一同完成。

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

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

分RSA秘鑰協(xié)商和DH秘鑰協(xié)商兩種情況來討論。（我們是站在一般的https瀏覽應(yīng)用來思考這個(gè)問題的，所以，這里只存在client驗(yàn)證server的單項(xiàng)討論）

1. 使用RSA秘鑰協(xié)商時(shí)，client會(huì)使用公鑰加密一組私有內(nèi)容發(fā)送給server來做秘鑰協(xié)商。如果server沒有私鑰。協(xié)商結(jié)果一點(diǎn)是不一致的，最后client發(fā)送

過去的finish（11）消息將無法被正確解密，server也無法偽裝出一個(gè)可以被正確解密的finished（13）消息發(fā)送回來。

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時(shí)，server用私鑰對(duì)消息（4）做了數(shù)字簽名，client可以用公鑰進(jìn)行驗(yàn)證。

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