文藝求關注.png

<h5>一 背景知識</h5>

1.基本術語 HTTP|HTTPS|SSL|TLS
2.HTTP和TCP的關系渡处，如長連接和短連接等
3.加密算法的大概知識（對稱加密和非對稱加密）
4.CA證書的用途

<h5>二 基本術語</h5>

<b>HTTP:</b>是一個專門用來傳輸web內(nèi)容的協(xié)議。

• 版本歷史：
  <b>1）</b>0.9 90年代推出時候為0.9版本
  <b>2）</b>1.0 之后推出了1.0版本 該版本曾被廣泛應用過
  <b>3）</b>1.1 這個 1.1 版本是1995年底開始起草的（技術文檔是 RFC2068）梳玫，并在1999年正式發(fā)布（技術文檔是 RFC2616）
  <b>4）</b>2.0 2015年發(fā)布

<b>SSL:</b>是Secure Sockets Layer的縮寫，翻譯成中文叫做安全套接字層

• 上世界90年代由網(wǎng)景公司設計（該公司還發(fā)明了"!!!，js腳本等）
• HTTP協(xié)議在傳輸數(shù)據(jù)的時候是明文傳輸?shù)模赡艽嬖跀?shù)據(jù)泄露（被嗅探）和篡改的問題艳汽。
• 而SSL協(xié)議就是為了解決上述問題而提出的。到了1999年对雪，SSL 因為應用廣泛河狐，已經(jīng)成為互聯(lián)網(wǎng)上的事實標準。IETF 就在那年把 SSL 標準化瑟捣。標準化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫）馋艺，中文叫做“傳輸層安全協(xié)議”。所以迈套，SSL和TLS可以視作同一個東西的不同階段捐祠。

<b>HTTPS:</b>即 HTTP + SSL

<h5>三 HTTP和TCP的關系</h5>

<b>1）HTTP協(xié)議和TCP協(xié)議</b>

• TCP協(xié)議是HTTP協(xié)議的基石，即HTTP協(xié)議需要依靠TCP協(xié)議來傳輸數(shù)據(jù)桑李。
• HTTP是應用層協(xié)議之一踱蛀。
• TCP是傳輸層協(xié)議之一。
• 有很多應用層的協(xié)議（如HTTP|SMTP等）都以TCP協(xié)議為基礎來進行數(shù)據(jù)傳輸贵白。
• 傳輸層協(xié)議主要有TCP和UDP兩種率拒，區(qū)別在于TCP協(xié)議是可靠的。

<b>2）短連接和長連接</b>

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

<b>3）HTTP各個版本中TCP的連接方式</b>

• 假設有一個網(wǎng)頁，里面包含好多圖片呛伴，還包含好多【外部的】CSS 文件和 JS 文件寥掐。在“短連接”的模式下，瀏覽器會先發(fā)起一個 TCP 連接磷蜀，拿到該網(wǎng)頁的 HTML 源代碼（拿到 HTML 之后，這個 TCP 連接就關閉了）百炬。然后褐隆，瀏覽器開始分析這個網(wǎng)頁的源碼，知道這個頁面包含很多外部資源（圖片剖踊、CSS庶弃、JS）衫贬。然后針對【每一個】外部資源，再分別發(fā)起一個個 TCP 連接歇攻，把這些文件獲取到本地（同樣的固惯，每抓取一個外部資源后，相應的 TCP 就斷開）
• 相反缴守，如果是“長連接”的方式葬毫，瀏覽器也會先發(fā)起一個 TCP 連接去抓取頁面。但是抓取頁面之后屡穗，該 TCP 連接并不會立即關閉贴捡，而是暫時先保持著（所謂的“Keep-Alive”）。然后瀏覽器分析 HTML 源碼之后村砂，發(fā)現(xiàn)有很多外部資源烂斋，就用剛才那個 TCP 連接去抓取此頁面的外部資源。
  HTTP1.0 版本默認使用短連接础废，也叫作一次性連接汛骂。因為那個時候網(wǎng)頁簡單。
  HTTP1.1 版本中默認使用長連接评腺，因為此時網(wǎng)頁已經(jīng)變得足夠復雜帘瞭，如果繼續(xù)使用短連接的方式效率太低（因為建立TCP連接需要時間和CPU成本）

