之前寫過一個(gè)關(guān)于HTTPS的文章，最近又重新看了看嘴脾，發(fā)現(xiàn)還有很多地方可以補(bǔ)充完善挠他，正好最近也看了關(guān)于RSA加密算法的知識，正好一起完善一下斤贰。

什么是HTTPS

HTTPS簡單的說就是安全版的HTTP智哀。

因?yàn)镠TTP協(xié)議的數(shù)據(jù)都是明文進(jìn)行傳輸?shù)模詫τ谝恍┟舾行畔⒌膫鬏斁秃懿话踩校瑸榱税踩珎鬏斆舾袛?shù)據(jù)瓷叫，網(wǎng)景公司設(shè)計(jì)了SSL（Secure Socket Layer），在HTTP的基礎(chǔ)上添加了一個(gè)安全傳輸層送巡，對所有的數(shù)據(jù)都加密后再進(jìn)行傳輸摹菠，客戶端和服務(wù)器端收到加密數(shù)據(jù)后按照之前約定好的秘鑰解密。

HTTPS是如何保證安全的

HTTPS的安全性是建立在密碼學(xué)的基礎(chǔ)之上的授艰，有很多算法起到了至關(guān)重要的作用辨嗽。

HTTPS的交互過程

通過上面的描述世落，我們已經(jīng)能大概知道HTTPS是使用加密算法在瀏覽器和服務(wù)器之前傳遞秘鑰淮腾，然后再使用秘鑰完成信息的加解密糟需。所以這個(gè)秘鑰是如何生成的，還有秘鑰是如何在瀏覽器和服務(wù)器之間傳遞的就成了HTTPS的關(guān)鍵谷朝，下面我們來詳細(xì)的了解一下這個(gè)過程洲押。

客戶端與服務(wù)端交互

1.交互流程

Client Hello 客戶端（通常是瀏覽器）先向服務(wù)器發(fā)出加密通信的請求,請求大概中包括下面內(nèi)容
- 支持的協(xié)議版本，比如TLS 1.0版圆凰。
- 一個(gè)客戶端生成的隨機(jī)數(shù) Random Number-RNc杈帐，稍后用于生成"對話密鑰"。
- 支持的加解密方法专钉，比如對稱加密支持AES挑童，秘鑰交換算法支持RSA、DH跃须，簽名算法支持sha256等站叼。(在更高版本的TLS協(xié)議中，交換的是密碼學(xué)套件菇民，所謂的套件就是一整套的加解密尽楔，秘鑰交換方案)。
- 支持的壓縮方法第练。
服務(wù)器收到請求,然后響應(yīng)
- 確認(rèn)使用的加密通信協(xié)議版本阔馋，比如TLS 1.0版本。如果瀏覽器與服務(wù)器支持的版本不一致娇掏，服務(wù)器關(guān)閉加密通信呕寝。
- 一個(gè)服務(wù)器生成的隨機(jī)數(shù)Random Number-RNs，稍后用于生成"對話密鑰"婴梧。
- 確認(rèn)使用的加密方法壁涎、秘鑰交換算法、簽名算法等等志秃。
- 把服務(wù)器證書發(fā)送給客戶端怔球。
- 服務(wù)器要求驗(yàn)證客戶端(瀏覽器)的證書(可選，大部分的服務(wù)器都不會要求)浮还。
客戶端收到服務(wù)器證書之后竟坛，會檢查證書的有效性，如果服務(wù)器證書并不是經(jīng)過CA機(jī)構(gòu)認(rèn)證的钧舌，瀏覽器就會在這個(gè)時(shí)候給用戶提出警告担汤。
客戶端收到服務(wù)器驗(yàn)證客戶端證書的請求，會將自己證書發(fā)送給服務(wù)器洼冻≌钙纾客戶端如果沒有證書，則需要發(fā)送一個(gè)不包含證的證書消息撞牢。如果服務(wù)器需要客戶端身份驗(yàn)證才能繼續(xù)握手率碾，則可能會使用致命的握手失敗警報(bào)進(jìn)行響應(yīng)叔营。(雙向認(rèn)證一般只存在于銀行等一些安全性要求比較高的場景中，像早些時(shí)候我們使用的網(wǎng)銀所宰，里面存儲的就是證書绒尊，用來在交易的時(shí)候和服務(wù)器端進(jìn)行雙向認(rèn)證，保證安全)
服務(wù)器收到客戶端證書仔粥，校驗(yàn)客戶端證書是否有效
客戶端把把上面流程中發(fā)送的所有消息(除了Client Hello)婴谱，使用客戶端的私鑰進(jìn)行簽名，然后發(fā)送給服務(wù)器躯泰。
服務(wù)器也保存著之前客戶端發(fā)送的消息谭羔，然后用客戶端發(fā)送過來的公鑰，進(jìn)行驗(yàn)簽麦向。
客戶端生成一個(gè)Pre-Master-Secret隨機(jī)數(shù)口糕，然后使用服務(wù)器證書中的公鑰加密，發(fā)送給服務(wù)器端磕蛇。
服務(wù)器端收到Pre-Master-Secret的加密數(shù)據(jù)景描，因?yàn)槭鞘褂盟墓 €加密的，所以可以使用私鑰解密得到Pre-Master-Secret秀撇。
這時(shí)候客戶端和服務(wù)端都同時(shí)知道了超棺，RNc、RNs呵燕、Pre-Master-Secret這三個(gè)隨機(jī)數(shù)棠绘，然后客戶端和服務(wù)器端使用相同的PRF算法計(jì)算得到一個(gè)Master-Secret。然后可以從Master-Secret中再生成作為最終客戶端和服務(wù)器端消息對稱加密的秘鑰再扭，和對消息進(jìn)行認(rèn)證的MAC秘鑰氧苍。

