企業(yè)建站知識推廣知識小程序微信營銷 APP開發(fā) 前端設(shè)計 MindManager 開發(fā)語言自媒體

淺談HTTPS（SSL/TLS）原理

發(fā)表日期：2017-03 文章編輯：小燈瀏覽次數(shù)：1909

一、https概述

1. ? ?什么是HTTP？

在了解https之前，我們首先來了解一下什么是http。http即Hypertext transfer protocol，超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，由萬維網(wǎng)協(xié)會（World Wide Web Consortium，W3C）和互聯(lián)網(wǎng)工程任務(wù)組（Internet

Engineering Task Force，IETF）制定標準，其中著名的RFC2616定義了http1.1。設(shè)計之初的目的是為了提供一種發(fā)布和接收html頁面的方法，由統(tǒng)一資源標識符（Uniform Resource Identifiers，URI）來標識。

HTTP是一個C/S架構(gòu)，由終端用戶通過使用瀏覽器或其它工具發(fā)起的一個http請求到服務(wù)器指定的端口上獲取數(shù)據(jù)內(nèi)容，默認為80端口，工作在OSI七層參考模型的應(yīng)用層上。

http協(xié)議到現(xiàn)在已經(jīng)演化出了很多版本，大部分向下兼容，目前版本有0.9、1.0、1.1及HTTP/2，其中0.9版本已經(jīng)過時不在使用，主流版本為1.1，未來版本為2.0。

http協(xié)議為明文傳輸，所有信息均為可見的，存在不安全特性，信息極易被篡改和劫持，也因此衍生出了相對更為安全的https。

2. ? ?什么是HTTPS？

? ? ? HTTPS（Hyper Text Transfer Protocol Secure），即超文本傳輸安全協(xié)議，也稱為http over tls等，是一種網(wǎng)絡(luò)安全傳輸協(xié)議，其也相當于工作在七層的http，只不過是在會話層和表示層利用ssl/tls來加密了數(shù)據(jù)包，訪問時以https://開頭，默認443端口，同時需要證書，學(xué)習(xí)https的原理其實就是在學(xué)習(xí)ssl/tls的原理。

3. ? ?SSL/TLS

? ? ? SSL（Secure Sockets Layer），即安全套接層，是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信提供安全及數(shù)據(jù)完整性保障，使用X.509認證，網(wǎng)景公司（Netscape）在1994年推出HTTPS協(xié)議，以SSL進行加密，這是SSL的起源。IETF將SSL進行標準化，1999年公布第一版TLS標準文件。SSL目前有三個版本，SSL1.0、SSL2.0、SSL3.0，因其存在嚴重的安全問題，大多數(shù)公司目前均已不在使用了。因此本文著重是基于TLS講解。

? ? ? TLS（Transport Layer Security），即安全傳輸層，IETF將SSL標準化后的產(chǎn)物。其實TLS可以理解為SSL的升級版，TLS目前也有三個版本，TLS1.0、TLS1.1、TLS1.2，TLS目前只是草案，并未面世，目前常用的為TLS1.2，server配置通常三個版本均支持。

? ? ? 擴展知識：X.509標準。SSL證書格式遵循X.509標準，X.509是由國際電信聯(lián)盟（ITU-T）制定的數(shù)字證書標準，ITU于1988年制訂了X.500系列標準，其中X.500和X.509是安全認證系統(tǒng)的核心，X.500定義了一種區(qū)別命名規(guī)則，以命名樹來確保用戶名稱的唯一性，X.509則為X.500用戶名稱提供了通信實體鑒別機制，并規(guī)定了實體鑒別過程中廣泛適用的證書語法和數(shù)據(jù)接口，X.509稱之為證書。X.509給出的鑒別框架是一種基于公開密鑰體制的鑒別業(yè)務(wù)密鑰管理，即一個用戶有兩把密鑰，公鑰和私鑰，同時該標準也規(guī)范了公開密鑰認證、證書吊銷列表、授權(quán)證書、證書路徑驗證算法等。

