一姜性、背景知識

1.1.基本術(shù)語HTTP|HTTPS|SSL|TLS

1.2.HTTP和TCP的關(guān)系，如長連接和短連接等

1.3.加密算法的大概知識(對稱加密和非對稱加密)

1.4.CA證書的用途

二挑庶、基本術(shù)語

2.1、"HTTP"：

是一個專門用來傳輸web內(nèi)容的協(xié)議。

版本歷史：

0.9 ? ?90年代推出時候為0.9版本

1.0 ? ?之后推出了1.0版本 該版本曾被廣泛應(yīng)用過

1.1 ? ?這個 1.1 版本是1995年底開始起草的（技術(shù)文檔是 RFC2068）色瘩，并在1999年正式發(fā)布（技術(shù)文檔是 RFC2616）

2.0 ? ?2015年發(fā)布

2.1.1又跛、響應(yīng)體

響應(yīng)行一般由協(xié)議版本碍拆、狀態(tài)碼及其描述組成 比如 HTTP/1.1 200 OK

其中協(xié)議版本HTTP/1.1或者HTTP/1.0，200就是它的狀態(tài)碼，OK則為它的描述感混。

//常見狀態(tài)碼：

100~199：表示成功接收請求端幼，要求客戶端繼續(xù)提交下一次請求才能完成整個處理過程。

200~299：表示成功接收請求并已完成整個處理過程弧满。常用200

300~399：為完成請求婆跑，客戶需進(jìn)一步細(xì)化請求。例如：請求的資源已經(jīng)移動一個新地址庭呜、常用302(意味著你請求我滑进，我讓你去找別人),307和304(我不給你這個資源，自己拿緩存)

400~499：客戶端的請求有錯誤募谎，常用404(意味著你請求的資源在web服務(wù)器中沒有)403(服務(wù)器拒絕訪問扶关，權(quán)限不夠)

500~599：服務(wù)器端出現(xiàn)錯誤，常用500

2.2数冬、"SSL":

是Secure Sockets Layer的縮寫驮审，翻譯成中文叫做安全套接字層。上世界90年代由網(wǎng)景公司設(shè)計（該公司還發(fā)明了"!!!吉执，js腳本等）

HTTP協(xié)議在傳輸數(shù)據(jù)的時候是明文傳輸?shù)姆枰赡艽嬖跀?shù)據(jù)泄露（被嗅探）和篡改的問題。

而SSL協(xié)議就是為了解決上述問題而提出的戳玫。到了1999年熙掺，SSL 因為應(yīng)用廣泛，已經(jīng)成為互聯(lián)網(wǎng)上的事實標(biāo)準(zhǔn)咕宿。IETF 就在那年把 SSL 標(biāo)準(zhǔn)化币绩。標(biāo)準(zhǔn)化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協(xié)議”府阀。所以缆镣，SSL和TLS可以視作同一個東西的不同階段。

2.3试浙、"HTTPS":即 HTTP + SSL

三董瞻、HTTP和TCP的關(guān)系

3.1、"HTTP協(xié)議和TCP協(xié)議"

TCP協(xié)議是HTTP協(xié)議的基石田巴，即HTTP協(xié)議需要依靠TCP協(xié)議來傳輸數(shù)據(jù)钠糊。

HTTP是應(yīng)用層協(xié)議之一。

TCP是傳輸層協(xié)議之一壹哺。

有很多應(yīng)用層的協(xié)議（如HTTP|SMTP等）都以TCP協(xié)議為基礎(chǔ)來進(jìn)行數(shù)據(jù)傳輸抄伍。

傳輸層協(xié)議主要有TCP和UDP兩種，區(qū)別在于TCP協(xié)議是可靠的管宵。

3.2截珍、"短連接和長連接"

HTTP 對TCP連接的使用攀甚，分為兩種方式：俗稱“短連接”和“長連接”（“長連接”又稱“持久連接”，英文為“Keep-Alive”或“Persistent Connection”）

3.3岗喉、HTTP各個版本中TCP的連接方式

