新手教程：HTTPS初探初探

* 本文作者：HPT @Dragon團隊，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載

本篇主要為大家帶來的是HTTPS的內容，相信大家已經從各種途徑看過不少關于HTTPS的精彩內容，在下在這里只是抱著一顆菜鳥學習的心跟大神們交流一下，也希望能夠給和我一樣水平的人一點饋贈，在追求安全的道路上，有很多美好的風景，那下面就讓我帶你看看我眼中的HTTPS吧，看看你是否和我理解的一樣呢！

當今互聯網，基于B/S架構的應用大部分都運用了HTTPS這個技術，其主要目的就是保護數據在傳輸過程中的隱私，在傳輸過程中是無法窺探到傳輸的明文數據的，但是事無絕對，想要攻擊基于HTTPS傳輸的通信也不是沒有可能。（網上的例子有很多，最近BLACKHAT大會上的兩位研究員也研究出了很炫的攻擊手段；但是，本人也還沒把這個技術手段研究透，不敢在大神們面前獻丑）本篇主要講述HTTPS的安全性以及怎么達到這種安全性的細節，關于HTTPS中的密碼學知識、證書知識暫時會一帶而過，因為這又將是一個非常大的話題，不是一句兩句話能講清楚的哦！

下面主要帶著以下四個疑慮去認識HTTPS：

1.HTTPS和HTTP的關系

2.HTTPS為什么比HTTP安全呢

3.HTTPS在實際生活中的運用

4.本地化測試HTTPS和HTTP在傳輸過程中的現象

1.HTTPS和HTTP的關系

HTTP全稱是超文本傳輸協議，基于網絡7層模型中的最上層的應用層協議，而HTTPS則是一種加密的超文本傳輸協議，它和HTTP在協議的本質上是一樣的，多了一個“S”，差異就在于對于數據在傳輸數據的過程中，HTTPS對數據做了完全加密，他兩都是處于TCP傳輸層之上的，廢話不多說，先看幾張圖來認識下HTTP和HTTPS吧：

HTTP請求：

圖1

HTTP數據包：

圖2

HTTPS請求：

圖3

HTTPS數據包：

圖4

從上面的4張圖，大家可以看到HTTP與HTTPS大概的區別了吧，首先從請求上來說，一個是HTTP請求，能看到請求的報頭；而另外一個就是SSL/TLS請求，沒有任何信息；在數據包中也可以顯而易見這個區別，HTTP數據包是完全裸露的，你可以看到任何信息，而HTTPS數據包只是二進制加密后的數據，看不到任何有用信息。

2. HTTPS為什么比HTTP安全呢

上面的步驟已經向大家證明了HTTPS相比于HTTP的安全性，那么接下來仔細分析下到底為什么會這樣，帶著這個疑問繼續往下看。

HTTPS之所以能夠對傳輸的數據進行加密，主要是在TCP協議層和HTTP協議層中間架起了一層SSL/TSL協議層，這一層能夠把在網絡中傳輸的數據進行有效的加密。SSL（Security Socket Layer）這一層能夠保持數據的安全，主要依賴證書檢測、非對稱加密、對稱加密、數據完整性校驗以及隨機數這5個密碼學的基礎知識，從而構建出一個完整可信的傳輸鏈。其實說到這里，大家心中的疑惑應該跟我是一樣的，用了這些加密算法又怎么樣呢，為什么一定是安全的呢，我也可以在傳輸的過程中對數據進行自行加密呀，用最高深的加密方法不就行了嗎？不要急，且行且看，下面這張圖是基于SSL協議的五層網絡模型圖，

圖5 SSL協議網絡模型圖

圖5中在原來的五層模型中嵌入了SSL/TSL層，用來為傳輸中的數據進行加密的服務，從這張圖上可以看出，當數據從HTTP層往下流的時候經過SSL層的加密服務，然后再把數據組合到TCP層進而傳輸，而當數據從另一端的TCP層向上流的時候，將加密后的數據往上交付，SSL層會為其解密，然后再交付給HTTP層。

概括的講，就是一個端到端的加、解密流程而已，圖6通過剖析SSL的工作機制就會向你解釋這種安全性的原因與細節，

圖6 SSL工作機制

步驟 1. Client Hello – 客戶端發送所支持的 SSL/TLS 最高協議版本號、所支持的加密算法集合及壓縮方法集合和隨機數A等信息給服務器端。

