HTTPS如何確保Web安全

前言：全網HTTPS勢在必行

HTTPS（全稱：HyperText Transfer Protocol over Secure Socket Layer），是爲了保證客戶端與服務器之間數據傳輸的安全。 近兩年，Google、Baidu、Facebook 等這樣的互聯網巨頭，不謀而合地開始大力推行 HTTPS， 國內外的大型互聯網公司不少也都已經啓用了全站 HTTPS，這也是將來互聯網發展的趨勢，做爲前端工程師，瞭解HTTPS的原理也是必修課之一。
2019年離全網使用HTTPS已經不遠了，列舉幾個各大互聯網公司爲鼓勵使用HTTPS而提出的要求：
1.Google的搜索引擎算法，讓採用 HTTPS 的網站在搜索中排名更靠前；
2.蘋果要求App Store中的全部應用都必須使用 HTTPS 加密鏈接；
3.微信小程序也要求必須使用 HTTPS 協議；
4.新一代的 HTTP/2 協議的支持需以 HTTPS 爲基礎；
5.新版本chrome已將HTTP協議網站標記不安全

隱患：爲何要給HTTP加S？

HTTP協議從誕生至今已經具備至關優秀和方便的一面，然而HTTP並不是只有好的一面，事物皆具兩面性，它的不足之處也是很明顯：

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

除此以外，HTTP自己還有不少缺點。並且，還有像某些特定的Web服務器和特定的Web瀏覽器在實際應用中存在的不足（也能夠說成是脆弱性或安全漏洞），另外，用Java和PHP等編程語言開發的Web應用也可能存在安全漏洞。

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

因爲HTTP自己不具有加密的功能，因此也沒法作到對通訊總體（使用HTTP協議通訊的請求和響應的內容）進行加密。因此，HTTP報文使用明文方式發送。若是要問爲何通訊時不加密是一個缺點，這是由於，按TCP/IP協議族的工做機制，通訊內容在全部的通訊線路上都有可能遭到窺視。
所謂互聯網，是由能連通到全世界的網絡組成，不管世界哪一個角落的服務器在和客戶端通訊時，在此通訊線路上的某些網絡設備、光纜、計算機等都不多是我的的私有物，因此不排除某個環節中會遭到惡意窺視行爲。
即便已通過加密處理的通訊，也會被窺視到通訊內容，這點和未加密的通訊是相同的。只是說若是通訊通過加密，就有可能讓人沒法破解報文信息的含義，但加密處理後的報文信息自己仍是會被看到。
竊聽相同段上的通訊並不是難事。只須要收集在互聯網上流動的數據包就行。對於收集來的數據包的解析工做，能夠交給那些抓包或嗅探工具。

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

HTTP協議中的請求和相應不會對通訊方進行確認。也就是說存在「服務器是否就是發送請求中URI真正指定的主機，返回的響應是否真的返回到實際提出請求的客戶端」等相似問題。
在HTTP協議通訊時，因爲不存在確認通訊方的處理步驟，任何人均可以發送請求，同時，服務器只要接收到請求，只要發送端的IP地址和端口號沒有被Web服務器設定限制訪問，無論對方是誰都會返回一個響應，所以會存在如下各類隱患：

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

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

所謂完整性是指信息的準確度。若沒法證實其完整性，一般也就意味着沒法判斷信息是否準確。
所以，在請求或響應送出以後知道對方接收以前的這段時間內，即便請求或相應的內容遭到篡改，也沒有辦法獲悉。
換句話說，沒有任何辦法確認，發出的請求、響應和接收到的請求、響應是先後相同的。文件內容在傳輸中可能已經被村改成其餘內容，像這樣，請求或響應在傳輸途中遭攻擊者攔截並篡改內容的攻擊成爲中間人攻擊（Man-in-the-Middle attack,MITM)。

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

上面提了那麼多HTTP的缺點天然在HTTPS中咱們得解決它，下面咱們來看看HTTPS是如何保證咱們數據傳輸安全的。

1. HTTPS實際上是身披SSL外殼的HTTP

HTTPS並不是是應用層的一種新協議。知識HTTP通訊接口部分用SSL(Secure Socket Layer，安全套階層)和TLS（Transport Layer Security，安全傳輸層協議)協議代替而已。
一般,HTTP直接和TCP通訊。當使用SSL時，則變成先和SSL通訊，再由SSL和TCP通訊了。簡單來講，與SSL組合使用的HTTP被稱爲HTTPS（HTTP Secure,超文本傳輸安全協議）或HTTP over SSL。
採用了SSL後，HTTP就擁有了HTTPS的加密、證書和完整性保護這些功能。SSL是獨立於HTTP的協議，因此不光是HTTP協議，其它運行在應用層的SMTP和Telnet等協議都可配合SSL協議使用。能夠說SSL是當今世界上應用最爲普遍的網絡安全技術。

