SSL的那些事兒

Https，SSL 平時我們都聽的挺多，知道它是用來加密的，但是對於裡面的工作原理不是很清楚，所以在這裡我也總結下 SSL 的工作原理，希望大家能夠幫助到大家。

PS：其實這篇文章寫了很久了，是在一次公司的內部培訓準備的，寫了幾天PPT，也看了好多資料，雖然講完了，但是一直放在自己的iCloud里了，最近又突然看到它了，想到畢竟也是花了時間在上面，還是想整理下發出來，和大家一起學習探討。

目錄

1. 不安全的Case
2. SSL出現的背景
3. SSL的演進
4. SSL的工作流程
5. 小結

一，不安全的Case

明文傳輸

眾所周知，明文傳輸肯定是不安全的。下面這個例子里，A 告訴 B 的每一句話，都會被 C 看到。

密文傳輸

這種對稱加密傳輸的過程是需要通信雙方都能提前知道加密密鑰，然後才能讀懂雙方發送的密文。一旦雙方其中有一方泄露了加密密鑰，整個通信過程就會有危險了。下面這個例子，如果 C 不管通過什麼途徑獲取到了加密密鑰，那麼 C 就能看到 A 和 B 之間的通信內容了。

二，SSL出現的背景

基於萬維網的電子商務和網上銀行等新興應用，極大地方便了人們的日常生活，受到人們的青睞。由於這些應用都需要在網路上進行在線交易，它們對網路通信的安全性提出了更高的要求。傳統的萬維網協議HTTP不具備安全機制——採用明文的形式傳輸數據、不能驗證通信雙方的身份、無法防止傳輸的數據被篡改等，導致HTTP無法滿足電子商務和網上銀行等應用的安全性要求。

與此同時，所有行業都面臨著如下三大風險：

• 竊聽風險（eavesdropping）：第三方可以獲知通信內容。
• 篡改風險（tampering）：第三方可以修改通信內容。
• 冒充風險（pretending）：第三方可以冒充他人身份參與通信。

那麼什麼是SSL呢？相信大家都會有這個疑問。

• SSL(Secure Socket Layer)是netscape公司設計的主要用以保障在Internet上數據傳輸安全，利用數據加密(Encryption)技術，可確保數據在網路上之傳輸過程中不會被截取及竊聽。一般通用之規格為40 bit之安全標準，美國則已推出128 bit之更高安全標準，但限制出境。當前版本為3.0。它已被廣泛地用於Web瀏覽器與伺服器之間的身份認證和加密數據傳輸。

• IETF(Internet Engineering Task Force (IETF))將SSL作了標準化，即RFC2246,並將其稱為TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差別非常微小。

• 在WAP的環境下，由於手機及手持設備的處理和存儲能力有限，wap論壇（WAP Forum）在TLS的基礎上做了簡化，提出了WTLS協議（Wireless Transport Layer Security），以適應無線的特殊環境。

三，SSL的演進

在講到SSL演進之前，還是先跟大家講下我們的對稱加密和非對稱加密。

對稱加密 symmetric cryptographic

• 簡單的說就是加密和解密用的同一個密鑰。常見的有DES，RC5。

• 優點：加解密速度快。缺點：容易暴露密鑰。

• 公式：E(msg, key) = emsg， D(emsg, key) = msg。

非對稱加密 asymmetric cryptographic

• 是指一對加密密鑰與解密密鑰，這兩個密鑰是數學相關，用某用戶密鑰加密後所得的信息，只能用該用戶的解密密鑰才能解密。如果知道了其中一個，並不能計算出另外一個。因此如果公開了一對密鑰中的一個，並不會危害到另外一個的秘密性質。稱公開的密鑰為公鑰；不公開的密鑰為私鑰。

• 簡單的說就是加密密鑰與解密密鑰不同，分私鑰和公鑰。這種方法大多用於密鑰交換，RSA便是一個我們熟知的例子。

• 優點：安全性高，不用暴露私鑰。缺點：加解密速度慢。

• 公式：E(msg, publickey) = emsg， D(emsg, publickey) != msg， D(emsg, privatekey) = msg。

公鑰加密和私鑰解密

下面這個圖例子里，其實是有兩個場景：

1. B 手上是有一對密鑰的，一個公鑰和一個私鑰，然後在 A 和 B 通信的過程中，B 把公鑰交給 A，私鑰是自己保管的，然後 A 就可以拿著這個公鑰去加密談話內容了，而且這個加密的內容只能是 B 才能解密的。
2. 流程是 1 裡面是一樣的，主要是加密的內容換成了一個對稱密鑰，然後用對稱密鑰去保證通信安全。

