前言
#近幾年，網路上有翻天覆地的變化，尤其是我們一直習以為常的HTTP協議，在逐漸的被HTTPS協議所取代，在瀏覽器、搜尋引擎、CA機構、大型互聯網企業的共同促進下，互聯網迎來了“HTTPS加密時代”，HTTPS將在未來的幾年內全面取代HTTP成為傳輸協議的主流。
讀完本文，希望你能明白：
HTTP通訊存在什麼問題
HTTPS如何改進HTTP存在那些問題
HTTPS運作原理是什麼
一、什麼是HTTPS
HTTPS是在HTTP上建立SSL加密層，並對傳輸資料進行加密，是HTTP協定的安全版。現在它被廣泛用於萬維網上安全敏感的通訊，例如交易支付方面。
HTTPS主要作用是：
（1）對資料進行加密，並建立一個資訊安全通道，來確保傳輸過程中的資料安全;
（2）對網站伺服器進行真實身份認證。
我們常常會在Web的登入頁面和購物結算介面等使用HTTPS通訊。使用HTTPS通訊時，不再用 http://，而是改用 https://。另外，當瀏覽器造訪HTTPS通訊有效的網路網站時，瀏覽器的網址列內會出現一個帶鎖的標記。對HTTPS的顯示方式會因瀏覽器的不同而有所改變。
二、為什麼需要HTTPS
在HTTP協定中有可能有資訊竊取或身分偽裝等安全性問題。使用HTTPS通訊機制可以有效地防止這些問題，接下來，我們先來了解下HTTP協定存在的哪些問題：
通訊使用明文（不加密），內容可能被竊聽
由於HTTP本身不具備加密的功能，所以也無法做到對通訊整體（使用HTTP協定通訊的請求和回應的內容）進行加密。即，HTTP封包使用明文（指未經加密的封包）方式傳送。
HTTP明文協定的缺陷是導致資料外洩、資料竄改、流量劫持、釣魚攻擊等安全問題的重要原因。 HTTP協定無法加密數據，所有通訊資料都在網路中明文「裸奔」。透過網路的嗅探設備及一些技術手段，就可還原HTTP封包內容。
無法證明封包的完整性，所以可能遭竄改
所謂完整性是指資訊的準確度。若無法證明其完整性，通常也意味著無法判斷資訊是否準確。由於HTTP協定無法證明通訊的封包完整性，因此，在要求或回應送出之後直到對方接收之前的這段時間內，即使請求或回應的內容遭到竄改，也沒有辦法獲悉。換句話說，沒有任何辦法確認，發出的請求/回應和接收到的請求/回應是前後相同的。
不驗證通訊方的身份，因此有可能遭遇偽裝
HTTP協定中的請求和回應不會對通訊方進行確認。在HTTP協定通訊時，由於不存在確認通訊方的處理步驟，任何人都可以發起請求。另外，伺服器只要接收到請求，不管對方是誰都會回傳一個回應（但也僅限於發送端的IP位址和連接埠號碼沒有被Web伺服器設定限制存取的前提下）
HTTP協定無法驗證通訊方身份，任何人都可以偽造虛假伺服器欺騙用戶，實現“釣魚詐欺”，用戶無法察覺。
反觀HTTPS協議，它比HTTP協議相比多了以下優勢（下文會詳細介紹）:
資料隱私性：內容經過對稱加密，每個連接產生一個唯一的加密金鑰
資料完整性：內容傳輸經過完整性校驗
身份認證：第三方無法偽造服務端（客戶端）身分
三、 HTTPS如何解決HTTP上述問題?
HTTPS並非是應用層的一種新協定。只是HTTP通訊介面部分用SSL和TLS協定取代而已。
通常，HTTP直接和TCP通訊。使用SSL時，則演變成先和SSL通信，再由SSL和TCP通信了。簡言之，所謂HTTPS，其實就是身披SSL協定這層外殼的HTTP。
在採用SSL後，HTTP就擁有了HTTPS的加密、憑證和完整性保護這些功能。也就是說HTTP加上加密處理和認證以及完整性保護後即是HTTPS。
HTTPS 協定的主要功能基本上都依賴TLS/SSL 協議，TLS/SSL 的功能實現主要依賴三類基本演算法：雜湊函數、對稱加密和非對稱加密，其利用非對稱加密實現身分認證和金鑰協商，對稱加密演算法採用協商的金鑰對資料加密，基於雜湊函數驗證資訊的完整性。
1.解決內容可能被竊聽的問題－加密
#方法1.對稱加密
這種方式加密和解密同用一個金鑰。加密和解密都會用到金鑰。沒有金鑰就無法對密碼解密，反過來說，任何人只要持有金鑰就能解密了。
以對稱加密方式加密時必須將金鑰也發給對方。可究竟怎樣才能安全地轉交？在網路上轉送金鑰時，如果通訊被監聽那麼金鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰。
方法2.非對稱加密
公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰，另一把叫做公開金鑰。顧名思義，私有金鑰不能讓其他人知道，而公開金鑰則可以隨意發布，任何人都可以獲得。
使用公開金鑰加密方式，發送密文的一方使用對方的公開金鑰進行加密處理，對方收到被加密的訊息後，再使用自己的私有金鑰進行解密。利用這種方式，不需要發送用來解密的私有金鑰，也不必擔心金鑰被攻擊者竊聽而盜走。
非對稱加密的特點是資訊傳輸一對多，伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通訊。
這種方式有以下缺點：
公鑰是公開的，所以針對私鑰加密的訊息，駭客截獲後可以使用公鑰進行解密，取得其中的內容；
公鑰不包含伺服器的訊息，使用非對稱加密演算法無法確保伺服器身分的合法性，存在中間人攻擊的風險，伺服器傳送給客戶端的公鑰可能在傳送過程中被中間人截獲並篡改；
使用非對稱加密在資料加密解密過程中需要消耗一定時間，降低了資料傳輸效率；
#方法3.對稱加密非對稱加密(HTTPS採用這種方式)
使用對稱金鑰的好處是解密的效率比較快，使用非對稱金鑰的好處是可以使得傳輸的內容不能被破解，因為就算你攔截到了數據，但是沒有對應的私鑰，也是不能破解內容的。就比如說你搶到了一個保險箱，但是沒有保險箱的鑰匙也不能打開保險箱。那我們就將對稱加密與非對稱加密結合起來,充分利用兩者各自的優勢，在交換密鑰環節使用非對稱加密方式，之後的建立通信交換報文階段則使用對稱加密方式。
具體做法是：發送密文的一方使用對方的公鑰進行加密處理“對稱的密鑰”，然後對方用自己的私鑰解密拿到“對稱的密鑰”，這樣可以確保交換的金鑰是安全的前提下，使用對稱加密方式進行通訊。所以，HTTPS採用對稱加密和非對稱加密兩者並用的混合加密機制。
2.解決封包可能遭竄改問題－數位簽章
網路傳輸過程中需要經過許多中間節點，雖然資料無法被解密，但可能被竄改，那如何校驗資料的完整性呢？ ----校驗數位簽章。
數位簽章有兩種功效：
能確定訊息確實是由發送者簽署並發出來的，因為別人假冒不了發送者的簽名。
數位簽章能確定訊息的完整性,證明資料是否未被竄改過。
數位簽名如何產生:
將一段文字先用Hash函數產生訊息摘要，然後用發送者的私鑰加密產生數位簽名，與原文文一起傳送給接收者。接下來就是接收者校驗數位簽章的流程了。
校驗數位簽章流程：
接收者只有用發送者的公鑰才能解密被加密的摘要訊息，然後用HASH函數對收到的原文產生一個摘要訊息，與上一個步驟所得到的摘要資訊比較。如果相同，則表示收到的資訊是完整的，在傳輸過程中沒有被修改，否則說明資訊被修改過，因此數位簽章能夠驗證資訊的完整性。
假設訊息傳遞在Kobe，James兩人之間發生。 James將訊息連同數位簽名一起發送給Kobe，Kobe接收到訊息後，透過校驗數位簽名，就可以驗證接收到的訊息就是James發送的。當然，這個過程的前提是Kobe知道James的公鑰。問題的關鍵的是，和訊息本身一樣，公鑰不能在不安全的網路中直接發送給Kobe,或者說拿到的公鑰如何證明是James的。
此時就需要引進了憑證授權單位（Certificate Authority，簡稱CA），CA數量並不多，Kobe客戶端內建了所有受信任CA的憑證。 CA對James的公鑰（和其他資訊）數位簽章後產生憑證。
3.解決通訊方身分可能被偽裝的問題－數位憑證
數位憑證認證機構處於客戶端與伺服器雙方都可信賴的第三方機構的立場。
我們來介紹數位憑證認證機構的業務流程：
伺服器的營運人員向第三方機構CA提交公鑰、組織資訊、個人資訊(域名)等資訊併申請認證;
CA透過線上、線下等多種手段驗證申請者提供資訊的真實性，如組織是否存在、企業是否合法，是否擁有網域的所有權等;
如資訊審核通過， CA會發給申請者認證文件-證書。憑證包含以下資訊：申請者公鑰、申請者的組織資訊和個人資訊、簽發機構 CA的資訊、有效時間、憑證序號等資訊的明文，同時包含一個簽章。其中簽署的產生演算法：首先，使用雜湊函數計算公開的明文資訊的資訊摘要，然後，採用CA的私鑰對資訊摘要進行加密，密文即簽章;
客戶端Client 向伺服器Server 發出請求時，Server 傳回憑證檔案;
客戶端Client 讀取憑證中的相關的明文訊息，採用相同的雜湊函數計算得到資訊摘要，然後，利用對應CA的公鑰解密簽名數據，對比憑證的資訊摘要，如果一致，則可以確認憑證的合法性，即伺服器的公開金鑰是值得信賴的。
用戶端也會驗證憑證相關的網域資訊、有效時間等資訊; 用戶端會內建信任CA的憑證資訊(包含公鑰)，如果CA不被信任，則找不到對應CA的證書，證書也會被判定非法。
四、 HTTPS工作流程
1.Client發起一個HTTPS（例如https://juejin.im/user）的請求，根據RFC2818的規定，Client知道需要連接Server的443（預設）連接埠。
2.Server把事先設定好的公鑰憑證（public key certificate）回傳給客戶端。
3.Client驗證公鑰憑證：例如是否在有效期限內，憑證的用途是不是符合Client要求的站點，是不是在CRL撤銷清單裡面，它的上一層憑證是否有效，這是一個遞歸的過程，直到驗證到根憑證（作業系統內建的Root憑證或Client內建的Root憑證）。如果驗證通過則繼續，不通過則顯示警告訊息。
4.Client使用偽隨機數產生器產生加密所使用的對稱金鑰，然後用憑證的公鑰加密這個對稱金鑰，發給Server。
5.Server使用自己的私鑰（private key）解密這個訊息，得到對稱金鑰。至此，Client和Server雙方都持有了相同的對稱金鑰。
6.Server使用對稱金鑰加密“明文內容A”，傳送給Client。
7.Client使用對稱金鑰解密回應的密文，得到「明文內容A」。
8.Client再次發起HTTPS的請求，使用對稱金鑰加密請求的“明文內容B”，然後Server使用對稱金鑰解密密文，得到“明文內容B”。
五、HTTP 與HTTPS 的區別
HTTP 是明文傳輸協議，HTTPS 協定是由SSL HTTP 協定建構的可進行加密傳輸、身份認證的網路協定，比HTTP 協定安全。
關於安全性，用最簡單的比喻形容兩者的關係就是卡車運貨，HTTP下的貨車是敞篷的，貨物都是暴露的。而https則是封閉貨櫃車，安全性自然提升不少。
HTTPS比HTTP更安全，對搜尋引擎更友好，利於SEO,Google、百度優先索引HTTPS網頁;
HTTPS需要用到SSL證書，而HTTP不用;
HTTPS標準連接埠443，HTTP標準連接埠80;
HTTPS基於傳輸層，HTTP基於應用層;
HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;
六、為何不所有的網站都使用HTTPS
既然HTTPS那麼安全可靠，那為何不所有的Web網站都使用HTTPS？
首先，很多人還是會覺得HTTPS實施有門檻，這個門檻在於需要權威CA頒發的SSL憑證。從證書的選擇、購買到部署，傳統的模式下都會比較耗時且耗力。
其次，HTTPS普遍認為效能消耗大於HTTP，因為與純文字通訊相比，加密通訊會消耗更多的CPU及記憶體資源。如果每次通訊都加密，會消耗相當多的資源，平攤到一台電腦上時，能夠處理的請求數量必定也會隨之減少。但事實並非如此，使用者可以透過效能優化、把憑證部署在SLB或CDN，來解決此問題。舉個實際的例子，在「雙十一」期間，全站HTTPS的淘寶、天貓依然保證了網站和行動端的存取、瀏覽、交易等操作的順暢、平滑。透過測試發現，經過優化後的許多頁面效能與HTTP持平甚至還有小幅提升，因此HTTPS經過優化之後其實並不慢。
除此之外，想要節省購買憑證的開銷也是原因之一。要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。
最後是安全意識。相較於國內，國外網路產業的安全意識與技術應用相對成熟，HTTPS部署趨勢是由社會、企業、政府共同去推動的。
以上是為什麼HTTPS比HTTP更安全?的詳細內容。更多資訊請關注PHP中文網其他相關文章！