HTTPS的加密原理

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

加密和解密要用到密鑰，若是沒有密鑰就沒有辦法對密碼解密。換句話來講，任何人只要持有密鑰就可以對密文進行解密。

HTTPS在加密過程當中使用了非對稱加密技術和對稱加密技術。

對稱加密算法

採用單鑰密碼系統的加密方式，同一個密鑰能夠同時作信息的加密和解密，這種加密的方法稱爲對稱加密，也稱爲單密鑰加密。

下面會把對稱加密算法稱爲共享密鑰加密算法。

假如如今，SSL在通訊過程當中，使用了對稱加密算法，也就是說客戶端和服務器同時共享一個密鑰。

因而，以共享密鑰的方式加密，必須將密鑰發給對方。這個時候，假如通訊過程被監聽，密鑰被攻擊者獲取了，那麼這個時候也就失去了加密的意義了。

那麼，有沒有辦法解決這個問題呢？答案是確定的，也就是使用兩把密鑰。

下面先看使用兩把密鑰的非對稱加密算法。

非對稱加密算法

與對稱加密算法相反，非對稱加密算法須要兩個密鑰來進行加密和解密，這兩個密鑰是配對的，分別是公開密鑰（公鑰）和私有密鑰（私鑰）。

通常狀況下，公鑰是能夠被公開的，它主要用來加密明文。而相應的，私鑰不能被公開，用來解密公鑰加密的密文。

值得注意的是：公鑰加密後的密文只能經過對應的私鑰來解密，而私鑰加密的密文卻能夠經過對應的公鑰來解密。

以上，公鑰加密私鑰解密用來加密，私鑰加密公鑰解密用來簽名。相關用途後面會講到。

下面會把非對稱加密算法稱爲公開密鑰加密算法。

因而如今，假設如今由服務器來生成一對公鑰和密鑰。

當客戶端第一次發請求和服務器協商的時候，服務器就生成了一對公鑰和私鑰。

緊接着，服務器把公鑰發給客戶端（明文，不須要作任何加密），客戶端接收後，隨機生成一個密鑰，使用服務器發過來的公鑰進行加密。

再接着，客戶端把使用公鑰加密的密鑰發給服務器，服務器接收到了之後，用配對的私鑰進行解密，就獲得了客戶端隨機生成的那個密鑰。

這個時候，客戶端和服務端所持的密鑰都是相同的。此時，交換密鑰環節就完成了。

因而通訊開始時就可進行上面所述的共享密鑰加密方式來進行加密。

同時使用

可能，有小夥伴就會問，爲何要大費周章使用非對稱加密的方式，而後再獲得相同的密鑰，進行共享密鑰加密的通訊呢？

因爲公開密鑰加密處理起來比共享密鑰加密方式更爲複雜，所以在通訊的時候使用公開密鑰加密的方式，效率很低。

因而，咱們須要使用非對稱加密的方式來保證密鑰共享的過程當中密鑰的安全性，然後在通訊的過程當中使用對稱加密算法，這是最合理的設計方式，在保證安全性的同時又保證了性能。

因此，HTTPS採用共享密鑰加密和公開密鑰加密二者並用的混合加密機制。在交換密鑰使用環節使用公開密鑰加密方式，以後創建的通訊交換報文階段則使用共享密鑰加密方式。

以上，大概就是使用對稱加密和非對稱加密的過程。看似過程很完美，其實還存在着一個問題，就是：如何保證服務器傳過來的公開密鑰的正確性。換句話說，就是保證它不被攔截篡改。

使用證書保證公鑰的正確性

假如如今正準備和某臺服務器創建公開密鑰加密方式下的通訊，如何證實客戶端收到的公開密鑰就是本來預想的那臺服務器發行的公開密鑰呢？或許，在公開密鑰傳輸的過程當中，真正的公開密鑰可能已經被攻擊者替換掉了。

爲了解決這個問題，可使用由數字證書機構和其相關頒發的公開密鑰證書。

下面闡述一下數字證書認證機構（簡稱CA）的業務流程：

首先，服務器的運營人員向數字證書機構提出公開密鑰的申請。數字證書認證機構在判明提出申請者的身份以後，會對已申請的公開密鑰作數字簽名，而後分配這個已簽名的公開密鑰，並將該公開密鑰放入公鑰證書後綁定在一塊兒。

