HTTP不安全問題
前面複習總結了數據加密算法保證數據安全不泄露，消息驗證碼MAC算法保證數據沒有被篡改，還有公開密鑰算法三種用途，加密解密，密鑰協商，身份驗證。上面這些方案，算法都是TLS協議的一部分，用來解決HTTP不安全的問題。這篇日誌把上面這些東西整理下，看看TLS/SSL協議在開始到結束的身份認證，密鑰協商和數據加密步驟如何一步一步保證HTTP安全的。TLS/SSL協議既然是用來解決HTTP不安全問題，那麼先來總結下HTTP幾個核心的不安全原因。
- 沒有身份驗證
HTTP使用TCP/IP協議傳輸報文，TCP協議只保證數據能正確傳送到通信雙方處，在C/S模式下，對於服務器來說，只要接收到的HTTP請求格式是正確的，就會響應該請求，不做身份驗證的話服務器不知道這條請求是誰發來的，對於客戶端也一樣，客戶端訪問服務器主機www.badui.com，請求發送出去後，可能經過很多中間設備，如網關服務器，中間就可能會受到“中間人攻擊”，最終訪問到的是www.badui.cn。還有就是不可抵賴性問題，在多人通信中，大家持有相同的密鑰進行加密和解密，假設B收到A發送的一條消息，但A抵賴了，說消息不是他發送的，是C發送的，因爲C也有共同的密鑰，C也可以加密數據後發送給B，所以A可以抵賴。同理還有第三方證明問題，假如A發送了一條消息給B，但B無法向D證明這條消息是A發送的，原因是C也有共同的密鑰，C也可以向B發消息，所以B無法向D證明這條消息是來自A的還是C的。
所以說如果不去驗證消息發送方的身份的話，會出現一系列不可靠不安全的問題。
- 數據沒有加密
HTTP是明文傳輸的，並不會對消息進行加密，TCP/IP發送報文會經過很多個路由節點，如果中途消息被截獲了，那麼你的信息就泄露了。TLS/SSL使用對稱加密或者公開密鑰算法保證數據的安全。
- 沒有驗證數據篡改
上面說到，HTTP數據傳輸過程可能會經過很多個路由節點，中途某個節點如果消息被截獲了，可能被攻擊者修改原始數據，再進行轉發，且由於HTTP使用的TCP/IP協議不進行身份驗證，造成的問題是服務器端和客戶端接收到請求後，只要格式正確，消息內容完整，都會以爲該消息是正確的，原始的數據。解決方法就是使用消息驗證碼，給發送的消息用共同的密鑰計算出一個MAC值，隨消息一起發送，接收方使用共同的密鑰對消息進行計算得到MAC值，再與一起發送來的MAC值做比較，一致則認爲消息沒有被篡改過。
HTTP與TLS/SSL
應用層協議HTTP中引入TLS/SSL協議，在任何應用層數據到達傳輸層TCP/IP之前，都會先由TLS/SSL協議“加工”處理，將HTTP和TLS/SSL結合在一起就是我們現在常見的HTTPS，對於HTTP Web服務器，默認是監聽端口號80上的HTTP請求，如果支持HTTPS，則默認監聽端口號443上的HTTPS請求。總的來說，TLS/SSL協議是單獨的模塊，單獨的協議，在應用層上的協議都可以使用它。
TLS/SSL加密協議步驟總結
前面說到的密鑰協商，數據加密，消息驗證和身份驗證，都是TLS/SSL協議的一部分，目的是解決HTTP不安全的問題，除此之外，還需要使用PKI技術來解決中間人攻擊問題，下面就來按順序整理整個TLS/SSL協議的運作過程。
密鑰協商-動態密鑰
通信雙方建立連接時需要協商出共同的密鑰，這個過程十分重要，因爲密鑰用來進行消息的加密和解密，如果密鑰協商中途泄露了關鍵信息，那麼前面協商出的密鑰就白費了。你可能會想，使用像靜態密鑰的方式，通信雙方事前就存儲好共同的密鑰，一直使用它來加密解密不就可以了嗎，何必每次建立連接時都去協商一個新的密鑰呢？對於C/S模式下，服務器通常要處理許多許多的客戶端請求，如果服務器給每一個客戶端都分配一個固定不變的密鑰，那麼對於服務器端的數據庫存儲量會越來越大，且一旦服務器端密鑰泄露，造成的後果就是所有與這些客戶端通信的密鑰都泄露了。所以需要使用動態密鑰（或者說會話密鑰）的方式，也就是每次通信連接建立時協商出本次通信的密鑰，通信結束後密鑰就被丟棄。
在客戶端和服務器端建立連接時，先使用密鑰協商算法商量出預備主密鑰，預備主密鑰再通過同樣的密碼衍生算法轉換出主密鑰。前面講到密鑰協商的一般有兩種方式，RSA和DH密鑰協商。
RSA密鑰協商
RSA密鑰協商步驟大致如下：
- 客戶端發送連接請求給服務器端，服務器端接收到請求後，將自己的密鑰對中公鑰部分發送回客戶端。
- 客戶端接收到服務器端公鑰後，自己使用隨機數生成器生成一個預備主密鑰，然後使用服務器公鑰對預備主密鑰進行加密，再發送回給服務器端。此時由於中間方沒有服務器端私鑰，所以即使攔截了加密後的預備主密鑰，也沒辦法解密。
- 服務器端接收到客戶端迴應後，使用自己的私鑰解密出預備主密鑰，完成密鑰協商。
不過RSA密鑰協商有些不足是，預備主密鑰其實完全是由客戶端決定的，服務器端只是提供公鑰給客戶端進行加密，安全傳輸預備主密鑰而已，假設客戶端生成的預備主密鑰安全性不高，那麼中間方完全可以在截獲了被加密的預備主密鑰後，直接對其進行破解嘗試，而不需要去破解服務器端的私鑰。
DH密鑰協商
DH密鑰協商則完全是由通信雙方共同參與協商的過程，通信雙方各自保留一部分信息，並通過互相交換這部分信息，一起協商得到預備主密鑰，即使中途某一部分參數信息別截獲，也沒辦法依靠這一部分信息計算出預備主密鑰。DH密鑰協商用到的DH參數由通信雙方任意一方生成都可以，這裏假設在服務器端生成，過程大致如下：
- 客戶端發送建立請求，服務器端接收後，生成一個RSA密鑰對，DH參數和DH密鑰，並將RSA公鑰發送給客戶端。
- 服務器端使用RSA私鑰簽名DH參數和服務器DH公鑰，和簽名值，三個一起發送給客戶端。
- 客戶端通過服務器端的RSA公鑰驗證簽名值，並解密得到DH參數和服務器端DH公鑰。
- 客戶端通過DH參數生成客戶端的DH密鑰對，然後將客戶端DH公鑰發送給服務器端。
- 此時服務器端持有的信息有：服務器端RSA密鑰，DH參數和DH密鑰，客戶端DH公鑰。客戶端持有信息有：服務器端RSA公鑰，服務器端DH參數和DH公鑰，自己的客戶端DH密鑰。
- 最後，服務器端使用自己的DH私鑰和客戶端的DH公鑰計算出預備主密鑰。客戶端使用自己的DH私鑰和服務器端的DH公鑰計算出預備主密鑰。完成密鑰協商。
從上述過程可以看到，通信雙方協商密鑰時，必須互相發送參數，客戶端需要服務器DH公鑰，服務器端需要客戶端公鑰，然後再和各自自己的DH私鑰計算出預備主密鑰。即使中間雙方的DH公鑰都泄露了，也沒辦法計算出預備主密鑰，並且密鑰只在本次通信有效，會話結束後密鑰就會失效，提供了前向安全性，什麼是前向安全性？下一篇日誌說。
