http&https&證書&數字簽名

http協議

http是超文本傳輸協議，是用來網絡間傳輸數據。底層是tcp協議(傳輸控制協議)。

是一種面向鏈接的主機對主機層的可靠傳輸，這裏的可靠是指數據丟失極小。Tcp創建一次鏈接須要通過3次握手，而後纔開始傳輸數據。就是請求-迴應-再確認，保證發送和接收。

所以傳輸數據的效率不及udp數據報文協議（一種非面向鏈接的不可靠傳輸協議）。

http協議傳輸數據，數據在網絡間是明文傳輸的，所以不是很安全，容易被竊取。

https協議

是http協議的安全版，數據傳輸利用了加密技術，在網絡傳輸中數據就不是處於裸奔狀態了。

對稱加密和非對稱加密

加密有兩種，對稱加密和非對稱加密。

對稱加密，即對數據的加密和解密都是用同一個祕鑰，這個祕鑰由發送方和接收方共同維護。可是共同維護這其中成本較高。

非對稱加密，即對數據的加密和解密用不一樣的祕鑰。通常發送方用一個公鑰來對發送的數據加密，接收方用一個祕鑰來解密。

https採用的加密技術就是非對稱加密技術，瀏覽器端使用服務器提供的公鑰進行對數據加密發給服務器，服務器用私鑰對數據進行解密。解密後又將要返回的數據用祕鑰加密，瀏覽器又用公鑰解密。

有沒有發現上面的過程仍是有不安全的地方，由於公鑰是公開的，在服務器端對數據用祕鑰加密後，傳輸給請求者，這時候其餘人就能夠截獲數據利用公鑰解密，這樣就可能會發生數據泄露的危險。

有沒有更好的解決辦法呢。有，就是請求方和服務器之間協議出一個祕鑰(具體過程目前不太清楚)。請求方將這個祕鑰夾在數據中公鑰加密後傳輸給服務器，服務器用私鑰進行解密，從數據中獲得這個私鑰，而後將要返回的數據用這個私鑰加密後傳輸給請求方。請求方用以前的協議出的祕鑰解密。

證書和CA

以上還有一個問題，就是服務器怎麼將公鑰送到請求者手中呢？就要講講證書和CA了。

證書顧名思義，能證實其身份證書。而CA就是頒發安全證書的權威機構。

一般是服務器端會將公鑰發給CA，CA會產生一個安全證書，證書裏面就包含服務器的公鑰。

證書頒發的細節這裏先不展開，能夠先簡單理解爲，網站（服務器）向CA提交了申請，CA審覈經過後，將證書頒發給網站（服務器），用戶訪問網站（服務器 ）的時候，網站（服務器）將證書給到用戶。

數字簽名和摘要

上面說到證書，就要提一提數字簽名和摘要了。

數字簽名和摘要是要來保證證書的合法有效的強力手段。

摘要就是對傳輸的內容用hash算法對其計算獲得一個固定長度的串，就是摘要了。

而後對摘要用CA的私鑰進行加密就屬於數字簽名了。

必需要用CA的公鑰才能解密。

證書包含了以下內容：

1. 證書包含了頒發證書的機構的名字 -- CA
2. 證書內容自己的數字簽名（用CA私鑰加密）
3. 證書持有者的公鑰
4. 證書籤名用到的hash算法

CA自己有本身的證書，江湖人稱「根證書」。這個「根證書」是用來證實CA的身份的，本質是一份普通的數字證書。

瀏覽器一般會內置大多數主流權威CA的根證書。

瀏覽器內置的CA的根證書包含了以下關鍵內容：

1. CA的公鑰（很是重要！！！）

鑑別證書：

徹底僞造的證書

這種狀況比較簡單，對證書進行檢查：

1. 證書頒發的機構是僞造的：瀏覽器不認識，直接認爲是危險證書
2. 證書頒發的機構是確實存在的，因而根據CA名，找到對應內置的CA根證書、CA的公鑰。
3. 用CA的公鑰，對僞造的證書的摘要進行解密，發現解不了。認爲是危險證書

篡改過的證書

假設代理經過某種途徑，拿到XX的證書，而後將證書的公鑰偷偷修改爲本身的，而後喜滋滋的認爲用戶要上鉤了。然而太單純了：

1. 檢查證書，根據CA名，找到對應的CA根證書，以及CA的公鑰。
2. 用CA的公鑰，對證書的數字簽名進行解密，獲得對應的證書摘要AA
3. 根據證書籤名使用的hash算法，計算出當前證書的摘要BB
4. 對比AA跟BB，發現不一致--> 斷定是危險證書

 

 參考了園裏大神的文章 http://www.cnblogs.com/chyingp/p/https-introduction.html