深刻TLS/SSL協議

整體

TLS/SSL協議是爲了解決網絡通信中的信息安全問題而誕生的。git

它的設計目的主要有三個:github

  • 身份驗證——搞清楚與我通信的人是否是我所想的那個。
  • 保密性——就算第三方拿到了通信內容,也搞不清楚其中所表達的意思。
  • 完整性——保證通信內容的完整性。

TLS/SSL協議主要包含兩部分:
一、Record記錄協議算法

  • 使用對稱加密算法來解決通信消息加密的部分。

二、Handshake握手協議瀏覽器

  • 爲了完成對稱加密,須要經過握手協議來傳遞密鑰。

對稱加密

對稱加密算法是指在加密和解密過程當中使用相同的密鑰。安全

舉例:
張三在與李四通信時爲了防止第三方竊聽,使用莫斯密碼將通信內容加密。李四接收到通信內容後,使用相同的莫斯密碼將內容解密。網絡

由於使用了相同的莫斯密碼,因此這屬於對稱加密。dom

網絡通信中的對稱加密之因此可以使用相同的密鑰對內容進行加/解密,是由於使用了異或運算。函數

異或運算

在數學領域中異或運算:當兩兩數值相同爲否,而數值不一樣時爲真。網站

在計算機領域中的異或運算: 加密

舉例:
現有一把密鑰:1010,與明文:0110。

一、使用密鑰對明文進行加密,得出密文爲:1100

  • 1 XOR 0 = 1
  • 0 XOR 1 = 1
  • 1 XOR 1 = 0
  • 0 XOR 0 = 0

二、使用相同的密鑰對密文進行解密,得出明文:0110

  • 1 XOR 1 = 0
  • 0 XOR 1 = 1
  • 1 XOR 0 = 1
  • 0 XOR 0 = 0

可見XOR異或運算是對稱加密的關鍵!

優勢:

  • 異或運算執行速度很是快,只需遍歷一遍就能夠了。

缺點:

  • 要求進行異或運算的密鑰與明文長度要一致的。明文有大有小,大到能夠是幾百兆甚至是幾個G,要求密鑰是一樣的大小是不可能的。

填充

異或運算要求雙方長度一致的這個缺點要怎麼解決呢?聰明的同窗或許已經想到解決方法了:就是將明文劃分爲多個等長的塊。

好比密鑰爲16字節的,那就將明文劃分爲多個16字節的塊,分別用密鑰對這些明文塊進行加解密。

Block cipher分組加密原理就是這樣:將明文劃分爲多個等長的Block塊,對每個Block塊分別加解密。

但並非全部的明文都能剛好的劃分爲16字節的塊。這時就須要填充!

填充的目的:

  • 當最後一個明文Block塊的長度不足時,就須要填充。

填充主要有兩種方法:

  • 位填充:以比特位爲單位進行填充。
  • 字節填充:以字節爲單位進行填充。

其中字節填充有4種填充方式:

  • 補零--最後不足的字節所有填上0。
    好比以16字節劃分,最後一個Block塊只有12個字節,那麼就填入00 00 00 00。
  • ANSI X9.23--也是補零,只是在最後一個字節填寫說明須要填充多少個字節。
    好比以16字節劃分,最後一個Block塊只有12個字節,那麼就填入00 00 00 04。
  • ISO 10126--填隨機數,在最後一個字節填寫說明須要填充多少個字節。
    好比以16字節劃分,最後一個Block塊只有12個字節,那麼就填入45 A3 D2 04。
  • PKCS7--須要填充多少個字節,就填寫多少。
    好比以16字節劃分,最後一個Block塊只有12個字節,那麼就填入04 04 04 04。

工做模式

對明文進行分組、填充後,還要按照必定的規律或方法進行加/解密。這些規律或者方法就是工做模式。

分組工做模式:block cipher mode of operation

  • 容許使用用一個分組密碼密鑰對多於一塊的數據進行加密,並保證其安全性。

一、 電子密碼本ECB模式--Electronic codebook
就是直接將明文分解爲多個塊,對每一個塊進行加密。

這種工做方法很是簡單、快速。可是缺點在於一樣的明文塊會被加密成相同的密文塊;所以,它不能很好的隱藏數據模式。

舉例:
對圖片進行ECB以後,是沒法隱藏到圖像的輪廓特性的。以下圖所示:

二、密碼分組連接CBC模式--Cipher-block chaining
每一個明文塊先與前一個密文塊進行異或後,再進行加密。在這種方法中,每一個密文塊都依賴於它前面的全部明文塊。同時,爲了保證每條消息的惟一性,在第一個塊中須要使用初始化向量。

它的主要缺點在於加密過程是串行的,沒法被並行化。

