一、什么是HTTPS

HTTPS也是一個(gè)應(yīng)用層協(xié)議，而HTTP協(xié)議內(nèi)容的傳輸方式是明文的，這就導(dǎo)致在傳輸過程中會(huì)出現(xiàn)一些被篡改的情況，基于這種情況，所以HTTPS就是在HTTP協(xié)議的基礎(chǔ)上引入了一個(gè)加密層，那么什么是加密解密呢？

1、加密解密是什么

簡(jiǎn)單點(diǎn)說，加密就是把明文進(jìn)行一系列的變換，生成密文。
解密就是把密文再進(jìn)行一系列變換，還原成明文。
而在這個(gè)加密解密過程中，往往會(huì)有一個(gè)或多個(gè)中間數(shù)據(jù)，輔助這個(gè)過程，而這樣的數(shù)據(jù)就叫密鑰。

加密解密過程，就像我們用鑰匙鎖門一樣，插進(jìn)鑰匙空逆時(shí)針轉(zhuǎn)一下，就是加密過程，順時(shí)針轉(zhuǎn)一下，就是解密過程，而鑰匙上的齒輪就是密鑰

加密解密到如今已經(jīng)發(fā)展成?個(gè)獨(dú)立的學(xué)科，密碼學(xué)，而密碼學(xué)的奠基人，也正是計(jì)算機(jī)科學(xué)的祖師爺之?：艾倫·麥席森·圖靈

2、為什么要加密

舉個(gè)例子：我們打開電腦，會(huì)彈出各種各樣莫名其妙的煩人彈窗廣告，而我們?nèi)c(diǎn)擊關(guān)閉時(shí)，就會(huì)給我們彈到其他頁面，有時(shí)會(huì)給我們下載一些不需要的東西。

由于我們通過網(wǎng)絡(luò)傳輸?shù)娜魏蔚臄?shù)據(jù)包都會(huì)經(jīng)過運(yùn)營(yíng)商的網(wǎng)絡(luò)設(shè)備(路由器、交換機(jī)等)，那么運(yùn)營(yíng)商的網(wǎng)絡(luò)設(shè)備就可以解析出你傳輸?shù)臄?shù)據(jù)內(nèi)容，并進(jìn)行篡改。這就是運(yùn)營(yíng)商劫持事件。
我們點(diǎn)擊關(guān)閉按鈕，其實(shí)就是在給服務(wù)器發(fā)送一個(gè)HTTP請(qǐng)求，獲取到的HTTP響應(yīng)其實(shí)就包含了該APP的下載鏈接，運(yùn)營(yíng)商劫持后，就會(huì)發(fā)現(xiàn)這個(gè)請(qǐng)求是要下載的對(duì)應(yīng)APP，那么就會(huì)自動(dòng)的把用戶的響應(yīng)給篡改成對(duì)應(yīng)APP的下載地址了。
所以，因?yàn)镠TTP的內(nèi)容是明文傳輸?shù)?#xff0c;明文數(shù)據(jù)會(huì)經(jīng)過路由器、wifi熱點(diǎn)，通信服務(wù)運(yùn)營(yíng)商、代理服務(wù)器等多個(gè)物理節(jié)點(diǎn)，如果在傳輸過程中被劫持，那么傳輸?shù)膬?nèi)容則完全暴露了。劫持者還可以對(duì)篡改傳輸?shù)男畔⑶也槐浑p方察覺，這就是中間人攻擊，所以我們就需要對(duì)信息進(jìn)行加密。

當(dāng)然，不僅運(yùn)營(yíng)商可以進(jìn)行劫持，其他黑客或不法分子也是可以用同樣的手段進(jìn)行劫持信息，來竊取用戶的隱私或者篡改內(nèi)容，甚至竊取用戶的支付寶、微信等支付密碼，所以明文傳輸是比較危險(xiǎn)的。

3、常見的加密方式

1、對(duì)稱加密

• 采用單密鑰的加密方法，用同一個(gè)密鑰對(duì)信息進(jìn)- 行加密和解密，這種加密方法稱為對(duì)稱加密，也稱為單密鑰加密。
• 特征：加密和解密所用的密鑰都是相同的。
• 特點(diǎn)：算法公開、計(jì)算量小、加密速度快、加密效率高。
• 常見對(duì)稱加密算法：DES、3DES、AES等

