本篇文章帶給大家的內容是關於HTTPS如何確保Web安全？ （程式碼範例），有一定的參考價值，有需要的朋友可以參考一下，希望對你有幫助。
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本身還有很多缺點。而且，還有像某些特定的網頁伺服器和特定的網頁瀏覽器在實際應用中存在的不足（也可以說成是脆弱性或安全漏洞），另外，用Java和PHP等程式語言開發的網路應用也可能存在安全漏洞。
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的通信步驟：
以上是HTTPS如何保證Web安全？ （程式碼範例）的詳細內容。更多資訊請關注PHP中文網其他相關文章！