<h5>四 加密和解密</h5>

• 加密：給你一個明文，可以通過一定的加密算法得到一串密文的過程歇僧。明文————>密文
• 解密：給你一個密文图张，可以通過對應的解密算法得到初始原文的過程。密文————>明文
• 對稱加密：加密和解密使用相同的密鑰诈悍。"速度快|效率高|存在密鑰傳輸安全的問題"
• 非對稱加密：加密和解密使用不同的密鑰祸轮。擁有一個公鑰一個私鑰，使用公鑰進行加密使用私鑰來進行解密侥钳。"速度慢|安全性強"
  對稱加密和非對稱加密的特點也影響到了SSL協(xié)議的設計适袜。

<h5>五 HTTPS協(xié)議為什么要設計成這樣？（WHY）</h5>

<b>1）兼容性問題</b>

• 比如：①已有的web應用應該盡可能無縫的遷移到HTTPS舷夺，最好是做到零成本苦酱。②瀏覽器廠家改動應該盡可能的小
  • ①"HTTPS協(xié)議還是基于TCP來進行傳輸"
  • ②"把HTTP協(xié)議包裹起來成為一個新的協(xié)議"
  • ③好比以前的HTTP協(xié)議是塑料水管容易戳破，現(xiàn)在就在以前塑料水管的基礎上再包上一層金屬管给猾。這樣就可以做到疫萤，原有的管道能夠照常運行，且不再容易被戳破敢伸。

<b>2）可擴展性</b>

• SSL/TLS 可以跟很多常用的應用層協(xié)議（比如：FTP扯饶、SMTP、POP、Telnet）搭配尾序，來強化這些應用層協(xié)議的安全性
• 如果把SSL看成是一層金屬管钓丰，那么他不僅能夠對輸水管道進行加固，而且也能對輸電管道每币，輸煤氣管道進行加固携丁。

<b>3）保密性</b>

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

<b>4）完整性</b>

• 能夠確保HTTP協(xié)議的內(nèi)容不被修改。
• 因為你的網(wǎng)絡流量需要經(jīng)過 ISP 的線路才能到達公網(wǎng)痕慢。如果你使用的是明文的 HTTP尚揣，ISP 很容易就可以在你訪問的頁面中植入廣告

<b> 5）真實性</b>
HTTPS 協(xié)議必須有某種機制來確保“真實性”的需求掖举。
如何確定我們訪問的網(wǎng)站是真實的快骗，關于這一點僅僅根據(jù)域名來判斷是不靠譜的。因為我們的DNS系統(tǒng)本身就是不可靠的（域名欺騙和域名劫持）塔次，所以我們看到的網(wǎng)址里面的域名未必是真實的方篮。

<b> 6）性能</b>

• 使用HTTPS的時候性能不能太差，因此在設計的時候需要考慮兩個問題：
  ① 加密和解密采用什么樣的方式來進行：對稱加密還是非對稱加密励负？
  ② 采用什么樣的連接方式：短連接還是長連接

<h5>六 設計HTTPS協(xié)議的難點</h5>

個人認為最難的地方在于對傳輸數(shù)據(jù)進行加密和解密這一塊藕溅，也就是密鑰交換。
如果客戶端和服務器端需要進行HTTPS通信继榆，那么首先需要協(xié)商雙方應該采用什么樣的加密算法巾表，確定了加密算法之后還需要傳輸加密和解密中可能涉及到的密鑰，而此時尚處于握手階段略吨，所有的數(shù)據(jù)傳輸都還是明文的集币，那么應該如何安全的傳輸密鑰成為最大的問題。

<h5>七 解決密鑰安全傳輸?shù)膯栴}</h5>

<b>1）單獨使用對稱加密來傳輸</b>

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

<b>2）使用非對稱加密來傳輸 效率太低</b>
<b>3）使用非對稱加密+對稱加密：</b>