咱們用白話文來翻譯一下上面這段話：
首先，CA會向申請者頒發一個證書，這個證書裏面的內容有：簽發者、證書用途、服務器申請的時候附帶的公鑰、服務器的加密算法、使用的HASH算法、證書到期的時間等等。
緊接着，把上面所提到的內容，作一次HASH求值，獲得一個HASH值。

再接着，用CA的私鑰進行加密，這樣就完成了數字簽名。而用CA的私鑰加密後，就生成了相似人體指紋的簽名，任何篡改證書的嘗試，都會被數字簽名發現。
最後，把數字簽名，附在數字證書的末尾，傳輸回來給服務器。
接下來，服務器會把這份由數字證書認證機構頒發的公鑰證書發給客戶端。這個時候，客戶端可使用數字證書機構的公開密鑰對其進行驗證。一旦驗證成功，客戶端便可以肯定這個公開密鑰是可信的。

咱們再用白話文來翻譯一下：
客戶端拿到這個數字證書之後，用CA私鑰對應的公鑰，能夠解密數字證書末尾的數字簽名，獲得原始的HASH值。
緊接着，客戶端按照證書中的HASH算法，對證書的內容求HASH值。若是經過CA公鑰解密的HASH和經過計算求得的HASH值相同，那麼認證經過，不然失敗。
若是認證經過，就能夠取得服務器的公開密鑰。

那客戶端上面的CA公鑰是從哪裏來的呢？
多數瀏覽器開發商發佈版本時，會事先在內部植入經常使用認證機關的公開密鑰。這樣，就方便客戶端對於數字證書真實性的驗證。

其具體過程是這樣子的（圖中簡化了數字簽名的過程）：

這裏其實就用到了非對稱加密算法，只不過如今這個加密算法用來簽名而不是加密。

使用私鑰加密，公鑰解密，用於公鑰的持有者驗證經過私鑰加密的內容是否被篡改，可是不用來保證內容是否被他人得到。

而使用公鑰加密，私鑰解密，則是相反的，它不保證信息被他人截獲篡改，可是保證信息沒法被中間人得到。

客戶端證書

HTTPS中不只可使用服務器證書，還可使用客戶端證書。以客戶端證書進行客戶端認證，它的做用與服務器證書是相同的。

因爲客戶端獲取證書須要用戶自行安裝客戶端證書，同時也面臨着費用的問題。

所以，現狀是，安全性極高的認證機構可辦法客戶端證書可是僅用於特殊用途的業務。好比那些可支撐客戶端證書支出費用的業務。

例如，銀行的網上銀行就採用了客戶端證書。在登陸網銀時不只要求用戶確認輸入ID和密碼，還會要求用戶的客戶端證書，以確認用戶是否從特定的終端訪問網銀。

HTTPS的安全通訊機制

爲了更好的理解HTTPS，小肆給你們畫了下圖來一塊兒觀察一下HTTPS的通訊步驟：

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

步驟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響應。

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

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

那如今有一個問題，整個過程當中產生的三個隨機數有什麼用呢？還有，後面進行HTTP通訊的時候，是用哪個密鑰進行加密，還有怎麼保證報文的完整性。

看下面這張圖。

對於客戶端：

當其生成了Pre-master secret以後，會結合原來的A、B隨機數，用DH算法計算出一個master secret，緊接着根據這個master secret推導出hash secret和session secret。

對於服務端：

當其解密得到了Pre-master secret以後，會結合原來的A、B隨機數，用DH算法計算出一個master secret，緊接着根據這個master secret推導出hash secret和session secret。

在客戶端和服務端的master secret是依據三個隨機數推導出來的，它是不會在網絡上傳輸的，只有雙方知道，不會有第三者知道。同時，客戶端推導出來的session secret和hash secret與服務端也是徹底同樣的。

那麼如今雙方若是開始使用對稱算法加密來進行通信，使用哪一個做爲共享的密鑰呢？過程是這樣子的：

雙方使用對稱加密算法進行加密，用hash secret對HTTP報文作一次運算生成一個MAC，附在HTTP報文的後面，而後用session-secret加密全部數據（HTTP+MAC），而後發送。

接收方則先用session-secret解密數據，而後獲得HTTP+MAC，再用相同的算法計算出本身的MAC，若是兩個MAC相等，證實數據沒有被篡改。

至此，整個過程介紹完畢。

技術放肆聊公衆號，每日干貨，最前沿的技術知識，掃描下方二維碼關注：