建站
咨詢
售后
建站咨詢
新聞中心
本文首先分析HTTP協(xié)議在安全性上的不足，進而闡述HTTPS實現(xiàn)安全通信的關(guān)鍵技術(shù)點和原理。然后通過抓包分析HTTPS協(xié)議的握手以及通信過程。最后總結(jié)一下自己在開發(fā)過程中遇到的HTTPS相關(guān)的問題，并給出當前項目中對HTTPS問題的系統(tǒng)解決方案，以供總結(jié)和分享。
成都創(chuàng)新互聯(lián)是一家專業(yè)提供開封企業(yè)網(wǎng)站建設(shè),專注與成都做網(wǎng)站、網(wǎng)站建設(shè)、H5場景定制、小程序制作等業(yè)務(wù)。10年已為開封眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進行中。
1.HTTP協(xié)議的不足
HTTP1.x在傳輸數(shù)據(jù)時，所有傳輸?shù)膬?nèi)容都是明文，客戶端和服務(wù)器端都無法驗證對方的身份，存在的問題如下：
- 通信使用明文(不加密)，內(nèi)容可能會被竊聽;
- 不驗證通信方的身份，有可能遭遇偽裝;
- 無法證明報文的完整性，所以有可能已遭篡改;
??其實這些問題不僅在HTTP上出現(xiàn)，其他未加密的協(xié)議中也會存在這類問題。
(1) 通信使用明文可能會被竊聽
??按TCP/IP協(xié)議族的工作機制，互聯(lián)網(wǎng)上的任何角落都存在通信內(nèi)容被竊聽的風險。而HTTP協(xié)議本身不具備加密的功能，所傳輸?shù)亩际敲魑?。即使已?jīng)經(jīng)過過加密處理的通信，也會被窺視到通信內(nèi)容，這點和未加密的通信是相同的。只是說如果通信經(jīng)過加密，就有可能讓人無法破解報文信息的含義，但加密處理后的報文信息本身還是會被看到的。
(2) 不驗證通信方的身份可能遭遇偽裝
在HTTP協(xié)議通信時，由于不存在確認通信方的處理步驟，因此任何人都可以發(fā)起請求。另外，服務(wù)器只要接收到請求，不管對方是誰都會返回一個響應。因此不確認通信方，存在以下隱患：
- 無法確定請求發(fā)送至目標的Web服務(wù)器是否是按真實意圖返回響應的那臺服務(wù)器。有可能是已偽裝的 Web 服務(wù)器;
- 無法確定響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端。有可能是已偽裝的客戶端;
- 無法確定正在通信的對方是否具備訪問權(quán)限。因為某些Web服務(wù)器上保存著重要的信息，只想發(fā)給特定用戶通信的權(quán)限;
- 無法判定請求是來自何方、出自誰手;
- 即使是無意義的請求也會照單全收，無法阻止海量請求下的DoS攻擊;
(3) 無法證明報文完整性，可能已遭篡改
所謂完整性是指信息的準確度。若無法證明其完整性，通常也就意味著無法判斷信息是否準確。HTTP協(xié)議無法證明通信的報文完整性，在請求或響應送出之后直到對方接收之前的這段時間內(nèi)，即使請求或響應的內(nèi)容遭到篡改，也沒有辦法獲悉。
比如，從某個Web網(wǎng)站下載內(nèi)容，是無法確定客戶端下載的文件和服務(wù)器上存放的文件是否前后一致的。文件內(nèi)容在傳輸途中可能已經(jīng)被篡改為其他的內(nèi)容。即使內(nèi)容真的已改變，作為接收方的客戶端也是覺察不到的。像這樣，請求或響應在傳輸途中，遭攻擊者攔截并篡改內(nèi)容的攻擊稱為中間人攻擊(Man-in-the-Middle attack，MITM)。
(4) 安全的HTTP版本應該具備的幾個特征
由于上述的幾個問題，需要一種能夠提供如下功能的HTTP安全技術(shù)：
(1) 服務(wù)器認證(客戶端知道它們是在與真正的而不是偽造的服務(wù)器通話);
(2) 客戶端認證(服務(wù)器知道它們是在與真正的而不是偽造的客戶端通話);
(3) 完整性(客戶端和服務(wù)器的數(shù)據(jù)不會被修改);
(4) 加密(客戶端和服務(wù)器的對話是私密的，無需擔心被竊聽);
(5) 效率(一個運行的足夠快的算法，以便低端的客戶端和服務(wù)器使用);
(6) 普適性(基本上所有的客戶端和服務(wù)器都支持這些協(xié)議);
2.HTTPS的關(guān)鍵技術(shù)
在這樣的需求背景下，HTTPS技術(shù)誕生了。HTTPS協(xié)議的主要功能基本都依賴于TLS/SSL協(xié)議，提供了身份驗證、信息加密和完整性校驗的功能，可以解決HTTP存在的安全問題。本節(jié)就重點探討一下HTTPS協(xié)議的幾個關(guān)鍵技術(shù)點。
(1) 加密技術(shù)
加密算法一般分為兩種：
對稱加密：加密與解密的密鑰相同。以DES算法為代表;
非對稱加密：加密與解密的密鑰不相同。以RSA算法為代表;
對稱加密強度非常高，一般破解不了，但存在一個很大的問題就是無法安全地生成和保管密鑰，假如客戶端和服務(wù)器之間每次會話都使用固定的、相同的密鑰加密和解密，肯定存在很大的安全隱患。
在非對稱密鑰交換算法出現(xiàn)以前，對稱加密一個很大的問題就是不知道如何安全生成和保管密鑰。非對稱密鑰交換過程主要就是為了解決這個問題，使密鑰的生成和使用更加安全。但同時也是HTTPS性能和速度嚴重降低的“罪魁禍首”。
HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制，在交換密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式。
(2) 身份驗證--證明公開密鑰正確性的證書
非對稱加密最大的一個問題，就是無法證明公鑰本身就是貨真價實的公鑰。比如，正準備和某臺服務(wù)器建立公開密鑰加密方式下的通信時，如何證明收到的公開密鑰就是原本預想的那臺服務(wù)器發(fā)行的公開密鑰?；蛟S在公開密鑰傳輸途中，真正的公開密鑰已經(jīng)被攻擊者替換掉了。
如果不驗證公鑰的可靠性，至少會存在如下的兩個問題：中間人攻擊和信息抵賴。
為了解決上述問題，可以使用由數(shù)字證書認證機構(gòu)(CA，Certificate Authority)和其相關(guān)機關(guān)頒發(fā)的公開密鑰證書。
CA使用具體的流程如下：
(1) 服務(wù)器的運營人員向數(shù)字證書認證機構(gòu)(CA)提出公開密鑰的申請;
(2) CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等;
(3) 如果信息審核通過，CA會對已申請的公開密鑰做數(shù)字簽名，然后分配這個已簽名的公開密鑰，并將該公開密鑰放入公鑰證書后綁定在一起。 證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發(fā)機構(gòu)CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名; 簽名的產(chǎn)生算法：首先，使用散列函數(shù)計算公開的明文信息的信息摘要，然后，采用CA的私鑰對信息摘要進行加密，密文即簽名;
(4) 客戶端在HTTPS握手階段向服務(wù)器發(fā)出請求，要求服務(wù)器返回證書文件;
(5) 客戶端讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要，然后，利用對應CA的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即公鑰合法;
(6) 客戶端然后驗證證書相關(guān)的域名信息、有效時間等信息;
(7) 客戶端會內(nèi)置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對應CA的證書，證書也會被判定非法。
在這個過程注意幾點：
(1) 申請證書不需要提供私鑰，確保私鑰永遠只能被服務(wù)器掌握;
(2) 證書的合法性仍然依賴于非對稱加密算法，證書主要是增加了服務(wù)器信息以及簽名;
(3) 內(nèi)置CA對應的證書稱為根證書;頒發(fā)者和使用者相同，自己為自己簽名，叫自簽名證書;
(4) 證書=公鑰+申請者與頒發(fā)者信息+簽名;
3.HTTPS協(xié)議原理
(1) HTTPS的歷史
HTTPS協(xié)議歷史簡介：
- (1) SSL協(xié)議的第一個版本由Netscape公司開發(fā)，但這個版本從未發(fā)布過;
- (2) SSL協(xié)議第二版于1994年11月發(fā)布。第一次部署是在Netscape Navigator1.1瀏覽器上，發(fā)行于1995年3月;
- (3) SSL 3于1995年年底發(fā)布，雖然名稱與早先的協(xié)議版本相同，但SSL3是完全重新設(shè)計的協(xié)議，該設(shè)計一直沿用到今天。
- (4) TLS 1.0于1999年1月問世，與SSL 3相比，版本修改并不大;
- (5) 2006年4月，下一個版本TLS 1.1才問世，僅僅修復了一些關(guān)鍵的安全問題;
- (6) 2008年8月，TLS1.2發(fā)布。該版本添加了對已驗證加密的支持，并且基本上刪除了協(xié)議說明中所有硬編碼的安全基元，使協(xié)議完全彈性化;
(2) 協(xié)議實現(xiàn)
宏觀上，TLS以記錄協(xié)議(record protocol)實現(xiàn)。記錄協(xié)議負責在傳輸連接上交換所有的底層消息，并可以配置加密。每一條TLS記錄以一個短標頭起始。標頭包含記錄內(nèi)容的類型(或子協(xié)議)、協(xié)議版本和長度。消息數(shù)據(jù)緊跟在標頭之后，如下圖所示：
TLS的主規(guī)格說明書定義了四個核心子協(xié)議：
- 握手協(xié)議(handshake protocol);
- 密鑰規(guī)格變更協(xié)議(change cipher spec protocol);
- 應用數(shù)據(jù)協(xié)議(application data protocol);
- 警報協(xié)議(alert protocol);
(3) 握手協(xié)議
握手是TLS協(xié)議中最精密復雜的部分。在這個過程中，通信雙方協(xié)商連接參數(shù)，并且完成身份驗證。根據(jù)使用的功能的不同，整個過程通常需要交換6~10條消息。根據(jù)配置和支持的協(xié)議擴展的不同，交換過程可能有許多變種。在使用中經(jīng)?？梢杂^察到以下三種流程：
- (1) 完整的握手，對服務(wù)器進行身份驗證(單向驗證，最常見);
- (2) 對客戶端和服務(wù)器都進行身份驗證的握手(雙向驗證);
- (3) 恢復之前的會話采用的簡短握手;
(4) 單向驗證的握手流程
本節(jié)以QQ郵箱的登錄過程為例，通過抓包來對單向驗證的握手流程進行分析。單向驗證的一次完整的握手流程如下所示：
主要分為四個步驟：
- (1) 交換各自支持的功能，對需要的連接參數(shù)達成一致;
- (2) 驗證出示的證書，或使用其他方式進行身份驗證;
- (3) 對將用于保護會話的共享主密鑰達成一致;
- (4) 驗證握手消息是否被第三方團體修改;
下面對這一過程進行詳細的分析。
1.ClientHello
在握手流程中，ClientHello是第一條消息。這條消息將客戶端的功能和選擇項傳送給服務(wù)器。包含客戶端支持的SSL的指定版本、加密組件(Cipher Suite)列表(所使用的加密算法及密鑰長度等)。
2.ServerHello
??ServerHello消息將服務(wù)器選擇的連接參數(shù)傳送回客戶端。這個消息的結(jié)構(gòu)與ClientHello類似，只是每個字段只包含一個選項。服務(wù)器的加密組件內(nèi)容以及壓縮方法等都是從接收到的客戶端加密組件內(nèi)篩選出來的。
3.Certificate
%
名稱欄目：HTTPS原理淺析及其在Android中的使用
標題來源：http://www.dlmjj.cn/article/dpcoegh.html