步驟 2. Server Hello – 服務器端收到客戶端信息后，選定雙方都能夠支持的 SSL/TLS 協議版本和加密方法及壓縮方法、 隨機數B和服務器證書返回給客戶端。

步驟 3. 客戶端主動再生成一個隨機數C，開始生成秘鑰，這個生成秘鑰的算法是客戶端跟服務器端共享的，因為之前協商的時候已經確定了算法了，生成秘鑰后就可以加密一段內容，試著跟服務區通信了，這個內容是經過先散列，散列后將原內容和散列集一起用剛才的密鑰加密；接著用服務器端證書中的公鑰對隨機數C加密。

步驟 4. 然后把加密過的內容和加密好的隨機數一起發向服務器端。

步驟 5. 服務器用私鑰解密得到隨機數C，這樣服務器端也同時擁有了隨機數A、B、C，即刻生成密鑰，再用密鑰對加密的內容進行解密，然后解開后對其中的明文內容進行散列，與客戶端發過來的散列值進行比較，如果相等，說明就是客戶端發過來的，通信成功。

步驟 6. 用步驟3中同樣的方式發一段加密過的內容給客戶端。

步驟 7. 用步驟5一樣的方式對服務器發來的內容進行驗證。

步驟 8. 客戶端確定開始通信。

步驟 9. 服務端確定開始通信。

3. HTTPS在實際生活中的運用

本人是非常喜歡購物的，那么我們就以大家經常購物的“淘寶”網為例，來看下淘寶采用的HTTPS協議是怎樣的呢？

圖7

好了，現在來分析下淘寶的數據傳輸的一個簡單的驗證機制吧，就拿圖7中紅圈圈出來的部分來說明，第一條“Client Hello”的這條消息，我們看到是從本地發往一個IP為140.205.174.1的請求，那么這個140.205.174.1通過驗證，證明就是淘寶的一臺服務器而已，這條消息表明本機正在向淘寶網發起一個請求；于是淘寶網回應了一個“Server Hello”的消息，看到回復的IP地址是140.205.248.253，怎么不是140.205.174.1呢?很容易可以回答你，淘寶每天有那么多的請求量，不可能所有數據都是放在一個服務器吧，可以想一想負載均衡、安全性方面的思路，那這里140.205.248.253就是淘寶的另外一臺服務器咯，它不僅回復了“Server Hello”，而且向你發送一些其他信息，我們可以展開編號為215的這條數據包來看一下，如圖8，

圖8

從圖8中你可以看到，服務器告訴客戶端，我支持的TLS的協議版本是1.2同時也傳過來一個隨機數并且選擇了算法TLS_RSA_WITH_AES_128_GCM_SHA256，好了接下來可以看到編號為216的數據包，傳遞的信息跟前面是一樣的，這里承認網絡學的不夠好，也不知道是啥原因，猜測是TCP的可靠性連接導致的重傳，只是猜測哦，未證實，如果有大牛明白的，還望解答。看到這里，不知道你是否跟我有一個一樣的疑問，在前面的SSL協議的分析中不是說好了服務端要傳遞證書過來給客戶端做驗證的嗎，怎么證書連個影都沒有呢？如果你能想到這個，說明前面的知識消化了，看下圖9,

圖9

圖9中可以看到紅圈圈出來的，一個“Client Hello”消息的數據包，一個似曾相識的IP地址140.205.248.25又出現了，想都不用想，這又是阿里的另外一臺服務器了，接著你看到編號為195的數據包，你就恍然大悟了，原來Certificate，也就是傳說中的證書在這里呀，于是可以展開這個數據包，圖10所示，

圖10

正如圖10所示，當你展開數據包的時候，你已經看到了Alibaba這幾個關鍵的字母，不錯，這就是淘寶的證書信息，這下就解決了上面的疑問，為什么在上面剛才的那段通信中，服務端沒有向本地發送證書信息呢，就是因為在這之前已經發送過證書進行驗證了，所以就不再需要了，但是還是有個問題，細心的你可以發現編號為195的數據包是IP為124.14.2.241這個主機返回過來的，通過查證，這不是淘寶服務器的地址呀，為何是由它來發送過來呢，這個問題同樣，在這里還是無法正確地回答你，網絡學的不好只能默默哭泣了，還是希望大牛能夠告知呀。

