* 本文作者：HPT @Dragon團(tuán)隊(duì)，本文屬FreeBuf原創(chuàng)獎(jiǎng)勵(lì)計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載
本篇主要為大家?guī)?lái)的是HTTPS的內(nèi)容，相信大家已經(jīng)從各種途徑看過(guò)不少關(guān)于HTTPS的精彩內(nèi)容，在下在這里只是抱著一顆菜鳥(niǎo)學(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ù)在傳輸過(guò)程中的隱私，在傳輸過(guò)程中是無(wú)法窺探到傳輸?shù)拿魑臄?shù)據(jù)的，但是事無(wú)絕對(duì)，想要攻擊基于HTTPS傳輸?shù)耐ㄐ乓膊皇菦](méi)有可能。（網(wǎng)上的例子有很多，最近BLACKHAT大會(huì)上的兩位研究員也研究出了很炫的攻擊手段；但是，本人也還沒(méi)把這個(gè)技術(shù)手段研究透，不敢在大神們面前獻(xiàn)丑）本篇主要講述HTTPS的安全性以及怎么達(dá)到這種安全性的細(xì)節(jié)，關(guān)于HTTPS中的密碼學(xué)知識(shí)、證書(shū)知識(shí)暫時(shí)會(huì)一帶而過(guò)，因?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在傳輸過(guò)程中的現(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ù)的過(guò)程中，HTTPS對(duì)數(shù)據(jù)做了完全加密，他兩都是處于TCP傳輸層之上的，廢話不多說(shuō)，先看幾張圖來(lái)認(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)求上來(lái)說(shuō)，一個(gè)是HTTP請(qǐng)求，能看到請(qǐng)求的報(bào)頭；而另外一個(gè)就是SSL/TLS請(qǐng)求，沒(méi)有任何信息；在數(shù)據(jù)包中也可以顯而易見(jiàn)這個(gè)區(qū)別，HTTP數(shù)據(jù)包是完全裸露的，你可以看到任何信息，而HTTPS數(shù)據(jù)包只是二進(jìn)制加密后的數(shù)據(jù)，看不到任何有用信息。
2. HTTPS為什么比HTTP安全呢
上面的步驟 已經(jīng)向大家證明了HTTPS相比于HTTP的安全性，那么接下來(lái)仔細(xì)分析下到底為什么會(huì)這樣，帶著這個(gè)疑問(wèn)繼續(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ù)的安全，主要依賴證書(shū)檢測(cè)、非對(duì)稱加密、對(duì)稱加密、數(shù)據(jù)完整性校驗(yàn)以及隨機(jī)數(shù)這5個(gè)密碼學(xué)的基礎(chǔ)知識(shí)，從而構(gòu)建出一個(gè)完整可信的傳輸鏈。其實(shí)說(shuō)到這里，大家心中的疑惑應(yīng)該跟我是一樣的，用了這些加密算法又怎么樣呢，為什么一定是安全的呢，我也可以在傳輸?shù)倪^(guò)程中對(duì)數(shù)據(jù)進(jìn)行自行加密呀，用最高深的加密方法不就行了嗎？不要急，且行且看，下面這張圖是基于SSL協(xié)議的五層網(wǎng)絡(luò)模型圖，
圖5 SSL協(xié)議網(wǎng)絡(luò)模型圖
圖5中在原來(lái)的五層模型中嵌入了SSL/TSL層，用來(lái)為傳輸中的數(shù)據(jù)進(jìn)行加密的服務(wù)，從這張圖上可以看出，當(dāng)數(shù)據(jù)從HTTP層往下流的時(shí)候經(jīng)過(guò)SSL層的加密服務(wù)，然后再把數(shù)據(jù)組合到TCP層進(jìn)而傳輸，而當(dāng)數(shù)據(jù)從另一端的TCP層向上流的時(shí)候，將加密后的數(shù)據(jù)往上交付，SSL層會(huì)為其解密，然后再交付給HTTP層。
概括的講，就是一個(gè)端到端的加、解密流程而已，圖6通過(guò)剖析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ù)器證書(shū)返回給客戶端。
步驟 3. 客戶端主動(dòng)再生成一個(gè)隨機(jī)數(shù)C，開(kāi)始生成秘鑰，這個(gè)生成秘鑰的算法是客戶端跟服務(wù)器端共享的，因?yàn)橹皡f(xié)商的時(shí)候已經(jīng)確定了算法了，生成秘鑰后就可以加密一段內(nèi)容，試著跟服務(wù)區(qū)通信了，這個(gè)內(nèi)容是經(jīng)過(guò)先散列，散列后將原內(nèi)容和散列集一起用剛才的密鑰加密；接著用服務(wù)器端證書(shū)中的公鑰對(duì)隨機(jī)數(shù)C加密。
步驟 4. 然后把加密過(guò)的內(nèi)容和加密好的隨機(jī)數(shù)一起發(fā)向服務(wù)器端。
步驟 5. 服務(wù)器用私鑰解密得到隨機(jī)數(shù)C，這樣服務(wù)器端也同時(shí)擁有了隨機(jī)數(shù)A、B、C，即刻生成密鑰，再用密鑰對(duì)加密的內(nèi)容進(jìn)行解密，然后解開(kāi)后對(duì)其中的明文內(nèi)容進(jìn)行散列，與客戶端發(fā)過(guò)來(lái)的散列值進(jìn)行比較，如果相等，說(shuō)明就是客戶端發(fā)過(guò)來(lái)的，通信成功。
步驟 6. 用步驟3中同樣的方式發(fā)一段加密過(guò)的內(nèi)容給客戶端。
步驟 7. 用步驟5一樣的方式對(duì)服務(wù)器發(fā)來(lái)的內(nèi)容進(jìn)行驗(yàn)證。
步驟 8. 客戶端確定開(kāi)始通信。
步驟 9. 服務(wù)端確定開(kāi)始通信。
3. HTTPS在實(shí)際生活中的運(yùn)用
本人是非常喜歡購(gòu)物的，那么我們就以大家經(jīng)常購(gòu)物的“淘寶”網(wǎng)為例，來(lái)看下淘寶采用的HTTPS協(xié)議是怎樣的呢？
圖7
好了，現(xiàn)在來(lái)分析下淘寶的數(shù)據(jù)傳輸?shù)囊粋€(gè)簡(jiǎn)單的驗(yàn)證機(jī)制吧，就拿圖7中紅圈圈出來(lái)的部分來(lái)說(shuō)明，第一條“Client Hello”的這條消息，我們看到是從本地發(fā)往一個(gè)IP為140.205.174.1的請(qǐng)求，那么這個(gè)140.205.174.1通過(guò)驗(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ā)送一些其他信息，我們可以展開(kāi)編號(hào)為215的這條數(shù)據(jù)包來(lái)看一下，如圖8，
圖8
從圖8中你可以看到，服務(wù)器告訴客戶端，我支持的TLS的協(xié)議版本是1.2同時(shí)也傳過(guò)來(lái)一個(gè)隨機(jī)數(shù)并且選擇了算法TLS_RSA_WITH_AES_128_GCM_SHA256，好了接下來(lái)可以看到編號(hào)為216的數(shù)據(jù)包，傳遞的信息跟前面是一樣的，這里承認(rèn)網(wǎng)絡(luò)學(xué)的不夠好，也不知道是啥原因，猜測(cè)是TCP的可靠性連接導(dǎo)致的重傳，只是猜測(cè)哦，未證實(shí)，如果有大牛明白的，還望解答。看到這里，不知道你是否跟我有一個(gè)一樣的疑問(wèn)，在前面的SSL協(xié)議的分析中不是說(shuō)好了服務(wù)端要傳遞證書(shū)過(guò)來(lái)給客戶端做驗(yàn)證的嗎，怎么證書(shū)連個(gè)影都沒(méi)有呢？如果你能想到這個(gè)，說(shuō)明前面的知識(shí)消化了，看下圖9,
圖9
圖9中可以看到紅圈圈出來(lái)的，一個(gè)“Client Hello”消息的數(shù)據(jù)包，一個(gè)似曾相識(shí)的IP地址140.205.248.25又出現(xiàn)了，想都不用想，這又是阿里的另外一臺(tái)服務(wù)器了，接著你看到編號(hào)為195的數(shù)據(jù)包，你就恍然大悟了，原來(lái)Certificate，也就是傳說(shuō)中的證書(shū)在這里呀，于是可以展開(kāi)這個(gè)數(shù)據(jù)包，圖10所示，
圖10
正如圖10所示，當(dāng)你展開(kāi)數(shù)據(jù)包的時(shí)候，你已經(jīng)看到了Alibaba這幾個(gè)關(guān)鍵的字母，不錯(cuò)，這就是淘寶的證書(shū)信息，這下就解決了上面的疑問(wèn)，為什么在上面剛才的那段通信中，服務(wù)端沒(méi)有向本地發(fā)送證書(shū)信息呢，就是因?yàn)樵谶@之前已經(jīng)發(fā)送過(guò)證書(shū)進(jìn)行驗(yàn)證了，所以就不再需要了，但是還是有個(gè)問(wèn)題，細(xì)心的你可以發(fā)現(xiàn)編號(hào)為195的數(shù)據(jù)包是IP為124.14.2.241這個(gè)主機(jī)返回過(guò)來(lái)的，通過(guò)查證，這不是淘寶服務(wù)器的地址呀，為何是由它來(lái)發(fā)送過(guò)來(lái)呢，這個(gè)問(wèn)題同樣，在這里還是無(wú)法正確地回答你，網(wǎng)絡(luò)學(xué)的不好只能默默哭泣了，還是希望大牛能夠告知呀。
好啦，講到這里，我的基本目的也已經(jīng)達(dá)到了，不管怎么樣，我們都親眼見(jiàn)識(shí)了下淘寶是怎么玩HTTPS這個(gè)好東西的，其中還是有不少疑問(wèn)的，除了剛才那兩個(gè)網(wǎng)絡(luò)問(wèn)題之外，其實(shí)回過(guò)頭還是可以仔細(xì)對(duì)照數(shù)據(jù)包的分發(fā)流程與順序來(lái)思考下為何是這樣的一個(gè)過(guò)程？如果是我自己搭建服務(wù)器，也是同樣的過(guò)程嗎？“革命尚未成功，同志仍需努力”呀！
4. 本地化測(cè)試HTTPS和HTTP在傳輸過(guò)程中的現(xiàn)象
好了，通過(guò)前面3個(gè)部分的了解，對(duì)HTTPS應(yīng)該有了一個(gè)還算不錯(cuò)的認(rèn)識(shí)吧，那么現(xiàn)在就差最后一步了，HTTPS傳輸過(guò)程中的數(shù)據(jù)是看不到的，除非你有密鑰，要不你是絕對(duì)不可能將密文變成明文的；是的，別人網(wǎng)站的是看不到，但是為了獲得一定的成就感、虛榮心，我們何不自己搭建一個(gè)小的web系統(tǒng)來(lái)測(cè)試下HTTPS，相信大家也知道了，我一直用的是WIRESHARK來(lái)抓取數(shù)據(jù)包的，下面的解密數(shù)據(jù)包也還是會(huì)用這個(gè)工具來(lái)做，開(kāi)始啦！
下面首先我們要搭建一個(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的方式來(lái)訪問(wèn)下本地的這個(gè)網(wǎng)站，圖11所示，
圖11
這里會(huì)有個(gè)紅叉叉，是因?yàn)檫@個(gè)HTTPS的證書(shū)是自己生成的，并沒(méi)有權(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)地址。
下面開(kāi)始抓包。如圖12所示，
圖12
很顯然，數(shù)據(jù)全部被加密了，什么都看不到了，接下來(lái)用我們自己生成的秘鑰來(lái)解包吧！具體在WIRESHARK中配置SSL的解密密鑰的步驟這里不會(huì)詳細(xì)講。當(dāng)配置好秘鑰后，再次用WIRESHARK抓包，就會(huì)出現(xiàn)圖13的效果，
圖13
可以看到，用密鑰解密數(shù)據(jù)包后，HTTP所有的報(bào)頭都是可以獲取到的。這里關(guān)于用密鑰解密數(shù)據(jù)包的時(shí)候會(huì)有一個(gè)比較棘手的問(wèn)題，就是關(guān)于服務(wù)端選取算法套的問(wèn)題，詳細(xì)地解釋下這個(gè)問(wèn)題，當(dāng)時(shí)也是被困擾了好久的。客戶端首先會(huì)與服務(wù)端協(xié)商，服務(wù)端會(huì)把自己的決定告訴客戶端，這個(gè)過(guò)程如圖14所示，
圖14
圖14描述的是客戶端發(fā)送請(qǐng)求到服務(wù)器端，同時(shí)客戶端會(huì)把自己支持的算法全部發(fā)給服務(wù)器，又服務(wù)器來(lái)選擇使用什么算法進(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è)散列算法，主要用來(lái)防止數(shù)據(jù)被篡改。那么為什么服務(wù)器會(huì)選擇這個(gè)算法呢，這是可控的嗎？回答是：可控的，就在服務(wù)端的配置文件中配置的一個(gè)算法支持序列，如圖 16（以Tomcat為例），
圖16
這是在Tomcat的Server.xml文件中配置HTTPS服務(wù)的時(shí)候所選取的算法套件，一旦配置完成后，以后服務(wù)器就會(huì)從這些可選的并且客戶端中存在的算法中選擇，這些都沒(méi)什么，但是如果你在服務(wù)不配置ciphers這個(gè)屬性的話，問(wèn)題就來(lái)了，服務(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é)商生成的一種算法，所以并不能用我們自己生成的秘鑰來(lái)解密，因此這種情況下，是無(wú)法解密HTTPS數(shù)據(jù)包的，至于具體的算法特性以及實(shí)現(xiàn)不在這里具體講述，有興趣的可以自己去查閱，目前我也還未嘗試過(guò)解密這種算法加密的數(shù)據(jù)，只能貢獻(xiàn)給大家這些了。
* 本文作者：HPT @Dragon團(tuán)隊(duì)，本文屬FreeBuf原創(chuàng)獎(jiǎng)勵(lì)計(jì)劃，未經(jīng)許可禁止轉(zhuǎn)載
京公網(wǎng)安備 11010502049343號(hào)