對(duì)稱加密其實(shí)就是通過同?個(gè)"密鑰"，把明文加密成密文，并且也能把密文解密成明文。

舉個(gè)例子：

?個(gè)簡(jiǎn)單的對(duì)稱加密，按位異或
假設(shè)：明文 a = 1234，密鑰 key = 8888
則加密 a ^ key 得到的密文 b 為 9834
然后針對(duì)密? 9834 再次進(jìn)行運(yùn)算 b ^ key，得到的就是原來的明文 1234。
當(dāng)然，按位異或只是最簡(jiǎn)單的對(duì)稱加密，HTTPS中并不是使?按位異或。

2、非對(duì)稱加密

• 需要兩個(gè)密鑰來進(jìn)行加密和解密，這兩個(gè)是公開密鑰（簡(jiǎn)稱公鑰）和私有密鑰（簡(jiǎn)稱私鑰）
• 特點(diǎn)：算法強(qiáng)度復(fù)雜、安全性依賴于算法與密鑰但是由于其算法復(fù)雜，而使得加密解密速度沒有對(duì)稱加密解密的速度快。
• 常見非對(duì)稱加密算法：RSA、DSA等

非對(duì)稱加密要用到兩個(gè)密鑰，?個(gè)叫做"公鑰"，?個(gè)叫做"私鑰"。而公鑰和私鑰是配對(duì)的，最大的缺點(diǎn)就是運(yùn)算速度非常慢，比對(duì)稱加密要慢很多。

• 通過公鑰對(duì)明文加密，變成密文，也可以通過私鑰對(duì)明文加密，變成密文
• 通過私鑰對(duì)密文解密，變成明文，也可以通過公鑰對(duì)密文解密，變成明文

舉個(gè)例子：

A要給B一些重要的文件，但是B可能不在，于是A和B就提前做了一個(gè)約定：
B說：我桌子上有一個(gè)盒子，我給你?把鎖，你把文件放盒子里用鎖鎖上，然后我回頭拿著鑰匙來開鎖取文件。
在這個(gè)場(chǎng)景中，這把鎖就相當(dāng)于公鑰，鑰匙就是私鑰，公鑰給誰都可以，不用怕被泄露，但是私鑰只有B自己持有，持有私鑰的人才能解密。

二、探究HTTPS如何實(shí)現(xiàn)加密

既然要保證數(shù)據(jù)安全，就需要對(duì)數(shù)據(jù)進(jìn)行"加密"，所以網(wǎng)絡(luò)傳輸中不再直接傳輸明文了，而是加密之后的"密文"。
加密的方式有很多，但是整體可以分成兩大類：對(duì)稱加密和非對(duì)稱加密。

1、方案一----只使用對(duì)稱加密

如果通信雙方都各自持有同?個(gè)密鑰C，且沒有別人知道，這兩方的通信安全當(dāng)然是可以被保證的（除非密鑰被破解）

引入對(duì)稱加密之后，即使數(shù)據(jù)被截獲，由于黑客不知道密鑰是啥是什么，因此就無法進(jìn)行解密，也就不知道請(qǐng)求的真實(shí)內(nèi)容是什么了。
但是，如果服務(wù)器同?時(shí)刻是給很多客戶端提供服務(wù)的呢。
這么多客戶端，每個(gè)人用的秘鑰都必須是不同的，因?yàn)?#xff0c;如果是相同，那密鑰就太容易擴(kuò)散和泄密了，黑客就也能拿到密鑰了，因此服務(wù)器就需要維護(hù)每個(gè)客戶端和每個(gè)密鑰之間的關(guān)聯(lián)關(guān)系，這也是個(gè)很麻煩的事情

比較理想的做法，就是能在客戶端和服務(wù)器建立連接的時(shí)候，雙方協(xié)商確定這次的密鑰是什么

但是如果直接把密鑰明文傳輸，那么黑客也就能獲得密鑰了，此時(shí)，后續(xù)的加密操作就形同虛設(shè)了。因此密鑰的傳輸也必須加密傳輸。
但是，要想對(duì)密鑰進(jìn)行對(duì)稱加密，就仍然需要先協(xié)商確定一個(gè)"密鑰的密鑰"，這就成了"先有雞還是先有蛋"的問題了，此時(shí)密鑰的傳輸再用對(duì)稱加密就行不通了。