三、計數器模式CTR模式--Counter
CTR將塊密碼變爲流密碼。它經過遞增一個加密計數器以產生連續的密鑰流,其中,計數器能夠是任意保證長時間不產生重複輸出的函數。
這樣加密和解密過程都可以進行並行處理並且加密效果也很是理想。

CTR模式一樣存在問題:沒法提供密文的完整性校驗。當密文在傳輸過程當中存在丟失的狀況下,是沒法保證密文的完整性的。

完整性校驗

MAC算法--Message Authentication Code
MAC算法可以實現消息的完整性校驗。工做原理是基於hash函數的。

hash函數是一種從任何一種數據中建立小的數字「指紋」的方法。hash函數把消息或數據壓縮成摘要,使得數據量變小,將數據的格式固定下來。
簡而言之就是:不管輸入多長的字符串,經過hash函數,都能獲得定長較短的字符串。

MAC工做流程如圖所示:

  • 發送方使用密文與密鑰經過MAC算法生成一個MAC序列。而後將密文與MAC序列值一塊兒打包發送。
  • 接收方拿到以後,將密文與密鑰使用相同的MAC算法也生成一個MAC序列。而後比對這兩個MAC序列是否相同。

CTR分組工做模式加上MAC算法就誕生了GCM分組工做模式。

AES對稱加密算法

高級加密標準AES算法--Advanced Encryption Standard

  • 經常使用的填充方法:PKCS7
  • 經常使用的分組工做模式:GCM

AES的分組Block塊長度固定爲128比特,也就是16字節。
密鑰長度則能夠是128,192或256比特。

AES加密過程是在一個4×4的字節矩陣上運做。
因此從上圖中看出,分組長度128比特分爲4個32比特。而不一樣長度的密鑰則分爲四、六、8組32位比特的矩陣。

AES加密流程:如圖所示


10輪加密可分爲初始輪、普通輪和最終輪。
一、初始輪

  • AddRoundKey輪密鑰加

二、普通輪

  • AddRoundKey輪密鑰加
  • SubBytes字節替代
  • ShiftRows行移位
  • MixColumns列混合

三、最終輪

  • SubBytes字節替代
  • ShiftRows行移位
  • AddRoundKey輪密鑰加

addRoundKey輪密鑰加

  • 矩陣中的每個字節都與該次回合密鑰(round key)作XOR運算;每一個子密鑰由密鑰生成方案產生。

SubBytes字節替代

  • 透過一個非線性的替換函數,用查找表的方式把每一個字節替換成對應的字節。

ShiftRows行移位

  • 將矩陣中的每一個橫列進行循環式移位。

MixColumns列混合

  • 爲了充分混合矩陣中各個直行的操做。這個步驟使用線性轉換來混合每內聯的四個字節。最後一個加密循環中省略MixColumns步驟,而以另外一個AddRoundKey取代。

非對稱密碼

對稱加密的最大的問題是怎麼把密鑰傳遞給對方。非對稱密碼能夠實現密鑰的安全傳遞。

每個參與方都有一對密鑰:

  • 公鑰--對對方公開
  • 私鑰--僅本身擁有

非對稱加解密過程:

  • 使用對方的公鑰加密
  • 使用本身的私鑰解密

舉例:
張三要和李四通信
第一步:張三用李四的公鑰進行加密,將密文發送給李四。
第二步:李四用本身的私鑰進行解密。

密文是沒法經過公鑰解密的,只有私鑰才能解密。

張三怎麼拿到李四的公鑰?有兩種辦法:

  • 第一種:經過PKI公鑰基礎設施拿到的。
  • 第二種:創建連接過程當中經過握手過程由李四傳給張三的。

RSA算法

RSA是基於公開密鑰密碼體制的。

公開密鑰密碼體制是一種「由已知加密密鑰推導出解密密鑰在計算上是不可行的」密碼體制。

RSA算法中公私鑰的產生:

  • 隨機選擇兩個不想等的質數pq
  • 計算pq的乘積n(明文小於n)。
  • 計算n的歐拉函數v, v=(p-1)*(q-1)
  • 隨機選擇一個整數e,且1<e<v,kv是互質。
  • 計算e對於v的膜反元素d(d * e)%v = (e * d)%v = 1
  • 公鑰:(e, n)
  • 私鑰:(d, n)

RSA的安全性依賴於大數因數分解很是很是困難,也就是經過一個大數n是很是難的分解出pq

RSA算法的加解密流程:以下圖所示

  • 加密
    m是明文,c是密文
  • 解密

因爲進行大量的大數乘法運算,RSA的速度是對應一樣安全級別的對稱密碼算法的1/1000左右。

PKI公鑰基礎設施

PKI是非對稱密碼學的一個很是重要的應用。

基於私鑰加密,只能使用公鑰解密的原理實現身份驗證的做用。