X.509標準知識來源：http://itrus.com.cn/2009/1126/235.html

4. ? ?Openssl

Openssl計劃在1998年開始，其目標是發(fā)明一套自由的加密工具，在互聯(lián)網(wǎng)上使用，它是一個開源的加密庫，由C語言寫成，SSL/TLS協(xié)議基于該庫進行的加解密。

Openssl支持多種不同的加密算法：

加密：

? ? AES、Blowfish、Camellia、SEED、DES、RC2、RC4、RC5等

散列函數(shù)：

? ? MD5、MD2、SHA-1、SHA-2、RIPEMD-160 等

公開密鑰加密：

? ? RSA、DSA、Diffie-Hellman key exchange（DH）等

? ? Openssl不僅包含加密庫，同時也是一個小型的CA程序，它可以幫助你完成一個CA的建設(shè)，具體參數(shù)可以通過man幫助來查看學(xué)習(xí)，這里暫時先不講這方面了。

二、基礎(chǔ)知識儲備

1. ? ?SNI概述

? ? ? https是http構(gòu)建在SSL之上的一種協(xié)議，SSL加密在到達應(yīng)用層的時候就已經(jīng)完成了，http層完全不知道下面發(fā)生了什么。根據(jù)https的工作原理，瀏覽器在訪問一個https站點時候，會先與服務(wù)器建立ssl連接，建立連接的第一個步驟就是要請求服務(wù)器證書，而服務(wù)器這個在發(fā)送證書的時候，是不知道瀏覽器訪問的是哪個域名的，所以無法根據(jù)不同的域名發(fā)送不同的證書，也因此有了眾所周知的事情，https往常在使用的時候必須要一個IP綁定一個證書，多個證書就要綁定在多個不同的IP之上，這個在我做CDN的HTTPS加速時飽受了痛苦，通常業(yè)務(wù)量大的時候一個設(shè)備就綁定了20多個IP，分別對應(yīng)不同的證書，管理起來異常的麻煩。那么有沒有一種技術(shù)即可以節(jié)省IP，又可以減少配置工作呢？答案是肯定的，為了解決這一問題，SNI技術(shù)應(yīng)運而生了。

? ? ? SNI（Server Name Indication），即服務(wù)器名稱指示，是一個擴展的TLS協(xié)議，在該協(xié)議下，在握手過程開始時就可以通過客戶端告訴它正在連接的服務(wù)器的主機名稱，這就允許了服務(wù)器在相同的IP地址和TCP端口號上綁定多個證書了，并且因此允許在相同的IP地址上提供多個安全的https網(wǎng)站，它與虛擬主機概念相同。

SNI通過讓客戶端發(fā)送主機名作為TLS協(xié)商的一部分來解決此問題，這就使得服務(wù)器能夠提前選擇正確的主機名，并向瀏覽器提供包含正確名稱的證書。SNI需要客戶端瀏覽器和server端程序同時支持，目前主流的瀏覽器和server端程序均已支持了該特性，近年來IE6的市場份額應(yīng)該可以小到忽略不計了。

以百度為例，SNI請求的字段數(shù)據(jù)包如下例子：

詳細釋義見RFC6066.

2. ? ?公鑰基礎(chǔ)設(shè)施PKI概述

? ? ? 說到HTTPS就不得不提及一下PKI，PKI（Public key Infrastructure）即公鑰基礎(chǔ)設(shè)施，簡單的說PKI技術(shù)就是利用公鑰理論和技術(shù)建立的提供信息安全服務(wù)的基礎(chǔ)設(shè)施，該體系在統(tǒng)一的安全認證標準和規(guī)范基礎(chǔ)上提供在線身份認證，是CA認證、數(shù)字證書、數(shù)字簽名以及相關(guān)安全應(yīng)用組件模塊的集合。做為一種技術(shù)體系，PKI可以作為支持認證、完整性、機密性和不可否認性的技術(shù)基礎(chǔ)，從技術(shù)上解決網(wǎng)上身份認證、信息完整性的抗抵賴等安全問題，為網(wǎng)絡(luò)應(yīng)用提供可靠的安全保障，但PKI不僅僅涉及到技術(shù)層面的問題。

