說說SSL/TLS協(xié)議

互聯(lián)網(wǎng)的通信安全，建立在SSL/TLS之上

引自 阮一峰《SSL/TLS協(xié)議運行機制的概述》。

為什么使用SSL/TLS

不使用SSL/TLS的HTTP通信，即明文通信湖雹，存在三大風險

  • 竊聽風險
  • 篡改風險
    • 訪問網(wǎng)頁插播小廣告
  • 冒充風險
    • 釣魚網(wǎng)站

SSL/TLS怎么解決以上問題：

  • 防竊聽：通信過程加密
  • 防篡改：具備校驗機制，一旦被篡改曙搬，通信雙方會立刻發(fā)現(xiàn)
  • 防冒充：配備證書摔吏，防止被冒充

發(fā)展歷程

  • SSL（Secure Socket Layer，安全套接字層）
    • 1994年Netscape公司設(shè)計了SSL 1.0纵装，但是未發(fā)布
    • 1995年Netscape公司發(fā)布SSL 2.0征讲，存在嚴重的安全漏洞被3.0替代
    • 1996年Netscape發(fā)布SSL 3.0，得到大規(guī)模應(yīng)用
  • TLS（Transport Layer Security橡娄，傳輸層安全性協(xié)議）
    • 1999年IETF將SSL標準化诗箍，并稱作TLS，發(fā)布了SSL的升級版TLS 1.0版本
    • 2006年發(fā)布TLS 1.1
    • 2008年發(fā)布TLS 1.2挽唉，目前應(yīng)用最廣泛的版本
    • 2018年8月發(fā)布TLS 1.3版本

TLS是SSL的升級版扳还，TLS 1.0的版本號是3.1

SSL/TLS如何工作

SSL混合使用了多種加密技術(shù)才避，理解SSL之前先理解這些加密技術(shù)：

  • SSL使用公開密鑰加密（public key cryptography）來提供認證
  • 私鑰加密（secret key cryptography）保證數(shù)據(jù)隱私
  • 數(shù)字簽名來保證數(shù)據(jù)完整性

公開密鑰加密（public key cryptography）

  • 也稱非對稱加密
  • 加解密采用一對密鑰，公鑰公開氨距，私鑰保密。
  • 用公鑰加密只有私鑰能解開棘劣，反之亦然俏让。
  • 主要用于身份驗證。（B使用自己的私鑰加密數(shù)據(jù)發(fā)送給A茬暇，如果A能夠采用B的公鑰進行解密首昔，則可以相信數(shù)據(jù)確實來自B）
    • 數(shù)字簽名
  • 公鑰存在形式：數(shù)字證書
  • 缺點：計算耗時
  • 常見的公開密鑰加密算法
    • RSA、ElGamal糙俗、背包算法勒奇、Rabin、迪菲-赫爾曼密鑰交換協(xié)議中的公鑰加密算法巧骚、橢圓曲線加密算法（ECC）

私鑰加密（secret key cryptography）

  • 也稱對稱加密赊颠、共享密鑰加密
  • 加解密采用采用相同的密鑰，因此是對稱的劈彪，且在通信雙方共享
  • 加解密速度比公開密鑰加密快很多竣蹦。
  • 常見的對稱加密算法有DES、3DES沧奴、AES痘括、Blowfish、IDEA滔吠、RC5纲菌、RC6。
  • 缺點：如何在通信雙方之間安全的共享密鑰疮绷？

工作原理

對稱加密算法加密速度快翰舌，而且很安全，因此可被用作數(shù)據(jù)傳輸?shù)募用芩惴ù＠ⅰ５瞧浔∪觞c是如何在通信雙方之間安全的共享密鑰灶芝，即密鑰分發(fā)問題。

有沒有辦法在非安全的通信信道上協(xié)商出一個安全的密鑰用于后續(xù)采用對稱加密進行通信使用（即使通信過程被第三方截獲唉韭，但是只有通信雙方才知道密鑰）夜涕？答案是肯定的。

為了解決這個問題属愤，協(xié)議設(shè)計者引入了公開密鑰加密算法（即非對稱加密）女器，利用該算法作為基礎(chǔ)，可以在非安全的傳輸通道上協(xié)商出一個安全的通信密鑰住诸。