但是，如果只是提供公鑰和私鑰，任何人都可以是 B，只要跟 C 謊稱自己就是那個 B，然後提供公鑰代替 B 的公鑰，這樣的導致的結果是 A 根本不知道自己是在跟一個假 B 在聊天，後果很嚴重。

證書

由於存在上面的身份不確認的問題，這裡我們引入了證書來幫助證明 B 就是 B，而不是假 B。

那麼什麼是證書呢？ 簡單的理解證書是一個包含身份ID（類似我們的身份證），和公鑰信息的一個數字文件。

數字證書就是互聯網通訊中標誌通訊各方身份信息的一串數字，提供了一種在Internet上驗證通信實體身份的方式，其作用類似於司機的駕駛執照或日常生活中的身份證。它是由一個由權威機構——-CA機構，又稱為證書授權（Certificate Authority）中心發行的，人們可以在網上用它來識別對方的身份。數字證書是一個經證書授權中心數字簽名的包含公開密鑰擁有者信息以及公開密鑰的文件。最簡單的證書包含一個公開密鑰、名稱以及證書授權中心的數字簽名

目前數字證書的格式普遍採用的是X.509V3國際標準，一個標準的X.509數字證書包含以下一些內容：

剛才上面有講，證書其實是由 CA 發放的，這裡就會牽扯到 CA 的概念了。簡單點講，CA 是一個信任中心，可以理解是跟央行一樣，央行發行的紙，你信嗎？ 這個紙，你當然不信，但是你信任央行啊，信任政府啊，自然這個紙它就值錢了。所以同理，CA 發放的證書自然也是真實可靠的。

• CA機構，又稱為證書授證（Certificate Authority）中心，作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA中心為每個使用公開密鑰的用戶發放一個數字證書，數字證書的作用是證明證書中列出的用戶合法擁有證書中列出的公開密鑰。CA機構的數字簽名使得攻擊者不能偽造和篡改證書。它負責產生、分配並管理所有參與網上交易的個體所需的數字證書，因此是安全電子交易的核心環節。由此可見，建設證書授權（CA）中心，是開拓和規範電子商務市場必不可少的一步。為保證用戶之間在網上傳遞信息的安全性、真實性、可靠性、完整性和不可抵賴性，不僅需要對用戶的身份真實性進行驗證，也需要有一個具有權威性、公正性、唯一性的機構，負責向電子商務的各個主體頒發並管理符合國內、國際安全電子交易協議標準的電子商務安全證書。

• 數字證書頒發過程一般為：管理員只需生成「證書請求」（後綴大多為.csr），它包含你的個人信息和公鑰，然後把這份請求交給諸如Globlesign，verisign等有CA服務公司（當然，連同幾百美金），你的證書請求經驗證後，CA用它的私鑰簽名，形成正式的證書發還給你。管理員再在server上導入這個證書就行了。

下圖就是 CA 到 用戶證書 的一個組織結構：

所以，只要引入了證書，那相當於，客戶端會去獲取到伺服器的證書，然後會去判斷這個證書是否是我們的 CA 所發放的，自然就校驗了證書的合法性。最後的結構就是我們的 B 小伙終於可以證明自己了，而不用哭暈在廁所里了。

說到這裡，可能有的小夥伴會問，由於商業證書都是要買的，沒有錢怎麼辦？或者是說我們的服務都是內網的，不用考慮太多。那有什麼可以滿足這種訴求嗎？ 既然有我們的 CA，那有沒有不是 CA 的呢？ 答案是有的。就是我們可以自己來當這個非官方 CA，相當於搭建一個私服，自己玩，自己嗨。

Self-signed certificate：由自己的私鑰簽名而非第三方CA簽發的證書。如果你不想花那筆錢，可以自己做CA，現在有一些工具（openssl，keynote）可以幫助生成自定義的CA，伺服器的證書和自簽名。當伺服器端安裝好有自定義CA簽名的證書時，這個時候客戶端是需要導入自定義的CA證書，意味著客戶端「信任」這個CA簽署的證書）。而商業CA的一般不用，因為它們已經內置在系統中了。

但是建議商業伺服器還是要買個證書來保證安全。

數字簽名

由於公鑰加密只能協商出一個會話密鑰，通過會話密鑰可以保證通信的機密性。但是不能保證通信的完整性。簡單的說就是證書能夠保證通信的內容不被破解，但是不能保證內容被篡改。