2、方案二----只使用非對(duì)稱加密

鑒于非對(duì)稱加密的機(jī)制，如果服務(wù)器先把公鑰以明文方式傳輸給瀏覽器，之后瀏覽器向服務(wù)器傳數(shù)據(jù)前都先用這個(gè)公鑰加密好再傳，從客戶端到服務(wù)器信道似乎是安全的，因?yàn)橹挥蟹?wù)器有相應(yīng)的私鑰能解開公鑰加密的數(shù)據(jù)。
但是服務(wù)器到瀏覽器的這條路怎么保障安全呢？
如果服務(wù)器用它的私鑰加密數(shù)據(jù)傳給瀏覽器，那么瀏覽器用公鑰可以解密它，而這個(gè)公鑰是一開始通過明文傳輸給瀏覽器的，若這個(gè)公鑰被中間人劫持到了，那他也能用該公鑰解密服務(wù)器傳來的信息了。

3、方案三----雙方都使用非對(duì)稱加密

1. 服務(wù)端擁有公鑰S與對(duì)應(yīng)的私鑰S’，客戶端擁有公鑰C與對(duì)應(yīng)的私鑰C’
2. 客戶端和服務(wù)端交換公鑰
3. 客戶端給服務(wù)端發(fā)信息：先用S對(duì)數(shù)據(jù)加密，再發(fā)送，只能由服務(wù)器解密，因?yàn)橹挥蟹?wù)器有私鑰S’
4. 服務(wù)端給客戶端發(fā)信息：先用C對(duì)數(shù)據(jù)加密，在發(fā)送，只能由客戶端解密，因?yàn)橹挥锌蛻舳擞兴借€C’

這樣貌似也行啊，但是

• 效率太低
• 依舊有安全問題

4、方案四----非對(duì)稱加密 + 對(duì)稱加密

先解決效率問題

• 服務(wù)端具有非對(duì)稱公鑰S和私鑰S’
• 客戶端發(fā)起https請(qǐng)求，獲取服務(wù)端公鑰S
• 客戶端在本地生成對(duì)稱密鑰C，通過公鑰S加密，發(fā)送給服務(wù)器
• 由于中間的網(wǎng)絡(luò)設(shè)備沒有私鑰，即使截獲了數(shù)據(jù)，也無法還原出內(nèi)部的原文，也就無法獲取到對(duì)稱密鑰，但是，真的不能獲取嗎？
• 服務(wù)器通過私鑰S’解密，還原出客戶端發(fā)送的對(duì)稱密鑰C，并且使用這個(gè)對(duì)稱密鑰加密給客戶端返回的響應(yīng)數(shù)據(jù)。
• 后續(xù)客戶端和服務(wù)器的通信都只用對(duì)稱加密即可，由于該密鑰只有客戶端和服務(wù)器兩個(gè)主機(jī)知道，其他主機(jī)/設(shè)備不知道密鑰即使截獲數(shù)據(jù)也沒有意義。

由于對(duì)稱加密的效率比非對(duì)稱加密高很多，因此只是在開始階段協(xié)商密鑰的時(shí)候使用非對(duì)稱加密，后續(xù)的傳輸仍然使用對(duì)稱加密。
但是，依然有安全問題，方案2，方案3，方案4都存在一個(gè)問題，如果最開始，中間人就已經(jīng)開始攻擊了呢？

5、中間人攻擊

在方案2、3、4中，客戶端獲取到公鑰S之后，對(duì)客戶端形成的對(duì)稱秘鑰C用服務(wù)端給客戶端的公鑰S進(jìn)行加密，中間人即使竊取到了數(shù)據(jù)，此時(shí)中間人確實(shí)無法解出客戶端形成的密鑰C，因?yàn)橹挥蟹?wù)器有私鑰S’。
但是，中間人的攻擊，如果在最開始握手協(xié)商的時(shí)候就進(jìn)行了，那就不一定了，假設(shè)hacker已經(jīng)成功成為中間人