以公開密鑰加密算法為基礎(chǔ)可以解決密鑰分發(fā)問題：

  • Alice含有一對密鑰驾胆，公鑰公開涣澡，私鑰保留。
  • Bob使用Alice的公鑰加密信息發(fā)給Alice丧诺，Alice用其私鑰解開入桂。即使Charlie截獲了Bob發(fā)給Alice的信息，但是由于其沒有Alice的私鑰驳阎，因此其無法解開抗愁。
  • Bob向Alice發(fā)消息是沒有問題的，但是Alice向Bob發(fā)送經(jīng)過Alice私鑰加密后的消息還是可以被Charlie解開（因為Alice的公鑰是公開的呵晚，Charlie可以使用Alice的公鑰解開Alice發(fā)送給Bob的消息）

所以蜘腌，單純使用公開密鑰加密是不行的，可利用公開密鑰加密算法協(xié)商出一套后期雙方通信的密鑰饵隙，并且保證即使第三方知道雙方通信的過程撮珠，依然無法知曉后期通信的真正密鑰。

基于此金矛，可以看出SSL/TLS的工作原理簡單來說就是芯急，使用公開密鑰加密算法為基礎(chǔ)對通信雙方進行認證，并協(xié)商出一套用于后期對稱加密的密鑰和算法绷柒。

密鑰協(xié)商過程

對SSL/TLS的密鑰協(xié)商過程簡單抽象成下面的通信（實際上比這個更復(fù)雜）


密鑰協(xié)商抽象過程
  • Bob 生成一個隨機數(shù)a志于，使用Alice公鑰加密成A后發(fā)送給Alice（Charlie無法將A解密成a，因為它沒有Alice私鑰）
  • Alice生成一個隨機數(shù)b废睦，使用Alice私鑰加密成B后發(fā)送給Bob（Charlie可以利用Alice的公鑰將B解密成b）
  • Bob再生成一個隨機數(shù)c伺绽，使用Alice的公鑰加密成C后發(fā)送給Alice（Charlie不知道C）。這一步嗜湃，Bob和Alice都知道三個數(shù)（a奈应、b、c）购披，但Charlie只知道b
  • 然后杖挣，Bob和Alice分別使用一個已知算法PRF，對三個隨機數(shù)a刚陡、b惩妇、c進行計算生成最終的共享密鑰K，后期通信就使用K進行筐乳。
  • 由于K沒有明文傳輸歌殃，且攻擊者由于沒有獲取到足夠信息也無法生成，每次協(xié)商都生成不同的密鑰蝙云。因此具有很強的安全性氓皱。

中間人攻擊

以上協(xié)商過程還存在漏洞：中間人攻擊。

Charlie可以自己生成一套公鑰和私鑰，然后將Alice的公鑰替換成自己的公鑰波材，從而偽裝成Alice跟Bob通信股淡，然后偽裝成Bob跟Alice進行通信。從而可以知曉雙方通信的各種隨機數(shù)廷区，然后可以計算出Bob和Alice通信的密鑰唯灵。或者單純就偽裝成Alice跟Bob通信

這里的關(guān)鍵是如何防止Alice的公鑰被替換隙轻？或者是Bob（客戶端）如何識別出Alice（服務(wù)端）是一個冒牌貨早敬？防止公鑰被替換，我們忽略了一個細節(jié)：公鑰怎么保存大脉，客戶端如何拿到公鑰的？

事實上水孩，公鑰是通信時候镰矿，另一方告訴我的。

任何人都可以生成自己的公鑰和私鑰俘种，在Bob向Alice發(fā)請求詢問Alice的公鑰的時候秤标，可以被Charlie攔截，然后Charlie將自己的公鑰發(fā)給Bob宙刘，從而偽裝成Alice苍姜。Bob無法識別出來Charlie是冒牌的。