參考:TLS協(xié)議

TLS RFC

2.Pre-Master-Secret

Pre-Master-Secret前兩個(gè)字節(jié)是TLS的版本號，這是一個(gè)比較重要的用來核對握手?jǐn)?shù)據(jù)的版本號泛范，因?yàn)樵贑lient Hello階段让虐，客戶端會發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號給服務(wù)端，而且是使用明文傳送的罢荡，如果握手的數(shù)據(jù)包被破解之后赡突，攻擊者很有可能串改數(shù)據(jù)包，選擇一個(gè)安全性較低的加密套件和版本給服務(wù)端区赵，從而對數(shù)據(jù)進(jìn)行破解惭缰。

所以，服務(wù)端需要對密文中解密出來對的Pre-Master-Secret中的版本號跟之前Client Hello階段的版本號進(jìn)行對比笼才，如果版本號變低漱受，則說明被篡改，則立即停止發(fā)送任何消息骡送。

參考：pre-master secret

3.Master-Secret

客戶端和服務(wù)端在生成Master-Secret的之后昂羡，會把Master-Secret作為PRF的參數(shù)絮记，繼續(xù)運(yùn)算，最終得到下面6個(gè)秘鑰紧憾，分別用于MAC算法和加解密算法到千。

秘鑰名稱	秘鑰作用
client write MAC key	客戶端對發(fā)送數(shù)據(jù)進(jìn)行MAC計(jì)算使用的秘鑰昌渤，服務(wù)端使用同樣的秘鑰確認(rèn)數(shù)據(jù)的完整性
server write MAC key	服務(wù)端對返回?cái)?shù)據(jù)進(jìn)行MAC計(jì)算使用的秘鑰赴穗，客戶端使用同一個(gè)秘鑰驗(yàn)證完整性
client write key	對稱加密key，客戶端數(shù)據(jù)加密膀息，服務(wù)端解密
server write key	服務(wù)端加密般眉，客戶端解密
client write IV	初始化向量，運(yùn)用于分組對稱加密
server write IV	初始化向量潜支，運(yùn)用于分組對稱加密

參考: TLS 中的密鑰計(jì)算

4.PRF算法

PRF表示（Pseudo-random Function）偽隨機(jī)函數(shù)

Master-secret和最終的6個(gè)秘鑰都是依靠PRF來生成的甸赃。

PRF是利用hash函數(shù)來實(shí)現(xiàn)，然后依賴遞歸可以生成無限長度的序列冗酿。具體使用哪種hash算嗎埠对，在TLS1.2之后需要的密碼學(xué)套件中指定。

然后master-secret和6個(gè)秘鑰只需要PRF生成滿足他們所需要的長度即可裁替。

比如Master-Secret的長度一直都是48位项玛。

參考: TLS 中的密鑰計(jì)算

5.雙向認(rèn)證

其實(shí)我們?nèi)粘ＴL問的絕大多數(shù)網(wǎng)站，都是單向認(rèn)證的(也就是說并沒有上面流程中的3弱判、4襟沮、5、6步驟)昌腰，這里為例展示HTTPS的完整交互流程开伏，所以分析的是雙向認(rèn)證。