1. 服務(wù)器具有非對(duì)稱加密算法的公鑰S，私鑰S’
2. 中間人具有非對(duì)稱加密算法的公鑰M，私鑰M’
3. 客戶端向服務(wù)器發(fā)起請(qǐng)求，服務(wù)器明文傳送公鑰S給客戶端
4. 中間人劫持?jǐn)?shù)據(jù)報(bào)文，提取公鑰S并保存好，然后將被劫持報(bào)文中的公鑰S替換成為自己的公鑰M，并將偽造報(bào)文發(fā)給客戶端
5. 客戶端收到報(bào)文，提取公鑰M，此時(shí)，自己當(dāng)然不知道公鑰被更換過了，自己形成對(duì)稱秘鑰C，用公鑰M加密對(duì)稱秘鑰C，形成報(bào)文發(fā)送給服務(wù)器
6. 中間人劫持后，直接用自己的私鑰M’進(jìn)行解密，得到對(duì)稱密鑰鑰C，再用曾經(jīng)保存的服務(wù)端公鑰S加密后，將報(bào)文推送給服務(wù)器
7. 服務(wù)器拿到報(bào)文，用自己的私鑰S’解密，得到對(duì)稱密鑰C
8. 雙方開始采用對(duì)稱密鑰C進(jìn)行對(duì)稱加密，進(jìn)行通信。但是一切都在中間人的掌握中，劫持?jǐn)?shù)據(jù)，進(jìn)行竊聽甚至修改，都是可以的

6、方案五----非對(duì)稱加密 + 對(duì)稱加密 + 證書認(rèn)證

1.1、CA認(rèn)證

服務(wù)端在使用HTTPS前，需要向CA機(jī)構(gòu)申領(lǐng)一份數(shù)字證書，數(shù)字證書里含有證書申請(qǐng)者信息、公鑰信息等。服務(wù)器把證書傳輸給瀏覽器，瀏覽器從證書里獲取公鑰就行了，證書就如身份證，證明服務(wù)端公鑰的權(quán)威性

這個(gè)證書也可以理解成是?個(gè)結(jié)構(gòu)化的字符串，里面包含了以下信息：證書發(fā)布機(jī)構(gòu)、證書有效期、公鑰、證書所有者、簽名等等
需要注意的是：申請(qǐng)證書的時(shí)候，需要在特定平臺(tái)生成查，會(huì)同時(shí)生成一對(duì)密鑰對(duì)，即公鑰和私鑰。這對(duì)密鑰對(duì)就是用來在網(wǎng)絡(luò)通信中進(jìn)行明文加密以及數(shù)字簽名的。其中公鑰會(huì)隨著CSR文件，一起發(fā)給CA進(jìn)行權(quán)威認(rèn)證，私鑰由服務(wù)端自己保留，用來后續(xù)進(jìn)行通信，其主要就是用來交換對(duì)稱秘鑰

1.2、數(shù)據(jù)簽名

簽名的形成是基于非對(duì)稱加密算法的，注意，目前暫時(shí)和https沒有關(guān)系，不要和https中的公鑰私鑰搞混了

當(dāng)服務(wù)端申請(qǐng)CA證書的時(shí)候，CA機(jī)構(gòu)會(huì)對(duì)該服務(wù)端進(jìn)行審核，并專門為該網(wǎng)站形成數(shù)字簽名，過程如下

1. CA機(jī)構(gòu)擁有非對(duì)稱加密的私鑰A和公鑰A’
2. CA機(jī)構(gòu)對(duì)服務(wù)端申請(qǐng)的證書明文數(shù)據(jù)進(jìn)行hash，形成數(shù)據(jù)摘要
3. 然后對(duì)數(shù)據(jù)摘要用CA私鑰A’加密，得到數(shù)字簽名S

服務(wù)端申請(qǐng)的證書明文和數(shù)字簽名S共同組成了數(shù)字證書，這樣一份數(shù)字證書就可以頒發(fā)給服務(wù)端了

CA機(jī)構(gòu)：

1. 只能用CA的私鑰形成簽名，CA私鑰只有CA自己知道，世界上，只有CA能夠完成簽名的過程
2. 因?yàn)镃A是權(quán)威機(jī)構(gòu)，為了保證合法性，一般OS和瀏覽器內(nèi)部，在出廠下載的時(shí)候，就已經(jīng)內(nèi)置了CA的公鑰

1.3、數(shù)據(jù)摘要和數(shù)字指紋

