SSL的那些事兒

時間 2019-12-05

標籤 ssl 那些事兒欄目 SSL 简体版

原文原文鏈接

SSL的那些事兒

Https，SSL 平時咱們都聽的挺多，知道它是用來加密的，可是對於裏面的工做原理不是很清楚，因此在這裏我也總結下 SSL 的工做原理，但願你們可以幫助到你們。html

PS：其實這篇文章寫了好久了，是在一次公司的內部培訓準備的，寫了幾天PPT，也看了好多資料，雖然講完了，可是一直放在本身的iCloud裏了，最近又忽然看到它了，想到畢竟也是花了時間在上面，仍是想整理下發出來，和你們一塊兒學習探討。web

一，不安全的Case

明文傳輸

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

密文傳輸

這種對稱加密傳輸的過程是須要通訊雙方都能提早知道加密密鑰，而後才能讀懂雙方發送的密文。一旦雙方其中有一方泄露了加密密鑰，整個通訊過程就會有危險了。下面這個例子，若是 C 無論經過什麼途徑獲取到了加密密鑰，那麼 C 就能看到 A 和 B 之間的通訊內容了。less

二，SSL出現的背景

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

與此同時，全部行業都面臨着以下三大風險：

竊聽風險（eavesdropping）：第三方能夠獲知通訊內容。

篡改風險（tampering）：第三方能夠修改通訊內容。

冒充風險（pretending）：第三方能夠冒充他人身份參與通訊。

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

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

IETF(www.ietf.org)將SSL做了標準化，即RFC2246,並將其稱爲TLS（Transport Layer Security），從技術上講，TLS1.0與SSL3.0的差異很是微小。

在WAP的環境下，因爲手機及手持設備的處理和存儲能力有限，wap論壇（www.wapforum.org）在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。

公鑰加密和私鑰解密

下面這個圖例子裏，實際上是有兩個場景：

B 手上是有一對密鑰的，一個公鑰和一個私鑰，而後在 A 和 B 通訊的過程當中，B 把公鑰交給 A，私鑰是本身保管的，而後 A 就能夠拿着這個公鑰去加密談話內容了，並且這個加密的內容只能是 B 才能解密的。

流程是 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之間的一個可選層。

－－－－－－－－－
| HTTP |
－－－－－－－－－
| SSL |
－－－－－－－－－
| TCP |
－－－－－－－－－
| IP |
－－－－－－－－－

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: [其它人不會聽到的...]