* 本文作者：HPT @Dragon團(tuán)隊(duì)，本文屬FreeBuf原創(chuàng)獎(jiǎng)勵(lì)計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載

本篇主要為大家?guī)淼氖荋TTPS的內(nèi)容，相信大家已經(jīng)從各種途徑看過不少關(guān)于HTTPS的精彩內(nèi)容，在下在這里只是抱著一顆菜鳥學(xué)習(xí)的心跟大神們交流一下，也希望能夠給和我一樣水平的人一點(diǎn)饋贈(zèng)，在追求安全的道路上，有很多美好的風(fēng)景，那下面就讓我?guī)憧纯次已壑械腍TTPS吧，看看你是否和我理解的一樣呢！

當(dāng)今互聯(lián)網(wǎng)，基于B/S架構(gòu)的應(yīng)用大部分都運(yùn)用了HTTPS這個(gè)技術(shù)，其主要目的就是保護(hù)數(shù)據(jù)在傳輸過程中的隱私，在傳輸過程中是無(wú)法窺探到傳輸?shù)拿魑臄?shù)據(jù)的，但是事無(wú)絕對(duì)，想要攻擊基于HTTPS傳輸?shù)耐ㄐ乓膊皇菦]有可能。（網(wǎng)上的例子有很多，最近BLACKHAT大會(huì)上的兩位研究員也研究出了很炫的攻擊手段；但是，本人也還沒把這個(gè)技術(shù)手段研究透，不敢在大神們面前獻(xiàn)丑）本篇主要講述HTTPS的安全性以及怎么達(dá)到這種安全性的細(xì)節(jié)，關(guān)于HTTPS中的密碼學(xué)知識(shí)、證書知識(shí)暫時(shí)會(huì)一帶而過，因?yàn)檫@又將是一個(gè)非常大的話題，不是一句兩句話能講清楚的哦！

下面主要帶著以下四個(gè)疑慮去認(rèn)識(shí)HTTPS：

1. HTTPS和HTTP的關(guān)系

2. HTTPS為什么比HTTP安全呢

3. HTTPS在實(shí)際生活中的運(yùn)用

4. 本地化測(cè)試HTTPS和HTTP在傳輸過程中的現(xiàn)象

1. HTTPS和HTTP的關(guān)系

HTTP全稱是超文本傳輸協(xié)議，基于網(wǎng)絡(luò)7層模型中的最上層的應(yīng)用層協(xié)議，而HTTPS則是一種加密的超文本傳輸協(xié)議，它和HTTP在協(xié)議的本質(zhì)上是一樣的，多了一個(gè)“S”，差異就在于對(duì)于數(shù)據(jù)在傳輸數(shù)據(jù)的過程中，HTTPS對(duì)數(shù)據(jù)做了完全加密，他兩都是處于TCP傳輸層之上的，廢話不多說，先看幾張圖來認(rèn)識(shí)下HTTP和HTTPS吧：

HTTP請(qǐng)求：

圖1

HTTP數(shù)據(jù)包：

圖2

HTTPS請(qǐng)求：

圖3

HTTPS數(shù)據(jù)包：

圖4

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

2. HTTPS為什么比HTTP安全呢

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

HTTPS之所以能夠?qū)鬏數(shù)臄?shù)據(jù)進(jìn)行加密，主要是在TCP協(xié)議層和HTTP協(xié)議層中間架起了一層SSL/TSL協(xié)議層，這一層能夠把在網(wǎng)絡(luò)中傳輸?shù)臄?shù)據(jù)進(jìn)行有效的加密。SSL（Security Socket Layer）這一層能夠保持?jǐn)?shù)據(jù)的安全，主要依賴證書檢測(cè)、非對(duì)稱加密、對(duì)稱加密、數(shù)據(jù)完整性校驗(yàn)以及隨機(jī)數(shù)這5個(gè)密碼學(xué)的基礎(chǔ)知識(shí)，從而構(gòu)建出一個(gè)完整可信的傳輸鏈。其實(shí)說到這里，大家心中的疑惑應(yīng)該跟我是一樣的，用了這些加密算法又怎么樣呢，為什么一定是安全的呢，我也可以在傳輸?shù)倪^程中對(duì)數(shù)據(jù)進(jìn)行自行加密呀，用最高深的加密方法不就行了嗎？不要急，且行且看，下面這張圖是基于SSL協(xié)議的五層網(wǎng)絡(luò)模型圖，

圖5 SSL協(xié)議網(wǎng)絡(luò)模型圖

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

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

圖6 SSL工作機(jī)制

步驟 1.Client Hello – 客戶端發(fā)送所支持的 SSL/TLS 最高協(xié)議版本號(hào)、所支持的加密算法集合及壓縮方法集合和隨機(jī)數(shù)A等信息給服務(wù)器端。

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