• 數(shù)據(jù)摘要：其基本原理是利用單向散列函數(shù)(Hash函數(shù))對(duì)信息進(jìn)行運(yùn)算，生成一串固定長(zhǎng)度的數(shù)字摘要。
• 數(shù)字指紋：并不是一種加密機(jī)制,但可以用來判斷數(shù)據(jù)有沒有被竄改。
• 摘要常見算法：MD5、SHA1、SHA256、SHA512等，算法把無限的映射成有限，因此可能會(huì)有碰撞，即兩個(gè)不同的信息，算出的摘要相同，但是概率非常低
• 摘要特征：和加密算法的區(qū)別是，摘要嚴(yán)格意義不是加密，因?yàn)闆]有解密，只不過從摘要很難反推原信息，通常用來進(jìn)行數(shù)據(jù)對(duì)比。

1.4、加密過程

在客戶端和服務(wù)器剛?建里連接的時(shí)候，服務(wù)器給客戶端返回一個(gè)證書，證書包含了之前服務(wù)端的公鑰，也包含了網(wǎng)站的身份信息

客戶端進(jìn)行認(rèn)證
當(dāng)客戶端獲取到這個(gè)證書之后，會(huì)對(duì)證書進(jìn)行校驗(yàn)，防止證書是偽造的

• 判定證書的有效期是否過期
• 判定證書的發(fā)布機(jī)構(gòu)是否受信任，操作系統(tǒng)中已內(nèi)置的受信任的證書發(fā)布機(jī)構(gòu)
• 驗(yàn)證證書是否被篡改：從系統(tǒng)中拿到該證書發(fā)布機(jī)構(gòu)的公鑰，對(duì)簽名解密，得到?個(gè)hash值(稱為數(shù)據(jù)摘要)，設(shè)為hash1，然后計(jì)算整個(gè)證書的hash值，設(shè)為hash2，對(duì)比hash1和hash2是否相等，如果相等，則說明證書是沒有被篡改過的

1.5、查看瀏覽器的受信任證書發(fā)布機(jī)構(gòu)

選擇"設(shè)置"，搜索"管理證書"，如果沒有，在隱私設(shè)置和安全性->安全里面找找，即可看到以下界面

1.6、還會(huì)存在中間人攻擊嗎？

1. 中間人有沒有可能篡改該證書呢？
   中間人篡改了證書的明文，但是，由于他沒有CA機(jī)構(gòu)的私鑰，所以hash之后無法用私鑰加密形成簽名，那么也就沒法辦法對(duì)篡改后的證書形成匹配的簽名，如果強(qiáng)行篡改，客戶端收到該證書后會(huì)發(fā)現(xiàn)明文和簽名解密后的值不一致，則說明證書已被篡改，證書不可信，從而終止向服務(wù)器傳輸信息，防止信息泄露給中間人
2. 中間人可能掉包整個(gè)證書嗎？
   因?yàn)橹虚g人沒有CA私鑰，所以無法制作假的證書，所以中間人只能向CA機(jī)構(gòu)申請(qǐng)真證書，然后用自己申請(qǐng)的證書進(jìn)行掉包，這個(gè)確實(shí)能做到證書的整體掉包，但是，證書明文中包含了域名等服務(wù)端認(rèn)證信息，如果整體掉包，客戶端依舊能夠識(shí)別出來。永遠(yuǎn)記住：中間人沒有CA私鑰，所以對(duì)任何證書都無法進(jìn)行合法修改，包括自己的

三、常見問題

1、為什么摘要內(nèi)容在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候一定要加密形成簽名?

常見的摘要算法有：MD5和SHA系列
以MD5為例，我們不需要研究具體的計(jì)算簽名的過程，只需要了解MD5的特點(diǎn)：

• 定長(zhǎng)：無論多長(zhǎng)的字符串，計(jì)算出來的MD5值都是固定長(zhǎng)度的(16字節(jié)版本或者32字節(jié)版本)
• 分散：原字符串只要改變?點(diǎn)點(diǎn)，最終得到的MD5值都會(huì)有很大的差別
• 不可逆：通過原字符串生成MD5很容易，但是通過MD5還原成原字符串理論上是不可能的

