SSL握手中的個別細節

1.CipherSuite
CipherSuite由三部分組成：金鑰交換演算法，對稱式加密演算法，簽名演算法。這三個演算法組合而成一個Suite，金鑰交換演算法描述握手訊息中的KeyExchange的相關細節，這裡交換的是pre-master，而對稱式加密演算法描述金鑰交換演算法交換的內容細節的用法，簽名演算法的作用主要在認證。所以，雖然一般上SSL握手都是在client KeyExchange中使用server的公開金鑰加密pre-master，然而這並不是唯一的做法，比如如果CipherSuite是TLS_DH_RSA_WITH_DES_CBC_SHA的話，那就說明使用DH演算法交換密鑰，而是用RSA進程前面，摘要演算法是SHA。注意，金鑰交換演算法和認證的類型沒有什麼關係，認證只是為了驗證對端的身份，和金鑰交換演算法屬於不同的業務範疇，它們之間的一點聯絡就是有的時候用伺服器憑證裡面的內容就能使得用戶端將pre-master安全的傳輸給伺服器，比如RSA簽名的RSA公開金鑰的認證，從認證中就能取出伺服器的公開金鑰，於是用戶端就可以使用該公開金鑰來加密自己的pre-master，自己留一份，傳給伺服器一份，於是兩端都有了這個pre-master，然後就可以計算出相同的對稱金鑰了，如果是DH金鑰交換演算法，那麼也很簡單，雖然認證中可能沒有DH相關的資訊，但是伺服器端可以在Server KeyExchange訊息中包含DH的自己的份額，然後用戶端在Client KeyExchange中包含DH的自己的份額，然後兩端即可計算出相同的對稱金鑰了，不管怎樣總是能協商出一個僅此兩端共用的對稱金鑰。認證用於認證，但是有時也能包含一些用於金鑰交換的資訊(比如RSA)，CipherSuite中的KeyExchangeMethod用於金鑰交換，資訊可以和認證毫無關聯。
2.certificate verify訊息
該訊息的含義在於認證用戶端，由於伺服器端通常信任很多用戶端，如果A和B都是伺服器信任的，A要是拿著B的認證進行驗證就不好了，所以用戶端如果提供認證的話，那麼就要發送這個訊息來證實自己就是認證的所有者。正如認證一個人的身份不能只看他的證件是否有效，還要他按指印或者簽字是一樣的道理。那麼為何伺服器端不用發送這個訊息來證實自己的身份呢？多個伺服器也是可以互相盜用認證的，以RSA金鑰交換演算法為例，答案就在於pre-master是用從伺服器憑證取出的公開金鑰加密的，然後由用戶端發給伺服器的，如果伺服器憑證不是自己的，那麼它將無法解密這個pre-master。不過要注意，有時候為了效率因素，有些情況下在SSL握手互動過程中是不驗證認證所有者的身份真實性的，這就可能招來中間人攻擊。
3.Finished訊息
該訊息是SSL握手中的最後要互傳的訊息，包含一個所有握手訊息的摘要值，這是為了防止中間人將強度較大的CipherSuite在client hello訊息中刪除，使得server不得不選擇強度較小的CipherSuite，然而這非client所願。問題是這個摘要不可以被中間人更改嗎？想象一下這時共用對稱金鑰已經協商好了，ChangeCipherSpec已經經過，所以這些訊息本身是加過密的。
4.所有細節詳情：參考RFC2246