服務(wù)器可以選擇是否要真正客戶端的證書遭商。這里以使用NGINX配置HTTPS為例固灵。

如果我們在NGINX的HTTPS相關(guān)配置中添加了下面這個(gè)配置，就表示需要驗(yàn)證客戶端的證書劫流。


ssl_verify_client on;

6.密碼學(xué)套件

密碼學(xué)套件是TLS發(fā)展了一段時(shí)間積累了很多密碼學(xué)使用的經(jīng)驗(yàn)之后提出的一整套的解決方案怎虫。一個(gè)套件中包含了應(yīng)用于整個(gè)握手和傳輸使用到的所有非對稱加密，對稱加密和哈希算法困介，甚至包括證書的類型大审。

密碼學(xué)套件是SSLv3開始提出的概念，從此座哩，零散的密碼學(xué)選擇問題變成了一個(gè)整體的密碼學(xué)套件選擇的問題徒扶。后續(xù)的版本在升級的時(shí)候會產(chǎn)生新的安全強(qiáng)度更高的密碼學(xué)套件，同時(shí)拋棄比較弱的密碼學(xué)套件

密碼套件分為三大部分：密鑰交換算法根穷，數(shù)據(jù)加密算法姜骡，消息驗(yàn)證算法导坟。

下面來分析一個(gè)密碼學(xué)套件的名稱，來解釋一下它包含的意思

15898756214901.jpg

TLS_DHE_RSA_WITH_AES_256_CBC_SHA226

WITH前面表示使用的非對稱加密算法圈澈，WITH后面表示使用的對稱加密和完整性校驗(yàn)算法

TLS:表示TLS協(xié)議惫周，如果未來TLS改名，這個(gè)名字可能會變康栈，否則會一直是這個(gè)名字
DHE_RSA:這里又兩個(gè)算法递递，表示第一個(gè)是約定密鑰交換的算法，第二個(gè)是約定證書的驗(yàn)證算法啥么。如果只有一個(gè)登舞，表示這兩中操作都是用同一個(gè)算法。
AES_256_CBC:指的是AES這種對稱加密算法的256位算法的CBC模式悬荣，AES本身是一類對稱加密算法的統(tǒng)稱菠秒，實(shí)際的使用時(shí)要指定位數(shù)和計(jì)算模式，CBC就是一種基于塊的計(jì)算模式氯迂。
SHA:表示用來校驗(yàn)數(shù)據(jù)完整性生成MAC甚负，使用的算法闷串，在TLS1.2之后也表示PRF算法使用的算法。

除了這種比較好理解的密碼學(xué)套件，還有見到一些比較奇怪的赎懦，比如

ALL:!EXPORT:!LOW:!aNULL:!SSLv2

我來解釋一下括授，上面出現(xiàn)的字段谊迄，更為詳細(xì)的大家可以去查看下面的文章窑多。

ALL:表示所有除了明文(eNULL)傳遞意外的密碼學(xué)套件
!EXPORT:EXPORT表示有出口限制的密碼學(xué)算法，前面加上!,就表示排除掉包含這些算法的密碼學(xué)套件拳芙。
!LOW:表示排除掉標(biāo)記為密碼強(qiáng)度比較低的算法察藐。
!aNULL:表示排除不提供身份驗(yàn)證算法的套件。
!SSLv2:表示排除所有SSLv2的套件舟扎。

大家可以使用openssl ciphers xxx命令查看套件表達(dá)式分飞，棘突所包含的密碼學(xué)套件

15898713164120.jpg

參考:

密碼學(xué)套件

密碼學(xué)套件表達(dá)式

HTTPS中的算法

除了了解HTTPS的交互流程，HTTPS中使用的算法及算法的作用睹限，也是我們必須要了解的一部分譬猫。

下面會按照算法的作用進(jìn)行分類，并簡單的介紹其中比較常見算法的作用羡疗，單并不會對算法的原理做過多的說明(主要是我也弄不明白)染服，會把相關(guān)的講解原理的文章鏈接提供出來，大家有興趣的可以自行去了解叨恨。

HTTPS中算法柳刮，根據(jù)算法的用途可以分為幾大類

加密算法 - 加密傳遞的信息，包括對稱加密和非對稱加密
秘鑰傳遞算法 - 在客戶端和服務(wù)器端傳遞加密使用的key，當(dāng)然通過上面的流程我們知道并不是直接傳遞加密的key
信息摘要/簽名算法 - 對傳遞的信息摘要秉颗，確保信息在傳遞過程中不會被篡改

