作者: 張洋
日期：2019-10

原創(chuàng)文章，轉(zhuǎn)載請注明出處

題目本來是在公司中做的一次分享攀圈，后來覺得30分鐘通過PPT能講的內(nèi)容實(shí)在有限暴凑，故整理成了這篇文章胆建。

帶著數(shù)據(jù)去旅行

一次完整的HTTP請求

在講HTTPS之前揩慕，我們有必要了解一下HTTP協(xié)議歼捏。先看一個完整的HTTP請求：

http.png

上面是我用Wireshark工具所抓到的一次完整HTTP請求的樣子霞溪。

• 首先可以看到的是三個TCP協(xié)議的數(shù)據(jù)包妇斤，也就是我們常說的TCP三次握手钞翔，在這之后蜕提，兩臺電腦之間的連接就建立起來了全庸。
• 繼續(xù)向下就可以看到HTTP請求了忧风，Request和Response一來一回默色，很好辨認(rèn)。大家還可以注意到在每個HTTP數(shù)據(jù)包之后還跟了一個TCP的包狮腿，這是TCP協(xié)議的確認(rèn)腿宰，表示告訴發(fā)送者:"你剛才的報(bào)文我已經(jīng)收到了"。
  頁面底部顯示了一個原始的HTTP GET請求報(bào)文的樣子缘厢，為什么請前面會出現(xiàn)亂碼呢吃度？其實(shí)前面的亂碼就是TCP/IP協(xié)議。不同于HTTP協(xié)議可以用字符編碼贴硫，TCP/IP的傳遞需要極致壓縮數(shù)據(jù)量椿每，每一個數(shù)據(jù)位就表示了一種特定的意思，需要使用TCP/IP的規(guī)則去解析（就像我們在軟件上面頁面所看到的解析結(jié)果）英遭，而不能使用字符編碼來閱讀间护。

什么是分層網(wǎng)絡(luò)模型

互聯(lián)網(wǎng)發(fā)展早期，需要解決的一個重要問題就是電腦之間如何傳輸數(shù)據(jù)挖诸。人們需要找到一種大家都認(rèn)同的規(guī)范汁尺，每個想要相互連接的計(jì)算機(jī)都需要按照規(guī)范來辦事。這期間有一個協(xié)議脫穎而出多律，他就是現(xiàn)在應(yīng)用非常廣泛的TCP/IP協(xié)議痴突，它規(guī)定了網(wǎng)絡(luò)上的計(jì)算機(jī)要如何找到另一臺計(jì)算機(jī)搂蜓，并且如何與之建立連接。TCP/IP的發(fā)明者還非常有遠(yuǎn)見地提出了“網(wǎng)絡(luò)分層”的概念苞也，將復(fù)雜的網(wǎng)絡(luò)通信劃分成了多個層次洛勉，每個層次只需要關(guān)心自己的問題，將大問題劃分為了很多個小問題從而解決了網(wǎng)絡(luò)通信的難題如迟。就像我們寫代碼需要分層一樣(Service,Controller,Dao層等等)，每一層只需要關(guān)注自己的功能攻走。
值得注意的是殷勘，TCP/IP協(xié)議只有四層，而我們現(xiàn)在經(jīng)常說起的OSI七層網(wǎng)絡(luò)模型昔搂，是由國際標(biāo)準(zhǔn)組織（ISO）后來才提出來的玲销。在此之前，雖然TCP/IP協(xié)議非常優(yōu)秀摘符，但是奈何市面上還是各玩各的贤斜，所以ISO想要制定一個大一統(tǒng)的協(xié)議，在很多細(xì)節(jié)上進(jìn)行了細(xì)化逛裤，成就了我們現(xiàn)在所看到的七層網(wǎng)絡(luò)模型瘩绒。我們簡單對比一下OSI七層模型和TCP/IP的四層模型：

網(wǎng)絡(luò)模型對比.jpg

