文章結(jié)構(gòu)
- 感人小故事： 通過故事，說一說為什么要加密。
- 密碼學： 單鑰加密&雙鑰加密。
- 數(shù)字簽名&數(shù)字證書&證書授權(quán)中心： 概念解釋。
- HTTP： 工作原理，三次握手，四次分手過程。
- HTTPS： HTTPS 是HTTP 和 SSL/TLS的結(jié)合。一次HTTPS過程包含兩次雙鑰加密，一次單鑰加密。
感人小故事
Section 1:
故事背景：二戰(zhàn)期間德軍安插在英國的間諜將收集的情報直接傳送給大本營。
情報內(nèi)容： 英國軍隊將在周末有軍事活動。
Section 2:
間諜拍腦袋一想，萬一被英國截獲了情報，就完蛋了。
于是跟大本營協(xié)商了一套加密密碼用來加密情報，即使情報被截獲，英國佬也不知道是什么意思。
完事大吉...
Section 3:
由于房東漲租，間諜的活動經(jīng)費緊張，不得已搬家。用來加密的密碼丟失了，被英國得到了，情報又不安全了。
間諜想哭...
Section 4:
吸取了以往教訓，大本營用兩套密碼（公鑰，私鑰）分別用于情報的加密和解密。 間諜用大本營給的公鑰加密，大本營用私鑰解密就看到情報內(nèi)容了。只要大本營不泄露私鑰，情報就是安全的。
間諜開心的笑了...
ps: 公鑰和私鑰是一一對應的，不可被模仿的。 公鑰加密的只能用私鑰解開，反之亦然。
Section 5:
英國人情報局：臥槽，搞不到情報，我就要下崗了。怎么辦，怎么辦。靈機一動，來一出偷梁換柱的戲法。用不為人知的手段換了間諜的公鑰，間諜用這個公鑰加密了情報發(fā)給大本營，中途就被英國截獲，用自己的私鑰就能解密，獲得情報內(nèi)容。用私鑰加密回信給德國間諜： “小樣，你的智商又一次沒碾壓”。
間諜OS： mmp，太可惡了，心中一萬頭草泥馬跑過...
Section 6:
大本營安慰間諜ing......
大本營對間諜說：我以后回信都用Hash函數(shù)生成摘要，用私鑰對摘要加密生成數(shù)字簽名，并將這個數(shù)字簽名隨同加密的回信一起給你。
間諜收到回信，先用公鑰解密數(shù)字簽名，得到摘要。就確定了該信件是大本營發(fā)的(因為能用公鑰解密)。
再對信件用Hash函數(shù)生成摘要，將得到的摘要和解密得到的摘要對照。如果一致，就確定信就沒被改過。
間諜突然想到： 咦，不對，沒解決問題啊。我的公鑰如果沒被替換，做這些毫無意義，公鑰被替換了，做這些也毫無意義。
大本營一幫蠢貨，??，難受ing......
問君能有幾多愁？恰似一江春水向東流。
一切皆枉然,奈何徒增悲傷...
Section 8:
間諜內(nèi)心os: 不能靠大本營的一幫蠢貨，還是得靠我！
熊熊斗志在燃燒????
只要讓我（間諜）能驗證“數(shù)字簽名”真?zhèn)尉驼娴氖裁炊疾慌铝恕?/p>
要求大本營找一個靠譜（公信力強）的單位（稱為“證書中心”，簡稱CA），為大本營的公鑰做認證并給到自己。CA用自己的私鑰對大本營的公鑰和一些其他相關(guān)信息一起加密，生成了“數(shù)字證書”。
大本營回信的時候，附帶上數(shù)字簽名，再加上CA的數(shù)字證書。間諜收到信，用CA的公鑰解開數(shù)字證書拿到大本營的公鑰，就能證明“數(shù)字簽名”是大本營的。
這下真的安全了...
ps:
CA是被認可的有公信力的組織。理論上不會作假，也沒法偽裝的。
CA的公鑰是公之于眾的。
CA的公鑰是可查的，可驗證的，沒法模仿的。
密碼學
加密方法
- 單鑰加密：又稱為對稱加密。加密解密用同一套密碼。一旦密鑰泄漏，密碼也就被破解。
- 雙鑰加密：又稱非對稱加密。加密解密用兩套密碼。一把是公開的公鑰，還有一把是不公開的私鑰。
說明：
- 公鑰和私鑰是一一對應的關(guān)系，有一把公鑰就會有一把獨一無二的私鑰。反之也成立。
- 所有的公鑰私鑰對都是不同的。
- 用公鑰可以解開私鑰加密信息，反之也成立。
- 同時生成公鑰私鑰相對比較容易，但是從公鑰推到出私鑰是不可能的。
- 在雙匙體系中，公鑰用來加密信息，私鑰用來做數(shù)字簽名。
數(shù)字簽名&數(shù)字證書&證書授權(quán)中心
數(shù)字簽名
數(shù)字簽名（又稱公鑰數(shù)字簽名）是只有信息的發(fā)送者才能產(chǎn)生的別人無法偽造的一段數(shù)字串，這段數(shù)字串同時也是對信息的發(fā)送者發(fā)送信息真實性的一個有效證明。
簡單地說，所謂數(shù)字簽名就是附加在數(shù)據(jù)單元上的一些數(shù)據(jù)，或是對數(shù)據(jù)單元所作密碼變換。這種數(shù)據(jù)或變換允許數(shù)據(jù)單元的接收者用以確認數(shù)據(jù)單元的來源和數(shù)據(jù)單元的完整性并保護數(shù)據(jù)，防止被人(例如接收者)進行偽造。
數(shù)字證書
每個人都有一對“鑰匙”（數(shù)字身份），其中一個只有她/他本人知道（私鑰），另一個公開的（公鑰）。簽名的時候用私鑰，驗證簽名的時候用公鑰。
又因為任何人都可以落款聲稱她/他就是你，因此公鑰必須向接受者信任的人（身份認證機構(gòu)）來注冊。注冊后身份認證機構(gòu)給你發(fā)一數(shù)字證書。對文件簽名后，你把此數(shù)字證書連同文件及數(shù)字簽名一起發(fā)給接受者，接受者向身份認證機構(gòu)求證是否真地是用你的私鑰簽發(fā)的文件。
證書授權(quán)中心
證書授權(quán)中心是管理和簽發(fā)安全憑證和加密信息安全秘鑰的網(wǎng)絡(luò)機構(gòu)。負責生產(chǎn)、分配并管理所有參與網(wǎng)上交易的個體所需要的數(shù)字證書。
任何人都可以生成自己的公鑰私鑰對，所以為了防止有人散布偽造的公鑰騙取信任，就需要一個可靠的第三方生成經(jīng)過認證的公鑰私鑰對，目前主要的數(shù)字服務(wù)認證商是美國加州的Verisign公司，它的主要業(yè)務(wù)是分發(fā)RSA數(shù)字證書。
HTTP
簡介
- HTTP協(xié)議是用于從WWW服務(wù)器傳輸超文本到本地瀏覽器的傳送協(xié)議。
- HTTP協(xié)議永遠都是客戶端發(fā)起請求，服務(wù)器回送響應。
- HTTP是基于TCP協(xié)議的，發(fā)送數(shù)據(jù)之前需要建立好連接。
- 默認HTTP的端口號為80
TCP協(xié)議
TCP 負責客戶端和網(wǎng)絡(luò)軟件之間的通信。
- 短連接： HTTP/1.0中默認使用短連接，客戶端和服務(wù)器每進行一次HTTP操作，就建立一次連接，但任務(wù)結(jié)束就中斷連接。短連接對服務(wù)端來說實現(xiàn)起來比較簡單，存在的連接都是有用的連接，不需要額外的控制手段，但是如果用戶訪問量很大，往往可能在很短的時間內(nèi)需要創(chuàng)建大量的連接，造成服務(wù)端響應過慢。
- 長連接： HTTP/1.1中默認使用長連接。長連接可以省去較多的和TCP建立和關(guān)閉連接的操作，節(jié)約時間。但是如果用戶量太大容易造成服務(wù)器負載過高最終導致服務(wù)不可用。
http的操作過程
- 獲取服務(wù)器的IP地址
客戶端分析指向頁面的URL，客戶端向DNS請求解析域名所對應的服務(wù)器地址，DNS系統(tǒng)解析出服務(wù)器的IP地址并返回服務(wù)器IP給客戶端。
http://host.com:8080/page.html解析結(jié)果：
| 協(xié)議名 | 主機名 | 端口號 | 對象路徑 |
|---|---|---|---|
| http | host.com | 8080 | page.html |
-
客戶端與服務(wù)器的進程建立TCP鏈接
也叫三次握手連接，默認端口號80.
SYN: 表示連接請求 ACK: 表示確認 FIN: 表示關(guān)閉連接 seq:表示報文序號 ack: 表示確認序號
- 第一次握手：Client將標志位SYN置為1，隨機產(chǎn)生一個值seq=J，并將該數(shù)據(jù)包發(fā)送給Server，Client進入SYN_SENT狀態(tài)，等待Server確認。
- 第二次握手：Server收到數(shù)據(jù)包后由標志位SYN=1知道Client請求建立連接，Server將標志位SYN和ACK都置為1，ack (number )=J+1，隨機產(chǎn)生一個值seq=K，并將該數(shù)據(jù)包發(fā)送給Client以確認連接請求，Server進入SYN_RCVD狀態(tài)。
- 第三次握手：Client收到確認后，檢查ack是否為J+1，ACK是否為1，如果正確則將標志位ACK置為1，ack=K+1，并將該數(shù)據(jù)包發(fā)送給Server，Server檢查ack是否為K+1，ACK是否為1，如果正確則連接建立成功，Client和Server進入ESTABLISHED狀態(tài)，完成三次握手，隨后Client與Server之間可以開始傳輸數(shù)據(jù)了。
- 客戶端發(fā)送請求命令
建立連接后，客戶機發(fā)送一個請求給服務(wù)器，請求方式的格式為：統(tǒng)一資源標識符（URI：Uniform Resource Identifier）、協(xié)議版本號，后邊是MIME信息包括請求修飾符、客戶機信息和可能的內(nèi)容。 - 服務(wù)器響應
服務(wù)器接到請求后，給予相應的響應信息，其格式為一個狀態(tài)行，包括信息的協(xié)議版本號、一個成功或錯誤的代碼，后邊是MIME信息包括服務(wù)器信息、實體信息和可能的內(nèi)容。
實體消息是服務(wù)器向瀏覽器發(fā)送頭信息后，它會發(fā)送一個空白行來表示頭信息的發(fā)送到此結(jié)束，接著，它就以Content-Type應答頭信息所描述的格式發(fā)送用戶所請求的實際數(shù)據(jù) - 服務(wù)器關(guān)閉TCP連接
一般情況下，一旦服務(wù)器向客戶端發(fā)送了請求數(shù)據(jù)，它就要關(guān)閉TCP連接，然后如果客戶端或者服務(wù)器在其頭信息加入了這行代碼Connection:keep-alive,TCP連接在發(fā)送后將仍然保持打開狀態(tài)，于是，客戶端可以繼續(xù)通過相同的連接發(fā)送請求。保持連接節(jié)省了為每個請求建立新連接所需的時間，還節(jié)約了網(wǎng)絡(luò)帶寬。
SYN: 表示連接請求 ACK: 表示確認 FIN: 表示關(guān)閉連接 seq:表示報文序號 ack: 表示確認序號
- 第一次揮手：Client發(fā)送一個FIN，用來關(guān)閉Client到Server的數(shù)據(jù)傳送。
- 第二次揮手：Server收到FIN后，發(fā)送一個ACK給Client，確認序號為收到序號+1
- 第三次揮手：Server發(fā)送一個FIN，用來關(guān)閉Server到Client的數(shù)據(jù)傳送。
- 第四次揮手：Client收到FIN后，接著發(fā)送一個ACK給Server，確認序號為收到序號+1。
- 客戶端解析信息，做對應的處理。
Https
什么是HTTPS？
https簡單的說就是http的安全版本，因為Http協(xié)議的數(shù)據(jù)都是明文進行傳輸?shù)?。為了安全傳輸敏感?shù)據(jù)，在http上添加了一個安全傳輸層（SSL / TLS協(xié)議），對所有數(shù)據(jù)都加密再進行傳輸。
- SSL的全稱是Secure Sockets Layer，即安全套接層協(xié)議，是為網(wǎng)絡(luò)通信提供安全及數(shù)據(jù)完整性的一種安全協(xié)議。
- TLS的全稱是Transport Layer Security，即安全傳輸層協(xié)議。它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本。它們所支持的加密算法不同，所以TLS與SSL3.0不能互操作。雖然如此，但是在我們理解HTTPS的過程中，我們可以把SSL和TLS看做是同一個協(xié)議。
HTTPS為了兼顧安全與效率，同時使用了對稱加密和非對稱加密。數(shù)據(jù)是被對稱加密傳輸?shù)?，對稱加密過程需要客戶端的一個密鑰，為了確保能把該密鑰安全傳輸?shù)椒?wù)器端，采用非對稱加密對該密鑰進行加密傳輸，總的來說，對數(shù)據(jù)進行對稱加密，對稱加密所要使用的密鑰通過非對稱加密傳輸。
- 客戶端發(fā)起請求
客戶端開始請求接口，連接到服務(wù)器的443端口。 - 服務(wù)端加密公鑰（非對稱加密）
服務(wù)器端有一個密鑰對，即公鑰和私鑰，是用來進行非對稱加密使用的。CA用私鑰加密服務(wù)端的公鑰和其他相關(guān)信息生成數(shù)字數(shù)字證書。 - 傳送數(shù)字證書
服務(wù)器將這個數(shù)字證書發(fā)送給客戶端。 - 客戶端解析證書（非對稱加密）
客戶端用CA的公鑰解析證書，驗證證書是否正確（頒發(fā)證書的機構(gòu)，過期時間等），拿到服務(wù)器的公鑰。然后生成一個隨機值，用公鑰對隨機值進行加密。 - 傳送加密信息
客戶端將加密的隨機值傳送給服務(wù)端。 - 服務(wù)端加密信息（對稱加密）
服務(wù)端用私鑰解密后，得到了客戶端傳過來的隨機值(私鑰)，然后把內(nèi)容通過該值進行對稱加密。 - 傳輸加密后的信息
將加密的信息發(fā)送給客戶端。 - 客戶端解密信息
客戶端用之前生成的隨機值解密服務(wù)端傳過來的信息，于是獲取了解密后的內(nèi)容。
整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。
HTTPS總結(jié)
- HTTPS = HTTP + SSL/TLS
- HTTPS的過程包含兩次非對稱加密（加密公鑰和加密客戶端生成的私鑰），一次對稱加密（傳輸信息的對稱加密）。
