歡迎您光臨深圳塔燈網(wǎng)絡(luò)科技有限公司！
余先生：13699882642
余先生：13699882642
8年
專注網(wǎng)站建設(shè)行業(yè)優(yōu)質(zhì)服務(wù)商
余先生：13699882642
為您解碼網(wǎng)站建設(shè)的點(diǎn)點(diǎn)滴滴
發(fā)表日期：2017-03 文章編輯：小燈 瀏覽次數(shù)：1937
一、https概述
? ? ??1. ? ?什么是HTTP？
? ? ??2. ? ?什么是HTTPS？
? ? ??3. ? ?SSL/TLS
? ? ??4. ? ?Openssl
二、基礎(chǔ)知識(shí)儲(chǔ)備
? ? ??1. ? ?SNI概述
? ? ??2. ? ?公鑰基礎(chǔ)設(shè)施PKI概述
? ? ? ? ? ??2.1 ? ?PKI的信任服務(wù)
? ? ? ? ? ??2.2 ? ?PKI標(biāo)準(zhǔn)
? ? ? ? ? ??2.3 ? ?PKI體系結(jié)構(gòu)
? ? ??3. ? ?CA中心
? ? ? ? ? ??3.1 ? ?CA的主要職責(zé)
? ? ??4. ? ?證書(shū)相關(guān)常識(shí)
? ? ? ? ? ??4.1 ? ?公鑰
? ? ? ? ? ??4.2 ? ?私鑰
? ? ? ? ? ??4.3 ? ?CSR文件
? ? ? ? ? ??4.4 ? ?OCSP在線證書(shū)狀態(tài)
? ? ? ? ? ??4.5 ? ?CRL證書(shū)吊銷列表
? ? ??5. ? ?證書(shū)鏈
? ? ??6. ? ?加密算法概述
? ? ? ? ? ??6.1 ? ?對(duì)稱加密算法
? ? ? ? ? ??6.2 ? ?非對(duì)稱加密算法
? ? ? ? ? ? 6.3 ? ?信息摘要算法
? ? ? ? ? ??6.4 ? ?HMAC
三、 ? ?TLS握手
? ? ??1. ? ?ClientHello
? ? ??2. ? ?Server Hello
? ? ??3. ? ?CertificateServer Key Exchange，Server?Hello Done
? ? ??4. ? ?Client Key Exchange
? ? ??5. ? ?New Session Ticket
? ? ??6. ? ?master secret
四、TLS握手概述版
五、HTTPS的優(yōu)化
六、參考文獻(xiàn)
在了解https之前，我們首先來(lái)了解一下什么是http。http即Hypertext transfer protocol，超文本傳輸協(xié)議，是互聯(lián)網(wǎng)上應(yīng)用最為廣泛的一種網(wǎng)絡(luò)協(xié)議，由萬(wàn)維網(wǎng)協(xié)會(huì)（World Wide Web Consortium，W3C）和互聯(lián)網(wǎng)工程任務(wù)組（Internet
Engineering Task Force，IETF）制定標(biāo)準(zhǔn)，其中著名的RFC2616定義了http1.1。設(shè)計(jì)之初的目的是為了提供一種發(fā)布和接收html頁(yè)面的方法，由統(tǒng)一資源標(biāo)識(shí)符（Uniform Resource Identifiers，URI）來(lái)標(biāo)識(shí)。
HTTP是一個(gè)C/S架構(gòu)，由終端用戶通過(guò)使用瀏覽器或其它工具發(fā)起的一個(gè)http請(qǐng)求到服務(wù)器指定的端口上獲取數(shù)據(jù)內(nèi)容，默認(rèn)為80端口，工作在OSI七層參考模型的應(yīng)用層上。
http協(xié)議到現(xiàn)在已經(jīng)演化出了很多版本，大部分向下兼容，目前版本有0.9、1.0、1.1及HTTP/2，其中0.9版本已經(jīng)過(guò)時(shí)不在使用，主流版本為1.1，未來(lái)版本為2.0。
http協(xié)議為明文傳輸，所有信息均為可見(jiàn)的，存在不安全特性，信息極易被篡改和劫持，也因此衍生出了相對(duì)更為安全的https。
? ? ? HTTPS（Hyper Text Transfer Protocol Secure），即超文本傳輸安全協(xié)議，也稱為http over tls等，是一種網(wǎng)絡(luò)安全傳輸協(xié)議，其也相當(dāng)于工作在七層的http，只不過(guò)是在會(huì)話層和表示層利用ssl/tls來(lái)加密了數(shù)據(jù)包，訪問(wèn)時(shí)以https://開(kāi)頭，默認(rèn)443端口，同時(shí)需要證書(shū)，學(xué)習(xí)https的原理其實(shí)就是在學(xué)習(xí)ssl/tls的原理。
? ? ? SSL（Secure Sockets Layer），即安全套接層，是一種安全協(xié)議，目的是為互聯(lián)網(wǎng)通信提供安全及數(shù)據(jù)完整性保障，使用X.509認(rèn)證，網(wǎng)景公司（Netscape）在1994年推出HTTPS協(xié)議，以SSL進(jìn)行加密，這是SSL的起源。IETF將SSL進(jìn)行標(biāo)準(zhǔn)化，1999年公布第一版TLS標(biāo)準(zhǔn)文件。SSL目前有三個(gè)版本，SSL1.0、SSL2.0、SSL3.0，因其存在嚴(yán)重的安全問(wèn)題，大多數(shù)公司目前均已不在使用了。因此本文著重是基于TLS講解。
? ? ? TLS（Transport Layer Security），即安全傳輸層，IETF將SSL標(biāo)準(zhǔn)化后的產(chǎn)物。其實(shí)TLS可以理解為SSL的升級(jí)版，TLS目前也有三個(gè)版本，TLS1.0、TLS1.1、TLS1.2，TLS目前只是草案，并未面世，目前常用的為T(mén)LS1.2，server配置通常三個(gè)版本均支持。
? ? ? 擴(kuò)展知識(shí)：X.509標(biāo)準(zhǔn)。SSL證書(shū)格式遵循X.509標(biāo)準(zhǔn)，X.509是由國(guó)際電信聯(lián)盟（ITU-T）制定的數(shù)字證書(shū)標(biāo)準(zhǔn)，ITU于1988年制訂了X.500系列標(biāo)準(zhǔn)，其中X.500和X.509是安全認(rèn)證系統(tǒng)的核心，X.500定義了一種區(qū)別命名規(guī)則，以命名樹(shù)來(lái)確保用戶名稱的唯一性，X.509則為X.500用戶名稱提供了通信實(shí)體鑒別機(jī)制，并規(guī)定了實(shí)體鑒別過(guò)程中廣泛適用的證書(shū)語(yǔ)法和數(shù)據(jù)接口，X.509稱之為證書(shū)。X.509給出的鑒別框架是一種基于公開(kāi)密鑰體制的鑒別業(yè)務(wù)密鑰管理，即一個(gè)用戶有兩把密鑰，公鑰和私鑰，同時(shí)該標(biāo)準(zhǔn)也規(guī)范了公開(kāi)密鑰認(rèn)證、證書(shū)吊銷列表、授權(quán)證書(shū)、證書(shū)路徑驗(yàn)證算法等。
X.509標(biāo)準(zhǔn)知識(shí)來(lái)源：http://itrus.com.cn/2009/1126/235.html
Openssl計(jì)劃在1998年開(kāi)始，其目標(biāo)是發(fā)明一套自由的加密工具，在互聯(lián)網(wǎng)上使用，它是一個(gè)開(kāi)源的加密庫(kù)，由C語(yǔ)言寫(xiě)成，SSL/TLS協(xié)議基于該庫(kù)進(jìn)行的加解密。
Openssl支持多種不同的加密算法：
加密：
? ? AES、Blowfish、Camellia、SEED、DES、RC2、RC4、RC5等
散列函數(shù)：
? ? MD5、MD2、SHA-1、SHA-2、RIPEMD-160 等
公開(kāi)密鑰加密：
? ? RSA、DSA、Diffie-Hellman key exchange（DH）等
? ? Openssl不僅包含加密庫(kù)，同時(shí)也是一個(gè)小型的CA程序，它可以幫助你完成一個(gè)CA的建設(shè)，具體參數(shù)可以通過(guò)man幫助來(lái)查看學(xué)習(xí)，這里暫時(shí)先不講這方面了。
? ? ? https是http構(gòu)建在SSL之上的一種協(xié)議，SSL加密在到達(dá)應(yīng)用層的時(shí)候就已經(jīng)完成了，http層完全不知道下面發(fā)生了什么。根據(jù)https的工作原理，瀏覽器在訪問(wèn)一個(gè)https站點(diǎn)時(shí)候，會(huì)先與服務(wù)器建立ssl連接，建立連接的第一個(gè)步驟就是要請(qǐng)求服務(wù)器證書(shū)，而服務(wù)器這個(gè)在發(fā)送證書(shū)的時(shí)候，是不知道瀏覽器訪問(wèn)的是哪個(gè)域名的，所以無(wú)法根據(jù)不同的域名發(fā)送不同的證書(shū)，也因此有了眾所周知的事情，https往常在使用的時(shí)候必須要一個(gè)IP綁定一個(gè)證書(shū)，多個(gè)證書(shū)就要綁定在多個(gè)不同的IP之上，這個(gè)在我做CDN的HTTPS加速時(shí)飽受了痛苦，通常業(yè)務(wù)量大的時(shí)候一個(gè)設(shè)備就綁定了20多個(gè)IP，分別對(duì)應(yīng)不同的證書(shū)，管理起來(lái)異常的麻煩。那么有沒(méi)有一種技術(shù)即可以節(jié)省IP，又可以減少配置工作呢？答案是肯定的，為了解決這一問(wèn)題，SNI技術(shù)應(yīng)運(yùn)而生了。
? ? ? SNI（Server Name Indication），即服務(wù)器名稱指示，是一個(gè)擴(kuò)展的TLS協(xié)議，在該協(xié)議下，在握手過(guò)程開(kāi)始時(shí)就可以通過(guò)客戶端告訴它正在連接的服務(wù)器的主機(jī)名稱，這就允許了服務(wù)器在相同的IP地址和TCP端口號(hào)上綁定多個(gè)證書(shū)了，并且因此允許在相同的IP地址上提供多個(gè)安全的https網(wǎng)站，它與虛擬主機(jī)概念相同。
SNI通過(guò)讓客戶端發(fā)送主機(jī)名作為T(mén)LS協(xié)商的一部分來(lái)解決此問(wèn)題，這就使得服務(wù)器能夠提前選擇正確的主機(jī)名，并向?yàn)g覽器提供包含正確名稱的證書(shū)。SNI需要客戶端瀏覽器和server端程序同時(shí)支持，目前主流的瀏覽器和server端程序均已支持了該特性，近年來(lái)IE6的市場(chǎng)份額應(yīng)該可以小到忽略不計(jì)了。
以百度為例，SNI請(qǐng)求的字段數(shù)據(jù)包如下例子：
? ? ? 說(shuō)到HTTPS就不得不提及一下PKI，PKI（Public key Infrastructure）即公鑰基礎(chǔ)設(shè)施，簡(jiǎn)單的說(shuō)PKI技術(shù)就是利用公鑰理論和技術(shù)建立的提供信息安全服務(wù)的基礎(chǔ)設(shè)施，該體系在統(tǒng)一的安全認(rèn)證標(biāo)準(zhǔn)和規(guī)范基礎(chǔ)上提供在線身份認(rèn)證，是CA認(rèn)證、數(shù)字證書(shū)、數(shù)字簽名以及相關(guān)安全應(yīng)用組件模塊的集合。做為一種技術(shù)體系，PKI可以作為支持認(rèn)證、完整性、機(jī)密性和不可否認(rèn)性的技術(shù)基礎(chǔ)，從技術(shù)上解決網(wǎng)上身份認(rèn)證、信息完整性的抗抵賴等安全問(wèn)題，為網(wǎng)絡(luò)應(yīng)用提供可靠的安全保障，但PKI不僅僅涉及到技術(shù)層面的問(wèn)題。
2.1 ? ?PKI的信任服務(wù)
? ? ? a) ? ?認(rèn)證
? ? ? b) ? ?支持密鑰管理
? ? ? c) ? ?完整性與不可否認(rèn)
2.2 ? ?PKI標(biāo)準(zhǔn)
? ? ? a) ? ?X.209（1988）ASN.1基本編碼規(guī)則的規(guī)范
? ? ? b) ? ?X.500（1993）信息技術(shù)之開(kāi)放系統(tǒng)互聯(lián)：概念、模型及服務(wù)簡(jiǎn)述
? ? ? c) ? ?X.509（1993）信息技術(shù)之開(kāi)放系統(tǒng)互聯(lián)：鑒別框架
? ? ? d) ? ?PKCS系列標(biāo)準(zhǔn)
? ? ? e) ? ?OCSP在線證書(shū)狀態(tài)協(xié)議
? ? ? f) ? ? LDAP輕量級(jí)目錄訪問(wèn)協(xié)議
2.3 ? ?PKI體系結(jié)構(gòu)
? ? ? a) ? ?認(rèn)證機(jī)構(gòu)CA（Certificate Authority）
? ? ? b) ? ?證書(shū)和證書(shū)庫(kù)
? ? ? c) ? ?密鑰備份及恢復(fù)
? ? ? d) ? ?密鑰和證書(shū)的更新
? ? ? e) ? ?證書(shū)歷史檔案
? ? ? f) ? ? 客戶端軟件
? ? ? g) ? ?交叉認(rèn)證
? ? ? 以上內(nèi)容不做過(guò)多的概述，因?yàn)楦鷮W(xué)習(xí)這個(gè)沒(méi)有什么太大的直接關(guān)系，可做為了解，其中CA中心會(huì)擴(kuò)展一下。
? ? ? 認(rèn)證機(jī)構(gòu)CA（Certificate Authority）在https中是一個(gè)很重要的角色，CA是PKI的核心執(zhí)行機(jī)構(gòu)，是PKI的主要組成部分，通常稱之為認(rèn)證中心，從廣義上講，認(rèn)證中心還應(yīng)該包括證書(shū)申請(qǐng)注冊(cè)機(jī)構(gòu)RA（Registration Authority），它是數(shù)字證書(shū)的申請(qǐng)注冊(cè)、證書(shū)簽發(fā)的管理機(jī)構(gòu)?？蛻舳耸窃趺打?yàn)證該證書(shū)的頒發(fā)機(jī)構(gòu)即CA中心是合法有效的呢，其實(shí)在系統(tǒng)瀏覽器中有預(yù)埋CA中心的根證書(shū)，在其中的根證書(shū)為可信任機(jī)構(gòu)，如圖：
3.1 ? ?CA的主要職責(zé)
? ? ? a)籠統(tǒng)的說(shuō)CA中心負(fù)責(zé)證書(shū)的簽發(fā)和管理等；
? ? ? b)驗(yàn)證并標(biāo)識(shí)證書(shū)申請(qǐng)者的身份，對(duì)證書(shū)申請(qǐng)者的信用度、申請(qǐng)證書(shū)的目的、身份的真實(shí)可靠性等問(wèn)題進(jìn)行審查，確保證書(shū)與身份綁定的準(zhǔn)確性；
? ? ? c)確保CA用于簽名證書(shū)的非對(duì)稱密鑰的質(zhì)量和安全性；
? ? ? d)管理證書(shū)信息資料，管理證書(shū)序號(hào)和CA標(biāo)識(shí)，確保證書(shū)主體標(biāo)識(shí)的唯一性，防止證書(shū)主 ?體名字的重復(fù)。在證書(shū)使用中確定并檢查證書(shū)的有效期，保證不使用過(guò)期或已作廢的證書(shū)， ? ?確保網(wǎng)上交易安全，發(fā)布和維護(hù)作廢證書(shū)列表（CRL）。
? ? ? 由此可見(jiàn)，CA是保證電子商務(wù)、網(wǎng)上銀行、互聯(lián)網(wǎng)環(huán)境健康等的權(quán)威性、可信任和公正的第三方機(jī)構(gòu)。
4.1 ? ?公鑰
? ? ? 公鑰（Public-key），即所謂的公共證書(shū)，由CA中心頒發(fā)的合法文件，可以在互聯(lián)網(wǎng)傳播，誰(shuí)都可以輕易獲取到。公鑰證書(shū)文件的擴(kuò)展名實(shí)際上只是一種使用習(xí)慣上的區(qū)別，后綴包括但不僅限于crt、cer、key、der、pem，pem可能包含了公鑰和私鑰文件，通常可以從pem文件中導(dǎo)出公鑰和私鑰。公鑰中包含頒發(fā)給哪個(gè)域名，公司名，加密算法，組織機(jī)構(gòu)，有效期等等信息，示例如圖：
? ? ? 當(dāng)然如果說(shuō)一個(gè)證書(shū)只能綁定一個(gè)域名的話，100個(gè)域名就要100個(gè)證書(shū)了，這樣管理和費(fèi)用成本都會(huì)顯著增加，根據(jù)不同用戶的不同需求，同時(shí)CA中心也會(huì)根據(jù)不同國(guó)家國(guó)情推出不同的產(chǎn)品，例如一個(gè)證書(shū)綁定多個(gè)單域名或泛域名，這些我們都是可以通過(guò)公鑰查看出來(lái)的，示例如圖：
4.2? ? 私鑰
? ? ? 私鑰（private-key），即通常就叫所謂的私鑰，私鑰在生成CSR文件的時(shí)候同時(shí)生產(chǎn)，后綴通常為.key，由使用者自己保管，不可在互聯(lián)網(wǎng)傳播，極其重要。
4.3 ? ?CSR文件
? ? ? CSR（Cerificate Signing Request）文件，即證書(shū)請(qǐng)求文件，用于發(fā)送給CA中心用來(lái)生產(chǎn)公鑰，該文件在生成的時(shí)候會(huì)填寫(xiě)一些基本信息，諸如國(guó)家代碼、公司名、省份城市、管理員郵箱等等信息，可以在線生成也可以通過(guò)openssl生成，例：
openssl req -new -nodes -newkey rsa:2048 -keyout xxx.key-out xxx.csr
4.4 ? ? OCSP在線證書(shū)狀態(tài)
? ? ? OCSP（Online Certificate Status Protocol），即在線證書(shū)狀態(tài)協(xié)議，其實(shí)就是一個(gè)請(qǐng)求應(yīng)答模式的協(xié)議，用于在線的查詢證書(shū)吊銷狀態(tài)，而無(wú)需查詢CRL，在對(duì)證書(shū)狀態(tài)實(shí)時(shí)性要求較高的場(chǎng)合適用于使用OCSP來(lái)查詢當(dāng)前證書(shū)狀態(tài)。
4.5 CRL證書(shū)吊銷列表
? ? ? CRL（Certificate Revocation List），即證書(shū)吊銷列表，它指定了一套證書(shū)發(fā)布者認(rèn)為無(wú)效的證書(shū)，CRL一定是被CA所簽署的，它可以使用與簽發(fā)證書(shū)相同的私鑰，也可以使用專門(mén)的CRL簽發(fā)私鑰，CRL中包含了被吊銷證書(shū)的序列號(hào)。通常情況下，公鑰證書(shū)中會(huì)寫(xiě)出該證書(shū)的CA中心CRL地址，示例如圖：
CRL中也會(huì)包含一些基本信息，例如列表更新時(shí)間，吊銷證書(shū)序號(hào)等，示例如圖：
? ? ? 簡(jiǎn)單點(diǎn)闡述證書(shū)鏈就是，為了盡可能的保證根證書(shū)的安全性，因此CA中心也采取了一種樹(shù)狀的結(jié)構(gòu)，一個(gè)root CA下面包含多個(gè)intermediates CA，然后根CA和次級(jí)CA都可以頒發(fā)證書(shū)給用戶，頒發(fā)的證書(shū)分別是根證書(shū)和次級(jí)證書(shū)，最后則是用戶的證書(shū)，也可以說(shuō)是中級(jí)證書(shū)，中級(jí)證書(shū)可以在CA下載到，這個(gè)一般是共通的，證書(shū)鏈的設(shè)計(jì)是基于“信任鏈”的理念設(shè)計(jì)的。 ? ? ? ? ? ?證書(shū)鏈的詳盡闡述則需要大家去自行學(xué)習(xí)了，我對(duì)于這個(gè)證書(shū)鏈的了解是因?yàn)橛龅竭^(guò)故障，也因此才了解了證書(shū)鏈?zhǔn)窃趺磦€(gè)東西，在之前做https加速的時(shí)候，早期的安卓系統(tǒng)版本比較低，在低版本的系統(tǒng)瀏覽器中訪問(wèn)某些移動(dòng)網(wǎng)站的時(shí)候，會(huì)報(bào)錯(cuò)，大意就是無(wú)法驗(yàn)證這個(gè)網(wǎng)站證書(shū)是合法的，因?yàn)闆](méi)有證書(shū)鏈，它不知道這個(gè)證書(shū)的上一級(jí)頒發(fā)者是誰(shuí)，新版本的系統(tǒng)及瀏覽器中則很少見(jiàn)到這種問(wèn)題。證書(shū)鏈?zhǔn)纠缦拢?/p>
6.1? ? 對(duì)稱加密算法
? ? ? 對(duì)稱加密技術(shù)（Stmmetric Cryptographic technique），即對(duì)稱加密技術(shù)，發(fā)送方和接收方使用相同的算法來(lái)進(jìn)行加解密。
? ? ? 優(yōu)點(diǎn)：算法公開(kāi)，計(jì)算量小，加密速度快，效率高。
? ? ? 缺點(diǎn)：加解密雙方使用同樣的密鑰，安全性得不到保障。
? ? ? 常見(jiàn)算法：
? ? ? ? ? DES、3DES、TDEA、RC4、RC5、AES等。
? ? ? DES（Data Encryption Standard）：數(shù)據(jù)加密標(biāo)準(zhǔn)，速度快，適用于加密大量數(shù)據(jù)的場(chǎng)景。
? ? ? 3DES（Triple Data Encryption Algorithm縮寫(xiě)TDEA，Triple DEA）：基于DES，對(duì)一塊數(shù)據(jù)應(yīng)用三次DES數(shù)據(jù)加密標(biāo)準(zhǔn)算法，強(qiáng)度更高。
? ? ? AES（Advanced Encryption Standard）：高級(jí)加密標(biāo)準(zhǔn)，是下一代加密算法標(biāo)準(zhǔn)，速度快，安全級(jí)別高。
6.2 ? ?非對(duì)稱加密算法
? ? ? 非對(duì)稱加密技術(shù)（asymmetric crypto-graphic technique），即采用了兩種相關(guān)變換的密碼技術(shù)，也就是公鑰和私鑰，公鑰加密私鑰解密，私鑰加密公鑰解密。
? ? ? 常見(jiàn)算法：
? ? ? ? ? RSA、DSA、ECC、DH等。
? ? ? RSA：RSA是1977年由羅納德·李維斯特（Ron Riverst）、阿迪·薩莫爾（Adi Shamir）和倫納德·阿德曼（Leonard Adleman）一起提出的，當(dāng)時(shí)三人都在麻省理工學(xué)院工作，RSA就是他們?nèi)诵帐祥_(kāi)頭字母的縮寫(xiě)拼在一起組成的。 ? ? ?
? ? ? RSA算法的安全性基于大數(shù)分解質(zhì)因子的困難性，由于人們一直未找到對(duì)大數(shù)進(jìn)行因子分解的有效方法，所以RSA在目前看來(lái)依然是安全的，RSA算法既可用于加密，也可用于簽名，是目前應(yīng)用最廣的公鑰算法。
? ? ? DSA（Digital Signature Algorithm）：數(shù)字簽名算法，基于離散對(duì)數(shù)難題的，只能用于簽名，不能用于加密。
? ? ? DH（Diffie-Hellman）：是一種安全的密鑰交換協(xié)議，它可以讓雙方在完全沒(méi)有對(duì)方任何預(yù)先信息的條件下通過(guò)不安全通道創(chuàng)建一個(gè)密鑰，這個(gè)密鑰可以在后續(xù)的通信中做為對(duì)稱密鑰來(lái)加密通訊內(nèi)容。
? ? ? 該算法詳細(xì)釋義參見(jiàn)維基百科：
?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)勢(shì)是在某些情況下它比其他方法使用更小的密鑰，提供相當(dāng)或更高等級(jí)的安全。
? ? ? 該算法詳細(xì)釋義參見(jiàn)維基百科： ? ? ? ? ? ? ? ? ? ? ? ? ? ?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ùn)算變?yōu)榱硪还潭ㄩL(zhǎng)度值是散列算法的基礎(chǔ)原理，可以產(chǎn)生一個(gè)128位16字節(jié)的散列值（hash value），用于確保信息傳輸完整一致。MD5是可以被破解的，對(duì)于需要高度安全的不適用于此摘要算法。
? ? ? SHA-1（Secure Hash Algorithm 1），即安全散列算法1，也是一種密碼散列函數(shù)，美國(guó)國(guó)家安全局涉及，SHA1可以生成一個(gè)被稱為消息摘要的160位20字節(jié)的散列值，散列值通常呈現(xiàn)形式為40個(gè)十六進(jìn)制數(shù)，sha1算法目前也已不在安全，2017年2月23日google與CWI Amesterdam宣布成功完成了一個(gè)碰撞攻擊。
6.4 ? ?HMAC
? ? ? HMAC（Keyed-hash message authentication code），即密鑰散列消息認(rèn)證碼，又稱散列消息認(rèn)證碼，是一種通過(guò)特別計(jì)算方式之后產(chǎn)生的消息認(rèn)證碼（MAC），使用密碼散列函數(shù)，同時(shí)結(jié)合一個(gè)加密密鑰，它可以用來(lái)保證數(shù)據(jù)的完整性，同時(shí)可以用來(lái)做某個(gè)消息的身份驗(yàn)證，由RFC2104定義，數(shù)學(xué)公式為：
? ? ? 其中：
? ? ? ? ? H為密碼散列函數(shù)（如MD5或SHA-1）
? ? ? ? ? K為密鑰（secret key）
? ? ? ? ? m是要認(rèn)證的消息
? ? ? ? ? ?K'是從原始密鑰K導(dǎo)出的另一個(gè)秘密密鑰（如果K短于散列函數(shù)的輸入塊大小，則向右填充（Padding）零；如果比該塊大小更長(zhǎng)，則對(duì)K進(jìn)行散列）
? ? ? ? ? ?||代表串接
? ? ? ? ? ⊕代表異或（XOR）
? ? ? ? ? ?opad是外部填充（0x5c5c5c…5c5c，一段十六進(jìn)制常量）
? ? ? ? ? ?ipad是內(nèi)部填充（0x363636…3636，一段十六進(jìn)制常量）
? ? ? TLS握手階段是發(fā)生在TCP建連之后開(kāi)始進(jìn)行的，握手其實(shí)就是在協(xié)商，協(xié)商加解密協(xié)議所需要的一些參數(shù)信息等內(nèi)容。
? ? ? TLS握手過(guò)程有單向驗(yàn)證和雙向驗(yàn)證之分，簡(jiǎn)單解釋一下，單向驗(yàn)證就是server端將證書(shū)發(fā)送給客戶端，客戶端驗(yàn)證server端證書(shū)的合法性等，例如百度、新浪、google等普通的https網(wǎng)站，雙向驗(yàn)證則是不僅客戶端會(huì)驗(yàn)證server端的合法性，同時(shí)server端也會(huì)驗(yàn)證客戶端的合法性，例如銀行網(wǎng)銀登陸，支付寶登陸交易等。
? ? ? TLS握手過(guò)程如下（圖來(lái)自RFC5246）：
? ? ? 接下來(lái)就以訪問(wèn)百度為例對(duì)上述握手過(guò)程拆解分析一下，且待我慢慢道來(lái)。
? ? ? 由于客戶端對(duì)一些加解密算法的支持程度不一樣，同時(shí)在TLS協(xié)議傳輸階段必須要使用相同的加密算法才能夠保證數(shù)據(jù)進(jìn)行正常的加解密，所以在TLS握手階段，客戶端首先要告知server端自己所使用的協(xié)議版本號(hào)，本地所支持的加密套件列表等信息，除了這些信息以外，客戶端還會(huì)產(chǎn)生一個(gè)隨機(jī)數(shù)，這個(gè)隨機(jī)數(shù)保存在客戶端的同時(shí)會(huì)發(fā)送給server端，用于后面要產(chǎn)生的master secret即主密鑰做準(zhǔn)備。
數(shù)據(jù)包分析如下：
將該hello包進(jìn)行拆解分析如下：
a）Record Layer：記錄層，記錄了該內(nèi)容的類型為Handshake（22），22則對(duì)應(yīng)下方十六進(jìn)制的16；
b）Version：TLS1.0（0x0301），該標(biāo)識(shí)記錄了TLS1.0實(shí)際上是基于ssl3.1而來(lái)的，對(duì)應(yīng)下方十六進(jìn)制為0301；
c）Handshake Type：Client Hello（1），標(biāo)識(shí)了這個(gè)握手類型是Client Hello階段，對(duì)應(yīng)下方十六進(jìn)制為01；
d）Random：GMT Unix Time時(shí)間則為從1970年1月1日至今所經(jīng)歷的秒數(shù)，Random
Bytes則為32個(gè)字節(jié)的隨機(jī)數(shù)，嚴(yán)格點(diǎn)來(lái)說(shuō)就是偽隨機(jī)數(shù)，因?yàn)檎嬲碾S機(jī)數(shù)是不存在的；
RFC5246定義如下：
e）Session ID Length：顧名思義就是客戶端想要用于該連接的Session id，初始值為空，也就是看到的0，因?yàn)槭堑谝淮卧L問(wèn)沒(méi)有該值；
f）Cipher Suites（15 suites）：該字段則為客戶端所支持的加密套件，共15套；
g）Extension：該字段就是前文中提到過(guò)的SNI相關(guān)字段，擴(kuò)展字段，其中就標(biāo)識(shí)了server name即主機(jī)名是什么及字段長(zhǎng)度，這樣就能在握手時(shí)獲取主機(jī)名并匹配到相對(duì)應(yīng)的證書(shū)了；
? ? ? Server端在收到客戶端發(fā)送的Client Hello之后，會(huì)回應(yīng)一個(gè)server hello，從server hello到server done，有的server端是會(huì)一次性發(fā)送完的，如上面RFC握手圖中所示的那樣，而有些server端會(huì)逐條的來(lái)發(fā)送，同時(shí)將公鑰發(fā)送至客戶端。
? ? ? 同樣的，server hello中也包含諸如握手類型，使用的版本號(hào)，偽隨機(jī)數(shù)，Session ID，加密套件等信息。
以上可以看出我們獲得了server端的偽隨機(jī)數(shù)，gmt時(shí)間以及協(xié)商到的加密套件TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
該數(shù)據(jù)包包含了證書(shū)信息以及key exchange等信息，如圖：
? ? ? Server端使用DH算法生成一個(gè)pubkey一并發(fā)送給client，client在收到pubkey后也計(jì)算一個(gè)pubkey并發(fā)送給server，server來(lái)驗(yàn)證是否正確，如果正確則交換信息完成。
? ? ? 注：這個(gè)pubkey具體作用我多方考證加上邏輯推理認(rèn)為就是這么個(gè)作用，如果想錯(cuò)了歡迎指正，我在修改。
? ? ? 客戶端key交換，并且客戶端使用change cipher spec通知server端開(kāi)始使用加密報(bào)文傳輸數(shù)據(jù)，在此之前的信息都是明文的，因此我可以通過(guò)wireshark看到。
? ? ? 在此階段，客戶端將通過(guò)RSA算法生成一個(gè)48字節(jié)的premaster secret，即預(yù)主密鑰，這個(gè)密鑰中包含了客戶端tls的版本號(hào)信息，如果有中間人共計(jì)，有意降低tls版本的話，則會(huì)馬上終止發(fā)送數(shù)據(jù)。
? ? ? 這個(gè)premaster secret是一個(gè)保密的key，只要被截獲就可以結(jié)合之前明文傳輸?shù)膫坞S機(jī)數(shù)計(jì)算出最終的master secret即主密鑰。因此該密鑰會(huì)通過(guò)公鑰證書(shū)加密傳送至server端，server端通過(guò)私鑰進(jìn)行解密獲取預(yù)主密鑰，此時(shí)客戶端和server端都有了相同的偽隨機(jī)數(shù)及預(yù)主密鑰。
? ? ? 該數(shù)據(jù)包主要是server端向客戶端發(fā)送新的session ticket，因?yàn)樽铋_(kāi)始并沒(méi)有這個(gè)信息，并通知客戶端開(kāi)始使用加密方式傳輸數(shù)據(jù)。
? ? ? 該session ticket就相當(dāng)于普通網(wǎng)站中的session，當(dāng)瀏覽器在次發(fā)送請(qǐng)求或者中間網(wǎng)絡(luò)原因連接被斷開(kāi)之后，client hello階段攜帶該session id，則認(rèn)為是同一個(gè)人訪問(wèn)，不在進(jìn)行證書(shū)交互階段，該session id的復(fù)用也是優(yōu)化的一點(diǎn)，最后會(huì)提到。同樣的這個(gè)數(shù)據(jù)也是被加密的，server端得到后進(jìn)行解密即可快速完成握手。其中該字段不僅包含session ticket，還包含ticket的壽命，即過(guò)期時(shí)間，長(zhǎng)度等。
? ? ? 這里不得不提詳細(xì)提一下session ticket和session id這兩個(gè)角色，簡(jiǎn)單的理解就是session id就是一個(gè)session會(huì)話標(biāo)識(shí)，當(dāng)下次訪問(wèn)時(shí)攜帶該標(biāo)識(shí)則認(rèn)為是同一個(gè)人訪問(wèn)，但是假如輪詢到集群中其它服務(wù)器，則可能無(wú)法識(shí)別該session id，因?yàn)槭浅醮谓ㄟB服務(wù)器給的，而session id是由服務(wù)器存儲(chǔ)的主要信息，是需要占用服務(wù)器內(nèi)存資源的，且不易擴(kuò)展。Session id的存儲(chǔ)及復(fù)用共享需要使用redis或memcache來(lái)實(shí)現(xiàn)。
? ? ? 也因此session ticket應(yīng)運(yùn)而生了，該字串中包含了當(dāng)時(shí)會(huì)話所使用的一些信息，解密出來(lái)即可快速重用（RFC5077對(duì)此有詳細(xì)釋義），session ticket存儲(chǔ)在客戶端，新會(huì)話后，服務(wù)器通過(guò)一個(gè)自己知道的密鑰ticket key將本次會(huì)話狀態(tài)加密，發(fā)送給客戶端，客戶端保存該ticket，下次建連時(shí)候發(fā)送給server端，該方式的問(wèn)題是集群中所有server設(shè)備使用相同的ticket key，因此也需要考慮該key的輪轉(zhuǎn)及輪轉(zhuǎn)時(shí)新舊key兼容的問(wèn)題。
? ? ? nginx會(huì)話緩存配置：ssl_session_cachessl_session_ticket_key
? ? ? 至此整個(gè)握手過(guò)程已經(jīng)講解完成，并且已經(jīng)開(kāi)始使用對(duì)稱密鑰傳輸數(shù)據(jù)，但是還有一些過(guò)程在數(shù)據(jù)包中是并不能直接體現(xiàn)出來(lái)的，因此在后面繼續(xù)討論。
? ? ? 主密鑰，用來(lái)對(duì)稱加密傳輸數(shù)據(jù)，主密鑰通過(guò)客戶端random、server端random及premaster secret得到，算法如下：
? ? ? master_secret= PRF(pre_master_secret, "master secret", ClientHello.random +ServerHello.random)
? ? ? 其實(shí)我這里并沒(méi)有理解master secret還沒(méi)有呢，為啥也參與運(yùn)算了。
? ? ? 這里還有一個(gè)key block的概念，我因?yàn)槔斫獾牟惶笍?，只能淺顯的描述以下了，想仔細(xì)的研究還得去看RFC文檔。master secret是有一系列的hash值組成的，它將作為數(shù)據(jù)加解密相關(guān)的secret的key material。
? ? ? Sessionsecret是從key material中獲取，key material經(jīng)過(guò)12次迭代計(jì)算，產(chǎn)生12個(gè)hash值，分成了6個(gè)元素，分別是：
ClientMac（Message Authentication Code）key、server Mac
key、client encryption key、server encryption key、clientIV（Initialization Vector）、serverIV
? ? ? 我理解最終的對(duì)稱加密就是使用這幾個(gè)hash值進(jìn)行加密解密以及數(shù)據(jù)完整性的校驗(yàn)，因?yàn)榭蛻舳撕蛃erver端兩頭都有了這幾個(gè)數(shù)據(jù)。
? ? ? 因?yàn)閷?duì)其理解的不太透徹，故此貼出部分RFC釋義：
? ? ? 由于以上信息太多，考慮到一般人沒(méi)心情看完這么多以及只想淺嘗輒止，在加上我寫(xiě)了這么多自己已經(jīng)邏輯混亂了，因此放出概述版，摘自微軟。
? ? ? 目前我頭腦中只有兩個(gè)大的方向。
? ? ? ? ? a）Session id及session ticket的復(fù)用，縮減證書(shū)交換時(shí)間，減少可能的計(jì)算以及RTT時(shí)間，例圖中所示：
? ? ? Session重用之后減少了證書(shū)交換等一系列的驗(yàn)證過(guò)程，縮減了RTT時(shí)間，握手次數(shù)，減少了算法加密過(guò)程，在簡(jiǎn)單的交換信息之后就直接開(kāi)始傳輸數(shù)據(jù)了。
? ? ? b）選取相對(duì)來(lái)說(shuō)計(jì)算量較小且安全的算法。
? ? ? 對(duì)于優(yōu)化只有這兩個(gè)思路，詳細(xì)的我現(xiàn)在還無(wú)法寫(xiě)出，因?yàn)槲乙呀?jīng)寫(xiě)累了。
? ? ? 維基百科、RFC文檔、經(jīng)驗(yàn)、互聯(lián)網(wǎng)文章
? ? ? 以上均為我個(gè)人學(xué)習(xí)理解之后總結(jié)的一些內(nèi)容，一口氣寫(xiě)的有點(diǎn)多了，難免有腦子糊涂想錯(cuò)的地方，歡迎大家拍磚勘誤，感謝。
? ? ? 勘誤聯(lián)系方式： ?294719425@qq.com
:
日期：2018-04 瀏覽次數(shù)：6839
日期：2017-02 瀏覽次數(shù)：3511
日期：2017-09 瀏覽次數(shù)：3747
日期：2017-12 瀏覽次數(shù)：3593
日期：2018-12 瀏覽次數(shù)：4902
日期：2016-12 瀏覽次數(shù)：4661
日期：2017-07 瀏覽次數(shù)：13709
日期：2017-12 瀏覽次數(shù)：3584
日期：2018-06 瀏覽次數(shù)：4335
日期：2018-05 瀏覽次數(shù)：4515
日期：2017-12 瀏覽次數(shù)：3625
日期：2017-06 瀏覽次數(shù)：4048
日期：2018-01 瀏覽次數(shù)：4019
日期：2016-12 瀏覽次數(shù)：3975
日期：2018-08 瀏覽次數(shù)：4486
日期：2017-12 瀏覽次數(shù)：3795
日期：2016-09 瀏覽次數(shù)：6554
日期：2018-07 瀏覽次數(shù)：3275
日期：2016-12 瀏覽次數(shù)：3295
日期：2018-10 瀏覽次數(shù)：3447
日期：2018-10 瀏覽次數(shù)：3553
日期：2018-09 瀏覽次數(shù)：3641
日期：2018-02 瀏覽次數(shù)：3668
日期：2015-05 瀏覽次數(shù)：3591
日期：2018-09 瀏覽次數(shù)：3377
日期：2018-06 瀏覽次數(shù)：3500
日期：2017-02 瀏覽次數(shù)：3937
日期：2018-02 瀏覽次數(shù)：4402
日期：2018-02 瀏覽次數(shù)：4267
日期：2016-12 瀏覽次數(shù)：3638
Copyright ? 2013-2018 Tadeng NetWork Technology Co., LTD. All Rights Reserved.
企業(yè)建站知識(shí)
推廣知識(shí)
小程序
微信營(yíng)銷
APP開(kāi)發(fā)