假設(shè)有一個網(wǎng)頁秋度，里面包含好多圖片，還包含好多【外部的】CSS 文件和 JS 文件沈堡。在“短連接”的模式下静陈，瀏覽器會先發(fā)起一個 TCP 連接，拿到該網(wǎng)頁的 HTML 源代碼（拿到 HTML 之后诞丽，這個 TCP 連接就關(guān)閉了）鲸拥。然后，瀏覽器開始分析這個網(wǎng)頁的源碼僧免，知道這個頁面包含很多外部資源（圖片刑赶、CSS、JS）懂衩。然后針對【每一個】外部資源撞叨，再分別發(fā)起一個個 TCP 連接，把這些文件獲取到本地（同樣的浊洞，每抓取一個外部資源后牵敷，相應(yīng)的 TCP 就斷開）

相反，如果是“長連接”的方式法希，瀏覽器也會先發(fā)起一個 TCP 連接去抓取頁面枷餐。但是抓取頁面之后，該 TCP 連接并不會立即關(guān)閉苫亦，而是暫時先保持著（所謂的“Keep-Alive”）毛肋。然后瀏覽器分析 HTML 源碼之后，發(fā)現(xiàn)有很多外部資源屋剑，就用剛才那個 TCP 連接去抓取此頁面的外部資源润匙。

HTTP1.0 版本默認(rèn)使用短連接，也叫作一次性連接唉匾。因為那個時候網(wǎng)頁簡單孕讳。

HTTP1.1 版本中默認(rèn)使用長連接，因為此時網(wǎng)頁已經(jīng)變得足夠復(fù)雜肄鸽，如果繼續(xù)使用短連接的方式效率太低（因為建立TCP連接需要時間和CPU成本）

四卫病、加密和解密

加密：給你一個明文，可以通過一定的加密算法得到一串密文的過程典徘。明文————>密文

解密：給你一個密文，可以通過對應(yīng)的解密算法得到初始原文的過程益咬。密文————>明文

對稱加密：加密和解密使用相同的密鑰逮诲。"速度快|效率高|存在密鑰傳輸安全的問題"

非對稱加密：加密和解密使用不同的密鑰帜平。擁有一個公鑰一個私鑰，使用公鑰進(jìn)行加密使用私鑰來進(jìn)行解密梅鹦。"速度慢|安全性強(qiáng)"

對稱加密和非對稱加密的特點也影響到了SSL協(xié)議的設(shè)計裆甩。

五、HTTPS協(xié)議為什么要設(shè)計成這樣齐唆？（WHY）

5.1嗤栓、兼容性問題?

①已有的web應(yīng)用應(yīng)該盡可能無縫的遷移到HTTPS，最好是做到零成本箍邮。②瀏覽器廠家改動應(yīng)該盡可能的小

①"HTTPS協(xié)議還是基于TCP來進(jìn)行傳輸"

②"把HTTP協(xié)議包裹起來成為一個新的協(xié)議"

③好比以前的HTTP協(xié)議是塑料水管容易戳破茉帅，現(xiàn)在就在以前塑料水管的基礎(chǔ)上再包上一層金屬管。這樣就可以做到锭弊，原有的管道能夠照常運行堪澎，且不再容易被戳破。

5.2味滞、可擴(kuò)展性

SSL/TLS 可以跟很多常用的應(yīng)用層協(xié)議（比如：FTP樱蛤、SMTP、POP剑鞍、Telnet）搭配昨凡，來強(qiáng)化這些應(yīng)用層協(xié)議的安全性

如果把SSL看成是一層金屬管，那么他不僅能夠?qū)斔艿肋M(jìn)行加固蚁署，而且也能對輸電管道便脊，輸煤氣管道進(jìn)行加固。

5.3形用、保密性

說白了以前是透明的塑料管道就轧，隨便花點功夫就能夠知道傳輸?shù)膬?nèi)容，而現(xiàn)在能夠做到足夠好的保密性田度。