2.1 ? ?PKI的信任服務(wù)

? ? ? a) ? ?認證

? ? ? b) ? ?支持密鑰管理

? ? ? c) ? ?完整性與不可否認

2.2 ? ?PKI標準

? ? ? a) ? ?X.209（1988）ASN.1基本編碼規(guī)則的規(guī)范

? ? ? b) ? ?X.500（1993）信息技術(shù)之開放系統(tǒng)互聯(lián)：概念、模型及服務(wù)簡述

? ? ? c) ? ?X.509（1993）信息技術(shù)之開放系統(tǒng)互聯(lián)：鑒別框架

? ? ? d) ? ?PKCS系列標準

? ? ? e) ? ?OCSP在線證書狀態(tài)協(xié)議

? ? ? f) ? ? LDAP輕量級目錄訪問協(xié)議

2.3 ? ?PKI體系結(jié)構(gòu)

? ? ? a) ? ?認證機構(gòu)CA（Certificate Authority）

? ? ? b) ? ?證書和證書庫

? ? ? c) ? ?密鑰備份及恢復(fù)

? ? ? d) ? ?密鑰和證書的更新

? ? ? e) ? ?證書歷史檔案

? ? ? f) ? ? 客戶端軟件

? ? ? g) ? ?交叉認證

? ? ? 以上內(nèi)容不做過多的概述，因為跟學(xué)習(xí)這個沒有什么太大的直接關(guān)系，可做為了解，其中CA中心會擴展一下。

3. ? ?CA中心

? ? ? 認證機構(gòu)CA（Certificate Authority）在https中是一個很重要的角色，CA是PKI的核心執(zhí)行機構(gòu)，是PKI的主要組成部分，通常稱之為認證中心，從廣義上講，認證中心還應(yīng)該包括證書申請注冊機構(gòu)RA（Registration Authority），它是數(shù)字證書的申請注冊、證書簽發(fā)的管理機構(gòu)。客戶端是怎么驗證該證書的頒發(fā)機構(gòu)即CA中心是合法有效的呢，其實在系統(tǒng)瀏覽器中有預(yù)埋CA中心的根證書，在其中的根證書為可信任機構(gòu)，如圖：

根證書可信任機構(gòu)

3.1 ? ?CA的主要職責(zé)

? ? ? a)籠統(tǒng)的說CA中心負責(zé)證書的簽發(fā)和管理等；

? ? ? b)驗證并標識證書申請者的身份，對證書申請者的信用度、申請證書的目的、身份的真實可靠性等問題進行審查，確保證書與身份綁定的準確性；

? ? ? c)確保CA用于簽名證書的非對稱密鑰的質(zhì)量和安全性；

? ? ? d)管理證書信息資料，管理證書序號和CA標識，確保證書主體標識的唯一性，防止證書主 ?體名字的重復(fù)。在證書使用中確定并檢查證書的有效期，保證不使用過期或已作廢的證書， ? ?確保網(wǎng)上交易安全，發(fā)布和維護作廢證書列表（CRL）。

? ? ? 由此可見，CA是保證電子商務(wù)、網(wǎng)上銀行、互聯(lián)網(wǎng)環(huán)境健康等的權(quán)威性、可信任和公正的第三方機構(gòu)。

4. ? ?證書相關(guān)常識

4.1 ? ?公鑰

? ? ? 公鑰（Public-key），即所謂的公共證書，由CA中心頒發(fā)的合法文件，可以在互聯(lián)網(wǎng)傳播，誰都可以輕易獲取到。公鑰證書文件的擴展名實際上只是一種使用習(xí)慣上的區(qū)別，后綴包括但不僅限于crt、cer、key、der、pem，pem可能包含了公鑰和私鑰文件，通常可以從pem文件中導(dǎo)出公鑰和私鑰。公鑰中包含頒發(fā)給哪個域名，公司名，加密算法，組織機構(gòu)，有效期等等信息，示例如圖：

