說明：這里我只記錄https中的傳輸層安全(Transport Layer Security，TLS)一些細節(jié)? 個人總結(jié)如有不恰當(dāng)?shù)牡胤竭€請禮貌指正
1 https是使用非對稱加密實現(xiàn)對稱加密的協(xié)商，通過非對稱加密確定一個受信任的來自目標(biāo)服務(wù)器的公鑰，通過這個公鑰來協(xié)商一個對稱加密的秘鑰之后的傳輸都使用這個對稱秘鑰來加密傳輸博肋。
2 現(xiàn)在的問題就是如何確保這個公鑰是受信任的? 首先明確一點：來自我們目標(biāo)服務(wù)器 沒有別修改的公鑰就是受信任的舟肉，如何保證這個過程沒有被修改和替換呢桶现，https中使用一個權(quán)威的第三方機構(gòu)來保證具體步驟如下：
3 首先服務(wù)器生成一對公鑰和私鑰 這對公鑰私鑰用于和client協(xié)商一次請求中的對稱密鑰（對稱秘鑰是通過公鑰傳輸給server的）為了保證公鑰在傳輸?shù)倪^程中不被修改和替換 server會先向CA機構(gòu)申請一個代表server的證書該證書由ca創(chuàng)建 證書包含了具體server的一些信息和Ca的一些信息比如ca的名稱證書的擁有者證書的有效期 簽名的加密算法 等基本信息厉碟，證書中還包含一個特殊的東西：數(shù)字簽名。數(shù)字簽名是ca跟具server提供的信息使用MD得到的一個固定長度的數(shù)據(jù)后使用ca自己的私鑰加密后的數(shù)據(jù)屠缭。server在每次收到client的請求是都將證書發(fā)送給client 當(dāng)然這個發(fā)送的過程中中間節(jié)點也能收到這個證書 但是中間節(jié)點對這個證書動的手腳或者替換這個證書 client都能知道箍鼓。一旦client發(fā)現(xiàn)證書被動過手腳 client報證書驗證不通過錯誤此次請求失敗。
? ? 4 client驗證證書的過程：client拿到證書后首先會從系統(tǒng)中找出ca的公鑰 解密出數(shù)字簽名的原始數(shù)據(jù) 然后更具證書中的算法和證書上的數(shù)據(jù) 自己重新計算一遍 之后對比兩個 數(shù)據(jù)數(shù)據(jù)是否一致如果一致則 證書是受信任的 這里中間節(jié)點如果要對證書使壞分兩點 中間節(jié)點自己也有一個合法的ca頒發(fā)的證書? 然后將自己的證書的信息改成 server的信息 將修改的后的證書替換原證書發(fā)送給clinet 這個時候client拿到修改后的證書 最后對比元數(shù)據(jù)肯定是不通過的 最后驗證失敗呵曹。還有一種就是中間節(jié)點同時修改信息和數(shù)字簽名 這樣修改的證書邏輯上就是一個完整的證書了 但由于client拿的公鑰無法解密出數(shù)字簽名的原始數(shù)據(jù)最終依然驗證失斂羁А（client只含有受信任的ca的公鑰）
5 現(xiàn)在假定client證書驗證通過 確定證書沒毛病之后 會從證書中取出server的公鑰 client使用這個公鑰加密自己生成的一個對稱加密的秘鑰發(fā)送給server 這個過程是不會出現(xiàn)安全問題的因為私鑰只在server中 server收到公鑰加密后的數(shù)據(jù)后使用私鑰解密拿到最終的對稱加密秘鑰 之后的通信過程就都是使用這個對稱加密秘鑰來保證通信的安全何暮。