雖然OSI七層模型有更細(xì)分的設(shè)計(jì)，但是他也無法撼動TCP/IP已經(jīng)實(shí)行多年的統(tǒng)治地位带族，所以O(shè)SI模型現(xiàn)在更多是一種建議和標(biāo)準(zhǔn)锁荔。
在TCP/IP模型中，我們的HTTP協(xié)議蝙砌，TCP協(xié)議阳堕，IP協(xié)議分別位于應(yīng)用層，傳輸層和互聯(lián)網(wǎng)層择克。當(dāng)我們發(fā)起一次HTTP請求恬总，瀏覽器會按照HTTP協(xié)議的要求，拼裝出HTTP的數(shù)據(jù)肚邢，再調(diào)用下層TCP協(xié)議提供的API將HTTP數(shù)據(jù)封裝到TCP協(xié)議中壹堰，再往下針對IP協(xié)議再一次封裝，最后到達(dá)物理網(wǎng)絡(luò)層道偷，數(shù)據(jù)被發(fā)送出去缀旁。
目標(biāo)主機(jī)收到數(shù)據(jù)以后，反過來將包裝好的數(shù)據(jù)一層一層剝開勺鸦，最終得到我們要傳遞的信息并巍，然后再一次將要返回的數(shù)據(jù)經(jīng)過層層協(xié)議的打包返回到源主機(jī)。

帶著保險(xiǎn)箱去旅行

從上面的基礎(chǔ)知識我們不難發(fā)現(xiàn)换途，HTTP協(xié)議是非常簡單且高效懊渡。

1. HTTP直接運(yùn)行在TCP協(xié)議之上刽射，依靠TCP來實(shí)現(xiàn)自己的穩(wěn)定性。
2. HTTP使用明文傳輸剃执，數(shù)據(jù)可讀性和可擴(kuò)展性都非常好誓禁。

但是它的簡單高效也成為了一把雙刃劍，原始的HTTP請求就像是在網(wǎng)上裸奔肾档，所有信息都是明文傳遞摹恰，毫無安全可言。隨著科技的發(fā)展怒见，人們對安全俗慈、隱私的要求越來越高，特別是在現(xiàn)在萬物互聯(lián)的時(shí)代遣耍，敏感信息如果不經(jīng)過保護(hù)直接在網(wǎng)上傳播闺阱，將造成極大的隱患。

------在這樣的歷史浪潮中舵变，HTTPs應(yīng)運(yùn)而生酣溃。

HTTPs與HTTP的區(qū)別就在這個s上，它代表的是"TLS"纪隙，既安全傳輸層協(xié)議赊豌。TLS也是運(yùn)行在TCP之上的應(yīng)用層協(xié)議，但是與一般傳輸數(shù)據(jù)的協(xié)議不同瘫拣，TLS所關(guān)心的亿絮，只有安全。我們可以認(rèn)為TLS就是一個運(yùn)行在TCP上的保險(xiǎn)箱麸拄，現(xiàn)在我們將需要保護(hù)的數(shù)據(jù)先裝入這個保險(xiǎn)箱派昧，再經(jīng)過TCP發(fā)送出去，就能實(shí)現(xiàn)我們對于安全的需求拢切。我們將HTTP over TCP蒂萎，變成了HTTP over TLS over TCP。

那么這個保險(xiǎn)箱是如何工作的呢淮椰？這就是我們今天的重點(diǎn)五慈。

何謂安全

我們考慮一下兩個人寫信的場景，怎樣才能做到安全的遠(yuǎn)程交流呢主穗？

1. 我不想我們寫信的內(nèi)容被人看懂
2. 得想個辦法保證內(nèi)容不被人修改
3. 你得在信里面證明你的身份
4. 一旦證明了這是你寫的泻拦，以后你可不許抵賴

如果能夠做到這四點(diǎn)，那么我們的信應(yīng)該是比較安全的忽媒，而這四點(diǎn)正好對應(yīng)了我們信息安全領(lǐng)域中的四個要點(diǎn)争拐，既：

1. 機(jī)密性
2. 完整性
3. 身份認(rèn)證
4. 不可否認(rèn)

下面我們就逐一來分析一下HTTPs是如何做到這四點(diǎn)的：

1. 機(jī)密性

我們知道兩臺計(jì)算機(jī)之間要想傳輸數(shù)據(jù)，這些數(shù)據(jù)必然會經(jīng)過層層路由晦雨，這些節(jié)點(diǎn)上的每臺計(jì)算機(jī)理論上都能看到我們的數(shù)據(jù)架曹，所以安全的首要目標(biāo)就是對我們想要傳輸?shù)臄?shù)據(jù)進(jìn)行加密隘冲。
根據(jù)密碼學(xué)的知識，擺在我們面前的有兩種選擇---對稱加密和非對稱加密绑雄。
對稱加密使用一把密鑰展辞，加密解密都用它，在雙方都知道密鑰并且妥善保管的情況下理論上非常安全万牺。但是對于我們復(fù)雜的網(wǎng)絡(luò)環(huán)境罗珍，一臺服務(wù)器需要服務(wù)眾多的客戶，難道要為每個客戶都配置一個對稱加密的密鑰嗎脚粟？這顯然不現(xiàn)實(shí)靡砌。