公鑰信息

? ? ? 當然如果說一個證書只能綁定一個域名的話，100個域名就要100個證書了，這樣管理和費用成本都會顯著增加，根據(jù)不同用戶的不同需求，同時CA中心也會根據(jù)不同國家國情推出不同的產(chǎn)品，例如一個證書綁定多個單域名或泛域名，這些我們都是可以通過公鑰查看出來的，示例如圖：

證書備用名稱

4.2? ? 私鑰

? ? ? 私鑰（private-key），即通常就叫所謂的私鑰，私鑰在生成CSR文件的時候同時生產(chǎn)，后綴通常為.key，由使用者自己保管，不可在互聯(lián)網(wǎng)傳播，極其重要。

4.3 ? ?CSR文件

? ? ? CSR（Cerificate Signing Request）文件，即證書請求文件，用于發(fā)送給CA中心用來生產(chǎn)公鑰，該文件在生成的時候會填寫一些基本信息，諸如國家代碼、公司名、省份城市、管理員郵箱等等信息，可以在線生成也可以通過openssl生成，例：

openssl req -new -nodes -newkey rsa:2048 -keyout xxx.key-out xxx.csr

4.4 ? ? OCSP在線證書狀態(tài)

? ? ? OCSP（Online Certificate Status Protocol），即在線證書狀態(tài)協(xié)議，其實就是一個請求應(yīng)答模式的協(xié)議，用于在線的查詢證書吊銷狀態(tài)，而無需查詢CRL，在對證書狀態(tài)實時性要求較高的場合適用于使用OCSP來查詢當前證書狀態(tài)。

4.5 CRL證書吊銷列表

? ? ? CRL（Certificate Revocation List），即證書吊銷列表，它指定了一套證書發(fā)布者認為無效的證書，CRL一定是被CA所簽署的，它可以使用與簽發(fā)證書相同的私鑰，也可以使用專門的CRL簽發(fā)私鑰，CRL中包含了被吊銷證書的序列號。通常情況下，公鑰證書中會寫出該證書的CA中心CRL地址，示例如圖：

CRL下載地址

CRL中也會包含一些基本信息，例如列表更新時間，吊銷證書序號等，示例如圖：

吊銷列表

5. ? ?證書鏈

? ? ? 簡單點闡述證書鏈就是，為了盡可能的保證根證書的安全性，因此CA中心也采取了一種樹狀的結(jié)構(gòu)，一個root CA下面包含多個intermediates CA，然后根CA和次級CA都可以頒發(fā)證書給用戶，頒發(fā)的證書分別是根證書和次級證書，最后則是用戶的證書，也可以說是中級證書，中級證書可以在CA下載到，這個一般是共通的，證書鏈的設(shè)計是基于“信任鏈”的理念設(shè)計的。 ? ? ? ? ? ?證書鏈的詳盡闡述則需要大家去自行學(xué)習(xí)了，我對于這個證書鏈的了解是因為遇到過故障，也因此才了解了證書鏈是怎么個東西，在之前做https加速的時候，早期的安卓系統(tǒng)版本比較低，在低版本的系統(tǒng)瀏覽器中訪問某些移動網(wǎng)站的時候，會報錯，大意就是無法驗證這個網(wǎng)站證書是合法的，因為沒有證書鏈，它不知道這個證書的上一級頒發(fā)者是誰，新版本的系統(tǒng)及瀏覽器中則很少見到這種問題。證書鏈示例如下：

證書鏈

6. ? ?加密算法概述

6.1? ? 對稱加密算法

? ? ? 對稱加密技術(shù)（Stmmetric Cryptographic technique），即對稱加密技術(shù)，發(fā)送方和接收方使用相同的算法來進行加解密。

? ? ? 優(yōu)點：算法公開，計算量小，加密速度快，效率高。

? ? ? 缺點：加解密雙方使用同樣的密鑰，安全性得不到保障。