5.4妒御、完整性

能夠確保HTTP協(xié)議的內(nèi)容不被修改。

因為你的網(wǎng)絡(luò)流量需要經(jīng)過 ISP 的線路才能到達(dá)公網(wǎng)镇饺。如果你使用的是明文的 HTTP乎莉，ISP 很容易就可以在你訪問的頁面中植入廣告

5.5、真實性

HTTPS 協(xié)議必須有某種機(jī)制來確奔轶裕“真實性”的需求惋啃。

如何確定我們訪問的網(wǎng)站是真實的，關(guān)于這一點僅僅根據(jù)域名來判斷是不靠譜的监右。因為我們的DNS系統(tǒng)本身就是不可靠的（域名欺騙和域名劫持）边灭，所以我們看到的網(wǎng)址里面的域名未必是真實的。

5.6健盒、性能

使用HTTPS的時候性能不能太差绒瘦，因此在設(shè)計的時候需要考慮兩個問題：

① 加密和解密采用什么樣的方式來進(jìn)行：對稱加密還是非對稱加密称簿？

② 采用什么樣的連接方式：短連接還是長連接

六、 設(shè)計HTTPS協(xié)議的難點

個人認(rèn)為最難的地方在于對傳輸數(shù)據(jù)進(jìn)行加密和解密這一塊惰帽，也就是密鑰交換憨降。

如果客戶端和服務(wù)器端需要進(jìn)行HTTPS通信，那么首先需要協(xié)商雙方應(yīng)該采用什么樣的加密算法该酗，確定了加密算法之后還需要傳輸加密和解密中可能涉及到的密鑰授药，而此時尚處于握手階段，所有的數(shù)據(jù)傳輸都還是明文的呜魄，那么應(yīng)該如何安全的傳輸密鑰成為最大的問題悔叽。

七、解決密鑰安全傳輸?shù)膯栴}

1耕赘、單獨使用對稱加密來傳輸

完全使用對稱加密來傳輸"不具備可行性"骄蝇，因為如果要使用對稱加密，那么瀏覽器和客戶端之間勢必需要先交換"對稱加密的密鑰"操骡。如果這個密鑰直接用明文來傳輸九火，則很有可能會被攻擊者偷窺到。

2册招、使用非對稱加密來傳輸 效率太低

3岔激、使用非對稱加密+對稱加密：存在中間人攻擊隱患（需要具備篡改通信數(shù)據(jù)的能力）[偽造公鑰][MITM]

4、正是因為"缺乏身份認(rèn)證機(jī)制"是掰，所以我們需要考慮身份認(rèn)證的問題虑鼎。

八、身份認(rèn)證的幾種方式

1键痛、基于某些私密共享的信息 |前提——通信雙方認(rèn)識彼此熟悉

2炫彩、基于雙方都信任的公證人 |如果通信雙方都不認(rèn)識彼此，那么就只能采用該模式（如C2C）

那么絮短，誰來充當(dāng)這個公證人呢江兢？"CA"華麗登場

如何解決SSL的身份認(rèn)證問題：使用CA

CA數(shù)字證書在技術(shù)實現(xiàn)上依賴于非對稱加密技術(shù)

九、維基百科中對HTTPS的定義

? ? 超文本傳輸安全協(xié)議（英語："Hypertext Transfer Protocol Secure"丁频，縮寫：HTTPS杉允，也被稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種網(wǎng)絡(luò)安全傳輸協(xié)議席里。在計算機(jī)網(wǎng)絡(luò)上叔磷，HTTPS經(jīng)由超文本傳輸協(xié)議進(jìn)行通信，但利用SSL/TLS來對數(shù)據(jù)包進(jìn)行加密奖磁。HTTPS開發(fā)的主要目的改基，是'提供對網(wǎng)絡(luò)服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性'咖为。這個協(xié)議由網(wǎng)景公司（Netscape）在1994年首次提出寥裂，隨后擴(kuò)展到互聯(lián)網(wǎng)上嵌洼。

