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

淺談HTTPS（SSL/TLS）原理

發表日期：2017-03 文章編輯：小燈瀏覽次數：2043

一、https概述

1. ? ?什么是HTTP？

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

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

HTTP是一個C/S架構，由終端用戶通過使用瀏覽器或其它工具發起的一個http請求到服務器指定的端口上獲取數據內容，默認為80端口，工作在OSI七層參考模型的應用層上。

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

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

2. ? ?什么是HTTPS？

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

3. ? ?SSL/TLS

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

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

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

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

4. ? ?Openssl

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

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

加密：

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

散列函數：

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

公開密鑰加密：

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

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

二、基礎知識儲備

1. ? ?SNI概述

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

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

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

以百度為例，SNI請求的字段數據包如下例子：

詳細釋義見RFC6066.

2. ? ?公鑰基礎設施PKI概述

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

2.1 ? ?PKI的信任服務

? ? ? a) ? ?認證

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

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

2.2 ? ?PKI標準

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

? ? ? b) ? ?X.500（1993）信息技術之開放系統互聯：概念、模型及服務簡述

? ? ? c) ? ?X.509（1993）信息技術之開放系統互聯：鑒別框架

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

? ? ? e) ? ?OCSP在線證書狀態協議

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

2.3 ? ?PKI體系結構

? ? ? a) ? ?認證機構CA（Certificate Authority）

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

? ? ? c) ? ?密鑰備份及恢復

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

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

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

? ? ? g) ? ?交叉認證

? ? ? 以上內容不做過多的概述，因為跟學習這個沒有什么太大的直接關系，可做為了解，其中CA中心會擴展一下。

3. ? ?CA中心

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

根證書可信任機構

3.1 ? ?CA的主要職責

? ? ? a)籠統的說CA中心負責證書的簽發和管理等；

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

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

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

? ? ? 由此可見，CA是保證電子商務、網上銀行、互聯網環境健康等的權威性、可信任和公正的第三方機構。

4. ? ?證書相關常識

4.1 ? ?公鑰

? ? ? 公鑰（Public-key），即所謂的公共證書，由CA中心頒發的合法文件，可以在互聯網傳播，誰都可以輕易獲取到。公鑰證書文件的擴展名實際上只是一種使用習慣上的區別，后綴包括但不僅限于crt、cer、key、der、pem，pem可能包含了公鑰和私鑰文件，通?？梢詮膒em文件中導出公鑰和私鑰。公鑰中包含頒發給哪個域名，公司名，加密算法，組織機構，有效期等等信息，示例如圖：

公鑰信息

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

證書備用名稱

4.2? ? 私鑰

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

4.3 ? ?CSR文件

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

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

4.4 ? ? OCSP在線證書狀態

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

4.5 CRL證書吊銷列表

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

CRL下載地址

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

吊銷列表

5. ? ?證書鏈

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

證書鏈

6. ? ?加密算法概述

6.1? ? 對稱加密算法

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

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

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

? ? ? 常見算法：

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

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

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

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

6.2 ? ?非對稱加密算法

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

? ? ? 常見算法：

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

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

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

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

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

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

?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），即橢圓曲線密碼學，基于橢圓曲線數學。主要優勢是在某些情況下它比其他方法使用更小的密鑰，提供相當或更高等級的安全。

? ? ? 該算法詳細釋義參見維基百科： ? ? ? ? ? ? ? ? ? ? ? ? ? ?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），一種被廣泛使用的密碼散列函數，將數據運算變為另一固定長度值是散列算法的基礎原理，可以產生一個128位16字節的散列值（hash value），用于確保信息傳輸完整一致。MD5是可以被破解的，對于需要高度安全的不適用于此摘要算法。

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

6.4 ? ?HMAC

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

HMAC數學公式

? ? ? 其中：

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

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

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

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

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

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

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

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

三、 ?TLS握手

? ? ? TLS握手階段是發生在TCP建連之后開始進行的，握手其實就是在協商，協商加解密協議所需要的一些參數信息等內容。

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

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

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

1. ? ?ClientHello

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

數據包分析如下：

client hello

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

a）Record Layer：記錄層，記錄了該內容的類型為Handshake（22），22則對應下方十六進制的16；

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

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

d）Random：GMT Unix Time時間則為從1970年1月1日至今所經歷的秒數，Random

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

RFC5246定義如下：

Random

Cipher Suites

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

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

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

2. ? ?Server Hello

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

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

server hello

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

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

該數據包包含了證書信息以及key exchange等信息，如圖：

證書交換

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

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

4. ? ?Client Key Exchange

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

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

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

5. ? ?New Session Ticket

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

session ticket

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

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

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

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

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

6. ? ?master secret

? ? ? 主密鑰，用來對稱加密傳輸數據，主密鑰通過客戶端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值組成的，它將作為數據加解密相關的secret的key material。

? ? ? Sessionsecret是從key material中獲取，key material經過12次迭代計算，產生12個hash值，分成了6個元素，分別是：

ClientMac（Message Authentication Code）key、server Mac

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

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

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

四、TLS握手概述版

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

五、 ?HTTPS的優化

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

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

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

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

? ? ? 對于優化只有這兩個思路，詳細的我現在還無法寫出，因為我已經寫累了。

六、 ?參考文獻

? ? ? 維基百科、RFC文檔、經驗、互聯網文章

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

? ? ? 勘誤聯系方式： ?294719425@qq.com

本頁內容由塔燈網絡科技有限公司通過網絡收集編輯所得，所有資料僅供用戶學習參考，本站不擁有所有權，如您認為本網頁中由涉嫌抄襲的內容，請及時與我們聯系，并提供相關證據，工作人員會在5工作日內聯系您，一經查實，本站立刻刪除侵權內容。本文鏈接:http://www.webpost.com.cn/20475.html

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