解決辦法：

  • 提供一個由權(quán)威機構(gòu)（CA）頒發(fā)的證書來證明這個公鑰就是屬于Alice的悬包。
  • Alice發(fā)送給Bob的不再是單純的公鑰衙猪，而是由CA認證的證書，這個證書里面包含了Alice的公鑰布近，發(fā)行機構(gòu)信息（CA）垫释，以及證書持有者（Alice），還有CA的簽名撑瞧，證書有效期
  • Bob相信CA棵譬，從而可以相信CA頒發(fā)的證書，從而相信其拿到的公鑰就是Alice的公鑰预伺，從而相信和它通信的就是Alice（因為只有Alice才有私鑰）订咸。

如何校驗證書

Alice發(fā)給Bob的證書，Bob如何校驗真?zhèn)危?/p>

  • 首先Bob拿到證書后酬诀，查看證書的頒發(fā)者是否可信脏嚷，如果不可信則終止連接。
  • 怎么知道證書的頒發(fā)者是否可信料滥？
    • 系統(tǒng)里面預(yù)裝根證書然眼，或者用戶自己安裝根證書，根證書是CA自己給自己頒發(fā)的證書葵腹。這個信任靠得就是平臺本身和用戶自己高每。
    • 如果CA在你信任的CA表里面屿岂，那么說明是受信任的。
  • CA可信任后鲸匿，需要進一步檢查證書有沒有被篡改爷怀。
    • 完整性校驗依賴于數(shù)字簽名。
    • 證書上面有CA的簽名带欢。簽名生成過程：
      • 利用HASH算法對證書內(nèi)容計算出HASH值运授，然后CA用自己的私鑰對HASH進行加密，這就是CA對該證書的簽名
    • 校驗：
      • 利用CA的公鑰（根證書里面有）對簽名進行解密乔煞，得到的就是解密后的HASH值
      • 利用HASH算法對證書內(nèi)容計算出HASH吁朦，和上一步解密后的HASH對比，如果不一致則認為被篡改
    • 為啥篡改者不連簽名也一起改了渡贾？
      • 因為它沒有CA的私鑰逗宜。
  • 別忘了，還有證書有效期檢查

證書知識

證書格式標準目前主要為X.509
證書包括的主要內(nèi)容：

  • 頒發(fā)機構(gòu)（CA）的名字（issuer）
  • 證書持有者（subject）
  • 證書持有者的公鑰和算法
  • 證書有效期
  • 證書內(nèi)容本身的數(shù)字簽名和算法（用CA私鑰加密）
  • 證書序列號（具有唯一性空骚，可以吊銷）

證書可以自簽名（自己給自己頒發(fā)）纺讲，也可以由權(quán)威的CA頒發(fā)。

證書頒發(fā)機構(gòu)CA分根CA和中間CA囤屹，通常證書不是直接由根CA頒發(fā)熬甚，而是由一個或多個中間CA簽發(fā)。根CA給中間CA頒發(fā)證書肋坚，中間CA再給你頒發(fā)證書乡括。最終用戶用來認證公鑰的證書被稱作end user 證書。

這些證書構(gòu)成了一條證書鏈冲簿。在服務(wù)端向客戶端發(fā)送證書的時候粟判，就需要發(fā)送證書鏈。

SSL/TLS 協(xié)議

工作原理講了峦剔，來看看協(xié)議實際過程档礁。

協(xié)議層級

位于傳輸層和應(yīng)用層之間，與應(yīng)用層協(xié)議無關(guān)吝沫。

SSL/TLS通信開始于信息交換呻澜，這里的信息交換叫做SSL握手。

SSL握手有三個主要目的：

  • 協(xié)商加密套件
  • 認證通信方（可選）
  • 基于協(xié)商好的加密機制構(gòu)建信息安全

SSL握手過程

SSL握手
1. ClientHello

客戶端向服務(wù)器發(fā)起加密通信的請求
主要提供以下信息

  • 最高支持的TLS協(xié)議版本
  • 一個客戶端生成的隨機數(shù)惨险，稍后用于生成“對話密鑰”
  • 支持的加密套件列表
  • 支持的壓縮算法

加密套件格式(TLS 1.3之前)： 密鑰交換算法_對稱加密算法_MAC算法_PRF

2. Server hello