• 存在中間人攻擊隱患（需要具備篡改通信數(shù)據(jù)的能力）[偽造公鑰][MITM]

<b>4）正是因為"缺乏身份認證機制"，所以我們需要考慮身份認證的問題考榨。</b>

<h5>八 身份認證的幾種方式</h5>

1) 基于某些私密共享的信息 |前提——通信雙方認識彼此熟悉
2）基于雙方都信任的公證人 |如果通信雙方都不認識彼此跨细，那么就只能采用該模式（如C2C）
   那么，誰來充當這個公證人呢河质？"CA"華麗登場

如何解決SSL的身份認證問題：使用CA
CA數(shù)字證書在技術實現(xiàn)上依賴于非對稱加密技術

<h5>維基百科中對HTTPS的定義</h5>

超文本傳輸安全協(xié)議（英語："Hypertext Transfer Protocol Secure"冀惭，縮寫：HTTPS申鱼，也被稱為HTTP over TLS，HTTP over SSL或HTTP Secure）是一種網(wǎng)絡安全傳輸協(xié)議云头。在計算機網(wǎng)絡上，HTTPS經(jīng)由超文本傳輸協(xié)議進行通信淫半，但利用SSL/TLS來對數(shù)據(jù)包進行加密溃槐。HTTPS開發(fā)的主要目的，是提供對網(wǎng)絡服務器的身份認證科吭，保護交換數(shù)據(jù)的隱私與完整性昏滴。這個協(xié)議由網(wǎng)景公司（Netscape）在1994年首次提出，隨后擴展到互聯(lián)網(wǎng)上对人。

擴充知識：
網(wǎng)景（英語：Netscape）是一個自1994年開始的品牌谣殊。"1994年4月4"日它最初成立的名字是'馬賽克通信公司'。該公司有一款名稱為"網(wǎng)景導航者"的瀏覽器牺弄，因此"網(wǎng)景"也是是網(wǎng)景通信公司（Netscape Communications Corporation）的常用簡稱姻几。網(wǎng)景通信公司曾經(jīng)是一家美國的電腦服務公司，以其生產(chǎn)的同名網(wǎng)頁瀏覽器而聞名势告。1998年11月蛇捌，網(wǎng)景被美國在線（AOL）收購，2003年7月網(wǎng)景被解散咱台，網(wǎng)景大部分的程序員被解雇络拌，2008年3月1日美國在線宣布停止對網(wǎng)景瀏覽器的技術支持。

網(wǎng)景公司（Netscape）在1994年推出首版網(wǎng)頁瀏覽器回溺，網(wǎng)景導航者時春贸，推出HTTPS協(xié)議，以SSL進行加密遗遵，這是SSL的起源萍恕。IETF將SSL進行標準化，1999年公布了第一版TLS標準文件

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

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

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

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

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

• ③ 服務器發(fā)回其數(shù)字證書登澜，此證書通常包含服務器的名稱阔挠、受信任的證書頒發(fā)機構（CA）和服務器的公鑰。

• ④ 客戶端確認其頒發(fā)的證書的有效性脑蠕。

• ⑤ 為了生成會話密鑰用于安全連接购撼，客戶端使用服務器的公鑰加密隨機生成的密鑰跪削，并將其發(fā)送到服務器，只有服務器才能使用自己的私鑰解密迂求。

• ⑥ 利用隨機數(shù)碾盐，雙方生成用于加密和解密的對稱密鑰。

  以上就是TLS協(xié)議的握手揩局，握手完畢后的連接是安全的毫玖，直到連接（被）關閉。如果上述任何一個步驟失敗凌盯，TLS握手過程就會失敗付枫，并且斷開所有的連接。
  

TLS 1.2在 RFC 5246 中定義驰怎，于2008年8月發(fā)表阐滩。它基于更早的TLS 1.1規(guī)范。

