HTTP是什么
超文本傳輸協(xié)議（英文：HyperText Transfer Protocol，縮寫：HTTP）是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議。是一個(gè)基于請(qǐng)求與響應(yīng)模式的、無狀態(tài)的、應(yīng)用層的協(xié)議，常基于TCP的連接方式，絕大多數(shù)的Web開發(fā)，都是構(gòu)建在HTTP協(xié)議之上的Web應(yīng)用。
為了方便通信就必須統(tǒng)一約定好雙方的數(shù)據(jù)協(xié)議，如果每個(gè)人都搞一套自己的規(guī)則，這玩起來就很麻煩了。因此IETF (互聯(lián)網(wǎng)工程任務(wù)組) 推動(dòng)了HTTP的統(tǒng)一和發(fā)展。現(xiàn)在大家用得最多的還是1999年收錄于RFC 2616的1.1版本，2015年發(fā)布的2.0版本在推廣道路上任重道遠(yuǎn)。
HTTP[S]報(bào)文
最直觀上的差異，HTTP協(xié)議用明文傳輸報(bào)文，HTTPS用密文。
HTTP的缺陷
- 竊聽風(fēng)險(xiǎn)（eavesdropping）：明文傳輸，第三方可以獲知通信內(nèi)容。
- 篡改風(fēng)險(xiǎn)（tampering）：第三方可以修改通信內(nèi)容。
- 冒充風(fēng)險(xiǎn)（pretending）：第三方可以冒充他人身份參與通信。
HTTPS是什么
超文本傳輸安全協(xié)議（英語：Hypertext Transfer Protocol Secure，縮寫：HTTPS，常稱為HTTP over TLS，HTTP over SSL或HTTP Secure）
是一種透過計(jì)算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議。HTTPS經(jīng)由HTTP進(jìn)行通信，但利用SSL/TLS協(xié)議來加解密數(shù)據(jù)包。
HTTPS開發(fā)的主要目的，是提供對(duì)網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換數(shù)據(jù)的隱私與完整性；
HTTPS并不是一個(gè)單獨(dú)的協(xié)議，而是對(duì)工作在一加密連接（TLS/SSL）上的常規(guī)HTTP協(xié)議的稱呼。因此HTTPS被稱之為身披SSL外殼的HTTP。
SSL/TLS協(xié)議
傳輸層安全性協(xié)議（Transport Layer Security，縮寫作 TLS），及其前身安全套接層（Secure Sockets Layer，縮寫作 SSL）是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信，提供安全及數(shù)據(jù)完整性保障
發(fā)展歷史
網(wǎng)景公司（Netscape）在1994年推出首版網(wǎng)頁瀏覽器，網(wǎng)景導(dǎo)航者時(shí)，推出HTTPS協(xié)議，以SSL進(jìn)行加密，這是SSL的起源。后面，IETF將SSL進(jìn)行標(biāo)準(zhǔn)化，稱為TLS。在瀏覽器、電子郵件、即時(shí)通信、VoIP、網(wǎng)絡(luò)傳真等應(yīng)用程序中，廣泛支持這個(gè)協(xié)議
| 協(xié)議 | 年份 | 描述 |
|---|---|---|
| SSL 1.0 | N/A | 從未公開過，因?yàn)榇嬖趪?yán)重的安全漏洞 |
| SSL 2.0 | 1995 | 因?yàn)榇嬖跀?shù)個(gè)嚴(yán)重的安全漏洞而被3.0版本替代 |
| SSL 3.0 | 1996 | 2014年10月Google發(fā)現(xiàn)該版本的嚴(yán)重漏洞，建議全面禁用SSL版本 |
| TLS 1.0 | 1999 | IETF標(biāo)準(zhǔn)化后的第一個(gè)版本。包括可以降級(jí)到SSL 3.0的實(shí)現(xiàn)，這削弱了連接的安全性 |
| TLS 1.1 | 2006 | - |
| TLS 1.2 | 2008 | 刪除了對(duì)SSL的兼容。目前使用最廣泛的版本 |
| TLS 1.3 | 2018 | 截至本文撰寫，為建議標(biāo)準(zhǔn)的互聯(lián)網(wǎng)草案 |
在TCP/IP模型的位置：介于傳輸層與應(yīng)用層之間
TLS內(nèi)部協(xié)議劃分
- 記錄協(xié)議：位于TLS握手協(xié)議的下面，在可靠的傳輸協(xié)議(如TCP/IP)上面。其負(fù)責(zé)識(shí)別不同的消息類型，以及每條消息的完整性、安全性驗(yàn)證
- 握手協(xié)議：服務(wù)端與客戶端在應(yīng)用程序協(xié)議傳輸之前進(jìn)行相互認(rèn)證，協(xié)商加密算法和加密密鑰
另外還有3個(gè)輔助協(xié)議：
- 改變加密方式協(xié)議，用來通知對(duì)方要切換加解密方案了(有點(diǎn)冗余，在TLS1.3里面已經(jīng)被刪掉了)
- 警告協(xié)議，定義了校驗(yàn)及其他出錯(cuò)類型，
- 應(yīng)用數(shù)據(jù)協(xié)議， 把http，smtp等數(shù)據(jù)流傳入記錄層做處理并傳輸。
SSL/TLS解決了什么問題
【內(nèi)容加密】所有信息都是加密傳播，第三方無法竊聽。（密鑰協(xié)商機(jī)制）
【數(shù)據(jù)完整性】具有校驗(yàn)機(jī)制，一旦被篡改，通信雙方會(huì)立刻發(fā)現(xiàn)。（MAC（Message authentication code）校驗(yàn)機(jī)制）
【身份認(rèn)證】配備身份證書，防止身份被冒充（證書認(rèn)證機(jī)制）
SSL的握手過程
以下是使用curl請(qǐng)求https://baidu.com的詳情
foam@cee: ~ ? curl "https://baidu.com" -v
* Rebuilt URL to: https://baidu.com/
* Trying 123.125.115.110...
* TCP_NODELAY set
* Connected to baidu.com (123.125.115.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=CN; L=Beijing; O=BeiJing Baidu Netcom Science Technology Co., Ltd; OU=service operation department; CN=www.baidu.cn
* start date: Apr 3 00:00:00 2018 GMT
* expire date: Apr 3 12:00:00 2019 GMT
* subjectAltName: host "baidu.com" matched cert's "baidu.com"
* issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
* SSL certificate verify ok.
> GET / HTTP/1.1
...
< HTTP/1.1 302 Moved Temporarily
...
我們分析下其中TLS1.2握手的過程：
TLS handshake, Client Hello【客戶端向服務(wù)端問好】
客戶端通過發(fā)送Client Hello報(bào)文開始建立SSL通信，報(bào)文包含客戶端支持的SSL版本，加密套件列表，隨機(jī)數(shù)。上面例子中，ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH就是客戶端支持的加密套件的表達(dá)式。TLS handshake, Server Hello【服務(wù)端回禮】
服務(wù)端回復(fù)Server Hello作為應(yīng)答，報(bào)文包含服務(wù)端選擇好的SSL版本，加密套件，隨機(jī)數(shù)。上面例子中，服務(wù)端選擇了TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256。TLS handshake, Certificate【服務(wù)端亮出身份】
服務(wù)端發(fā)送證書鏈（從根證書到自身的證書）。證書包含證書所有者、頒發(fā)機(jī)構(gòu)以及公鑰、數(shù)字簽名等信息。
客戶端收到證書后，會(huì)校驗(yàn)域名；判斷有效時(shí)間；判斷頒發(fā)機(jī)構(gòu)是否可信任；用頒發(fā)機(jī)構(gòu)的公鑰解開加密后的數(shù)字簽名（解開后得到證書摘要和摘要算法），計(jì)算并判斷證書摘要是否一致。
如果校驗(yàn)過程中出現(xiàn)問題，客戶端將報(bào)Alert警告，并終止SSL握手。當(dāng)然，如果警告級(jí)別只是warning（還有一種是fatal），那么客戶端也可以選擇忽略警告并繼續(xù)完成握手過程。TLS handshake, Server key exchange【服務(wù)端將密鑰生成參數(shù)及方法告知客戶端】
對(duì)于使用DHE/ECDHE非對(duì)稱密鑰協(xié)商算法的，會(huì)有該次握手（RSA、DH、ECDH則沒有）。
以ECDHE為例，服務(wù)端隨機(jī)生成隨機(jī)值Rb，計(jì)算Pb(x,y) = Rb * Q(x, y)。然后將Pb(x, y)發(fā)送給客戶端，用來在后續(xù)步驟中計(jì)算出PreMasterSecret。ps：該條消息包含一個(gè)用服務(wù)端私鑰作的簽名。TLS handshake, Server finished【服務(wù)端提醒：關(guān)于密鑰生成，該說的我都說完了】
服務(wù)器發(fā)送這條消息表明，服務(wù)器部分的密鑰交換信息已經(jīng)發(fā)送完了，等待客戶端的消息以繼續(xù)接下來的步驟。這條消息只用作提醒，不包含數(shù)據(jù)域。TLS handshake, Client key exchange【客戶端將密鑰生成參數(shù)及方法告知服務(wù)端】
這條消息會(huì)把PreMasterSecret或者生成PreMasterSecret的數(shù)據(jù)發(fā)給服務(wù)端。
具體是哪種數(shù)據(jù)與所選用的密鑰交換算法有關(guān)：
- RSA：數(shù)據(jù)為用服務(wù)器RSA公鑰加密過的PreMasterSecret
- ECDHE：客戶端隨機(jī)生成隨機(jī)值Ra，計(jì)算Pa(x, y) = Ra * Q(x, y)。然后將Pa(x, y)發(fā)給服務(wù)端。客戶端計(jì)算Sa(x, y) = Ra * Pb(x, y)；服務(wù)器計(jì)算Sb(x, y) = Rb *Pa(x, y)；算法保證了Sa = Sb = S，提取其中的S的x向量作為PreMasterSecret
ps: 此次握手過后，雙方都拿到了可以計(jì)算出MasterSecret的PreMasterSecret。
PRF( secret , label , seed )
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
TLS change cipher, Client hello【客戶端：接下來我要用新的加密方式與你交流啦】
客戶端發(fā)送更改加密方式信號(hào)。本流程不攜帶任何數(shù)據(jù)，也不參與最后的哈希完整性計(jì)算。只是一個(gè)宣告信道開始的流程。TLS1.3將其移除。TLS handshake, Finished【客戶端：我對(duì)握手全過程計(jì)算了哈希，你驗(yàn)證下】
客戶端發(fā)送，用協(xié)商好的對(duì)稱加密密鑰（MasterSecret）加密過的握手?jǐn)?shù)據(jù)包。該數(shù)據(jù)包完整地計(jì)算了從握手開始到結(jié)束的所有內(nèi)容的哈希值，保證了整個(gè)握手過程中，數(shù)據(jù)沒有被篡改。服務(wù)端會(huì)去做校驗(yàn)。
ps: 這條是整個(gè)SSL握手過程中，首次使用對(duì)稱性加密的數(shù)據(jù)。TLS change cipher, Client hello【服務(wù)端：接下來我也要用新的加密方式與你交流啦】
服務(wù)端發(fā)送更改加密方式信號(hào)。TLS1.3將其移除。TLS handshake, Finished【服務(wù)端：我也對(duì)握手全過程計(jì)算了哈希，你也驗(yàn)證下】
服務(wù)端發(fā)送，用協(xié)商好的對(duì)稱加密密鑰加密過的握手?jǐn)?shù)據(jù)包。客戶端也會(huì)去做校驗(yàn)。
握手終于結(jié)束啦，接下來的http數(shù)據(jù)傳輸將全部用辛辛苦苦協(xié)商好的MasterSecret進(jìn)行對(duì)稱加密。
TLS1.3減少了握手期間的RTT（來回通信延遲）
擴(kuò)展
密碼學(xué)套件的標(biāo)準(zhǔn)名字
以TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256為例：
- TLS代表的是TLS協(xié)議
- WITH是一個(gè)分隔單詞，前面的
ECDHE_RSA是握手過程所使用的非對(duì)稱加密方法，后面的AES_128_GCM_SHA256是加密信道的對(duì)稱加密方法和用于數(shù)據(jù)完整性檢查的哈希方法 - ECDHE_RSA，客戶端與服務(wù)端之間在握手期間，密鑰交換信息使用的非對(duì)稱加密算法是第一個(gè)算法，證書認(rèn)證時(shí)使用的非對(duì)稱加密算法是第二個(gè)。有的證書套件，例如TLS_RSA_WITH_AES_256_CBC_SHA，WITH單詞前面只有一個(gè)RSA單詞，這時(shí)就表示密鑰交換算法和證書算法都是使用的RSA，所以只指定一次即可。可選的主要的密鑰交換算法包括: RSA, DH, ECDH, ECDHE。可選的主要的證書算法包括：RSA, DSA, ECDSA。兩者可以獨(dú)立選擇，并不沖突。
- AES_128_GCM，指的是AES這種對(duì)稱加密算法的128位算法的GCM模式
- SHA256，計(jì)算消息完整性的哈希算法。
Charles等代理程序是怎么實(shí)現(xiàn)解析https的
本質(zhì)是中間人。代理程序處在客戶端與服務(wù)端之間，服務(wù)端下發(fā)證書的時(shí)候，代理程序copy一份數(shù)據(jù)，并將公鑰信息換成自己的，最后用自己的根證書簽名。
最最重要的一步是，將自己的根證書加入到系統(tǒng)信任證書列表里邊。沒有內(nèi)鬼是破解不了HTTPS的。
參考資料
HTTPS的二三事
圖解HTTP之HTTPS詳解
HTTPS協(xié)議詳解(四)：TLS/SSL握手過程
沃通
維基百科
阮一峰博客
TLS的密碼學(xué)套件
深度解讀SSL/TLS實(shí)現(xiàn)
Master secret的生成
ECC證書和RSA證書
TLS1.3/QUIC 是怎樣做到 0-RTT 的
- 本文固定鏈接: http://zoufeng.net/2018/08/23/about-https/
- 轉(zhuǎn)載請(qǐng)注明: foam 2018年08月23日于 foam 發(fā)表