正因?yàn)镸D5有這樣的特性，我們可以認(rèn)為如果兩個(gè)字符串的MD5值相同，則認(rèn)為這兩個(gè)字符串相同
假設(shè)我們的證書只是?個(gè)簡(jiǎn)單的字符串hello，對(duì)這個(gè)字符串計(jì)算hash值(比如MD5)，結(jié)果為：BC4B2A76B9719D91
如果hello中有任意的字符被篡改了，比如變成了hella，那么計(jì)算的MD5值就會(huì)變化很大：BDBD6F9CF51F2FD8
然后我們可以把這個(gè)字符串hello的哈希值BC4B2A76B9719D91從服務(wù)器返回給客戶端，此時(shí)客戶端就只要計(jì)算hello的哈希值，看看是不是BC4B2A76B9719D91即可。

但是，如果黑客把hello篡改了，同時(shí)也把哈希值重新計(jì)算下，客戶端就分辨不出來了

所以被傳輸?shù)墓Ｖ挡荒軅鬏斆魑?#xff0c;需要傳輸密文
所以，對(duì)證書明文(這里就是“hello”)hash形成散列摘要，然后CA使用自己的私鑰加密形成簽名，將hello和加密的簽名合起來形成CA證書，頒發(fā)給服務(wù)端，當(dāng)客戶端請(qǐng)求的時(shí)候，就發(fā)送給客戶端，中間人截獲了，因?yàn)闆]有CA私鑰，就無法更改或者整體掉包，就能安全的證明證書的合法性。最后，客戶端通過操作系統(tǒng)里已經(jīng)存了的證書發(fā)布機(jī)構(gòu)的公鑰進(jìn)行解密，還原出原始的哈希值，再進(jìn)行校驗(yàn)。

2、為什么簽名不直接加密，而是要先hash形成摘要?

縮小簽名密文的長(zhǎng)度，加快數(shù)字簽名和驗(yàn)證簽名的運(yùn)算速度

3、如何成為中間人

• ARP欺騙：在局域網(wǎng)中，hacker經(jīng)過收到ARP的Request廣播包，能夠偷聽到其它節(jié)點(diǎn)的IP和MAC地址。例如，黑客收到兩個(gè)主機(jī)A和B的地址，告訴B(受害者)，自己是A，使得B在發(fā)送給A的數(shù)據(jù)包都被黑客截取
• ICMP攻擊：由于ICMP協(xié)議中有重定向的報(bào)文類型，那么我們就可以偽造一個(gè)ICMP信息然后發(fā)送給局域網(wǎng)中的客戶端，并偽裝自己是一個(gè)更好的路由通路。從而導(dǎo)致目標(biāo)所有的上網(wǎng)流量都會(huì)發(fā)送到我們指定的接口上，達(dá)到和ARP欺騙同樣的效果
• 假wifi、假網(wǎng)站等

四、總結(jié)

完整流程：

HTTPS工作過程中涉及到的密鑰有三組：

• 第一組(非對(duì)稱加密)：用于校驗(yàn)證書是否被篡改，服務(wù)器持有私鑰(私鑰在形成CSR文件與申請(qǐng)證書時(shí)獲得)，客戶端持有公鑰(操作系統(tǒng)包含了可信任的CA認(rèn)證機(jī)構(gòu)有哪些，同時(shí)持有對(duì)應(yīng)的公鑰)，服務(wù)器在收到客戶端請(qǐng)求時(shí)，返回?cái)y帶簽名的證書，客戶端通過這個(gè)公鑰進(jìn)行證書驗(yàn)證，保證證書的合法性，進(jìn)?步保證證書中攜帶的服務(wù)端公鑰權(quán)威性。
• 第二組(非對(duì)稱加密)：用于協(xié)商生成對(duì)稱加密的密鑰，客戶端用收到的CA證書中的公鑰(是可被信任的)給隨機(jī)生成的對(duì)稱加密的密鑰加密，傳輸給服務(wù)器，服務(wù)器通過私鑰解密獲取到對(duì)稱加密密鑰
• 第三組(對(duì)稱加密)：客戶端和服務(wù)器后續(xù)傳輸?shù)臄?shù)據(jù)都通過這個(gè)對(duì)稱密鑰進(jìn)行加密和解密

第一組非對(duì)稱加密的密鑰是為了讓客戶端拿到第二組非對(duì)稱加密的公鑰
第二組非對(duì)稱加密的密鑰是為了讓客戶端把這個(gè)對(duì)稱密鑰傳給服務(wù)器
其實(shí)一切的關(guān)鍵都是圍繞這個(gè)對(duì)稱加密的密鑰，其他的機(jī)制都是輔助這個(gè)密鑰工作的