在下面的例子里，A 小伙和 B 小伙通過一段時間的溝通已經互有好感，此時 B 小伙想要告訴 A 小伙：」我喜歡你」。但是居心叵測的 C 非要過來插一腳，在後面補一句變成了：」我喜歡你 我去年買了個表」，可想而知，從此世界少了一對，不知道 C 是出於什麼心態啊。不管怎麼樣，C 成功篡改了通信內容。

那麼問題來了，有什麼辦法可以讓 A 小伙和 B 小伙在一起呢。

duang，duang，duang，數字簽名來了。數字簽名就是為了解決信息被篡改的幹活。

數字簽名是指用原文進行HASH運算得到摘要信息並用發送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發送者的公鑰才能解密被加密的摘要信息，然後用HASH函數對收到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。

有了數字簽名的幫助，誰都無法阻止 A 和 B 在一起了。而這一切都是 SSL 自動幫我們做了，就是這麼自然，但是了解裡面的原理還是很有必要的。

四，SSL的工作流程

首先來說下它的架構，SSL是一個介於HTTP協議與TCP之間的一個可選層。

－－－－－－－－－

－－－－－－－－－

• SSL層: 藉助SSL層協議的的信道安全的協商出一份加密密鑰，並用此密鑰來加密HTTP請求，SSL在TCP之上建立了一個加密通道，通過這一層的數據經過了加密，因此達到保密的效果

• TCP層：與web server的443埠建立連接，傳遞SSL處理後的數據。

• SSL協議可分為部分： SSL記錄協議（SSL Record Protocol）：它建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。 SSL握手協議（SSL Handshake Protocol）：它建立在SSL記錄協議之上，用於在實際的數據傳輸開始前，通訊雙方進行身份認證、協商加密演算法、交換加密密鑰等。

握手的過程

簡單的說客戶端會發出一個 ClientHello 來發起握手，這個消息裡面包含了自己可實現的演算法列表和其它一些需要的消息，伺服器端會回應一個 ServerHello，這裡面確定了這次通信所需要的演算法，然後發過去自己的證書（裡面包含了身份和自己的公鑰）。客戶端在收到這個消息後會生成一個秘密消息，用伺服器的公鑰加密後傳過去，然後伺服器端用自己的私鑰解密後，會話密鑰協商成功，雙方可以用同一份會話密鑰來安全通信了。

舉個更形象的例子：

我們假設A與B通信，A是SSL客戶端，B是SSL伺服器端，加密後的消息放在方括弧[]里，以突出明文消息的區別。雙方的處理動作的說明用圓括弧（）括起。

A：我想和你安全的通話，我這裡的對稱加密演算法有DES,RC5,密鑰交換演算法有RSA和DH，摘要演算法有MD5和SHA。

B：我們用DES－RSA－SHA這對組合好了。這是我的證書，裡面有我的名字和公鑰，你拿去驗證一下我的身份（把證書發給A）。目前沒有別的可說的了。

A：（查看證書上B的名字是否無誤，並通過手頭早已有的CA的證書驗證了B的證書的真實性，如果其中一項有誤，發出警告並斷開連接，這一步保證了B的公鑰的真實性）產生一份秘密消息，這份秘密消息處理後將用作加密密鑰，加密初始化向量和hmac的密鑰。將這份秘密消息-協議中稱為per_master_secret-用B的公鑰加密，封裝成稱作ClientKeyExchange的消息。由於用了B的公鑰，保證了第三方無法竊聽）

我生成了一份秘密消息，並用你的公鑰加密了，給你（把ClientKeyExchange發給B）

注意，下面我就要用加密的辦法給你發消息了！

（將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰）

[我說完了]

B：（用自己的私鑰將ClientKeyExchange中的秘密消息解密出來，然後將秘密消息進行處理，生成加密密鑰，加密初始化向量和hmac的密鑰，這時雙方已經安全的協商出一套加密辦法了）

注意，我也要開始用加密的辦法給你發消息了！

[我說完了]

A: [我的秘密是…]

B: [其它人不會聽到的…]

小結

自此，我們終於撥開了 SSL 的迷霧，SSL 一個看似簡單的東西，裡面涵蓋了對稱加密，非對稱加密，證書 和 數字簽名。對 SSL 感興趣的小夥伴了解下這些還是有好處的，至少都是和我們學習工作息息相關的。

參考

• The Transport Layer Security (TLS) Protocol Version 1.2
• PKI技術原理(收集 整理 歸納) - 一顆平和的心 - 51CTO技術博客
• 看圖片 讀故事：輕鬆理解數字簽名和數字證書
• SSL是如何工作的?安全技術信息安全實驗室_希賽網
• 百度—您的訪問出錯了

推薦閱讀：