• 主要區(qū)別包括：
  • ① 可使用密碼組合選項指定偽隨機函數(shù)使用SHA-256替換MD5-SHA-1組合县忌。
  • ② 可使用密碼組合選項指定在完成消息的哈希認證中使用SHA-256替換MD5-SHA-1算法掂榔，但完成消息中哈希值的長度仍然被截斷為96位。
  • ③ 在握手期間MD5-SHA-1組合的數(shù)字簽名被替換為使用單一Hash方法芹枷，默認為SHA-1衅疙。
  • ④ 增強服務器和客戶端指定Hash和簽名算法的能力。
  • ⑤ 擴大經(jīng)過身份驗證的加密密碼鸳慈，主要用于GCM和CCM模式的AES加密的支
  • ⑥ 添加TLS擴展定義和AES密碼組合饱溢。
  • ⑦ 所有TLS版本在2011年3月發(fā)布的RFC 6176中刪除了對SSL的兼容，這樣TLS會話將永遠無法協(xié)商使用SSL 2.0以避免安全問題走芋。

//HTTPS協(xié)議中關于SSL/TLS層握手過程的說明

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

• 客戶端

  • ① 我想要和你[服務端]進行安全的通話绩郎，我這里的支持的對稱加密算法有DES|AES|RC5,密鑰交換算法有RSA和DH,消息摘要算法有MD5和SHA1|SHA256
  • ② [我說完了]

• 服務端

  • ① 我們使用AES-RSA-SHA256的組合方式吧。
    -② 服務器端證書發(fā)送給客戶端翁逞，并說[這是我的證書肋杖，里面有我的信息和公鑰，你拿去驗證一下我的身份吧]挖函。
    -③ [我說完了]
    "——————該階段雙方已經(jīng)協(xié)商好了加密[AES]_會話密鑰交換[RSA]消息校驗[SHA256]的一套方法状植。

<b>階段二：驗證證書的有效性并交換會話密鑰</b>

• 客戶端

  • ① 檢查證書上面的信息，并通過已有的CA證書驗證服務器端證書的真實性怨喘，如果有誤則發(fā)出警告并斷開連接津畸。
  • ② 客戶端從接收到的證書中提取出公鑰
  • ③ 生成隨機數(shù)作為會話密鑰，即session key,該密鑰將被在建立安全通道后用作對稱加密的密鑰必怜。
  • ④ 使用提取出來的公鑰加密之前生成的會話密鑰肉拓，封裝成一個ClientKeyExchange消息[其實就是使用公鑰對會話密鑰進行加密之后的密文]。
  • ⑤ 以后我就要使用session key對消息進行加密來和你進行通信了梳庆！
  • ⑥ [我說完了]

• 服務端

  • ① 使用自己的私鑰對收到ClientKeyExchange消息進行解密暖途，得到會話密鑰卑惜，即session key。
    "【注】該消息由客戶端使用服務器端發(fā)送給其的公鑰進行加密驻售，所以服務器端可以使用私鑰來解密露久。</br>
  • ② 使用會話密鑰加密初始化向量
  • ③ 加密HMAC的密鑰
  • ④ 以后我也要使用session key對消息進行加密來和你進行通信了！
  • ⑤ [我說完了]
    "——————該階段完成會話密鑰session key的安全交換欺栗。

<b>階段三：使用會話密鑰加密消息抱环，所有的消息在安全的信道中傳輸</b>

• 客戶端

  • ① 要發(fā)送給服務端的消息是CMsg:我的小秘密是....
  • ② 使用會話秘鑰對CMsg進行對稱加密得到密文CMsg1:xxxxxooooooo
  • ③ 把CMsg1發(fā)送給服務器端

• 服務端

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

  • ② 使用本地的私鑰對收到的消息Msg1進行解密，得到原文為CMsg:我的小秘密是....

  • ③ 對客戶端的消息進行響應纸巷，要發(fā)送給客戶端的消息為SMsg:其它人不會聽到的，我也有個小秘密...

  • ④ 使用會話密鑰對SMsg進行對稱加密得到密文SMsg1:oooooxxxxxxx

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

    "——————該階段在傳輸之前使用會話密鑰對所有的消息進行對稱加密處理眶痰。
    

關注一下又不會懷孕.png