確保Web安全的 HTTPS

寫下前面

閱讀這篇文章可能須要20分鐘，但能幫你瞭解關於HTTPS的SSL、CA、密鑰加密之間的關係。

HTTP的缺點

HTTP主要有這些不足，列舉以下：

• 通訊使用明文（不加密），內容可能會被竊聽
• 不驗證通訊方的身份，所以有可能遭遇假裝
• 沒法證實報文的完整性，因此有可能已遭篡改

通訊使用明文可能會被竊聽

因爲HTTP自己不具有加密的功能，因此也沒法作到對通訊總體（使用HTTP協議通訊的請求和響應內容）進行加密。即，HTTP報文使用明文（指未通過加密的報文）方式發送。

TCP/IP是可能被竊聽的網絡

按TCP/IP協議簇的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。

即便已經加密處理過的通訊，也會被窺視到通訊內容，這點和未加密過得通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理過的報文信息自己仍是會被看到的。可使用Wireshark或Fiddler進行抓包。

加密處理防止被竊聽

在目前你們正在研究的如何防止竊聽保護信息的幾種對策中，最爲普及的就是加密技術。加密的對象能夠有這麼幾個：

通訊的加密

HTTP協議中沒有加密機制，但能夠經過和SSL（Secure Socket Layer，安全套接[ip+port]層）或TLS（Transport Layer Security，安全傳輸協議）的組合使用，加密HTTP的通訊內容。

用SSL創建安全通訊線路以後，就能夠在這條線路上進行HTTP通訊了。與SSL組合使用的HTTP被稱爲HTTPS（HTTP Secure，超文本傳輸安全協議）或HTTP over SSL。

內容的加密

誠然，爲了作到有效的內容加密，前提是要求客戶端和服務器同時具有加密和解密機制。因爲該方式不一樣於SSL或TLS將整個通訊線路加密處理，因此內容仍然有被篡改的風險。

不驗證通訊方的身份就可能遭到假裝

HTTP協議中的請求和響應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中URL真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端手中」等相似問題。

任何人均可以發起請求

服務器只要接收到請求，無論對方是誰都會返回一個響應（但也僅限於發送端的IP地址和端口號沒有被Web服務器設定限制訪問的前提下）。由於不確認通訊方，會存在如下隱患：

• 沒法肯定請求發送至目標的Web服務器是不是按真實意圖返回響應的那臺服務器。有多是假裝的Web服務器。
• 沒法肯定響應返回到的客戶端是不是按真實意圖接收響應的那個客戶端。有多是已假裝的客戶端。
• 沒法肯定正在通訊的對方是否具有訪問權限。由於某些Web服務器上保存着重要的信息，只想發給特定用戶通訊的權限。
• 沒法判斷請求是來自何方、出自誰手。
• 即便是無心義的請求也會照單全收。沒法阻止海量請求下的DOS（Denial of Service，拒絕服務攻擊）。

查明對手的證書

雖然使用HTTP協議沒法確認通訊方，但若是使用SSL則能夠。SSL不只提供加密處理，並且還使用了一種被稱爲證書的手段，可用於確認方。

證書由值得信任的第三方機構頒發，用以證實服務器和客戶端是實際存在的。另外，僞造證書從技術角度來講是異常困難的一件事。因此，只要可以確認通訊方（服務器或客戶端）持有的證書，便可判斷通訊方的真實意圖。

經過使用證書，以證實通訊方就是意料中的服務器。這對使用者我的來說，也減小了信息泄露的危險性。

在掘金主頁點開瀏覽器地址欄的小鎖以後，再點擊證書，即可以看到第三方機構頒發給 *.juejin.im 的證書。

另外，客戶端持有證書便可完成我的身份的確認，也可用於對Web網站的認證環節。例如在配置Git的時候，在本地持有的證書。

沒法證實報文完整性，可能已遭篡改

接受到的內容可能有誤

因爲HTTP協議沒法證實通訊的報文完整性，所以，在請求或響應發出去以後直到對方接收以前的這段時間內，即便請求或響應的內容遭到篡改，也沒辦法獲悉。像這樣，遭攻擊者攔截並篡改內容的攻擊稱爲中間人攻擊（Man-in-the-Middle attack，MITM）。

如何防止篡改

雖然有使用HTTP協議肯定報文完整性的方法，但事實上並不便捷、可靠。其中經常使用的是MD5和SHA-1等散列值校驗的方法，以及用來確認文件的數字簽名方法。

