ssl的基礎知識,趁最近的專案又再熟悉下:
單向的意思是僅客戶端驗證服務端證書，而不需要客戶端也給證書給服務端去驗證.
協議:tlsv1.2
random: 生成會話金鑰用
cipher suites:宣告支援的演算法
cipher suite:回應採用的演算法
random：用於生成會話金鑰
伺服器證書給客戶端，
server端ecdh 的引數,dh演算法是金鑰交換演算法，給對方引數是必要的
使用ecdh交換金鑰和rsa公鑰證書加密傳送金鑰是一樣的效果，如果之前是rsa,就沒有這步，後續直接client key exchage就夠了
server hello結束
ecdh，客戶端給引數給服務端，用於交換金鑰
rsa證書, 則會用證書公鑰加密會話金鑰
change cipher spec前面說的會話金鑰，在這真正使用.
客戶端通知伺服器開始使用加密方式傳送報文。客戶端使用上面的3個隨機數client random, server random, pre-master secret, 計算出48位元組的master secret, 這個就是用於加解密的對稱加密演算法的會話金鑰。
服務端按此方法可計算出同樣的會話金鑰.
客戶端傳送第乙個加密報文。使用hmac演算法計算收到和傳送的所有握手訊息的摘要，然後通過rfc5246中定義的乙個偽函式prf計算出結果，加密後傳送。
服務端完成和客戶端類似的change cipher spec, encrypted handshake message動作.
前面的握手太複雜，如果金鑰失效了每次，都重新握手，挺麻煩.
引入類似web中cookie和session的機制.
特別注意最後server 端發了個new session ticket! 它怎麼來的?
1：客戶端發起client hello，拓展中帶上空的session ticket tls，表明自己支援session ticket。
2：伺服器在握手過程中，如果支援session ticket，則傳送new session ticket型別的握手報文，其中包含了能夠恢復包括主金鑰在內的會話資訊，當然，最簡單的就是只傳送master key。為了讓中間人不可見，這個session ticket部分會進行編碼、加密等操作。
3：客戶端收到這個session ticket，就把當前的master key和這個ticket組成一對鍵值儲存起來。伺服器無需儲存任何會話資訊，客戶端也無需知道session ticket具體表示什麼。
4：當客戶端嘗試會話復用時，會在client hello的拓展中加上session ticket，然後伺服器收到session ticket，回去進行解密、解碼能相關操作，來恢復會話資訊。如果能夠恢復會話資訊，那麼久提取會話資訊的主金鑰進行後續的操作。
session ticket
SSL伺服器認證過程！
理解有錯誤的地方，請高手指正！1，ca中心，有一套自己的公鑰和私鑰，ca用自己的私鑰去生成乙個自認證的證書 2，ca中心的自認證證書是有公信力的，一般被客戶端所熟知，發放到每個客戶端！3，客戶端需要將ca中的自認證證書加入信任列表！4，伺服器要加入ca體系，要向ca中心申請，ca中心驗證了伺服器的資...
SSL 單向和雙向認證加密過程
1原理 2單向和雙向驗證 3 詳解 1 單向認證 只有乙個物件校驗對端的證書合法性。通常都是client來校驗伺服器的合法性。那麼client需要乙個ca.crt,伺服器需要server.crt,server.key 2 雙向認證 相互校驗，伺服器需要校驗每個client,client也需要校驗伺服...
SSL的單向認證和雙向認證
客戶端向伺服器傳送clienthello訊息，說明它支援的最高tls協議版本，隨機數 密碼演算法列表及壓縮方法。伺服器回覆serverhello訊息，包含基於客戶端clienthello訊息所選擇的tls協議版本，隨機數 密碼演算法列表及壓縮方法。伺服器選擇的協議版本為客戶端和伺服器都支援的最高版本...