[HTTPS]https原理 數字證書 數字簽名

從Chrome直接對所有http網站標爲不安全開始，我就對https產生了興趣，也去了解了一些加密知識，直到現在纔有了一個比較模糊的認識

對https的一點認識和感悟

這篇文章記錄了我認識https加密原理的全過程，全篇幾乎沒有專業詞彙用最通俗的文字進行表達（其實是自己比較撈），希望能對理解https和數字證書原理有困難的朋友有所幫助 2019-11-08 17:19:54

一、從明文到加密通信談起

1. http協議是明文通訊，很不安全，很容易遭受中間人攻擊，被截獲後可以直接讀出真實信息，也容易被篡改，造成信息泄露等後果；
   
2. 於是乎可以考慮加密通信，比如歷史上有著名的凱撒密碼等等，這種手段就需要把加密手段告訴對方，但是互聯網通信是公共信道，怎麼把加密/解密方法安全送給對方呢；

二、非對稱加密和對稱加密

1. 現在提兩個概念：對稱加密和非對稱加密，對稱加密就是加密祕鑰和解密祕鑰相同的加密方式，而非對稱加密的加密密鑰和解密密鑰是不同的，非對稱加密被髮明至今不過半個世紀的時間。
   

2. 顯然，對稱加密不能勝任上文提到的場景任務，而非對稱加密就可以解決這個問題：

   1. A向B發起通信請求
   2. B生成一個私鑰和一個公鑰，私鑰用於自己加密不能告訴其他任何人
   3. 說明：被私鑰加密後的密文只能被公鑰解密，被公鑰加密後的密文只能被私鑰解密
   4. 然後B把公鑰以明文形式發送給A
   5. A收到公鑰之後就可以用公鑰加密信息發送給B，B也可以用私鑰加密信息發送給A
      

3. 看起來很安全，但是，這種手段仍然存在被中間人利用的漏洞：

   1. 在B發送公鑰給A的時候，中間人C截獲公鑰
   2. 中間人C自己生成一對公私鑰，然後把自己的公鑰發送給A
      
   3. A收到的是C的公鑰，用C的公鑰加密明文信息P得到密文S發送給B
   4. 此時C又截獲A發給B的密文S，然後用自己的私鑰解密密文S得到明文P
      
   • 此時已經能夠說明這個方式不夠安全了，就不再繼續了

4. 反思一下，這個非對稱的加密手段的問題就在於A不能確定收到的公鑰是誰的，如果能證明A收到的公鑰就是B的，中間人便無機可乘

三、CA和證書

1. 考慮一下自己在生活中是怎麼證明自己是自己的：身份證，我們爲什麼相信身份證？
2. 答：身份證是政府發的，我們肯定認爲政府是可以信任的；如果政府認爲某張身份證是真的，那麼我們也認爲某張身份證是真的
3. 在上文中如果有一個機構能幫助我們證明A收到的公鑰是B的，問題就解決了。
4. 解決方法是：給B發一個身份證，身份證上有B的公鑰，與B通信之前先驗證他的身份證，如果身份證上說：B的公鑰是P（即公鑰：P和名稱：B是對應的，就好比王小明的名字和他的身份證號是對應的一樣），我們就可以使用P和B通信。
5. 實際上，這個發證機構叫CA(Certificate Authority)，身份證就是數字證書，數字證書由CA簽發。
6. 現在的信任問題就轉移到這個數字證書上面了，只要數字證書是真的，證書上面的公鑰就是真的，我們就可以安全通信，那麼如何保證數字證書是真的呢？

四、證書的簽發與證書鏈

1證書的簽發