提供文件下載服務的Web網站也會提供相應的以PGP（Pretty Good Privacy，完美隱私）建立的數字簽名及MD5算法生成的散列值。PGP是用來證實建立文件的數字簽名，MD5是由單向函數生成的散列值。

不論使用哪種方法，都須要操縱客戶端的用戶本人親自檢查驗證下載的文件是否就是原來服務器上的文件。瀏覽器沒法自動幫用戶檢查。

惋惜的是，用這些方法也依然沒法百分百保證確認結果正確。由於PGP和MD5自己被改寫的話，用戶是沒有辦法意識到的。

爲了有效防止這些弊端，有必要使用 HTTPS。SSL 提供認證和加密處理及摘要功能。僅靠 HTTP 確保完整性是很是困難的，所以經過和其餘協議組合使用來實現這個目標。

HTTP+加密+認證+完整性保護=HTTPS

HTTP加上加密處理和認證以及完整性保護後既是HTTPS

HTTPS是身披SSL外殼的HTTP

HTTPS並不是是應用層的一種新協議。只是HTTP通訊接口部分用SSL（Secure Socket Layer）和TLS（Transport layer Security）協議代替而已。

一般HTTP直接和TCP通訊。當使用SSL時，則演變成先和SSL通訊，再由SSL和TCP通訊了。

SSL是獨立於HTTP的協議，因此不光是HTTP協議，其餘運行在應用層的SMTP和Telnet等協議都可配合SSL協議使用。能夠說SSL是當今世界上應用最普遍的網絡安全技術。

相互交換密鑰的公開密鑰加密技術

在對SSL講解以前，咱們先來了解一下加密方法。SSL採用一種叫作公開密鑰加密（Public-key cryptography）的加密方式。

近代的加密方法中加密算法是公開的，而密鑰確實保密的。經過這種方式得以保持加密方法的安全性。

共享密鑰加密的困境

加密和解密用同一個密鑰的方式稱爲共享密鑰加密（Common key crypto system），也被稱爲對稱密鑰加密。

以共享密鑰方式加密時必須將密鑰也發給對方。可究竟怎樣才能

安全地轉交

？在互聯網上轉發密鑰時，若是通訊被監聽那麼密鑰就可會落入攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。

使用兩把密鑰的公開密鑰加密

公開密鑰加密方式很好地解決了共享密鑰加密的困境。

公開密鑰加密使用一對非對稱的密鑰。一把叫作私鑰（private key），另外一把叫作公開密鑰（public key）。顧名思義，私有密鑰不能讓其餘任何人知道，而公開密鑰則能夠隨意發佈，任何人均可以得到。

使用公開密鑰加密方式，發送密文的一方使用對方的公開密鑰進行加密處理，對方接收到被加密的信息後，再使用本身的私有密鑰進行解密。利用這種方式，不須要發送用來解密的私有密鑰，也沒必要擔憂密鑰被攻擊者竊聽而盜走。

HTTPS採用混合加密機制

HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。若密鑰可以實現安全交換，那麼有可能會考慮僅使用公開密鑰加密來通訊。可是公開密鑰加密和共享密鑰加密相比，其處理速度要慢。

因此充分利用二者各自的優點，在交換密鑰環節使用公開密鑰加密方式，以後的創建通訊交換報文階段則使用共享密鑰加密方式。

證實公開密鑰正確性的證書

遺憾的是，公開密鑰加密方式仍是存在一些問題。那就是沒法證實公開密鑰自己就是貨真價實的公開密鑰。好比，正準備和某臺服務器創建公開密鑰加密方式下的通訊時，如何證實收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰。或許在公開密鑰傳輸途中，真正的公開密鑰已經被攻擊者替換掉了。

爲了解決上述問題，可使用由數字證書認證機構（CA，Certificate Authority）和其相關機關頒發的公開密鑰證書。

數字證書認證機構處於客戶端與服務器雙方都信賴的第三方機構的立場上。咱們先來介紹下數字證書認證機構的業務流程。首先，服務器的運營人員先數字證書認證機構提出公開密鑰的申請。數字證書認證機構在判別提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。

服務器會將這份由數字證書認證機構頒發的公鑰證書發送給客戶端，以進行公開密鑰加密方式通訊。公鑰證書也可叫作數字證書或直接稱爲證書。