十案疲、擴(kuò)充知識：

網(wǎng)景（英語：Netscape）是一個自1994年開始的品牌封恰。"1994年4月4"日它最初成立的名字是'馬賽克通信公司'。該公司有一款名稱為"網(wǎng)景導(dǎo)航者"的瀏覽器褐啡，因此"網(wǎng)景"也是是網(wǎng)景通信公司（Netscape Communications Corporation）的常用簡稱诺舔。網(wǎng)景通信公司曾經(jīng)是一家美國的電腦服務(wù)公司，以其生產(chǎn)的同名網(wǎng)頁瀏覽器而聞名备畦。1998年11月低飒，網(wǎng)景被美國在線（AOL）收購，2003年7月網(wǎng)景被解散懂盐，網(wǎng)景大部分的程序員被解雇褥赊，2008年3月1日美國在線宣布停止對網(wǎng)景瀏覽器的技術(shù)支持。

網(wǎng)景公司（Netscape）在1994年推出首版網(wǎng)頁瀏覽器莉恼，網(wǎng)景導(dǎo)航者時拌喉，推出HTTPS協(xié)議，以SSL進(jìn)行加密俐银，這是SSL的起源尿背。IETF將SSL進(jìn)行標(biāo)準(zhǔn)化，1999年公布了第一版TLS標(biāo)準(zhǔn)文件

IETF:互聯(lián)網(wǎng)工程任務(wù)小組（英語：Internet Engineering Task Force捶惜，縮寫為 IETF）負(fù)責(zé)互聯(lián)網(wǎng)標(biāo)準(zhǔn)的開發(fā)和推動.

該網(wǎng)站提供免費的安全證書：https://letsencrypt.org

十一田藐、SSL協(xié)議握手的過程：

通過握手，客戶端和服務(wù)器協(xié)商各種參數(shù)用于創(chuàng)建安全連接：

① 當(dāng)客戶端連接到支持TLS協(xié)議的服務(wù)器要求創(chuàng)建安全連接并列出了受支持的密碼組合（加密密碼算法和加密哈希函數(shù)）吱七，握手開始汽久。

② 服務(wù)器從該列表中決定加密和散列函數(shù)，并通知客戶端踊餐。

③ 服務(wù)器發(fā)回其數(shù)字證書景醇，此證書通常包含服務(wù)器的名稱、受信任的證書頒發(fā)機(jī)構(gòu)（CA）和服務(wù)器的公鑰市袖。

④ 客戶端確認(rèn)其頒發(fā)的證書的有效性啡直。

⑤ 為了生成會話密鑰用于安全連接，客戶端使用服務(wù)器的公鑰加密隨機(jī)生成的密鑰苍碟，并將其發(fā)送到服務(wù)器酒觅，只有服務(wù)器才能使用自己的私鑰解密。

⑥ 利用隨機(jī)數(shù)微峰，雙方生成用于加密和解密的對稱密鑰舷丹。

以上就是TLS協(xié)議的握手，握手完畢后的連接是安全的蜓肆，直到連接（被）關(guān)閉颜凯。如果上述任何一個步驟失敗谋币，TLS握手過程就會失敗，并且斷開所有的連接症概。

十二蕾额、TLS 1.2在 RFC 5246 中定義，于2008年8月發(fā)表彼城。它基于更早的TLS 1.1規(guī)范诅蝶。主要區(qū)別包括：

① 可使用密碼組合選項指定偽隨機(jī)函數(shù)使用SHA-256替換MD5-SHA-1組合。

② 可使用密碼組合選項指定在完成消息的哈希認(rèn)證中使用SHA-256替換MD5-SHA-1算法募壕，但完成消息中哈希值的長度仍然被截斷為96位调炬。

③ 在握手期間MD5-SHA-1組合的數(shù)字簽名被替換為使用單一Hash方法，默認(rèn)為SHA-1舱馅。

④ 增強(qiáng)服務(wù)器和客戶端指定Hash和簽名算法的能力缰泡。