? ? ? 常見算法：

? ? ? ? ? DES、3DES、TDEA、RC4、RC5、AES等。

? ? ? DES（Data Encryption Standard）：數(shù)據(jù)加密標準，速度快，適用于加密大量數(shù)據(jù)的場景。

? ? ? 3DES（Triple Data Encryption Algorithm縮寫TDEA，Triple DEA）：基于DES，對一塊數(shù)據(jù)應(yīng)用三次DES數(shù)據(jù)加密標準算法，強度更高。

? ? ? AES（Advanced Encryption Standard）：高級加密標準，是下一代加密算法標準，速度快，安全級別高。

6.2 ? ?非對稱加密算法

? ? ? 非對稱加密技術(shù)（asymmetric crypto-graphic technique），即采用了兩種相關(guān)變換的密碼技術(shù)，也就是公鑰和私鑰，公鑰加密私鑰解密，私鑰加密公鑰解密。

? ? ? 常見算法：

? ? ? ? ? RSA、DSA、ECC、DH等。

? ? ? RSA：RSA是1977年由羅納德·李維斯特（Ron Riverst）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一起提出的，當時三人都在麻省理工學(xué)院工作，RSA就是他們?nèi)诵帐祥_頭字母的縮寫拼在一起組成的。 ? ? ?

? ? ? RSA算法的安全性基于大數(shù)分解質(zhì)因子的困難性，由于人們一直未找到對大數(shù)進行因子分解的有效方法，所以RSA在目前看來依然是安全的，RSA算法既可用于加密，也可用于簽名，是目前應(yīng)用最廣的公鑰算法。

? ? ? DSA（Digital Signature Algorithm）：數(shù)字簽名算法，基于離散對數(shù)難題的，只能用于簽名，不能用于加密。

? ? ? DH（Diffie-Hellman）：是一種安全的密鑰交換協(xié)議，它可以讓雙方在完全沒有對方任何預(yù)先信息的條件下通過不安全通道創(chuàng)建一個密鑰，這個密鑰可以在后續(xù)的通信中做為對稱密鑰來加密通訊內(nèi)容。

? ? ? 該算法詳細釋義參見維基百科：

?https://zh.wikipedia.org/wiki/%E8%BF%AA%E8%8F%B2-%E8%B5%AB%E7%88%BE%E6%9B%BC%E5%AF%86%E9%91%B0%E4%BA%A4%E6%8F%9B

? ? ? ECC（Elliptic curve cryptography），即橢圓曲線密碼學(xué)，基于橢圓曲線數(shù)學(xué)。主要優(yōu)勢是在某些情況下它比其他方法使用更小的密鑰，提供相當或更高等級的安全。

? ? ? 該算法詳細釋義參見維基百科： ? ? ? ? ? ? ? ? ? ? ? ? ? ?https://zh.wikipedia.org/wiki/%E6%A4%AD%E5%9C%86%E6%9B%B2%E7%BA%BF%E5%AF%86%E7%A0%81%E5%AD%A6

6.3 ? ?信息摘要算法

? ? ? 信息摘要算法如下：

? ? ? ? ? ? md2、md4、md5、sha、sha1等。

? ? ? MD5（MD5 Message-Digest Algorithm），一種被廣泛使用的密碼散列函數(shù)，將數(shù)據(jù)運算變?yōu)榱硪还潭ㄩL度值是散列算法的基礎(chǔ)原理，可以產(chǎn)生一個128位16字節(jié)的散列值（hash value），用于確保信息傳輸完整一致。MD5是可以被破解的，對于需要高度安全的不適用于此摘要算法。

? ? ? SHA-1（Secure Hash Algorithm 1），即安全散列算法1，也是一種密碼散列函數(shù)，美國國家安全局涉及，SHA1可以生成一個被稱為消息摘要的160位20字節(jié)的散列值，散列值通常呈現(xiàn)形式為40個十六進制數(shù)，sha1算法目前也已不在安全，2017年2月23日google與CWI Amesterdam宣布成功完成了一個碰撞攻擊。