步驟 3. 客戶端主動(dòng)再生成一個(gè)隨機(jī)數(shù)C，開始生成秘鑰，這個(gè)生成秘鑰的算法是客戶端跟服務(wù)器端共享的，因?yàn)橹皡f(xié)商的時(shí)候已經(jīng)確定了算法了，生成秘鑰后就可以加密一段內(nèi)容，試著跟服務(wù)區(qū)通信了，這個(gè)內(nèi)容是經(jīng)過先散列，散列后將原內(nèi)容和散列集一起用剛才的密鑰加密；接著用服務(wù)器端證書中的公鑰對(duì)隨機(jī)數(shù)C加密。

步驟 4. 然后把加密過的內(nèi)容和加密好的隨機(jī)數(shù)一起發(fā)向服務(wù)器端。

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

步驟 6. 用步驟3中同樣的方式發(fā)一段加密過的內(nèi)容給客戶端。

步驟 7. 用步驟5一樣的方式對(duì)服務(wù)器發(fā)來的內(nèi)容進(jìn)行驗(yàn)證。

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

步驟 9. 服務(wù)端確定開始通信。

3. HTTPS在實(shí)際生活中的運(yùn)用

本人是非常喜歡購(gòu)物的，那么我們就以大家經(jīng)常購(gòu)物的“淘寶”網(wǎng)為例，來看下淘寶采用的HTTPS協(xié)議是怎樣的呢？

圖7

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

圖8

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

圖9

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

圖10

正如圖10所示，當(dāng)你展開數(shù)據(jù)包的時(shí)候，你已經(jīng)看到了Alibaba這幾個(gè)關(guān)鍵的字母，不錯(cuò)，這就是淘寶的證書信息，這下就解決了上面的疑問，為什么在上面剛才的那段通信中，服務(wù)端沒有向本地發(fā)送證書信息呢，就是因?yàn)樵谶@之前已經(jīng)發(fā)送過證書進(jìn)行驗(yàn)證了，所以就不再需要了，但是還是有個(gè)問題，細(xì)心的你可以發(fā)現(xiàn)編號(hào)為195的數(shù)據(jù)包是IP為124.14.2.241這個(gè)主機(jī)返回過來的，通過查證，這不是淘寶服務(wù)器的地址呀，為何是由它來發(fā)送過來呢，這個(gè)問題同樣，在這里還是無(wú)法正確地回答你，網(wǎng)絡(luò)學(xué)的不好只能默默哭泣了，還是希望大牛能夠告知呀。

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

4. 本地化測(cè)試HTTPS和HTTP在傳輸過程中的現(xiàn)象

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

下面首先我們要搭建一個(gè)符合我們測(cè)試標(biāo)準(zhǔn)的系統(tǒng)，在這里不會(huì)詳細(xì)講搭建系統(tǒng)的步驟及詳情，這不是本文的重點(diǎn)，網(wǎng)上例子很多，下面就會(huì)以我本地搭建的一個(gè)小型Web網(wǎng)站為例（Tomcat7、JDK7、OpenSSL0.9.8）。

當(dāng)一切都配置完成后，以HTTPS的方式來訪問下本地的這個(gè)網(wǎng)站，圖11所示，

圖11

這里會(huì)有個(gè)紅叉叉，是因?yàn)檫@個(gè)HTTPS的證書是自己生成的，并沒有權(quán)威機(jī)構(gòu)（CA）的授權(quán)、認(rèn)證，所以是屬于不安全的范疇的。下面就用對(duì)其進(jìn)行抓包，這里要注意了，如果是用WIRESHARK進(jìn)行本地抓包，是要手動(dòng)建立一條本地路由的，否則它是默認(rèn)不會(huì)抓取本地的數(shù)據(jù)包的，在WINDOW下可以用以下命令：

這個(gè)192.168.5.118就是你的本地局域網(wǎng)IP地址，255.255.255.255這個(gè)掩碼是固定值，而192.168.5.1就是你的IP地址對(duì)應(yīng)的網(wǎng)關(guān)地址。

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

圖12

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

圖13

可以看到，用密鑰解密數(shù)據(jù)包后，HTTP所有的報(bào)頭都是可以獲取到的。這里關(guān)于用密鑰解密數(shù)據(jù)包的時(shí)候會(huì)有一個(gè)比較棘手的問題，就是關(guān)于服務(wù)端選取算法套的問題，詳細(xì)地解釋下這個(gè)問題，當(dāng)時(shí)也是被困擾了好久的?？蛻舳耸紫葧?huì)與服務(wù)端協(xié)商，服務(wù)端會(huì)把自己的決定告訴客戶端，這個(gè)過程如圖14所示，

圖14

圖14描述的是客戶端發(fā)送請(qǐng)求到服務(wù)器端，同時(shí)客戶端會(huì)把自己支持的算法全部發(fā)給服務(wù)器，又服務(wù)器來選擇使用什么算法進(jìn)行后續(xù)的通信加密數(shù)據(jù)，看圖15，

圖15

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

圖16

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

圖17

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

* 本文作者：HPT @Dragon團(tuán)隊(duì)，本文屬FreeBuf原創(chuàng)獎(jiǎng)勵(lì)計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載