服務(wù)端選擇雙方都支持的SSL版本羹幸、最佳加密套件、壓縮算法辫愉，產(chǎn)生一個隨機數(shù)返回栅受。


3. Certificate （可選）

服務(wù)端發(fā)送給客戶端它的證書或者證書鏈（以公鑰證書開始，鏈到根CA）。這一步可選屏镊，依賴于前兩步是否要求驗證服務(wù)端依疼。

4. Certificate request（可選）

服務(wù)端要求驗證客戶端身份的時候才會用到，用來請求客戶端發(fā)送它的證書給服務(wù)端
金融機構(gòu)往往只允許認證客戶連入自己的網(wǎng)絡(luò)而芥，就會向正式客戶提供USB密鑰律罢，里面就包含了一張客戶端證書。

5. Server key exchange（可選）

依賴于Server hello階段選擇密碼交換算法棍丐，如果是基于Diffie-Hellman算法误辑，則需要發(fā)送該消息，里面包含了Server的DH公鑰歌逢。

6. Server hello done
image.png
7. Certificate（可選）

如果第4步巾钉，服務(wù)端要求客戶端發(fā)送證書，則發(fā)送該消息秘案。
格式和服務(wù)端發(fā)送證書一樣

8. Client key exchange

客戶端生成用于創(chuàng)建用于對稱加密的密鑰的信息（premaster key睛琳，看作第三個隨機數(shù)？）踏烙。 對于RSA，客戶端然后使用服務(wù)器的公鑰加密此密鑰信息并將其發(fā)送到服務(wù)器历等。 對于基于Diffie-Hellman的密碼套件讨惩，此消息包含客戶端的DH公鑰。

這個消息發(fā)送個服務(wù)端后寒屯，客戶端和服務(wù)端可以根據(jù)之前的兩個隨機數(shù)荐捻，加上premaster key，然后利用前面協(xié)商好的PRF算法生成后續(xù)通信用的加密密鑰寡夹。

9. Certificate verify（可選）

這個消息是向服務(wù)端提供了證書之后才需要發(fā)送处面，它使用自己的私鑰加密到現(xiàn)在為止發(fā)送的所有消息的hash，然后服務(wù)端通過客戶端證書里的公鑰解密后進行hash驗證菩掏，來確保確實由客戶端的私鑰簽署魂角。

10 Change Cipher Spec

客戶端告訴服務(wù)端，后續(xù)通信就用協(xié)商好的密鑰進行加密

11. Client Finished

客戶端握手結(jié)束通知智绸。這一項也是前面發(fā)送的所有內(nèi)容的hash值野揪。應(yīng)該是用協(xié)商好的密鑰進行加密，供服務(wù)端進行驗證瞧栗。（不確定）

12 Server Change cipher spec

服務(wù)端發(fā)送改變密鑰通知

13 Server Finished

服務(wù)端握手結(jié)束通知

image.png

SSL協(xié)議握手完成之后就已經(jīng)生成了一套后續(xù)通信用的對稱密鑰以及算法斯稳，后續(xù)則使用協(xié)商好的密鑰進行加解密通信。

總結(jié)

SSL/TLS構(gòu)建的是一個加密通道迹恐，和上層應(yīng)用協(xié)議無關(guān)挣惰。
HTTP over TLS = HTTPS
MQTT也支持TLS
你也可以自定義協(xié)議基于SSL、TLS