對稱加密.png

那么非對稱加密呢？一把私鑰對應(yīng)一把公鑰珊楼，私鑰加密的內(nèi)容只有公鑰可以解開，公鑰加密的內(nèi)容也只有私鑰可以解開度液，那么我們在服務(wù)器上配置一把私鑰厕宗，再把公鑰發(fā)給所有客戶，是不是就行了呢堕担？

非對稱加密.png

答案是否定的已慢，原因有兩點(diǎn)：

1. 服務(wù)器是面向大眾客戶的，公鑰必然會公開霹购，誰都可以獲取佑惠，那么路由的中間節(jié)點(diǎn)一樣可以拿著這把公鑰解析服務(wù)器返回的報(bào)文。
2. 非對稱加密的性能無法適應(yīng)互聯(lián)網(wǎng)高并發(fā)的環(huán)境齐疙，所有請求都用非對稱加密會導(dǎo)致連接異常緩慢膜楷，無法使用。

基于上述兩點(diǎn)贞奋，HTTPs做了一個非常聰明的選擇赌厅，就是混合加密。現(xiàn)在我們在TCP三次握手的基礎(chǔ)上再引入TLS的四次握手轿塔，而這次會晤的重要目標(biāo)就是協(xié)商出密鑰特愿。為了便于理解我們先看一個簡單的模型：

1. 客戶端通過可靠的渠道獲取到服務(wù)器的公鑰。
2. 客戶端生成一個隨機(jī)數(shù)作為對稱加密的密鑰勾缭，也就是本次會話的主密鑰
   (實(shí)際上生成主密鑰需要Server-Client都參與揍障，通過相同的算法算出來，但是在老版本的RSA交換密鑰中最終的安全性還是客戶端保證的俩由，所以這里我們簡單認(rèn)為是客戶端生成了一個隨機(jī)數(shù)即可毒嫡，后面會詳細(xì)講到)
3. 客戶端用Server的公鑰將主密鑰加密傳輸給Server。

4. 后續(xù)交換內(nèi)容均用主密鑰進(jìn)行加密解密采驻。

   
   
   混合加密.png

2. 完整性

機(jī)密性我們可以滿足之后审胚，來看看第二個需要考慮的重點(diǎn)匈勋，完整性。
大家應(yīng)該也有注意到膳叨，我們在HTTPs握手模型中的前幾次數(shù)據(jù)交換也都是明文傳輸?shù)那⒔啵驗(yàn)殡p方還沒有協(xié)商出主密鑰的時(shí)候是無法進(jìn)行加密傳輸?shù)摹６谶@個過程中又有許多關(guān)鍵的信息菲嘴，這些信息我們需要有一定的手段保證他們不會被人修改饿自。
這時(shí)候就需要引入數(shù)字簽名。
在數(shù)字簽名中首先要提到的就是摘要算法（也就是我們常說的Hash函數(shù)龄坪，HTTPs中常見的有SHA-2族等）昭雌，它的作用是將任意長度的數(shù)據(jù)映射成一串固定長度的字符串。摘要算法有幾個特點(diǎn)：

1. 單向性健田，無法通過計(jì)算出來的字符串反推出原文
2. 雪崩效應(yīng)烛卧，即原文中一點(diǎn)點(diǎn)微小的改變也會導(dǎo)致計(jì)算出的字符串完全不一樣，無法通過規(guī)律逆向推導(dǎo)妓局。
3. 抵抗沖突总放，既然是將無限打的數(shù)據(jù)集映射到有限大的空間中（字符串空間），勢必會出現(xiàn)映射沖突的可能好爬，既不同的數(shù)據(jù)映射出的字符串是相同的局雄。抵抗沖突是摘要算法的一個重要指標(biāo)，一個好的摘要算法他的沖突概率應(yīng)該是非常非常小的存炮。
   這三個特點(diǎn)使得我們可以很好的驗(yàn)證原文數(shù)據(jù)的完整性炬搭，我們只需要使用SHA-2計(jì)算出報(bào)文的摘要，將它附在報(bào)文后面穆桂。接收方收到報(bào)文后宫盔，再通過同樣的算法計(jì)算報(bào)文的摘要，如果和發(fā)送過來的摘要相同充尉，那么就可以驗(yàn)證
   數(shù)據(jù)的完整性飘言。