6.4 ? ?HMAC

? ? ? HMAC（Keyed-hash message authentication code），即密鑰散列消息認證碼，又稱散列消息認證碼，是一種通過特別計算方式之后產(chǎn)生的消息認證碼（MAC），使用密碼散列函數(shù)，同時結(jié)合一個加密密鑰，它可以用來保證數(shù)據(jù)的完整性，同時可以用來做某個消息的身份驗證，由RFC2104定義，數(shù)學(xué)公式為：

HMAC數(shù)學(xué)公式

? ? ? 其中：

? ? ? ? ? H為密碼散列函數(shù)（如MD5或SHA-1）

? ? ? ? ? K為密鑰（secret key）

? ? ? ? ? m是要認證的消息

? ? ? ? ? ?K'是從原始密鑰K導(dǎo)出的另一個秘密密鑰（如果K短于散列函數(shù)的輸入塊大小，則向右填充（Padding）零；如果比該塊大小更長，則對K進行散列）

? ? ? ? ? ?||代表串接

? ? ? ? ? ⊕代表異或（XOR）

? ? ? ? ? ?opad是外部填充（0x5c5c5c…5c5c，一段十六進制常量）

? ? ? ? ? ?ipad是內(nèi)部填充（0x363636…3636，一段十六進制常量）

三、 ?TLS握手

? ? ? TLS握手階段是發(fā)生在TCP建連之后開始進行的，握手其實就是在協(xié)商，協(xié)商加解密協(xié)議所需要的一些參數(shù)信息等內(nèi)容。

? ? ? TLS握手過程有單向驗證和雙向驗證之分，簡單解釋一下，單向驗證就是server端將證書發(fā)送給客戶端，客戶端驗證server端證書的合法性等，例如百度、新浪、google等普通的https網(wǎng)站，雙向驗證則是不僅客戶端會驗證server端的合法性，同時server端也會驗證客戶端的合法性，例如銀行網(wǎng)銀登陸，支付寶登陸交易等。

? ? ? TLS握手過程如下（圖來自RFC5246）：

? ? ? 接下來就以訪問百度為例對上述握手過程拆解分析一下，且待我慢慢道來。

1. ? ?ClientHello

? ? ? 由于客戶端對一些加解密算法的支持程度不一樣，同時在TLS協(xié)議傳輸階段必須要使用相同的加密算法才能夠保證數(shù)據(jù)進行正常的加解密，所以在TLS握手階段，客戶端首先要告知server端自己所使用的協(xié)議版本號，本地所支持的加密套件列表等信息，除了這些信息以外，客戶端還會產(chǎn)生一個隨機數(shù)，這個隨機數(shù)保存在客戶端的同時會發(fā)送給server端，用于后面要產(chǎn)生的master secret即主密鑰做準備。

數(shù)據(jù)包分析如下：

client hello

將該hello包進行拆解分析如下：

a）Record Layer：記錄層，記錄了該內(nèi)容的類型為Handshake（22），22則對應(yīng)下方十六進制的16；

b）Version：TLS1.0（0x0301），該標識記錄了TLS1.0實際上是基于ssl3.1而來的，對應(yīng)下方十六進制為0301；

c）Handshake Type：Client Hello（1），標識了這個握手類型是Client Hello階段，對應(yīng)下方十六進制為01；

d）Random：GMT Unix Time時間則為從1970年1月1日至今所經(jīng)歷的秒數(shù)，Random

Bytes則為32個字節(jié)的隨機數(shù)，嚴格點來說就是偽隨機數(shù)，因為真正的隨機數(shù)是不存在的；

RFC5246定義如下：

Random

Cipher Suites

e）Session ID Length：顧名思義就是客戶端想要用于該連接的Session id，初始值為空，也就是看到的0，因為是第一次訪問沒有該值；

f）Cipher Suites（15 suites）：該字段則為客戶端所支持的加密套件，共15套；

