1.HTTPS是什么

使用來自wiki的解釋:

超文本傳輸安全協(xié)議（英語：HyperText Transfer Protocol Secure应又，縮寫：HTTPS；常稱為HTTP over TLS乏苦、HTTP over SSL或HTTP Secure）是一種通過計算機(jī)網(wǎng)絡(luò)進(jìn)行安全通信的傳輸協(xié)議株扛。HTTPS經(jīng)由HTTP進(jìn)行通信，但利用SSL/TLS來加密數(shù)據(jù)包汇荐。HTTPS開發(fā)的主要目的洞就，是提供對網(wǎng)站服務(wù)器的身份認(rèn)證，保護(hù)交換資料的隱私與完整性掀淘。這個協(xié)議由網(wǎng)景公司（Netscape）在1994年首次提出旬蟋，隨后擴(kuò)展到互聯(lián)網(wǎng)上。

歷史上革娄，HTTPS連接經(jīng)常用于萬維網(wǎng)上的交易支付和企業(yè)信息系統(tǒng)中敏感信息的傳輸倾贰。在2000年代末至2010年代初，HTTPS開始廣泛使用拦惋，以確保各類型的網(wǎng)頁真實匆浙，保護(hù)賬戶和保持用戶通信，身份和網(wǎng)絡(luò)瀏覽的私密性厕妖。

另外首尼，還有一種安全超文本傳輸協(xié)議（S-HTTP）的HTTP安全傳輸實現(xiàn)，但是HTTPS的廣泛應(yīng)用而成為事實上的HTTP安全傳輸實現(xiàn)言秸，S-HTTP并沒有得到廣泛支持软能。

ps:翻閱資料發(fā)現(xiàn),S-HTTP的原理是對于每次數(shù)據(jù)的交互都進(jìn)行 RSA非對稱加密,對比HTTPS來說,S-HTTP加密單次事務(wù)的交互,而HTTPS則是對通信層進(jìn)行加密,我想效率和普適性可能也是決定市場采用HTTPS而不是S-HTTP的一大因素。

1.1 TLS/SSL

1.1.1 介紹