接到證書的客戶端可使用數字證書認證機構的公開密鑰，對那張證書上的數字簽名進行驗證，一旦驗證經過，客戶端即可明確兩件事：一，認證服務器的公開密鑰是真實有效的數字證書認證機構所頒發。二，服務器的公開密鑰是值得信賴的。

此處認證機關的公開密鑰必須安全地轉交給客戶端。使用通訊方式時，如何轉交是一件很困難的事，所以，多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。

HTTPS的安全通訊機制

爲了更好的理解HTTPS，咱們來觀察一下HTTPS的通訊步驟。

步驟1：客戶端經過發送Client Hello報文開始SSL通訊。報文中包含客戶端支持的SSL的指定版本、加密組件（Cipher Suite）列表（所使用的的加密算法及密鑰長度等）。

步驟2：服務器可進行SSL通訊時，會以Server Hello報文做爲應答。和客戶端同樣，在報文中包含SSL版本以及加密組件。服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟3：以後服務器發送Certificate報文。報文中包含公開密鑰證書。

步驟4：最後服務器發送Server Hello Done報文通知客戶端，最初階段的SSL 握手協商部分結束。

步驟5：SSL第一次握手結束以後，客戶端以Client Key Exchange報文做爲響應。報文中包含通訊加密中使用的一種被稱爲Pre-master secret的隨機密碼串。該報文已用步驟3中公開密鑰進行加密。

步驟6：接着客戶端繼續發送Change Cipher Spec報文。該報文會提示服務器，在此報文以後的通訊會採用Pre-master secret密鑰加密。

步驟7：客戶端發送Finished報文。該報文包含鏈接至今所有報文的總體校驗值。此次握手協商是否可以成功，要以服務器是否可以正確解密該報文做爲斷定依據。

步驟8：服務器一樣發送Change Cipher Spec報文。

步驟9：服務器一樣發送Finished報文。

步驟10：服務器和客戶端的Finished報文交換完畢以後，SSL鏈接就算創建完成。固然，通訊會受到SSL的保護。今後處開始進行應用層協議的通訊，即發送HTTP請求。

步驟11：應用層協議通訊，即發送HTTP響應。

最後由客戶端斷開鏈接。斷開鏈接時，發送client_notify報文。上圖作了一些省略，這步以後再發送TCP-FIN報文來關閉與TCP的通訊。

在上述；流程中，應用層發送數據時會附加一種叫作MAC（Massage Authentication Code）的報文摘要。MAC可以查知報文是否找到篡改，從而保護報文的完整性。

下面是對整個流程的圖解。圖中說明了從僅使用服務器端的公開密鑰證書（服務器證書）創建HTTPS通訊的整個過程。

SSL與TSL

HTTPS 使用 SSL（Secure Socket Layer） 和 TLS（Transport LayerSecurity）這兩個協議。

SSL技術最初是由瀏覽器開發商網景通訊公司率先倡導的，開發過SSL3.0以前的版本。目前主導權已轉移到IETF（Internet Engineering Task Force，Internet工程任務組）的手中。

IETF以SSL3.0爲基準，後又指定了TSL1.0、TSL1.1和TSL1.2.TSL是以SSL爲原型開發的協議，有時會統一稱該協議爲SSL。當前主流的版本是SSL3.0和TSL1.0。

SSL速度慢嗎

HTTPS也存在一些問題，那就是當使用SSL時，他的處理速度會變慢。

SSL的慢分兩種。一種是指通訊慢。另外一種是指因爲大量消耗CPU及內存等資源，致使處理速度變慢。

和使用HTTP相比，網絡負載可能會變慢2到100倍。除去和TCP鏈接，發送HTTP請求-響應之外，還必須進行SSL通訊，所以總體上處理通訊量不可避免會增長。

另外一點是SSL必須進行加密處理。在服務器和客戶端都須要進行加密和解密的運算操做。所以從結果上將，比起HTTP會更多地消耗服務器和客戶端的硬件資源，致使負載加強。

針對速度變慢這一問題，並無根本性的解決方案，咱們可使用SSL加速器這種（專用服務器）硬件來改善該問題。該硬件爲SSL通訊專用硬件，相對軟件來講，可以提升數倍SSL的計算速度。

參考：《圖解HTTP》

百度百科-公開密鑰

HTTPS的故事