1.加密算法

加密算法基本可以分為兩種對稱加密和非對稱加密

對稱加密

顧名思義就是加密和解密都是用一個(gè)同樣的秘鑰痢毒，它的優(yōu)點(diǎn)就行加解密的速度很快，缺點(diǎn)就是尤其需要注意秘鑰的傳輸蚕甥，不能泄露哪替。

包含的算法有 AES DES RC4等，常用的是AES

非對稱加密-RSA

非對稱加密有一對秘鑰公鑰和私鑰菇怀。使用公鑰加密凭舶，然后使用私鑰解密。公鑰可以公開的發(fā)送給任何人敏释。使用公鑰加密的內(nèi)容库快，只有私鑰可以解開摸袁。安全性比對稱加密大大提高钥顽。缺點(diǎn)是和對稱加密相比速度較慢，加解密耗費(fèi)的計(jì)算資源較多靠汁。

這里我們先只需要了解RSA之所以安全的原因是蜂大，大整數(shù)的因數(shù)分解，是一件非常困難的事情蝶怔。目前奶浦，除了暴力破解，還沒有發(fā)現(xiàn)別的有效方法踢星。

所以這個(gè)大整數(shù)越大澳叉，RSA被破解的難度也就越高。

具體的算法可以了解下面的兩篇文章沐悦。

RSA算法原理1

RSA算法原理2

2.秘鑰傳遞算法

在HTTPS中比較常用的有RSA成洗、DH、ECDHE算法藏否。

對你沒看錯(cuò)還是RSA瓶殃，因?yàn)镽SA非對稱加密的特性，非常適合用來傳遞秘鑰副签，而RSA在HTTPS中也正是承擔(dān)的這一個(gè)關(guān)鍵作用遥椿。

具體的算法就不在這里展開了，感興趣的大家可以下面的wiki中了解一下淆储。

因?yàn)檫@些算法都用到了數(shù)論的一些知識冠场，我自己也是似懂非懂。但是他們有一個(gè)共同點(diǎn)就是都是運(yùn)用了質(zhì)數(shù)和模運(yùn)算相關(guān)的數(shù)學(xué)原理和公式本砰，感覺他們之間應(yīng)該也是有一定的關(guān)聯(lián)和關(guān)系碴裙。(后悔沒有好好學(xué)數(shù)學(xué)呀)

參考：

RSA和DH算法

ECDHE-wiki

DH-wiki

3.摘要/簽名算法

HTTPS中常見的有MD5、SHA256、MAC青团、HMAC等譬巫，下面主要說明一下這些算法的區(qū)別和聯(lián)系。

1. MD5

是一種消息摘要算法(Message-Digest Algorithm),一種被廣泛使用的密碼散列函數(shù)(Hash Function)督笆，針對任意長度的輸入芦昔，可以產(chǎn)生出一個(gè)定長128位（16字節(jié)）的散列值。

2. SHA

SHA表示安全哈希算法(Secure Hash Algorithm)娃肿，經(jīng)過了很長時(shí)間的發(fā)展SHA算法已經(jīng)發(fā)展成了一個(gè)擁有眾多算法的SHA家族咕缎。常見的有SHA0、SHA1料扰、SHA2(包含SHA224凭豪、SHA256等)、SHA3晒杈。0嫂伞，1，2拯钻，3表示SHA算法大的版本帖努，每個(gè)大版本中又根據(jù)輸出字節(jié)長度的不同分為和不同的算法。比如SHA256 使用的是SHA2粪般，輸出的是256字節(jié)拼余。更詳細(xì)的大家可以看下面wiki百科中的內(nèi)容，很詳細(xì)亩歹。

SHA稱作安全哈希算法的原因是匙监，它相比MD5算法，需要更多的計(jì)算次數(shù)小作，最終的輸出長度也要長亭姥，(SHA0和SHA1是160字節(jié)。SHA256是256字節(jié))躲惰。如果想要破解需要付出比MD5高的多的計(jì)算次數(shù)致份。

經(jīng)過長時(shí)間的發(fā)展，MD5和SHA0础拨、SHA1已經(jīng)被認(rèn)為不安全氮块，已經(jīng)不再建議使用。

SHA2是目前被最常使用的算法诡宗，目前還沒有針對SHA2的有效攻擊滔蝉。