1. 首先說明：①CA的身份是權威的證書籤發機構，這是整個數字證書信任體系的基石，即CA本身是可信的，如果CA不可信了，整個信任體系就不能成立；②下文僅討論數字證書的一部分構成
2. 網站A向CA申請證書籤發時，和之前提到的非對稱加密通信類似，CA會生成一對公私鑰。
3. 公鑰發送給A，A用CA的公鑰加密自己的”申請書“，上面包含一些自己的基本信息，包括A自己的公鑰，域名等；
4. CA收到後使用自己的私鑰把A的公鑰，域名等信息加密，這個過程叫簽名，得到的密文就叫數字簽名，數字簽名與A的明文個人信息組合在一起就成爲數字證書。
5. 與A通信時，B用CA的公鑰解密數字簽名與明文一比對，能對上，就說明證書是真的，即證書不可僞造，不可篡改。
6. 至此，雖然證書本身不可篡改，但似乎又出現了CA公鑰是不是真的的問題，是不是就進入了一個雞生蛋蛋生雞的問題？當然不是！解決方案如下：
7. 需要說明的是：與CA通信時其實並不是只接收CA的公鑰，而是也是驗證CA的證書，即CA也是有證書的。
8. 而CA的證書（公鑰）其實根本就用不着在互聯網上傳播，而是採用出廠即內置的辦法，比如Chrome瀏覽器會直接內置CA自己的證書，多數操作系統也是在安裝的時候就會一同安裝CA自己的證書，CA的證書是自己給自己簽發的（實際上只有根CA的證書是這樣的，根CA的證書稱爲根證書，後面會說明，這裏可以忽略這個說法，爲便於理解就先假定CA的證書都是自己簽發的），也是大家公認的，在驗證來自CA的信息的時候，直接從硬盤中讀取CA的證書（公鑰），至此，問題就順利解決了。

2證書鏈

1. 前面提到只有根證書是根CA自己簽發的，我之前看了很多介紹證書的文章很多是這樣解釋證書鏈的：講的是與站點A通信時用CA的證書（公鑰）驗證A的證書，而驗證CA的證書時又用上一級CA的證書（公鑰）驗證這個CA的證書…直到根CA那裏爲止，可以先忽略這裏的第一條和第二條內容，直接從3開始看
2. 我不準備這樣記載和說明這個過程，而是倒過來說明，從根CA開始
3. 前面說了CA的證書會被內置，CA是可以有很多的，而且可以越來越多，這樣就需要添加內置的證書，怎麼更新呢，上互聯網上去更新嗎，我上了這麼久的網也沒見過要求下載證書的（12306除外，等會另外說）
4. 根據前文約定，CA的證書是自己給自己簽發的，從互聯網上下載證書就又出現了安全問題，所以一般不要從互聯網上下載證書添加到內置證書庫裏。那這個問題怎麼解決呢？
5. 現在的真實情況是電腦、手機和瀏覽器等等廠商都內置了一定數量的證書，而這些證書已經足夠讓我們驗證互聯網上的所有身份信息而不需要另外安裝證書，那麼是怎麼做到的呢？
6. 答：通過證書鏈。
7. CA可以有很多，但是根CA不多，根CA是最最上層的CA，是最爲權威和可信的存在，而他們可以給新成立的次級CA發證書，這個發證書的手段恐怕就不是通過互聯網了，可以通過U盤/硬盤/打印/手寫等方式頒發。總之是可以確保這個過程是安全的方法，然後這個次級CA就可以給用戶網站發證書了。
8. 驗證證書鏈舉例：

假設

1. 網站：A向CA：B申請到一個證書N，
2. B自己的證書M是根CA：C簽發給B的
3. C的證書：P是自己簽發給自己的

此時用戶U訪問A，得到A的證書N,發現是B簽發的（證書裏面包括簽發者與被簽發者的信息），U發現自己的沒有內置B的證書M，於是驗證M，發現是C簽發的，而U自己內置了C的證書P，驗證用P驗證M通過，再用M驗證N，通過則說明通信可信

五、密鑰交換

1. 到這裏，A已經可以確定B的身份並可以向B發送安全的加密信息，但是這時候B還不能確定A的身份，因爲B的公鑰是公開的，誰都可以使用B的公鑰將信息加密後發送給B，也就是說，這時候A還可以被其他人冒充。
2. 這時候A使用某種對稱加密算法生成一個對稱加密密鑰。
3. A使用B的公鑰加密此對稱加密密鑰和對應加密算法後發送給B，此消息是用B給的公鑰加密過的，不會外泄。
4. 從此以後，雙方就用這個對稱加密密鑰進行加密通信，沒有其他人能夠竊聽和篡改。

六、12306要求安裝證書的例子

1. 從前面的說明，已經瞭解到從互聯網上安裝證書是不安全的，並且由於證書鏈的緣故，其影響是鏈式的

2. 因此12306要求我們安裝證書本來就不合理

3. 我們看看12306讓我們安裝了什麼證書

4. 證書鏈的頂端是SRCA，對話框下面提示了這個根CA沒有內置，因此可以認爲不安全

5. 那這個SRCA是個什麼？全稱Sinorail Certification Authority，中鐵數字證書認證中心，搞了半天就是自己給自己發了個證書然後自己當上了根CA

6. 當然現在的12306沒有這麼搞了，還是遵守了國際規則，現在他的證書是這樣的