g）Extension：該字段就是前文中提到過的SNI相關(guān)字段，擴展字段，其中就標識了server name即主機名是什么及字段長度，這樣就能在握手時獲取主機名并匹配到相對應(yīng)的證書了；

2. ? ?Server Hello

? ? ? Server端在收到客戶端發(fā)送的Client Hello之后，會回應(yīng)一個server hello，從server hello到server done，有的server端是會一次性發(fā)送完的，如上面RFC握手圖中所示的那樣，而有些server端會逐條的來發(fā)送，同時將公鑰發(fā)送至客戶端。

? ? ? 同樣的，server hello中也包含諸如握手類型，使用的版本號，偽隨機數(shù)，Session ID，加密套件等信息。

server hello

以上可以看出我們獲得了server端的偽隨機數(shù)，gmt時間以及協(xié)商到的加密套件TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

3. ? ?Certificate Server Key Exchange，Server Hello Done

該數(shù)據(jù)包包含了證書信息以及key exchange等信息，如圖：

證書交換

? ? ? Server端使用DH算法生成一個pubkey一并發(fā)送給client，client在收到pubkey后也計算一個pubkey并發(fā)送給server，server來驗證是否正確，如果正確則交換信息完成。

? ? ? 注：這個pubkey具體作用我多方考證加上邏輯推理認為就是這么個作用，如果想錯了歡迎指正，我在修改。

4. ? ?Client Key Exchange

? ? ? 客戶端key交換，并且客戶端使用change cipher spec通知server端開始使用加密報文傳輸數(shù)據(jù)，在此之前的信息都是明文的，因此我可以通過wireshark看到。

? ? ? 在此階段，客戶端將通過RSA算法生成一個48字節(jié)的premaster secret，即預(yù)主密鑰，這個密鑰中包含了客戶端tls的版本號信息，如果有中間人共計，有意降低tls版本的話，則會馬上終止發(fā)送數(shù)據(jù)。

? ? ? 這個premaster secret是一個保密的key，只要被截獲就可以結(jié)合之前明文傳輸?shù)膫坞S機數(shù)計算出最終的master secret即主密鑰。因此該密鑰會通過公鑰證書加密傳送至server端，server端通過私鑰進行解密獲取預(yù)主密鑰，此時客戶端和server端都有了相同的偽隨機數(shù)及預(yù)主密鑰。

5. ? ?New Session Ticket

? ? ? 該數(shù)據(jù)包主要是server端向客戶端發(fā)送新的session ticket，因為最開始并沒有這個信息，并通知客戶端開始使用加密方式傳輸數(shù)據(jù)。

session ticket

? ? ? 該session ticket就相當于普通網(wǎng)站中的session，當瀏覽器在次發(fā)送請求或者中間網(wǎng)絡(luò)原因連接被斷開之后，client hello階段攜帶該session id，則認為是同一個人訪問，不在進行證書交互階段，該session id的復(fù)用也是優(yōu)化的一點，最后會提到。同樣的這個數(shù)據(jù)也是被加密的，server端得到后進行解密即可快速完成握手。其中該字段不僅包含session ticket，還包含ticket的壽命，即過期時間，長度等。

? ? ? 這里不得不提詳細提一下session ticket和session id這兩個角色，簡單的理解就是session id就是一個session會話標識，當下次訪問時攜帶該標識則認為是同一個人訪問，但是假如輪詢到集群中其它服務(wù)器，則可能無法識別該session id，因為是初次建連服務(wù)器給的，而session id是由服務(wù)器存儲的主要信息，是需要占用服務(wù)器內(nèi)存資源的，且不易擴展。Session id的存儲及復(fù)用共享需要使用redis或memcache來實現(xiàn)。

? ? ? 也因此session ticket應(yīng)運而生了，該字串中包含了當時會話所使用的一些信息，解密出來即可快速重用（RFC5077對此有詳細釋義），session ticket存儲在客戶端，新會話后，服務(wù)器通過一個自己知道的密鑰ticket key將本次會話狀態(tài)加密，發(fā)送給客戶端，客戶端保存該ticket，下次建連時候發(fā)送給server端，該方式的問題是集群中所有server設(shè)備使用相同的ticket key，因此也需要考慮該key的輪轉(zhuǎn)及輪轉(zhuǎn)時新舊key兼容的問題。