SHA3是2015年才發(fā)布的，還沒有大規(guī)模的取代SHA2塔沃。

參考 SHA算法家族

3. MAC 和 HMAC

相對于上面的MD5和SHA蝠引，這兩種算法對于我算是比較陌生的。

MAC是消息認(rèn)證碼(Message Authentication Code)的簡稱。它和上面兩種算法的區(qū)別是MAC的計(jì)算需要一個(gè)Key(上面HTTPS流程中就生了計(jì)算MAC的KEY)螃概。只有知道了KEY才能正確的計(jì)算出對應(yīng)的MAC矫夯。

HMAC的全稱是密鑰散列消息認(rèn)證碼(Keyed-hash message authentication code)。是指用秘鑰并使用Hash散列算法生成認(rèn)證碼的一類算法的總稱吊洼。

那么MAC算法和HMAC算法是什么關(guān)系呢训貌？

我覺得可以這么理解。

MAC只是定義了一個(gè)概念---使用一個(gè)key冒窍，給一段消息生成一個(gè)授權(quán)碼递沪；但是生成這個(gè)授權(quán)碼的算法它并沒有定義。所以如果你使用SHA256這種Hash散列算法來生成授權(quán)碼综液，那么這種算法就可以被稱為HMAC-SHA256款慨。

所以HMAC是MAC的一類實(shí)現(xiàn)方式，就像快排是排序算法中的一種實(shí)現(xiàn)方式一樣谬莹。

參考：

MAC-Wiki

Difference between MAC and HMAC?

4. Salted Hash 和 HMAC

加鹽Hash和HMAC在某種程度上很相似檩奠，但是在使用場景上還是有很大的區(qū)別。目前還有沒找到解釋的比較好的文章届良，后面再進(jìn)行補(bǔ)充

todo

HTTPS證書

現(xiàn)在HTTPS基本已經(jīng)成為了一個(gè)網(wǎng)站的標(biāo)配笆凌。想要給一個(gè)網(wǎng)站添加對HTTPS的支持圣猎，就需要針對這個(gè)網(wǎng)站的域名申請證書士葫。

HTTPS證書類型

這里順便說明一下目前的HTTPS證書大概分為3類。

域名型HTTPS 證書（DVSSL）：信任等級一般送悔，只需驗(yàn)證網(wǎng)站的真實(shí)性便可頒發(fā)證書保護(hù)網(wǎng)站慢显；
企業(yè)型HTTPS 證書（OVSSL）：信任等級強(qiáng)，須要驗(yàn)證企業(yè)的身份欠啤，審核嚴(yán)格荚藻，安全性更高；
增強(qiáng)型HTTPS 證書（EVSSL）：信任等級最高洁段，一般用于銀行證券等金融機(jī)構(gòu)应狱，審核嚴(yán)格，安全性最高祠丝，同時(shí)可以激活綠色網(wǎng)址欄疾呻。

DV,OV

我們看到越是高等級的證書，審核的嚴(yán)格程度也就越高写半。并在瀏覽器中會有一定程度的展示岸蜗，也會給用戶一種更為安全的感覺，當(dāng)然價(jià)格也是更加昂貴叠蝇。

HTTPS證書內(nèi)容和結(jié)構(gòu)

15898733815306.jpg

Certificate
- Version Number（證書版本）
- Serial Number(序列號)
- Signature Algorithm ID（該和客戶端使用的簽名算法）
- Issuer Name(證書簽發(fā)者 DN)
- Validity period(有效期)
  - Not Before(生效開始時(shí)間)
  - Not After(有效結(jié)束時(shí)間)
- Subject name(證書使用者)
- Subject Public Key Info(證書)
  - Public Key Algorithm(公鑰算法)
  - Subject Public Key(證書公鑰)
- Issuer Unique Identifier (optional)(簽發(fā)者唯一身份信息璃岳，可選)
- Subject Unique Identifier (optional)(使用者唯一身份信息，可選)
- Extensions (optional)(擴(kuò)展字段)
  - ...
- Signature(CA機(jī)構(gòu)對證書的簽名)

參考 X.509 wiki

X.509 數(shù)字證書的基本原理及應(yīng)用

X.509證書的讀取與解釋

如何獲得HTTPS證書

簡單來說獲的HTTPS證書有兩種方式

在有CA認(rèn)證的機(jī)構(gòu)申請
自己生成

1.通過CA機(jī)構(gòu)申請

