HTTPS相關原理

在互聯網安全通信方式上,目前用的最多的就是HTTPS配合SSL和數字證書來保證傳輸和認證安全了。本文追本溯源圍繞這個模式談一談。

名詞解釋

首先解釋一下上面的幾個名詞:

· HTTPSHTTP(超文本傳輸協議)基礎上提出的一種安全的HTTP協議,因此可以稱爲安全的超文本傳輸協議。HTTP協議直接放置在TCP協議之上,而HTTPS提出在HTTP和TCP中間加上一層加密層。從發送端看,這一層負責把HTTP的內容加密後送到下層的TCP,從接收方看,這一層負責將TCP送來的數據解密還原成HTTP的內容。

· SSL(Secure Socket Layer):Netscape公司設計的主要用於WEB的安全傳輸協議。從名字就可以看出它在HTTPS協議棧中負責實現上面提到的加密層。因此,一個https協議棧大致是這樣的:

 

· 數字證書一種文件的名稱,好比一個機構或人的簽名,能夠證明這個機構或人的真實性。其中包含的信息,用於實現上述功能。

· 加密和認證加密是指通信雙方爲了防止敏感信息在信道上被第三方竊聽而泄漏,將明文通過加密變成密文,如果第三方無法解密的話,就算他獲得密文也無能爲力;認證是指通信雙方爲了確認對方是值得信任的消息發送或接受方,而不是使用假身份的騙子,採取的確認身份的方式。只有同時進行了加密和認真才能保證通信的安全,因此在SSL通信協議中這兩者都被應。

    因此,這三者的關係已經十分清楚了:https依賴一種實現方式,目前通用的是SSL,數字證書是支持這種安全通信的文件。另外有SSL衍生出TLS和WTLS,前者是IEFT將SSL標準化之後產生的(TSL1.0),與SSL差別很小,後者是用於無線環境下的TSL。

 

2 如何加密

2.1 常用的加密算法

· 對稱密碼算法:是指加密和解密使用相同的密鑰,典型的有DES、RC5、IDEA(分組加密),RC4(序列加密);

· 非對稱密碼算法:又稱爲公鑰加密算法,是指加密和解密使用不同的密鑰(公開的公鑰用於加密,私有的私鑰用於解密)。比如A發送,B接收,A想確保消息只有B看到,需要B生成一對公私鑰,並拿到B的公鑰。於是A用這個公鑰加密消息,B收到密文後用自己的與之匹配的私鑰解密即可。密鑰是B生成的。反過來也可以用私鑰加密公鑰解密。也就是說對於給定的公鑰有且只有與之匹配的私鑰可以解密,對於給定的私鑰,有且只有與之匹配的公鑰可以解密。典型的算法有RSA,DSA,DH;


 

· 散列算法:散列變換是指把文件內容通過某種公開的算法,變成固定長度的值(散列值),這個過程可以使用密鑰也可以不使用。這種散列變換是不可逆的,也就是說不能從散列值變成原文。因此,散列變換通常用於驗證原文是否被篡改。典型的算法有:MD5,SHA,Base64,CRC等。

    在散列算法(也稱摘要算法)中,有兩個概念,強無碰撞和弱無碰撞。弱無碰撞是對給定的消息x,僞造出摘要信息相同的明文。強無碰撞是指在不知道被僞造的明文是什麼的情況下,也能僞造出具有相同摘要信息的明文。

已知HASH函數f(x),單向是指已知x可以求出f(x),但是從f(x)無法推斷x。

弱無碰撞是指已知x,要找出y使得f(y)=f(x)是不可行的。

強無碰撞是指想找出數對x,y,使得f(x)=f(y)是不可行的。

 

2.2 SSL協議通信流程

    需要注意的是非對稱加解密算法的效率要比對稱加解密要低的多。所以SSL在握手過程中使用非對稱密碼算法來協商密鑰,實際使用對稱加解密的方法對http內容加密傳輸

客戶端向服務器端發起對話,協商傳送加密算法。例如:對稱加密算法有DES、RC5,密鑰交換算法有RSA和DH,摘要算法有MD5和SHA。