⑤ 擴(kuò)大經(jīng)過身份驗證的加密密碼，主要用于GCM和CCM模式的AES加密的支持代嗤。

⑥ 添加TLS擴(kuò)展定義和AES密碼組合棘钞。

⑦ 所有TLS版本在2011年3月發(fā)布的RFC 6176中刪除了對SSL的兼容，這樣TLS會話將永遠(yuǎn)無法協(xié)商使用SSL 2.0以避免安全問題资溃。

十三武翎、HTTPS協(xié)議中關(guān)于SSL/TLS層握手過程的說明

階段一：協(xié)商加密方式等參數(shù)

客戶端 ① 我想要和你[服務(wù)端]進(jìn)行安全的通話，我這里的支持的對稱加密算法有DES|AES|RC5,密鑰交換算法有RSA和DH,消息摘要算法有MD5和SHA1|SHA256

② [我說完了]

服務(wù)端 ① 我們使用AES-RSA-SHA256的組合方式吧溶锭。

② 服務(wù)器端證書發(fā)送給客戶端宝恶，并說[這是我的證書，里面有我的信息和公鑰趴捅，你拿去驗證一下我的身份吧]垫毙。

③ [我說完了]

"——————該階段雙方已經(jīng)協(xié)商好了加密[AES]__會話密鑰交換[RSA]_消息校驗[SHA256]的一套方法。

'階段二：驗證證書的有效性并交換會話密鑰

客戶端 ① 檢查證書上面的信息拱绑，并通過已有的CA證書驗證服務(wù)器端證書的真實性综芥，如果有誤則發(fā)出警告并斷開連接。

② 客戶端從接收到的證書中提取出公鑰

③ 生成隨機(jī)數(shù)作為會話密鑰猎拨，即session key,該密鑰將被在建立安全通道后用作對稱加密的密鑰膀藐。

④ 使用提取出來的公鑰加密之前生成的會話密鑰，封裝成一個ClientKeyExchange消息[其實就是使用公鑰對會話密鑰進(jìn)行加密之后的密文]红省。

⑤ 以后我就要使用session key對消息進(jìn)行加密來和你進(jìn)行通信了额各！

⑥ [我說完了]

服務(wù)端 ① 使用自己的私鑰對收到ClientKeyExchange消息進(jìn)行解密，得到會話密鑰吧恃，即session key虾啦。

"【注】該消息由客戶端使用服務(wù)器端發(fā)送給其的公鑰進(jìn)行加密，所以服務(wù)器端可以使用私鑰來解密。

② 使用會話密鑰加密初始化向量

"【注】如果采用的是CBC分組模式進(jìn)行加密處理則需要用到初始向量

③ 加密HMAC的密鑰

④ 以后我也要使用session key對消息進(jìn)行加密來和你進(jìn)行通信了傲醉！

⑤ [我說完了]

"——————該階段完成會話密鑰session key的安全交換蝇闭。

'階段三：使用會話密鑰加密消息，所有的消息在安全的信道中傳輸

客戶端 ① 要發(fā)送給服務(wù)端的消息是CMsg:我的小秘密是....

② 使用會話秘鑰對CMsg進(jìn)行對稱加密得到密文CMsg1:xxxxxooooooo

③ 把CMsg1發(fā)送給服務(wù)器端

服務(wù)端 ① 接收到客戶端發(fā)送來的消息CMsg1:xxxxxooooooo

② 使用本地的私鑰對收到的消息Msg1進(jìn)行解密硬毕，得到原文為CMsg:我的小秘密是....

③ 對客戶端的消息進(jìn)行響應(yīng)呻引，要發(fā)送給客戶端的消息為SMsg:其它人不會聽到的，我也有個小秘密...

④ 使用會話密鑰對SMsg進(jìn)行對稱加密得到密文SMsg1:oooooxxxxxxx

⑤ 把SMsg1發(fā)送給客戶端

"——————該階段在傳輸之前使用會話密鑰對所有的消息進(jìn)行對稱加密處理昭殉。