傳輸層安全性協(xié)議（英語：Transport Layer Security举畸，縮寫：TLS）及其前身安全套接層（英語：Secure Sockets Layer埋嵌，縮寫：SSL）是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信提供安全及數(shù)據(jù)完整性保障俱恶。網(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 1.0標(biāo)準(zhǔn)文件（RFC 2246）聪全。隨后又公布TLS 1.1（RFC 4346泊藕，2006年）、TLS 1.2（RFC 5246难礼，2008年）和TLS 1.3（RFC 8446娃圆，2018年）。在瀏覽器蛾茉、電子郵件讼呢、即時通信、VoIP谦炬、網(wǎng)絡(luò)傳真等應(yīng)用程序中悦屏，廣泛使用這個協(xié)議。許多網(wǎng)站键思，如Google础爬、Facebook、Wikipedia等也以這個協(xié)議來創(chuàng)建安全連線吼鳞，發(fā)送資料看蚜。目前已成為互聯(lián)網(wǎng)上保密通信的工業(yè)標(biāo)準(zhǔn)。

SSL包含記錄層（Record Layer）和傳輸層赔桌，記錄層協(xié)議確定傳輸層數(shù)據(jù)的封裝格式供炎。傳輸層安全協(xié)議使用X.509認(rèn)證，之后利用非對稱加密演算來對通信方做身份認(rèn)證纬乍，之后交換對稱密鑰作為會談密鑰（Session key）碱茁。這個會談密鑰是用來將通信兩方交換的資料做加密，保證兩個應(yīng)用間通信的保密性和可靠性仿贬，使客戶與服務(wù)器應(yīng)用之間的通信不被攻擊者竊聽纽竣。

1.1.2 數(shù)字證書

是用于公開密鑰基礎(chǔ)建設(shè)的電子文件，用來證明公開密鑰擁有者的身份茧泪。此文件包含了公鑰信息蜓氨、擁有者身份信息（主體）、以及數(shù)字證書認(rèn)證機(jī)構(gòu)（發(fā)行者）對這份文件的數(shù)字簽名队伟，以保證這個文件的整體內(nèi)容正確無誤穴吹。擁有者憑著此文件，可向電腦系統(tǒng)或其他用戶表明身份嗜侮，從而對方獲得信任并授權(quán)訪問或使用某些敏感的電腦服務(wù)港令。電腦系統(tǒng)或其他用戶可以透過一定的程序核實證書上的內(nèi)容啥容，包括證書有否過期、數(shù)字簽名是否有效顷霹，如果你信任簽發(fā)的機(jī)構(gòu)咪惠，就可以信任證書上的密鑰，憑公鑰加密與擁有者進(jìn)行可靠的通信淋淀。

簡而言之遥昧，認(rèn)證機(jī)構(gòu)用自己的私鑰對需要認(rèn)證的人（或組織機(jī)構(gòu)）的公鑰施加數(shù)字簽名并生成證書，即證書的本質(zhì)就是對公鑰施加數(shù)字簽名朵纷。

人們透過信任數(shù)字證書認(rèn)證機(jī)構(gòu)的根證書炭臭、及其使用公開密鑰加密作數(shù)字簽名核發(fā)的公開密鑰認(rèn)證，形成信任鏈架構(gòu)袍辞，已在TLS實現(xiàn)并在萬維網(wǎng)的HTTPS鞋仍、在電子郵件的SMTPS和STARTTLS廣泛應(yīng)用。業(yè)界現(xiàn)行的標(biāo)準(zhǔn)是國際電信聯(lián)盟電信標(biāo)準(zhǔn)化部門制定的X.509[2]革屠，并由IETF發(fā)行的RFC 5280詳細(xì)述明凿试。

1.1.3 x.509

X.509是密碼學(xué)里公鑰證書的格式標(biāo)準(zhǔn)。X.509證書已應(yīng)用在包括TLS/SSL在內(nèi)的眾多網(wǎng)絡(luò)協(xié)議里似芝，同時它也用在很多非在線應(yīng)用場景里那婉，比如電子簽名服務(wù)。X.509證書里含有公鑰党瓮、身份信息（比如網(wǎng)絡(luò)主機(jī)名详炬，組織的名稱或個體名稱等）和簽名信息（可以是證書簽發(fā)機(jī)構(gòu)CA的簽名，也可以是自簽名）寞奸。對于一份經(jīng)由可信的證書簽發(fā)機(jī)構(gòu)簽名或者可以通過其它方式驗證的證書呛谜，證書的擁有者就可以用證書及相應(yīng)的私鑰來創(chuàng)建安全的通信，對文檔進(jìn)行數(shù)字簽名枪萄。

除了證書本身功能隐岛，X.509還附帶了證書吊銷列表和用于從最終對證書進(jìn)行簽名的證書簽發(fā)機(jī)構(gòu)直到最終可信點為止的證書合法性驗證算法。

X.509是ITU-T標(biāo)準(zhǔn)化部門基于他們之前的ASN.1定義的一套證書標(biāo)準(zhǔn)瓷翻。

1.2 加密相關(guān)

1.2.1 Hash

Hash聚凹，一般翻譯做散列、雜湊齐帚，或音譯為哈希妒牙，是把任意長度的輸入（又叫做預(yù)映射pre-image）通過散列算法變換成固定長度的輸出，該輸出就是散列值对妄。

Hash算法也被稱為散列算法湘今，Hash算法雖然被稱為算法，但實際上它更像是一種思想剪菱。Hash算法沒有一個固定的公式摩瞎，只要符合散列思想的算法都可以被稱為是Hash算法拴签。

特點: 無法反向破解,可以用來校驗唯一性.

1.2.2 對稱加密

采用單鑰密碼系統(tǒng)的加密方法，同一個密鑰可以同時用作信息的加密和解密旗们，這種加密方法稱為對稱加密

常見: AES DES 3DES 特點:效率高

1.2.3 非對稱加密

一對密鑰,公鑰和私鑰,公鑰加密的數(shù)據(jù)只能通過私鑰來解密,私鑰加密的數(shù)據(jù)只能通過公鑰解密. 保證非對稱加密的安全性是極大整數(shù)的因數(shù)分解(數(shù)學(xué)實現(xiàn)基于互質(zhì),歐拉函數(shù),歐拉定理,模反,具體不詳細(xì)解釋),wiki是這么說的:

對極大整數(shù)做因數(shù)分解的難度決定了RSA算法的可靠性篓吁。換言之，對一極大整數(shù)做因數(shù)分解愈困難蚪拦，RSA算法愈可靠。

假如有人找到一種快速因數(shù)分解的算法冻押，那么RSA的可靠性就會極度下降驰贷。但找到這樣的算法的可能性是非常小的。今天只有短的RSA密鑰才可能被暴力破解洛巢。到2008年為止括袒，世界上還沒有任何可靠的攻擊RSA算法的方式。

只要密鑰長度足夠長稿茉，用RSA加密的信息實際上是不能被解破的锹锰。

常見: RSA 特點:效率低,耗時長

1.3 為什么要引入HTTPS

使用http交互信息存在以下隱患:

• 通信使用明文（不加密），內(nèi)容會被竊聽

• 不驗證通信方的的身份漓库，因此有可能遭遇偽裝

• 無法驗證報文的完整性恃慧，所以可能被篡改

1.4 總結(jié)

個人來看,由于HTTP的不安全性,急需一個安全的協(xié)議做補(bǔ)充,而HTTPS就是在HTTP協(xié)議的基礎(chǔ)上,添加了傳輸層安全性協(xié)議(TLS/SSL),TLS/SSL是一個協(xié)議標(biāo)準(zhǔn),而x.509則是這個協(xié)議標(biāo)準(zhǔn)的一個實現(xiàn).而x.509就用到了加密相關(guān)的hash算法,對稱加密算法,非對稱加密算法.

2.HTTPS的執(zhí)行流程

image.png

1.ClientHello 首先https請求是基于http的，也就是基于tcp的渺蒿，所以先得建立tcp三次握手痢士，這個就不說了，然后tcp握手后是SSL層的握手茂装，也就是圖中的ClientHello消息怠蹂，client發(fā)送本地最新的TLS版本、算法組合的一個集合和其他很多輔助的信息少态，并且生成一個隨機(jī)數(shù)A城侧。具體的內(nèi)容可以看下圖：

image

可以看到隨機(jī)數(shù)（Random）是一個GMT UNIX時間加上一串隨機(jī)字節(jié)，算法組合（Cipher Suite）有26種彼妻。

2.ServerHello Server收到這些信息后比對自己的TLS版本嫌佑，選擇其中低的一個作為返回，并且從算法組合的集合中選出一種合適的組合澳骤，然后同樣也生成一個隨機(jī)數(shù)B歧强，一起打包到ServerHello中傳回給Client。內(nèi)容如圖：

image

這里選出了一種CipherSuite算法組合为肮。

3.Certificatie,ServerHelloDone 服務(wù)端在選出溝通策略之后將自己的證書信息告訴Client端（Certificate）摊册，通知Client關(guān)于秘鑰更新的信息（ServerkeyExchange），接下去就看你的了颊艳，并且表示該發(fā)的都發(fā)給你了茅特，我的Hello結(jié)束了（ServerHelloDone）忘分。

image

4.Client收到2，3步的信息后先驗證證書是不是合法的白修，包括它的頒發(fā)機(jī)構(gòu)妒峦，域名匹配，有限期限等兵睛，這個具體的過程就不探究了肯骇，只要知道這些步驟就行了。

5.證書驗證通過之后祖很，生成隨機(jī)數(shù)C1,然后用證書內(nèi)容中的公鑰通過服務(wù)器選擇的非對稱加密算法加密笛丙，得出為C2。

6.由之前的三個隨機(jī)數(shù)A假颇、B胚鸯、C1通過一個偽隨機(jī)函數(shù)再生成一個D，注意笨鸡！這個是最終http真正使用的加密秘鑰＝！形耗！哥桥。

7.由D再次通過偽隨機(jī)函數(shù)生成一個秘鑰組，包含6個秘鑰趟脂，假設(shè)為P1,P2,P3,P4,P5,P6泰讽。

8.ClientKeyExchange。通知Server秘鑰相關(guān)的信息昔期，發(fā)送第5步中算出的C2給Server端已卸。

9.Client端發(fā)送ClientKeyExchange之后，計算之前所有與Server端交互消息的hash值硼一，假設(shè)為client_hash1累澡，用步驟7中得到的其中一個P1進(jìn)行加密，結(jié)果為E般贼。

10.Server端收到C2后用私鑰結(jié)合非對稱算法解密C2愧哟，得到C1。

11.同樣的Server端也根據(jù)A哼蛆、B蕊梧、C1由偽隨機(jī)函數(shù)生成D(最終的加密秘鑰！Ｈ椤肥矢！),再由D得出秘組鑰（P1-P6），因為這里涉及到的算法都是一樣的叠洗，所以得出的秘鑰也是一樣的甘改。

12.Server端計算之前所有和Client端交互消息的hash值旅东，假設(shè)為server_hash2，大家可能發(fā)現(xiàn)了十艾，11抵代、12跟Client端的6、7忘嫉、9過程一致霹崎，只是少了9中的P1加密過程妆艘。

13.這個時候Client端會發(fā)送ChangeCipherSpec消息和EncryptedHandshakeMessage消息另凌，通知Server端接下去使用選定的加密策略來通信了翁授，并且將第9步中的E傳給了Server。（這里幾個步驟的順序只是為了好理解一點而這樣排列愧杯，實際兩條線是獨(dú)立在處理信息的，所以先后順序不能保證）

14.這個時候Client會再次計算之前握手消息的hash值鞋既，得出結(jié)果client_hash2力九。

15.Server在收到EncryptedHandshakeMessage消息帶過來的E之后，利用步驟11中的P1解密E邑闺，由于加密算法和P1都是相同的跌前，所以這里還原出了client_hash1，然后與步驟12中的server_hash2比對陡舅，如果一樣說明之前的幾條協(xié)商秘鑰的消息都被對方正確無誤的理解了抵乓。

16.Server端再次對之前的消息做hash值，得出server_hash2靶衍，用P2進(jìn)行加密結(jié)果為F灾炭，然后通過ChangeCipherSpec-EncryptedHandshakeMessage消息傳給Client端。

17.Client收到Server的消息后根據(jù)P2解密F還原得出server_hash2颅眶，與client_hash2比對如果一致蜈出，則認(rèn)為之前的交互過程都是正確無誤且被對方理解的。至此涛酗，整個握手過程就結(jié)束了铡原，之后的http數(shù)據(jù)報就會被之前確定的加密策略和加密秘鑰D進(jìn)行加密傳輸了。

總結(jié)：其實最終我們發(fā)現(xiàn)整個握手過程中并沒有直接傳輸最終的加密秘鑰D商叹，而且交換了一些算法策略和生成D的一些參數(shù)燕刻，這樣相對來說會更安全一點，直接傳D的話這個過程就由Client端完成了剖笙，中間如果出什么差錯Server會無感知無條件的信任Client傳過來的D卵洗，就有可能出現(xiàn)問題了，所以采用只傳策略和參數(shù)枯途，并且由雙方共同參與忌怎，這樣安全性和正確性就會提高很多籍滴。貼一張整個過程的抓包圖:

image

3.HTTPS的一些細(xì)節(jié)

1.HTTPS過程中為什么要使用隨機(jī)數(shù)?

主要是為了防止重放攻擊(回放攻擊),重放攻擊是指攻擊者發(fā)送一個目的主機(jī)已接收過的包，來達(dá)到欺騙系統(tǒng)的目的榴啸，主要用于身份認(rèn)證過程孽惰，破壞認(rèn)證的正確性。

2.HTTPS必須在每次請求中都要先在SSL層進(jìn)行握手?

瀏覽器客戶端訪問同一個https服務(wù)器鸥印，可以不必每次都進(jìn)行完整的TLS Handshake勋功，因為完整的TLS Handshake，涉及到認(rèn)證服務(wù)器的身份（數(shù)字證書）库说，需要做大量的非對稱加密/解密運(yùn)算狂鞋，此外還需要做偽隨機(jī)函數(shù)PRF，通過“Pre-Master Key”潜的、“Server Nonce”骚揍、“Client Nonce”共同推導(dǎo)出session key，非對稱加密算法RSA/DSA非常耗費(fèi)CPU資源啰挪。

為了克服這個困難信不，服務(wù)器維護(hù)一個以session ID為索引的結(jié)構(gòu)體，用于臨時存放session key亡呵，并在TLS handshake 階段分享給瀏覽器抽活。

當(dāng)瀏覽器重新連接https 服務(wù)器時，TLS handshake 階段锰什，出示自己的session ID下硕，服務(wù)器獲得session ID，以此為索引汁胆，可以獲得和該瀏覽器共同擁有的session key梭姓，使用session key可以直接對用戶流量做加密/解密動作。

這樣避免了大量的冪嫩码、指數(shù)計算糊昙。

當(dāng)然，如果服務(wù)器沒有查找到session ID谢谦，雙方的TLS安全參數(shù)協(xié)商按照正常流程走释牺。

使用 charles 抓包進(jìn)行分析 Session ID 的使用情況。假設(shè)有一次請求回挽，服務(wù)端允許使用 Session ID没咙，那么會有下面的流程：

• 客戶端的 Client Hello 帶上 Session ID

• 服務(wù)端復(fù)用 Session ID 后，會直接略過協(xié)商加密密鑰的過程千劈，直接發(fā)出一個 Change Cipher Spec 報文

• 然后就是加密的握手信息報文

  
  
  5A186DAE-E424-4FD2-9B4A-FC154DACDB4B.png

3.為什么我用Charles抓包可以看到HTTPS的內(nèi)容

1.客戶端向服務(wù)器發(fā)起HTTPS請求

2.Charles攔截客戶端的請求祭刚，偽裝成客戶端向服務(wù)器進(jìn)行請求

3.服務(wù)器向“客戶端”（實際上是Charles）返回服務(wù)器的CA證書

4.Charles攔截服務(wù)器的響應(yīng)，獲取服務(wù)器證書公鑰，然后自己制作一張證書涡驮，將服務(wù)器證書替換后發(fā)送給客戶端暗甥。（這一步，Charles拿到了服務(wù)器證書的公鑰）

5.客戶端接收到“服務(wù)器”（實際上是Charles）的證書后捉捅，生成一個對稱密鑰撤防，用Charles的公鑰加密，發(fā)送給“服務(wù)器”（Charles）

6.Charles攔截客戶端的響應(yīng)棒口，用自己的私鑰解密對稱密鑰寄月，然后用服務(wù)器證書公鑰加密，發(fā)送給服務(wù)器无牵。（這一步漾肮，Charles拿到了對稱密鑰

7.服務(wù)器用自己的私鑰解密對稱密鑰，向“客戶端”（Charles）發(fā)送響應(yīng)

8.Charles攔截服務(wù)器的響應(yīng)茎毁，替換成自己的證書后發(fā)送給客戶端

至此克懊，連接建立，Charles拿到了 服務(wù)器證書的公鑰 和 客戶端與服務(wù)器協(xié)商的對稱密鑰七蜘，之后就可以解密或者修改加密的報文了保檐。

(核心點:Charles生成了自己一套公鑰,私鑰,和自己的證書,因為自己的證書無法通過校驗,所以需要客戶端主動授權(quán),客戶端授權(quán)后,charles就可以完全代替客戶端與服務(wù)端交互,與服務(wù)端交互用的是服務(wù)端的公鑰加密,與客戶端交互用的是charles自己的私鑰解密)