參考資料

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 人面猴
    序言：七十年代末，一起剝皮案震驚了整個濱河市憎茂，隨后出現(xiàn)的幾起案子珍语，更是在濱河造成了極大的恐慌，老刑警劉巖唇辨，帶你破解...
    沈念sama閱讀 206,378評論 6贊 481
  • 死咒
    序言：濱河連續(xù)發(fā)生了三起死亡事件廊酣，死亡現(xiàn)場離奇詭異，居然都是意外死亡赏枚，警方通過查閱死者的電腦和手機亡驰，發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 88,356評論 2贊 382
  • 救了他兩次的神仙讓他今天三更去死
    文/潘曉璐 我一進店門，熙熙樓的掌柜王于貴愁眉苦臉地迎上來饿幅，“玉大人凡辱，你說我怎么就攤上這事±醵鳎” “怎么了透乾？”我有些...
    開封第一講書人閱讀 152,702評論 0贊 342
  • 道士緝兇錄：失蹤的賣姜人
    文/不壞的土叔 我叫張陵，是天一觀的道長磕秤。 經(jīng)常有香客問我乳乌，道長，這世上最難降的妖魔是什么市咆？ 我笑而不...
    開封第一講書人閱讀 55,259評論 1贊 279
  • ?港島之戀（遺憾婚禮）
    正文 為了忘掉前任汉操，我火速辦了婚禮，結(jié)果婚禮上蒙兰，老公的妹妹穿的比我還像新娘磷瘤。我一直安慰自己，他們只是感情好搜变，可當我...
    茶點故事閱讀 64,263評論 5贊 371
  • 惡毒庶女頂嫁案：這布局不是一般人想出來的
    文/花漫 我一把揭開白布采缚。 她就那樣靜靜地躺著，像睡著了一般挠他。 火紅的嫁衣襯著肌膚如雪扳抽。 梳的紋絲不亂的頭發(fā)上，一...
    開封第一講書人閱讀 49,036評論 1贊 285
  • 城市分裂傳說
    那天殖侵，我揣著相機與錄音摔蓝，去河邊找鬼。 笑死愉耙，一個胖子當著我的面吹牛贮尉，可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播朴沿，決...
    沈念sama閱讀 38,349評論 3贊 400
  • 雙鴛鴦連環(huán)套：你想象不到人心有多黑
    文/蒼蘭香墨 我猛地睜開眼猜谚，長吁一口氣：“原來是場噩夢啊……” “哼败砂！你這毒婦竟也來了？” 一聲冷哼從身側(cè)響起魏铅，我...
    開封第一講書人閱讀 36,979評論 0贊 259
  • 萬榮殺人案實錄
    序言：老撾萬榮一對情侶失蹤昌犹，失蹤者是張志新（化名）和其女友劉穎，沒想到半個月后览芳，有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體斜姥，經(jīng)...
    沈念sama閱讀 43,469評論 1贊 300
  • ?護林員之死
    正文 獨居荒郊野嶺守林人離奇死亡，尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 35,938評論 2贊 323
  • ?白月光啟示錄
    正文 我和宋清朗相戀三年沧竟，在試婚紗的時候發(fā)現(xiàn)自己被綠了铸敏。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 38,059評論 1贊 333
  • 活死人
    序言：一個原本活蹦亂跳的男人離奇死亡悟泵，死狀恐怖杈笔，靈堂內(nèi)的尸體忽然破棺而出，到底是詐尸還是另有隱情糕非，我是刑警寧澤蒙具，帶...
    沈念sama閱讀 33,703評論 4贊 323
  • ?日本核電站爆炸內(nèi)幕
    正文 年R本政府宣布，位于F島的核電站朽肥，受9級特大地震影響禁筏，放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜衡招，卻給世界環(huán)境...
    茶點故事閱讀 39,257評論 3贊 307
  • 男人毒藥：我在死后第九天來索命
    文/蒙蒙 一融师、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧蚁吝，春花似錦、人聲如沸舀射。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,262評論 0贊 19
  • 一樁弒父案，背后竟有這般陰謀
    文/蒼蘭香墨 我抬頭看了看天上的太陽脆烟。三九已至山林，卻和暖如春，著一層夾襖步出監(jiān)牢的瞬間邢羔，已是汗流浹背驼抹。 一陣腳步聲響...
    開封第一講書人閱讀 31,485評論 1贊 262
  • 情欲美人皮
    我被黑心中介騙來泰國打工， 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留拜鹤，地道東北人框冀。 一個月前我還...
    沈念sama閱讀 45,501評論 2贊 354
  • 代替公主和親
    正文 我出身青樓，卻偏偏與公主長得像敏簿，于是被迫代替她去往敵國和親明也。 傳聞我的和親對象是個殘疾皇子宣虾，可洞房花燭夜當晚...
    茶點故事閱讀 42,792評論 2贊 345