3. 身份認(rèn)證

有了完整性驗(yàn)證還是不夠，我們網(wǎng)絡(luò)中的人可能太壞了驼侠，如果他連摘要也一起修改了呢姿鸿？這時(shí)候還需要為摘要上一把小小的鎖，不能讓人輕易修改倒源，這就是數(shù)字簽名苛预。
現(xiàn)在我們將摘要信息用RSA非對稱加密中的私鑰進(jìn)行加密，在接收方使用公鑰解密驗(yàn)簽笋熬，即便中間人想要修改摘要热某，但是他無法得知原始的私鑰，所以數(shù)字簽名是無法偽造的。
客戶端接收到請求之后用服務(wù)器的公鑰將簽名解密昔馋，再驗(yàn)證完整性筹吐，這樣既可以保證消息沒有被篡改過，又可以保證消息確實(shí)是目標(biāo)服務(wù)器發(fā)送的秘遏。

數(shù)字簽名驗(yàn)簽

4. 不可否認(rèn)

由于存在偽裝（任何一方都可能被中間人冒名頂替）丘薛，所以其中一方可以假裝沒有收到對方消息或?qū)Ψ绞盏降南⒉皇亲约喊l(fā)的。
在使用數(shù)字簽名驗(yàn)簽的過程中我們也實(shí)現(xiàn)了不可否認(rèn)的特性邦危，大家可以想一想洋侨，既然中間人無法獲取私鑰，也就無法偽造簽名倦蚪。反過來講希坚，一旦我們驗(yàn)簽成功，說明數(shù)字簽名合法陵且，那么上述信息就確確實(shí)實(shí)是對應(yīng)的人發(fā)送的裁僧，無法抵賴。

5. 公鑰的信任問題

有了上述幾點(diǎn)的分析慕购，我們?yōu)镠TTP設(shè)計(jì)的安全方案似乎已經(jīng)可以了锅知。但是還有一個致命的問題，就怎么把公鑰安全地交到用戶手上脓钾？
之前的分析都基于一個假設(shè)，無論是非對稱交換密鑰桩警，還是簽名的驗(yàn)簽可训，都需要用到服務(wù)器的公鑰，并且我們都認(rèn)為這把公鑰一定是和服務(wù)器的私鑰對應(yīng)的捶枢。但是問題就出在這里握截，服務(wù)器如何安全的把公鑰傳遞給用戶？如果在公鑰的傳遞過程中就被人替換烂叔，那后續(xù)的加密等步驟不就沒有意義了嗎谨胞。
這個時(shí)候有同學(xué)會說，簡單啊蒜鸡，我們把這個公鑰加密一下傳輸給客戶不久好了嗎胯努？
。逢防。叶沛。。忘朝。灰署。
等等，那加密公鑰用的密鑰又怎么傳輸？這已經(jīng)成了一個雞生蛋的問題溉箕，網(wǎng)絡(luò)協(xié)議的制定者們也意識到了這一點(diǎn)晦墙，光靠算法等技術(shù)手段已經(jīng)沒法了，一定要人為介入打破這個循環(huán)肴茄。
咣的一聲晌畅，CA（Certification Authority）閃亮登場。
CA介入之后独郎，它以自己的信譽(yù)為各服務(wù)器的公鑰盡心擔(dān)保踩麦。這時(shí)候我們服務(wù)器在第一步發(fā)送給客戶的不再是簡單的公鑰，而是一連串的信息氓癌，包括服務(wù)器的域名谓谦，服務(wù)器持有者等等，當(dāng)然最重要的還是服務(wù)器的公鑰贪婉。
這些信息并不是簡單的發(fā)送反粥，他們經(jīng)過了CA的認(rèn)證，CA使用自己的私鑰對他們進(jìn)行了簽名疲迂，生成了數(shù)字證書才顿。
然后CA通知微軟蘋果安卓。尤蒿。郑气。等終端操作系統(tǒng)提供商：“你們把我(CA)的公鑰先放在你們的操作系統(tǒng)里”。這就是我們常說的根證書腰池。
這時(shí)候CA的擔(dān)保工作算是完成了尾组。客戶端在收到服務(wù)器的數(shù)字證書之后示弓，使用內(nèi)置在設(shè)備中的根證書進(jìn)行驗(yàn)簽讳侨，取得可信任的服務(wù)器公鑰，從而解決了公鑰的信任問題奏属。

