HTTPS協議詳解三 PKI 體系

1、rsa身份驗證的隱患

身份驗證和金鑰協商是tls的基礎功能，要求的前提是合法的伺服器掌握著對應的私鑰。但rsa演算法無法確保伺服器身份的合法性，因為公鑰並不包含伺服器的資訊，存在安全隱患:

客戶端c和伺服器s進行通訊，中間節點m截獲了二者的通訊;

節點m自己計算產生一對公鑰pub_m和私鑰pri_m;

c向s請求公鑰時，m把自己的公鑰pub_m發給了c;

c使用公鑰 pub_m加密的資料能夠被m解密，因為m掌握對應的私鑰pri_m，而 c無法根據公鑰資訊判斷伺服器的身份，從而 c和 m之間建立了"可信"加密連線;

中間節點 m和伺服器s之間再建立合法的連線，因此 c和 s之間通訊被m完全掌握，m可以進行資訊的竊聽、篡改等操作。

另外，伺服器也可以對自己的發出的資訊進行否認，不承認相關資訊是自己發出。

因此該方案下至少存在兩類問題：中間人攻擊和資訊抵賴。

2、身份驗證ca和證書

解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證伺服器的身份資訊，為此需要引入權威的第三方機構ca(如沃通ca)。ca 負責核實公鑰的擁有者的資訊，並頒發認證"證書"，同時能夠為使用者提供證書驗證服務，即pki體系(pki基礎知識)。

基本的原理為，ca負責審核資訊，然後對關鍵資訊利用私鑰進行"簽名"，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。ca也可以吊銷已經簽發的證書，基本的方式包括兩類 crl 檔案和 ocsp。ca使用具體的流程如下：

a.服務方s向第三方機構ca提交公鑰、組織資訊、個人資訊(網域名稱)等資訊並申請認證;

b.ca通過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有網域名稱的所有權等;

c.如資訊審核通過，ca會向申請者簽發認證檔案-證書。

證書包含以下資訊：申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 ca的資訊、有效時間、證書序列號等資訊的明文，同時包含乙個簽名;

簽名的產生演算法：首先，使用雜湊函式計算公開的明文資訊的資訊摘要，然後，採用 ca的私鑰對資訊摘要進行加密，密文即簽名;

d.客戶端 c 向伺服器 s 發出請求時，s 返回證書檔案;

e.客戶端 c讀取證書中的相關的明文資訊，採用相同的雜湊函式計算得到資訊摘要，然後，利用對應 ca的公鑰解密簽名資料，對比證書的資訊摘要，如果一致，則可以確認證書的合法性，即公鑰合法;

f.客戶端然後驗證證書相關的網域名稱資訊、有效時間等資訊;

g.客戶端會內建信任ca的證書資訊(包含公鑰)，如果ca不被信任，則找不到對應 ca的證書，證書也會被判定非法。

在這個過程注意幾點：

a.申請證書不需要提供私鑰，確保私鑰永遠只能伺服器掌握;

b.證書的合法性仍然依賴於非對稱加密演算法，證書主要是增加了伺服器資訊以及簽名;

c.內建 ca 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書（為什麼說"部署自簽ssl證書非常不安全"）

d.證書=公鑰+申請者與頒發者資訊+簽名;

3、證書鏈

如 ca根證書和伺服器證書中間增加一級證書機構，即中間證書，證書的產生和驗證原理不變，只是增加一層驗證，只要最後能夠被任何信任的ca根證書驗證合法即可。

a.伺服器證書 server.pem 的簽發者為中間證書機構 inter，inter 根據證書 inter.pem 驗證 server.pem 確實為自己簽發的有效證書;

b.中間證書 inter.pem 的簽發 ca 為 root，root 根據證書 root.pem 驗證 inter.pem 為自己簽發的合法證書;

c.客戶端內建信任 ca 的 root.pem 證書，因此伺服器證書 server.pem 的被信任。

HTTPS協議詳解 三 PKI 體系