TLS 1.2 基於DH是如何交換密鑰?

12-28

最近常見到ECDHE_RSA_WITH_AES_128_GCM_SHA256的加密方法,AES_128_GCM是數據交換時的加密演算法,SHA256是校驗的演算法,那麼ECDHE_RSA說是用在密鑰交換上.
據我所知道ECDHE是用在第3次客戶端請求到伺服器後,雙方都生成premaster secret.最後加上2次隨機數生成master secret.
問題來了,第一次clientHello就毫無疑問,但serverHello所相應的是SSL證書裡面RSA的公鑰,如何客戶端是XP系統,不支持RSA,瀏覽器又怎麼知道我這證書的真偽呢?
serverHello時所響應的DH公鑰有被RSA私鑰簽名了嗎?如果沒有,中間人是不是可以攔截,然後自己生成DH對,將中間人DH公鑰發給瀏覽器,瀏覽器再將自己生成的DH公鑰發給了中間人,中間人再生成一套DH對.再將這DH的公鑰發給伺服器.這樣中間人就有兩個master secret,在中間加/解密傳輸的數據.即經過3次握手會變成這樣:
client V2+中間人DH公鑰(A)+自己DH私鑰=master secret(A)
middle V2+client DH公鑰+自己DH私鑰(A)=master secret(A)
V2+server DH公鑰+自己DH私鑰(B)=master secret(B)
server V2+中間人 DH公鑰(B) +自己DH私鑰=master secret(B)
我這樣理解對嗎?如果client用SSL證書RSA公鑰檢驗收到的DH私鑰即能打破上面關係.
瀏覽器是不是用SSL證書的RSA公鑰對自己生成的DH公鑰簽名然後發給伺服器?這樣是不是也能解決上述問題?
還有一個問題就是客戶端只能驗證SSL證書的正確性(不被篡改)?並不能驗證SSL證書是從真正的伺服器發過來的?
如果是用ECDHE_RSA,那麼這裡的RSA是在什麼時候使用的?

參考：
TLS協議分析與現代加密通信協議設計
RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2

1. "但serverHello所相應的是SSL證書裡面RSA的公鑰,如何客戶端是XP系統,不支持RSA,瀏覽器又怎麼知道我這證書的真偽呢?"

（1）ServerHello 消息並不發送伺服器端的證書，伺服器在 Certificate 消息裡面發送伺服器的證書（其中包含RSA公鑰）。
（2） Windows XP系統自帶的 tls 協議實現 SChannel （ie瀏覽器使用這個實現），支持RSA數字簽名演算法。參考M$的官方文檔 TLS Cipher Suites (Windows)
（3）RSA演算法一般是純軟體比如C語言實現的，並不需要操作系統支持。
（4）瀏覽器藉助內置的根證書列表來驗證伺服器發過來的證書的真偽。

2. "serverHello時所響應的DH公鑰有被RSA私鑰簽名了嗎?"

SSL/TLS 協議規定，當使用 DH演算法+RSA證書做密鑰交換時，必須用證書的RSA私鑰對伺服器端的 DH 公鑰做數字簽名。事實上，不是光對DH公鑰做簽名，而是對
DH_p(模數) + DH_g(生成元) + DH_Ys(伺服器的DH公鑰) + client_random + server_random 一起做了數字簽名。
參見如下 TLS1.2 rfc標準: RFC 5246 - The Transport Layer Security (TLS) Protocol Version 1.2

struct { opaque dh_p&<1..2^16-1&>; opaque dh_g&<1..2^16-1&>; opaque dh_Ys&<1..2^16-1&>; } ServerDHParams; /* Ephemeral DH parameters */


      dh_p

         The prime modulus used for the Diffie-Hellman operation.
      dh_g

         The generator used for the Diffie-Hellman operation.
      dh_Ys

         The server"s Diffie-Hellman public value (g^X mod p).
      struct {

          select (KeyExchangeAlgorithm) {

              case dhe_rsa:

                  ServerDHParams params;

                  digitally-signed struct {

                      opaque client_random[32];

                      opaque server_random[32];

                      ServerDHParams params;

                  } signed_params;

          };

      } ServerKeyExchange;
      params

         The server"s key exchange parameters.

signed_params For non-anonymous key exchanges, a signature over the server"s key exchange parameters.

3. "我這樣理解對嗎?如果client用SSL證書RSA公鑰檢驗收到的DH私鑰即能打破上面關係."

client用伺服器證書的RSA公鑰校驗上面提到的伺服器DH公鑰的數字簽名，即可確認"我確實是在和這個RSA公鑰對應的伺服器做DH密鑰交換"

4."瀏覽器是不是用SSL證書的RSA公鑰對自己生成的DH公鑰簽名然後發給伺服器?這樣是不是也能解決上述問題?"

RSA數字簽名要用私鑰進行。
RSA加密用公鑰進行。
TLS協議共2類密鑰交換方法：DH/ECDH類密鑰交換，和 RSA密鑰交換。
RSA密鑰交換指：在客戶端生成一個 PreMasterSecret，然後用伺服器的RSA公鑰加密後，發給伺服器，伺服器用RSA私鑰解密，即可。

5. "還有一個問題就是客戶端只能驗證SSL證書的正確性(不被篡改)?並不能驗證SSL證書是從真正的伺服器發過來的?"
客戶端可以確信「我是在和持有當前伺服器RSA私鑰的實體在做密鑰交換」
證書可以不是從真正的伺服器發過來的，但是能通過驗證的，伺服器DH公鑰的數字簽名，只有持有RSA私鑰的實體才能簽署出來，據此驗證了對端的身份。

6. "如果是用ECDHE_RSA,那麼這裡的RSA是在什麼時候使用的?"
這裡的RSA是在 Server Key Exchange 的時候，對伺服器端的臨時 ECDH 公鑰做 RSA 數字簽名的時候用的。

7."最近常見到ECDHE_RSA_WITH_AES_128_GCM_SHA256的加密方法,AES_128_GCM是數據交換時的加密演算法,SHA256是校驗的演算法,那麼ECDHE_RSA說是用在密鑰交換上."

ECDHE_RSA_WITH_AES_128_GCM_SHA256 這種是TLS中的「CipherSuite」（密碼學演算法套件）。
其中的 SHA256 並不是做校驗/MAC演算法用的，而是用來構成 PRF做密鑰衍生的（從MasterSecret生成出來 AES_128_GCM用的密鑰），見 RFC 5288 - AES Galois Counter Mode (GCM) Cipher Suites for TLS 。

更詳細的分析，請閱讀 TLS協議分析與現代加密通信協議設計

如有錯誤，歡迎指正。