申請CA機(jī)構(gòu)認(rèn)證的證書大致需要以下步驟

1.1 生成CSR(Certificate Signing Request)文件

主要方式有兩種，本地生成和在線生成

1 通過openssl命令本地生成CSR


openssl req -new -nodes -sha256 -newkey rsa:2048 -keyout myprivate.key -out mydomain.csr

-new 指定生成一個(gè)新的CSR铃慷，

nodes指定私鑰文件不被加密,

sha256 指定摘要算法单芜，

keyout生成私鑰,

newkey rsa:2048 指定私鑰類型和長度，

最終生成CSR文件mydomain.csr犁柜。

2 通過線上網(wǎng)站生成缓溅，一般需要填寫下面的內(nèi)容。

CSR文件內(nèi)容

線上的工具會把公鑰加入到CSR文件中赁温，并同時(shí)生成私鑰坛怪。

參考:在線CSR申請

1.2 CA機(jī)構(gòu)對證書簽名

接下來就需要按照CA機(jī)構(gòu)的要求，和想要申請的證書類型股囊，提交相關(guān)材料袜匿。

CA收到CSR并驗(yàn)證相關(guān)材料，并審核通過之后稚疹。需要進(jìn)行的很重要的一個(gè)步驟就是:使用CA機(jī)構(gòu)的私鑰對提供證書中的內(nèi)容進(jìn)行簽名居灯，并把簽名的結(jié)構(gòu)存放在證書的數(shù)字簽名部分。

CA機(jī)構(gòu)簽名完内狗，并發(fā)送給我們之后怪嫌，我們就能夠把證書部署在我們的服務(wù)器中了。

CA機(jī)構(gòu)進(jìn)行簽名

2.自己生成證書

參考自己生成HTTPS證書

大家可以參考上面的文章自己創(chuàng)建一個(gè)證書試試柳沙。

自己創(chuàng)建的證書同樣可以完成上面的步驟岩灭。只不過有一點(diǎn)就是，因?yàn)樽约荷傻淖C書沒有得到CA機(jī)構(gòu)的私鑰簽名赂鲤，所以當(dāng)瀏覽器通過HTTPS握手獲得服務(wù)器證書的時(shí)候噪径，沒有辦法確定這個(gè)證書是否就是來自請求的服務(wù)器。

這個(gè)時(shí)候?yàn)g覽器就會給出該網(wǎng)站不安全的提示数初。

不安全提示

如果客戶端不能確認(rèn)證書是安全找爱，但是卻貿(mào)然使用，就會有受到中間人攻擊的風(fēng)險(xiǎn)泡孩。

中間人攻擊

具體的概念大家可以去下面的文章中了解一下车摄，我們這里直接舉例說明一下。

這種中間人攻擊的方式仑鸥，常見于公共的未加密的WIFI吮播。

A想和B通訊，建立連接锈候，并請求了B的證書薄料。
C通過提供公共WIFI的方式，監(jiān)聽了A和B的通訊泵琳，攔截了B發(fā)送給A的證書摄职，并把證書替換成自己的誊役。
如果A沒有證書檢驗(yàn)機(jī)制的話，那么A并不能發(fā)現(xiàn)證書已經(jīng)被替換了谷市。
A還是以為在和B通訊蛔垢。就會使用已經(jīng)被替換了的證書中的公鑰(也就是C的公鑰)進(jìn)行加密。
C攔截到消息迫悠，使用自己的私鑰解密鹏漆，獲得原始的請求數(shù)據(jù)。然后就能隨意篡改创泄，然后使用B的公鑰加密艺玲，在發(fā)送給B，達(dá)到了攻擊的目的鞠抑。

中間人攻擊還有另外一種方式饭聚，危害性更大。

如果有惡意程序在我們的手機(jī)或者瀏覽器中安裝了一個(gè)證書搁拙，并且誘導(dǎo)我們把這書設(shè)置為信任證書秒梳。

那么如果有其他惡意程序，在和我們的終端進(jìn)行HTTPS握手的時(shí)候箕速，發(fā)送給我們使用上面的證書簽名的證書酪碘，那么我們的終端將無法識別這個(gè)惡意證書。導(dǎo)致中間人攻擊的發(fā)生盐茎。

要抵御中間人攻擊的一個(gè)有效方式就是兴垦，充分利用證書的認(rèn)證機(jī)制，還有對于證書的安裝和信任要各位謹(jǐn)慎庭呜。

參考：中間人攻擊-Wiki