https（詳細）

全球可信的SSL數字證書申請： http://cn.globalsign.com/ 

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

名詞解釋

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

• https：在http(超文本傳輸協議)基礎上提出的一種安全的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。

 

如何加密

經常使用的加密算法

• 對稱密碼算法：是指加密和解密使用相同的密鑰，典型的有DES、RC五、IDEA（分組加密），RC4（序列加密）；
• 非對稱密碼算法：又稱爲公鑰加密算法，是指加密和解密使用不一樣的密鑰（公開的公鑰用於加密，私有的私鑰用於解密）。好比A發送，B接收，A想確保消息只有B看到，須要B生成一對公私鑰，並拿到B的公鑰。因而A用這個公鑰加密消息，B收到密文後用本身的與之匹配的私鑰解密便可。反過來也能夠用私鑰加密公鑰解密。也就是說對於給定的公鑰有且只有與之匹配的私鑰能夠解密，對於給定的私鑰，有且只有與之匹配的公鑰能夠解密。典型的算法有RSA，DSA，DH；
• 散列算法：散列變換是指把文件內容經過某種公開的算法，變成固定長度的值（散列值），這個過程可使用密鑰也能夠不使用。這種散列變換是不可逆的，也就是說不能從散列值變成原文。所以，散列變換一般用於驗證原文是否被篡改。典型的算法有：MD5，SHA，Base64，CRC等。

在散列算法（也稱摘要算法）中，有兩個概念，強無碰撞和弱無碰撞。弱無碰撞是對給定的消息x，就是對你想僞造的明文，進行運算得出相同的摘要信息。也就是說你能夠控制明文的內容。強無碰撞是指能找到相同的摘要信息，但僞造的明文是什麼並不知道。

SSL的加密過程

須要注意的是非對稱加解密算法的效率要比對稱加解密要低的多。因此SSL在握手過程當中使用非對稱密碼算法來協商密鑰，實際使用對稱加解密的方法對http內容加密傳輸。下面是對這一過程的形象的比喻（摘自http://blog.chinaunix.net/u2/82806/showart_1341720.html）：

假設A與B通訊，A是SSL客戶端，B是SSL服務器端，加密後的消息放在方括號[]裏，以突出明文消息的區別。雙方的處理動做的說明用圓括號（）括起。

A：我想和你安全的通話，我這裏的對稱加密算法有DES,RC5,密鑰交換算法有RSA和DH，摘要算法有MD5和SHA。

B：咱們用DES－RSA－SHA這對組合好了。

這是個人證書，裏面有個人名字和公鑰，你拿去驗證一下個人身份（把證書發給A）。

A：（查看證書上B的名字是否無誤，並經過手頭早已有的數字的證書驗證了B的證書的真實性，若是其中一項有誤，發出警告並斷開鏈接，這一步保證了B的公鑰的真實性）

（產生一份祕密消息，這份祕密消息處理後將用做對稱加密密鑰，加密初始化向量和hmac的密鑰。將這份祕密消息-協議中稱爲per_master_secret-用B的公鑰加密，封裝成稱做ClientKeyExchange的消息。因爲用了B的公鑰，保證了第三方沒法竊聽）

我生成了一份祕密消息，並用你的公鑰加密了，給你（把ClientKeyExchange發給B）

注意，下面我就要用加密的辦法給你發消息了！

（將祕密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）

[我說完了]

B：（用本身的私鑰將ClientKeyExchange中的祕密消息解密出來，而後將祕密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）

注意，我也要開始用加密的辦法給你發消息了！

[我說完了]

A: [個人祕密是...]

B: [其它人不會聽到的...]

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

1.B使用數字證書把本身的公鑰和其餘信息包裝起來發送A，A驗證B的身份，下面會談到A是如何驗證的。

2.A生成了了加密密鑰、加密初始化向量和hmac密鑰是雙方用來將明文摘要和加密的。加密初始化向量和hmac密鑰首先被用來對明文摘要（防止明文被篡改），而後這個摘要和明文放在一塊兒用加密密鑰加密後傳輸。

3.因爲只有B有私鑰，因此只有B能夠解密ClientKeyExchange消息，並得到以後的通訊密鑰。

4.事實上，上述過程B沒有驗證A的身份，若是須要的話，SSL也是支持的，此時A也須要提供本身的證書，這裏就不展開了。在設置IIS的SSL Require的時候，一般默認都是igore client certification的。

 

數字證書

由上面的討論能夠知道，數字證書在ssl傳輸過程當中扮演身份認證和密鑰分發的功能。究竟什麼是數字證書呢？

簡而言之數字證書是一種網絡上證實持有者身份的文件，同時還包含有公鑰。一方面，既然是文件那麼就有可能「僞造」，所以，證書的真僞就須要一個驗證方式；另外一方面，驗證方須要認同這種驗證方式。

對於第一個需求，目前的解決方案是，證書能夠由國際上公認的證書機構頒發，這些機構是公認的信任機構，一些驗證證書的客戶端應用程序：好比瀏覽器，郵件客戶端等，對於這些機構頒發的證書徹底信任。固然想要請這些機構頒發證書但是要付「到了斯」的，一般在windows部署系統的時候會讓客戶端安裝咱們本身服務器的根證書，這樣客戶端一樣能夠信任咱們的證書。

對於第二個需求，客戶端程序一般經過維護一個「根受信任機構列表」，當收到一個證書時，查看這個證書是不是該列表中的機構頒發的，若是是則這個證書是可信任的，不然就不信任。

證書的信任

所以做爲一個https的站點須要與一個證書綁定，不管如何，證書老是須要一個機構頒發的，這個機構能夠是國際公認的證書機構，也能夠是任何一臺安裝有證書服務的計算機。客戶端是否可以信任這個站點的證書，首先取決於客戶端程序是否導入了證書頒發者的根證書。下圖說明了這個流程：

有時一個證書機構可能受權另外一個證書機構頒發證書，這樣就出現了證書鏈。

IE瀏覽器在驗證證書的時候主要從下面三個方面考察，只要有任何一個不知足都將給出警告

• 證書的頒發者是否在「根受信任的證書頒發機構列表」中
• 證書是否過時
• 證書的持有者是否和訪問的網站一致

另外，瀏覽器還會按期查看證書頒發者公佈的「證書吊銷列表」，若是某個證書雖然符合上述條件，可是被它的頒發者在「證書吊銷列表」中列出，那麼也將給出警告。每一個證書的CRL Distribution Point字段顯示了查看這個列表的url。儘管如此，windows對於這個列表是「不敏感」的，也就是說windows的api會緩存這個列表，直到設置的緩存過時纔會再從CRL Distribution Point中下載新的列表。目前，只能經過在證書頒發服務端儘可能小的設置這個有效期（最小1天），來儘可能使windows的客戶端「敏感」些。具體設置方法爲（winserver2003）：