《HTTPS權威指南》-公鑰基礎設施（PKI）學習筆記

握手中的身份驗證的流程：

由《HTTPS權威指南》-協議學習筆記知道了握手協議中身份驗證流程，這裏再摘出一遍：
一、Client向Server say hello
二、Server將明文信息（包含publicKey_server）用協商的散列算法散列、編碼而後用privateKey_server加密製做成了簽名。將簽名以及明文信息發送給Client。
三、Client用協商的散列算法計算明文的散列，使用publicKey_server解密服務器的簽名，對比本身計算出的散列是否和服務器給的散列一致。從而實現服務器的身份驗證。

這樣作的危險：
危險1：
一、若是Attacker截獲了Client的say hello，能夠把publicKey_attacker返回給Client，取得Client的信任，至此Attacker與Client創建了安全鏈接。
二、Attacker冒充Client向Server發送say hello，至此Attacker與Server創建了安全鏈接。
三、這樣，Client對Server發送的信息都被Attacker截獲並解密了。
危險2：
一、服務器能夠否定本身發送過的消息。

如何避免？
Client信任一些第三方權威機構（CA），而後由這些CA對Server的證書（包含了publicKey_Server）進行簽名，Server提供這個被CA簽名的證書給Client驗證。
這樣就造成了信任流：Client 信任 CA， CA信任Server，So Client信任Server。從而達到Server的身份驗證。
PKI（public key infrastructure公鑰基礎設施）就是用來解決如何使用和驗證證書的。當前使用的是基於可信的第三方機構，也就是證書頒發機構CA簽發證書。

實現流程圖：

屏幕快照 2016-12-21 09.53.21.png

所涉及到的新名詞：

• 訂閱人：須要證書來提供安全服務的團體（例如服務器）
• 登記機構（RA）：完成證書籤發的相關管理工做，例如對訂閱人身份驗證，而後纔會去找CA簽發證書。
• CSR文件：訂閱者的證書籤名申請，主要目的是攜帶公鑰信息，而且證實訂閱人擁有對應的私鑰（經過簽名證實），CSR還設計攜帶額外的元數據，但實際中並不是全部的都用到了，CA通常都會覆蓋CRS文件中的一些內容而且將其餘信息內置到證書裏面。
• CA：咱們都信任的證書頒發機構，它會在肯定申請用戶的身份以後簽發證書
• 信賴方：執行證書驗證的網頁瀏覽器，其餘程序及操做系統（例如iOS）
• CRL,OCSP：當出現私鑰泄密或者再也不須要使用時，就須要吊銷證書，CRL和OCSP是兩種吊銷標準。
  • CRL（certificate revocation list,證書吊銷列表）：是一組爲過時可是卻已經被吊銷的列表，CA維護了一個或多個這樣的列表，每一張證書須要在CRL分發點擴展中包含對應的CRL地址。CRL的最大問題在於它愈來愈大，實時查詢起來會很慢
  • OCSP（online certificate status protocol，在線證書狀態協議），支持實時查詢

證書，中間CA證書，證書鏈，根證書

證書：包含公鑰，訂閱人相關信息，以及證書頒發者數字簽名的數字文件。證書讓咱們能夠交換，存儲和使用公鑰，是整個PKI體系的基礎組成元素。

中間CA證書：根CA是很是重要的，若是根CA的密鑰被泄漏了，那麼就能夠簽發任意虛假證書，這時若是把根CA吊銷掉，全部使用過這個CA簽發的證書的網站都將沒法訪問。因此直接由根證書籤發最終實體證書是不容許的。證書發行商們爲了安全，一般會將這些根證書對應的私鑰保存在絕對斷網的金庫裏。在金庫裏用這些根私鑰，簽發一些「中級」證書，這些中級證書的私鑰擁有簽發再下一級證書的權限。這些中級私鑰被安裝到在線服務器上，經過簽發網站證書來賺錢。一旦這些服務器被黑，發行商就能夠利用金庫裏物理隔離的根證書私鑰，能夠簽發吊銷令，消滅這些中級證書的信任，而沒必要讓各家瀏覽器完全不信任這家發行商的根證書。再籤一條新的中級發行證書，又是一條能賺錢的好漢。引自：SSL證書鏈不完整問題：中間證書果真是個坑。

根證書：根證書是CA給本身頒發的證書,是信任鏈的起始點。安裝根證書意味着對這個CA認證中心的信任。

證書鏈：CA在驗證成功以後就會簽發證書。除了證書自己，CA還會提供全部的中間證書，從而構成了證書鏈到對應的根證書上。由於信賴方只保存着根證書，因此要經過證書鏈找到根證書來驗證。

使用證書進行身份驗證的流程

身份驗證流程：
一、信賴方添加可信任根證書庫，根證書庫中保存着可信任的CA的根證書
例如Apple：
Apple維護的根證書庫主要是給iOS和OSX平臺使用，若是某個CA但願加入到Apple的根證書庫裏面的話，就須要經過權威機構審計而且對Apple的客戶有商業價值。
二、證書訂閱人找到信賴方所信賴的CA的登記機構，發送CSR，申請簽名。
三、登記機構經過CA頒發給證書訂閱人證書。
四、信賴方要求服務器進行身份驗證。
五、服務器發送證書鏈給信賴方。
六、信賴方經過本身的根證書庫對證書鏈進行驗證（驗證簽名是否正確，檢查證書是否已經吊銷）。
七、握手流程中的身份驗證結束，開始使用證書中的公鑰進行密鑰交換流程。

示例場景：
對於Client：
一、根CA有一個金庫，保存着本身的私鑰：privateKey_CA
二、根CA把本身的根證書（使用本身的私鑰自簽名證書）植入到Client中，根證書包含着：publicKey_CA
三、基於上面兩個步驟，Client就能夠驗證根CA的簽名了。
對於中間CA：
一、中間CA擁有根CA中的金庫的私鑰的簽名（獲取了根CA的信任），有派發子證書的權利。
對於Server：
一、Server將本身的CSR（包含publicKey_Server，但不包含privateKey_Server）給RA，RA審覈後給中間CA，請求中間CA簽名（至關於獲取中間CA的信任）。
二、中間CA使用本身的私鑰給Server的證書籤名。
對於Client驗證Server：
一、在Client要求驗證Server身份時，Server將由中間CA簽名的證書鏈發給Client。
二、Client能夠從證書鏈尋找到根證書
三、Client從本身信任的根證書庫中尋找對應的根證書來驗證。
四、驗證經過後，使用publicKey_Server來開始握手流程中的密鑰交換。

參考文章：
ATS配置官方說明
蘋果強制使用HTTPS傳輸後APP開發者必須知道的事
SSL證書鏈不完整問題：中間證書果真是個坑。
關於iOS9中的App Transport Security相關說明及適配(更新於2016.7.1)
騰訊雲申請SSL證書
iOS使用自簽名證書實現HTTPS請求
iOS 升級HTTPS經過ATS你所要知道的
AFNetworking之於https認證

個人簡書主頁：www.jianshu.com/users/b92ab…