【轉自：http://blog.csdn.net/gschen_cn/article/details/79346047】
1 問題提出
現在廣泛使用的HTTP協議採用的是一種明文傳輸的方式，因此通信雙方的數據在網絡上傳輸是十分不安全的。2 解決方案
一種簡單的解決方案就是對傳輸的數據進行加密處理,目前流行的加密方式有兩種："對稱加密"和"非對稱加密"。
2.1 對稱加密
首先討論對稱加密方式,對稱加密指的是通信雙方使用同一套密鑰對數據進行加密和解密,如果使用對稱加密就意味着通信的雙方必須都知道密鑰，才能完成加密和解密操作。
【一種典型的場景是：】
客戶端發送密鑰至服務器，服務器接受該密鑰，之後所有的數據傳輸都採用該密鑰進行加密和解密；該方法雖然可以解決明文傳輸的問題，卻存在安全隱患。在密鑰協商階段，客戶端需要發送密鑰給服務器，此時如果攻擊者監測到該密鑰，就可以使用該密鑰來解密之後所有的數據，那麼本次經對稱加密後的數據傳輸也就變爲明文傳輸。
因此，如何確保對稱加密方式中密鑰的安全是此方式中最爲核心的問題。2.2 非對稱加密
接下來我們討論非對稱加密方式。 非對稱加密的密鑰有公鑰和私鑰之分，使用公鑰加密的數據只有私鑰才能解密，同理使用私鑰加密的數據只有公鑰才能解密。
那麼對傳輸數據進行非對稱加密是不是就是安全的呢？
【非對稱加密一種典型的場景是：】
由服務器生成公鑰和私鑰，並將公鑰發送給客戶端，之後服務器和客戶端之間所有的數據都採用公鑰和私鑰加密。接下來我們分析下這種場景。 客戶端接受到服務器發來的公鑰，然後使用公鑰對數據進行加密，根據非對稱加密的原理，我們瞭解這種加密數據只有服務器使用私鑰才能解密，因此任何攻擊者截取到該信息都無法完成解密，所以任何由客戶端向服務器發送的數據都是安全的。
但是，在開始階段，服務器需要將公鑰發送給客戶端，在這個過程中，攻擊者就有可能會拿到公鑰，這就意味之後所有由服務器發給客戶端的，經私鑰加密的數據，攻擊者同樣可以用截取到的公鑰對其進行解密。綜上，我們得出，採用非對稱加密的方式只能保證客戶端到服務器的數據是安全的，並不能保證服務器到客戶端也是安全的，因此只是一種單向安全的加密方式。
2.3 混合加密方式
接下來我們探討採用對稱加密+非對稱加密混合加密方式。
通過2.1 對稱加密方式 一節的分析，我們知道，此種方式最大的問題在於密鑰的安全性，一旦密鑰被攻擊者獲取，那麼本次傳輸將變爲明文傳輸。通過2.2 非對稱加密方式 我們瞭解非對稱加密只是單向安全的數據傳輸，即只有客戶端到服務器的傳輸纔是安全的。
結合二者的特點，我們提出，通信雙方所有的數據傳輸採用對稱加密方式，密鑰的傳輸採用非對稱加密方式。【一種典型的場景是：】
服務器生成公鑰和私鑰，並將公鑰發給客戶端；客戶端生成對稱加密的密鑰，用公鑰對該密鑰進行加密，併發給服務器，之後所有的數據傳輸都使用該密鑰進行加密；服務器收到該客戶端發過來的經公鑰加密的數據，使用私鑰對其解密，從而得到客戶端的密鑰，之後所有來自該客戶端的數據，都使用該密鑰解密。
這種混合加密的方式在一定程度上確實能提高數據傳輸的安全性，但是它就一定安全嗎？
我們日常上網經常會使用代理服務器，如果代理服務器僞造來自真實服務器的公鑰併發給客戶端，那麼之後所有的傳輸也將變爲明文傳輸。因此，對於混合加密方式核心的問題在於無法確認該公鑰是否來自真實服務器，而不是代理服務器的公鑰。
2.4 證書
在混合加密方式中，客戶端是直接向服務器請求公鑰，該公鑰有可能被僞造。我們改進一下這種方式，引入證書的概念。
證書包含三部分信息：服務器公鑰等明文信息；
摘要；
數字簽名；
摘要 = hash(明文信息);
數字簽名 = 該證書的頒發機構私鑰加密(摘要)；
【一種典型的場景是：】
客戶端向服務器請求證書；
找到證書頒發機構的證書，獲取公鑰，然後解密數字簽名，得到摘要A；
hash(明文信息) = 摘要B；
比較A和B是否相等，驗證證書合法性。
此舉能夠驗證該證書確實是由某證書機構頒發的，但是該機構就一定是合法的嗎？所以需要再次驗證它的合法性。
採取上述同樣的方法來驗證該機構的合法性，一層層的向上驗證，最終在客戶端瀏覽器中會預先安裝全球受信任的證書頒發機構的證書，我們稱之爲根證書。
所以對於每一個服務器的證書，採取向上一層層的驗證證書頒發頒發機構的合法性，只要最終經過了根證書的驗證，則表示該證書是合法的。
附錄
常見的hash算法： MD5 SHA1 SHA256
常見的對稱加密算法： DES 3DES TDEA Blowfish RC5 IDEA
常見的非對稱加密算法： RSA ECC Elgamal