服務器向客戶端發送服務器數字證書。比如:使用DES-RSA-MD5這對組合進行通信。客戶端可以驗證服務器的身份,決定是否需要建立通信。

客戶端向服務器傳送本次對話的密鑰。在 檢查服務器的數字證書是否正確、通過CA機構頒發的證書驗證了服務器證書的真實有效性之後,客戶端生成利用服務器的公鑰加密的本次對話的密鑰發送給服務器。

服務器用自己的私鑰解密,獲取本次通信的密鑰。

雙方的通信正式開始。

 

詳細通信過程見SSL握手階段詳細過程

從上面的過程可以看到,SSL協議是如何用非對稱密碼算法來協商密鑰,並使用密鑰加密明文並傳輸的。還有以下幾點補充:

· B使用數字證書把自己的公鑰和其他信息包裝起來發送A,用於A驗證B的身份。

· A生成的加密密鑰、加密初始化向量和hmac密鑰是雙方用來將明文摘要和加密的。加密初始化向量和hmac密鑰首先被用來對明文摘要(防止明文被篡改),然後這個摘要和明文放在一起用加密密鑰加密後傳輸。

· 由於只有B有私鑰,所以只有B可以解密ClientKeyExchange消息,並獲得之後的通信密鑰。

· 上述過程B沒有驗證A的身份,如果需要的話,SSL也是支持的,此時A也需要提供自己的證書。

2.3 數字證書

    由上面的討論可以知道,數字證書在SSL傳輸過程中扮演身份認證和密鑰分發的功能。究竟什麼是數字證書呢?

    簡而言之數字證書是一種網絡上證明持有者身份的文件,同時還包含有公鑰,數字證書=身份文件+公鑰。一方面,既然是文件那麼就有可能“僞造”,因此,證書的真僞就需要一個驗證方式;另一方面,驗證方需要認同這種驗證方式。

    對於第一個需求,目前的解決方案是,證書可以由國際上公認的證書機構頒發,這些機構是公認的信任機構,一些驗證證書的客戶端應用程序:比如瀏覽器,郵件客戶端等,對於這些機構頒發的證書完全信任。當然想要請這些機構頒發證書可是要付錢的,通常在windows部署系統的時候會讓客戶端安裝我們自己服務器的根證書,這樣客戶端同樣可以信任我們的證書。

    對於第二個需求,客戶端程序通常通過維護一個“根受信任機構列表”,當收到一個證書時,查看這個證書是否是該列表中的機構頒發的,如果是則這個證書是可信任的,否則就不信任。

2.3.1 證書的信任

    因此作爲一個https的站點需要與一個證書綁定,無論如何,證書總是需要一個機構頒發的,這個機構可以是國際公認的證書機構,也可以是任何一臺安裝有證書服務的計算機。客戶端是否能夠信任這個站點的證書,首先取決於客戶端程序是否導入了證書頒發者的根證書。下圖說明了這個流程:

 

    有時一個證書機構可能授權另一個證書機構頒發證書,這樣就出現了證書鏈。IE瀏覽器在驗證證書的時候主要從下面三個方面考察,只要有任何一個不滿足都將給出警告

· 證書的頒發者是否在“根受信任的證書頒發機構列表”中

· 證書是否過期

· 證書的持有者是否和訪問的網站一致

    另外,瀏覽器還會定期查看證書頒發者公佈的“證書吊銷列表”,如果某個證書雖然符合上述條件,但是被它的頒發者在“證書吊銷列表”中列出,那麼也將給出警告。證書與密鑰

    ssl的加密過程一節中,我們知道要實現ssl加密通信,必須要雙方協商密鑰,ssl採用的是非對稱加密來實現密鑰交換。在這個過程中,服務端向客戶端發送的公鑰就包含在證書中。客戶端將自己生成的密鑰用公鑰加密,服務端用於公鑰匹配的私鑰解密。因此,可以想到的是,服務端保存了一個私鑰,並且也與https的站點綁定了。


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章