CA介入

HTTPS握手過程

有了上述四點(diǎn)的分析跨跨，我們詳細(xì)看一下HTTPS的握手過程。前面我們有提到囱皿，HTTPs協(xié)議是在HTTP和TCP之間添加了一層TLS協(xié)議勇婴，它也屬于應(yīng)用層協(xié)議，它的作用就是在TCP建立起連接之后對傳輸通道進(jìn)行加密嘱腥，將HTTP放在TLS之上咆耿，可以保證在不影響HTTP本身協(xié)議的情況下獲得加密傳輸?shù)奶匦裕訦TTPS的握手過程也就是TLS的握手過程爹橱。

TLS交互過程.jpg

Encrypted Application Data.png

抓包數(shù)據(jù)顯示了一個完整的TLS握手過程(RSA密鑰交換)萨螺，從圖中我們可以看到窄做，直到第五個包，才開始正真?zhèn)鬏敂?shù)據(jù)Application Data慰技，并且從第二張圖可以看出實(shí)際的Application Data(也就是HTTP協(xié)議內(nèi)容)已經(jīng)經(jīng)過了加密椭盏，抓包所能看到的也只是亂碼。
下面我們就詳細(xì)分析一下在正式傳送數(shù)據(jù)之前的四個步驟是怎么做的：

HTTPS握手過程.png

第一步吻商，Client Hello掏颊。

首先由客戶端發(fā)起了一個打招呼的包：ClientHello，通過抓包我們可以看到TLS層的內(nèi)容：

Client Hello

有兩個點(diǎn)我們需要關(guān)注的就是Client傳輸了一個隨機(jī)數(shù)和21個Cipher Suites艾帐，我們詳細(xì)解釋一下這兩個點(diǎn)：

1. Client Random：客戶端隨機(jī)數(shù)乌叶。在之前的原理中我們有講到HTTPs握手的主要目的就是得出對稱加密的主密鑰。這個密鑰單獨(dú)由某一方生成都不太合適柒爸，應(yīng)為并不是每個主機(jī)都能產(chǎn)生完全的隨機(jī)數(shù)准浴，如果只是由某一方生成，很可能會產(chǎn)生比較弱的隨機(jī)數(shù)捎稚，容易被猜測乐横，導(dǎo)致加密密鑰被破解。所以我們在過程中會涉及到三個隨機(jī)數(shù)今野，并且后續(xù)可以看到Server端也會參與到隨機(jī)數(shù)的生成葡公，從而使“隨機(jī)數(shù)”更接近真實(shí)的隨機(jī)，保證安全条霜。
2. Cipher Suites：在之前的知識鋪墊中我們知道HTTPS的加密過程需要用到的密碼技術(shù)主要有：

• 對稱加密
• 非對稱加密
• 摘要算法
• 數(shù)字簽名
  每一種算法分類中有很多的選擇催什，例如對稱加密就有AES_256_GCM, AES_128_CBC等，非對稱加密也有RAS和ECDSA宰睡，他們的安全強(qiáng)度和性能都各有側(cè)重蛆楞。那在后續(xù)的連接中，針對算法的多種選擇夹厌，本次會話使用哪種組合呢？這些算法的組合就是我們說的Cipher Suites------密碼套件裆悄，看一個具體的Cipher Suite：
  
  Cipher Suite
  
  客戶端提供了許多這樣的組合矛纹，表示客戶端支持這些組合，供服務(wù)端進(jìn)行選擇光稼，每種組合的安全和性能各有差異或南，服務(wù)器結(jié)合自身情況盡心選擇。

第二步艾君，Server Hello

服務(wù)器收到了客戶端的招呼請求之后采够，做出了Server Hello的回應(yīng)，這里面有三個很重要的內(nèi)容：

1. Server端隨機(jī)數(shù)
2. 從Client Hello發(fā)送的Cipher Suites中選擇一個自己支持的Cipher Suite
3. 服務(wù)器自己的CA證書
   這一步服務(wù)器提供了必要的信息給客戶端冰垄，證書用于驗(yàn)證自己的身份蹬癌，以便確保公鑰安全的交到用戶手中，并且提供自己生成的隨機(jī)數(shù)，和選定的Cipher Suite逝薪，讓客戶端繼續(xù)進(jìn)行后續(xù)步驟隅要。