? ? ? nginx會話緩存配置：ssl_session_cachessl_session_ticket_key

? ? ? 至此整個握手過程已經(jīng)講解完成，并且已經(jīng)開始使用對稱密鑰傳輸數(shù)據(jù)，但是還有一些過程在數(shù)據(jù)包中是并不能直接體現(xiàn)出來的，因此在后面繼續(xù)討論。

6. ? ?master secret

? ? ? 主密鑰，用來對稱加密傳輸數(shù)據(jù)，主密鑰通過客戶端random、server端random及premaster secret得到，算法如下：

? ? ? master_secret= PRF(pre_master_secret, "master secret", ClientHello.random +ServerHello.random)

? ? ? 其實我這里并沒有理解master secret還沒有呢，為啥也參與運算了。

? ? ? 這里還有一個key block的概念，我因為理解的不太透徹，只能淺顯的描述以下了，想仔細的研究還得去看RFC文檔。master secret是有一系列的hash值組成的，它將作為數(shù)據(jù)加解密相關(guān)的secret的key material。

? ? ? Sessionsecret是從key material中獲取，key material經(jīng)過12次迭代計算，產(chǎn)生12個hash值，分成了6個元素，分別是：

ClientMac（Message Authentication Code）key、server Mac

key、client encryption key、server encryption key、clientIV（Initialization Vector）、serverIV

? ? ? 我理解最終的對稱加密就是使用這幾個hash值進行加密解密以及數(shù)據(jù)完整性的校驗，因為客戶端和server端兩頭都有了這幾個數(shù)據(jù)。

? ? ? 因為對其理解的不太透徹，故此貼出部分RFC釋義：

四、TLS握手概述版

? ? ? 由于以上信息太多，考慮到一般人沒心情看完這么多以及只想淺嘗輒止，在加上我寫了這么多自己已經(jīng)邏輯混亂了，因此放出概述版，摘自微軟。

五、 ?HTTPS的優(yōu)化

? ? ? 目前我頭腦中只有兩個大的方向。

? ? ? ? ? a）Session id及session ticket的復(fù)用，縮減證書交換時間，減少可能的計算以及RTT時間，例圖中所示：

? ? ? Session重用之后減少了證書交換等一系列的驗證過程，縮減了RTT時間，握手次數(shù)，減少了算法加密過程，在簡單的交換信息之后就直接開始傳輸數(shù)據(jù)了。

? ? ? b）選取相對來說計算量較小且安全的算法。

? ? ? 對于優(yōu)化只有這兩個思路，詳細的我現(xiàn)在還無法寫出，因為我已經(jīng)寫累了。

六、 ?參考文獻

? ? ? 維基百科、RFC文檔、經(jīng)驗、互聯(lián)網(wǎng)文章

? ? ? 以上均為我個人學(xué)習(xí)理解之后總結(jié)的一些內(nèi)容，一口氣寫的有點多了，難免有腦子糊涂想錯的地方，歡迎大家拍磚勘誤，感謝。

? ? ? 勘誤聯(lián)系方式： ?294719425@qq.com

本頁內(nèi)容由塔燈網(wǎng)絡(luò)科技有限公司通過網(wǎng)絡(luò)收集編輯所得，所有資料僅供用戶學(xué)習(xí)參考，本站不擁有所有權(quán)，如您認為本網(wǎng)頁中由涉嫌抄襲的內(nèi)容，請及時與我們聯(lián)系，并提供相關(guān)證據(jù)，工作人員會在5工作日內(nèi)聯(lián)系您，一經(jīng)查實，本站立刻刪除侵權(quán)內(nèi)容。本文鏈接:http://www.junxiaosheng.cn/20475.html

上一篇：<iOS HTTPS適配下一篇：iOS https>