好啦，講到這里，我的基本目的也已經達到了，不管怎么樣，我們都親眼見識了下淘寶是怎么玩HTTPS這個好東西的，其中還是有不少疑問的，除了剛才那兩個網絡問題之外，其實回過頭還是可以仔細對照數據包的分發流程與順序來思考下為何是這樣的一個過程？如果是我自己搭建服務器，也是同樣的過程嗎？“革命尚未成功，同志仍需努力”呀！

4. 本地化測試HTTPS和HTTP在傳輸過程中的現象

好了，通過前面3個部分的了解，對HTTPS應該有了一個還算不錯的認識吧，那么現在就差最后一步了，HTTPS傳輸過程中的數據是看不到的，除非你有密鑰，要不你是絕對不可能將密文變成明文的；是的，別人網站的是看不到，但是為了獲得一定的成就感、虛榮心，我們何不自己搭建一個小的web系統來測試下HTTPS，相信大家也知道了，我一直用的是WIRESHARK來抓取數據包的，下面的解密數據包也還是會用這個工具來做，開始啦！

下面首先我們要搭建一個符合我們測試標準的系統，在這里不會詳細講搭建系統的步驟及詳情，這不是本文的重點，網上例子很多，下面就會以我本地搭建的一個小型Web網站為例（Tomcat7、JDK7、OpenSSL0.9.8）。

當一切都配置完成后，以HTTPS的方式來訪問下本地的這個網站，圖11所示，

圖11

這里會有個紅叉叉，是因為這個HTTPS的證書是自己生成的，并沒有權威機構（CA）的授權、認證，所以是屬于不安全的范疇的。下面就用對其進行抓包，這里要注意了，如果是用WIRESHARK進行本地抓包，是要手動建立一條本地路由的，否則它是默認不會抓取本地的數據包的，在WINDOW下可以用以下命令：

這個192.168.5.118就是你的本地局域網IP地址，255.255.255.255這個掩碼是固定值，而192.168.5.1就是你的IP地址對應的網關地址。

下面開始抓包。如圖12所示，

圖12

很顯然，數據全部被加密了，什么都看不到了，接下來用我們自己生成的秘鑰來解包吧！具體在WIRESHARK中配置SSL的解密密鑰的步驟這里不會詳細講。當配置好秘鑰后，再次用WIRESHARK抓包，就會出現圖13的效果，

圖13

可以看到，用密鑰解密數據包后，HTTP所有的報頭都是可以獲取到的。這里關于用密鑰解密數據包的時候會有一個比較棘手的問題，就是關于服務端選取算法套的問題，詳細地解釋下這個問題，當時也是被困擾了好久的。客戶端首先會與服務端協商，服務端會把自己的決定告訴客戶端，這個過程如圖14所示，

圖14

圖14描述的是客戶端發送請求到服務器端，同時客戶端會把自己支持的算法全部發給服務器，又服務器來選擇使用什么算法進行后續的通信加密數據，看圖15，

圖15

于是，你可以從圖15中看到，服務器端選擇的是TLS_RSA_WITH_AES_128_CBC_SHA這個算法，這個算法就是經典的非對稱加密RSA與對稱加密AES128 CBC模式相結合的加密算法套，SHA是一個散列算法，主要用來防止數據被篡改。那么為什么服務器會選擇這個算法呢，這是可控的嗎？回答是：可控的，就在服務端的配置文件中配置的一個算法支持序列，如圖 16（以Tomcat為例），

圖16

這是在Tomcat的Server.xml文件中配置HTTPS服務的時候所選取的算法套件，一旦配置完成后，以后服務器就會從這些可選的并且客戶端中存在的算法中選擇，這些都沒什么，但是如果你在服務不配置ciphers這個屬性的話，問題就來了，服務端默認采取的算法就會是，圖17中的這個，

圖17

圖17的這個算法TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA算法是基于“Diffie-Hellman”的一個算法，這種方法是一種協商式秘鑰生成算法，是由服務端和客戶端自動自己協商生成的一種算法，所以并不能用我們自己生成的秘鑰來解密，因此這種情況下，是無法解密HTTPS數據包的，至于具體的算法特性以及實現不在這里具體講述，有興趣的可以自己去查閱，目前我也還未嘗試過解密這種算法加密的數據，只能貢獻給大家這些了。

* 本文作者：HPT @Dragon團隊，本文屬FreeBuf原創獎勵計劃，未經許可禁止轉載