第三步，Client Key Exchange

前兩個打招呼的報(bào)文實(shí)際上都是明文傳輸?shù)亩茫驗(yàn)樵诮⑦B接之前雙方都沒有密鑰步清，無法使用加密傳輸?shù)摹６拔挠刑岬降膬蓚€隨機(jī)數(shù)(Client Random和Server Random)都有被截獲的風(fēng)險(xiǎn)虏肾，如果中間人獲取到我們的隨機(jī)數(shù)廓啊，再根據(jù)同樣的算法進(jìn)行計(jì)算，不是就可以得到我們最終生成的對稱密鑰了嗎封豪？顯然我們不可能讓壞人輕易得逞谴轮，原因就在于第三步的Client Key Exchange中的第三個隨機(jī)數(shù)，我們通常稱之為預(yù)主密鑰(Pre Master)撑毛。
客戶端在收到了服務(wù)器返回的消息之后书聚，首先會用存放在本地的根證書對服務(wù)器證書進(jìn)行驗(yàn)證，驗(yàn)證通過便會認(rèn)為服務(wù)器證書中的公鑰是可信的藻雌，取出來備用雌续。
接下來客戶端會生成第三個隨機(jī)數(shù)，為了把這第三個隨機(jī)數(shù)安全的交給服務(wù)器胯杭，我們需要對他進(jìn)行加密驯杜，這時(shí)的情況跟第一次Client Hello時(shí)有所不同，因?yàn)槲覀円呀?jīng)有了可以信任的服務(wù)器公鑰做个。
客戶端根據(jù)服務(wù)器返回的Cipher Suite使用確定的算法和公鑰對第三個隨機(jī)數(shù)進(jìn)行加密傳輸鸽心。這時(shí)候只有服務(wù)器的私鑰可以解密獲取這第三個隨機(jī)數(shù)，從而保證了主密鑰的安全居暖。

在這一步里顽频，客戶端還做了一些小動作，由于客戶端現(xiàn)在已經(jīng)搶先服務(wù)端計(jì)算出了主密鑰太闺，而當(dāng)這條Client Key Exchange信息到達(dá)服務(wù)端時(shí)糯景，服務(wù)端應(yīng)該也能正確的計(jì)算出主密鑰，所以客戶端先用主密鑰對之前握手的信息做了摘要和簽名以供服務(wù)端計(jì)算出主密鑰之后當(dāng)場進(jìn)行驗(yàn)證省骂，這是雙方第一次使用對稱加密的主密鑰進(jìn)行加密蟀淮。

第四步，Server Change Cipher Spec

走到這一步钞澳，服務(wù)端會先用自己的私鑰解密怠惶，獲取到客戶端傳來的第三個隨機(jī)數(shù)（預(yù)主密鑰），接著通過相同的算法計(jì)算出主密鑰轧粟。服務(wù)端對上一步客戶端做的小動作進(jìn)行驗(yàn)簽策治，這是服務(wù)端第一次使用對稱加密主密鑰脓魏，如果驗(yàn)簽成功說明我們雙方的主密鑰計(jì)算成功，是安全的览妖。
接著服務(wù)端做了最后的回應(yīng)：

1. Change Cipher Spec轧拄，告訴客戶端，我準(zhǔn)備好了讽膏，后續(xù)咱們就用主密鑰加密溝通檩电，你懂的。
2. 對我們握手的信息用主密鑰進(jìn)行簽名府树，你驗(yàn)證一下俐末。

至此，整個HTTPs的握手完成奄侠。

后記

關(guān)于HTTPs的內(nèi)容確實(shí)有很多要講卓箫。比如本文所講的主要時(shí)原始的RSA密鑰交換，而目前應(yīng)用最多的密鑰交換算法是ECDHE垄潮，它在交換隨機(jī)數(shù)與預(yù)主密鑰時(shí)使用了不同的策略烹卒，但是流程原理與RSA密鑰交換是共通的。
HTTPs的每一步都有它的用意弯洗，少了任何一步都會導(dǎo)致信息安全出現(xiàn)漏洞旅急，原PPT的后面還有一部分反向案例分析，由于篇幅問題就下次再更新吧牡整。