最近大家在使用百度、谷歌或淘寶的時候，是不是注意瀏覽器左上角已經全部出現了一把綠色鎖，這把鎖表明該網站已經使用了 HTTPS 進行保護。仔細觀察，會發現這些網站已經全站使用 HTTPS。同時，iOS 9 系統默認把所有的 http 請求都改為 HTTPS 請求。隨著互聯網的發展，現代互聯網正在逐漸進入全站 HTTPS 時代。
全站 HTTPS 能夠帶來怎樣的優勢？HTTPS 的原理又是什么？同時，阻礙 HTTPS 普及的困難是什么？
為了解答大家的困惑，騰訊TEG架構平臺部靜態加速組高級工程師劉強，為大家綜合參考多種資料并經過實踐驗證，探究 HTTPS 的基礎原理，分析基本的 HTTPS 通信過程，迎接全站 HTTPS 的來臨。

1.HTTPS 基礎

HTTPS(Secure Hypertext Transfer Protocol)安全超文本傳輸協議 它是一個安全通信通道，它基于HTTP開發，用于在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版,是使用 TLS/SSL 加密的 HTTP 協議。

HTTP 協議采用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議 TLS/SSL 具有身份驗證、信息加密和完整性校驗的功能，可以避免此類問題。

TLS/SSL 全稱安全傳輸層協議 Transport Layer Security, 是介于 TCP 和 HTTP 之間的一層安全協議，不影響原有的 TCP 協議和 HTTP 協議，所以使用 HTTPS 基本上不需要對 HTTP 頁面進行太多的改造。

2.TLS/SSL 原理

HTTPS 協議的主要功能基本都依賴于 TLS/SSL 協議，本節分析安全協議的實現原理。

TLS/SSL 的功能實現主要依賴于三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。

散列函數 Hash，常見的有 MD5、SHA1、SHA256，該類函數特點是函數單向不可逆、對輸入非常敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用于防止信息篡改并驗證數據的完整性；對稱加密，常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰可以用于信息的加密和解密，掌握密鑰才能獲取信息，能夠防止信息竊聽，通信方式是1對1；非對稱加密，即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特點是，密鑰成對出現，一般稱為公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。因此掌握公鑰的不同客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通信，服務器可以實現1對多的通信，客戶端也可以用來驗證掌握私鑰的服務器身份。

在信息傳輸過程中，散列函數不能單獨實現信息防篡改，因為明文傳輸，中間人可以修改信息之后重新計算信息摘要，因此需要對傳輸的信息以及信息摘要進行加密；對稱加密的優勢是信息傳輸1對1，需要共享相同的密碼，密碼的安全是保證信息安全的基礎，服務器和 N 個客戶端通信，需要維持 N 個密碼記錄，且缺少修改密碼的機制；非對稱加密的特點是信息傳輸1對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信，但服務器發出的信息能夠被所有的客戶端解密，且該算法的計算復雜，加密速度慢。

結合三類算法的特點，TLS 的基本工作方式是，客戶端使用非對稱加密與服務器進行通信，實現身份驗證并協商對稱加密使用的密鑰，然后對稱加密算法采用協商密鑰對信息以及信息摘要進行加密通信，不同的節點之間采用的對稱密鑰不同，從而可以保證信息只能通信雙方獲取。

3.PKI 體系 3.1 RSA 身份驗證的隱患

身份驗證和密鑰協商是 TLS 的基礎功能，要求的前提是合法的服務器掌握著對應的私鑰。但 RSA 算法無法確保服務器身份的合法性，因為公鑰并不包含服務器的信息，存在安全隱患:

客戶端 C 和服務器 S 進行通信，中間節點 M 截獲了二者的通信；

節點 M 自己計算產生一對公鑰 pub_M 和私鑰 pri_M;

C 向 S 請求公鑰時，M 把自己的公鑰 pub_M 發給了 C;

C 使用公鑰 pub_M 加密的數據能夠被 M 解密，因為 M 掌握對應的私鑰 pri_M，而 C 無法根據公鑰信息判斷服務器的身份，從而 C 和 M 之間建立了”可信”加密連接;

中間節點 M 和服務器S之間再建立合法的連接，因此 C 和 S 之間通信被M完全掌握，M 可以進行信息的竊聽、篡改等操作。

另外，服務器也可以對自己的發出的信息進行否認，不承認相關信息是自己發出。

因此該方案下至少存在兩類問題：中間人攻擊和信息抵賴。

3.2 身份驗證-CA 和證書

解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，能夠驗證服務器的身份信息，為此需要引入權威的第三方機構 CA。CA 負責核實公鑰的擁有者的信息，并頒發認證”證書”，同時能夠為使用者提供證書驗證服務，即 PKI 體系。

基本的原理為，CA 負責審核信息，然后對關鍵信息利用私鑰進行”簽名”，公開對應的公鑰，客戶端可以利用公鑰驗證簽名。CA 也可以吊銷已經簽發的證書，基本的方式包括兩類 CRL 文件和 OCSP。CA 使用具體的流程如下：

a.服務方 S 向第三方機構CA提交公鑰、組織信息、個人信息(域名)等信息并申請認證；

b.CA 通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的所有權等；

c.如信息審核通過，CA 會向申請者簽發認證文件-證書。

證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，然后，采用 CA 的私鑰對信息摘要進行加密，密文即簽名；

d.客戶端 C 向服務器 S 發出請求時，S 返回證書文件；

e.客戶端 C 讀取證書中的相關的明文信息，采用相同的散列函數計算得到信息摘要，然后，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法；

f.客戶端然后驗證證書相關的域名信息、有效時間等信息；

g.客戶端會內置信任 CA 的證書信息(包含公鑰)，如果CA不被信任，則找不到對應 CA 的證書，證書也會被判定非法。

在這個過程注意幾點：

a.申請證書不需要提供私鑰，確保私鑰永遠只能服務器掌握；

b.證書的合法性仍然依賴于非對稱加密算法，證書主要是增加了服務器信息以及簽名；

c.內置 CA 對應的證書稱為根證書，頒發者和使用者相同，自己為自己簽名，即自簽名證書；

d.證書=公鑰+申請者與頒發者信息+簽名；

本文題目：HTTPS與HTTP有何不同？
本文來源：http://m.newbst.com/news27/181677.html

成都網站建設公司_創新互聯，為您提供商城網站、網站內鏈、小程序開發、靜態網站、手機網站建設、網站排名

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