簽名與驗籤的流程

  • 首先網站站長經過RSA算法生成一對公私鑰,而後將公鑰與站長的我的身份發送給Certificate Authority數字證書認證機構
  • CA機構覈實完我的信息後就對這些信息使用CA機構的私鑰進行加密生成一個公鑰數字證書
  • 而後將這個公鑰數字證書頒發給站長。公鑰數字證書的組成:CA信息、公鑰用戶信息、公鑰、權威機構的簽名和有效期。

具體的流程:如圖所示
簽名:

  • 將站長的我的信息經過hash函數生成一個hash值。
  • 而後用CA機構的私鑰對hash值進行加密。
  • 將加密後的內容與站長的我的信息還有網站的公鑰一塊兒打包成一個公鑰數字證書。

驗籤:

  • 當瀏覽器拿到這個公鑰數字證書以後,就把該證書內容分解出兩部分:站長我的信息與加密的hash值。
  • 瀏覽器將站長的我的信息經過證書說明的hash函數生成一個hash值。
  • 而後用CA機構的公鑰解密證書中的加密的hash值。
  • 對比兩個hash值是否相等。

證書類型:

  • 域名驗證證書domain validatedDV證書
    DV證書一般是免費的
  • 組織驗證證書organization validatedOV證書
    OV證書驗證更爲嚴格,一般是收費的
  • 擴展驗證證書extended validateEV證書
    EV證書最爲嚴格,因此也是最貴的。

從加密安全性上看,三類證書的保密性都是同樣的,只有在站長的我的信息驗證上有所不一樣。

DH密鑰交換協議

上面說到張三有兩種辦法能夠拿到李四的公鑰:

  • 第一種:經過PKI公鑰基礎設施拿到的。
  • 第二種:創建連接過程當中經過握手過程由李四傳給張三的。

RSA算法通常是第一種方法中用於CA機構的身份驗證上的。事實上RSA算法用於第二種方法也是可行的。

舉例:
張三與李四創建連接。李四用RSA算法生成一對公私鑰,在握手中李四將公鑰傳遞給張三。而後張三將對稱加密的密鑰用公鑰進行加密後傳遞給李四,李四用私鑰解密獲得密鑰。

就算第三方拿到公鑰,沒有私鑰是沒法解密密文的。

但這種方式有一個缺點:沒有前向保密性。
也就是說當第三方將通信的報文所有保存下來後,在破解出私鑰以後,就能知道全部密文內容。

DH密鑰交換協議就解決了這個問題。它能夠雙方在徹底沒有對方任何預先信息的條件下經過不安全信道建立起一個密鑰。因此每一次通信中密鑰都是實時生成的

具體流程:

  • 首先在握手過程當中,李四生成一對公私鑰,將公鑰發送給張三。
  • 張三收到李四的公鑰後,本身也生成一對公私鑰,將本身的公鑰發送給李四。
  • 而後張三和李四用DH協議將對方的公鑰和本身的私鑰生成一個密鑰。這兩個密鑰是徹底相同的。

DH密鑰交互協議的原理:

  • 李四指定兩個隨機公開數gp,而後指定本身私鑰a,根據gp和私鑰a生成公鑰A
  • 李四將公開數gp與本身公鑰A發送給張三。
  • 張三本身指定一個私鑰b,而後基於公開數gp和私鑰b生成公鑰B
  • 張三將本身公鑰B發送給李四。
  • 張三和李四根據對方的公鑰和本身的私鑰,生成對稱加密用的密鑰K

如圖所示

DH交換協議的問題:容易遭到中間人僞造攻擊。

簡單來講:第三方僞裝本身是張三向李四進行一次DH密鑰交換,而後又僞裝李四向張三進行一個DH密鑰交換。就能夠知道密鑰K

解決這個方法很簡單,就是使用PKI公鑰基礎體系中的身份驗證。第三方就沒法僞裝李四這個站長了。

從圖中看出DH協議也涉及到大量的大數乘法運算,速度也是很是慢的。而目前使用的DH密鑰交換協議是基於ECC橢圓曲線加持過的,速度很是的快。稱爲ECDHE密鑰交換算法。具體細節能夠本身去搜索查詢。

總結

TLS1.2中常用的一個安全套件是:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

具體說明一下:

  • ECDHE:密鑰交換算法
  • RSA:身份驗證算法
  • AES:對稱加密的算法
  • 128:對稱加密的密鑰長度
  • GCM:對稱加密的工做模式
  • SHA256:hash算法

參考文獻:

分組密碼工做模式--wiki
高級加密標準--wiki
RSA算法--wiki
DH密鑰交換協議--wiki
《計算機網絡:自頂向下方法》
Web協議詳解與抓包實戰--陶輝

結尾

更多文章請移步樓主github,若是喜歡請點一下star,對做者也是一種鼓勵。

相關文章
相關標籤/搜索