概述

HTTPS全稱Secure Hypertext Transfer Protocol(安全超文本傳輸協(xié)議)，是一個(gè)安全通信通道，用于在客戶計(jì)算機(jī)和服務(wù)器之間交換信息。它使用安全套接字層進(jìn)行信息交換，簡(jiǎn)單來(lái)說它是HTTP的安全版，是使用TLS/SSL加密的HTTP協(xié)議。

HTTPS = HTTP + TLS/SSL

HTTP協(xié)議采用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風(fēng)險(xiǎn)，而協(xié)議TLS/SSL具有身份驗(yàn)證、信息加密和完整性校驗(yàn)的功能，可以避免此類問題發(fā)生。

TLS全稱Transport Layer Security(安全傳輸層協(xié)議), 前身是SSL，故現(xiàn)在用TLS/SSL統(tǒng)稱。是介于TCP和HTTP之間的一層安全協(xié)議，不影響原有的TCP協(xié)議和HTTP協(xié)議，所以使用HTTPS基本上不需要對(duì)HTTP頁(yè)面進(jìn)行太多的改造。

套用在TCP/IP四層模型里的結(jié)構(gòu)如下：

 

 

 

 

TLS/SSL原理

TLS/SSL的功能實(shí)現(xiàn)主要依賴于三類基本算法：散列函數(shù)(Hash)、對(duì)稱加密和非對(duì)稱加密。

其利用非對(duì)稱加密實(shí)現(xiàn)身份認(rèn)證和密鑰協(xié)商，對(duì)稱加密算法采用協(xié)商的密鑰對(duì)數(shù)據(jù)加密，基于散列函數(shù)驗(yàn)證信息的完整性。

TLS/SSL = 非對(duì)稱加密 + 對(duì)稱加密 + 散列算法

非對(duì)稱加密

加密和解密使用不同密鑰的加密算法，也稱為公私鑰加密。密鑰成對(duì)出現(xiàn)，一般稱為公鑰(publickey)和私鑰(privatekey)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。即服務(wù)器持有私鑰，客戶端持有公鑰，客戶端要發(fā)送的信息經(jīng)過公鑰加密后傳遞給服務(wù)器，服務(wù)器用私鑰解密得到明文信息。

特點(diǎn)：

• 可以實(shí)現(xiàn)1對(duì)多的通信;
• 保密性比較好，只有公鑰需要被傳遞，故私鑰被劫持的概率很低;
• 安全性高，保密性保證私鑰安全，因此安全性僅依賴于算法本身;
• 計(jì)算復(fù)雜，加密速度慢。

在TLS/SSL中，非對(duì)稱加密僅用于“身份認(rèn)證”和“密鑰協(xié)商”，不在后續(xù)正文數(shù)據(jù)傳輸中使用，這是安全性與性能之間的平衡取舍。

對(duì)稱加密

加密和解密使用相同密鑰的加密算法。即客戶端與服務(wù)器所持有的密鑰是相同的，客戶端要發(fā)送的信息經(jīng)過密鑰加密后傳遞給服務(wù)器，服務(wù)器用相同密鑰解密得到明文信息。

特點(diǎn)：

• 通信方式是1對(duì)1，為了足夠安全，服務(wù)器和N個(gè)客戶端通信，需要維持N個(gè)密碼記錄;
• 安全性不僅取決于加密算法本身，密鑰管理的安全性更是重要;
• 計(jì)算量小、加密速度快、加密效率高;
• 缺少吊銷和修改密鑰的機(jī)制。

在TLS/SSL中，對(duì)稱加密的密鑰是通過非對(duì)稱加密的“密鑰協(xié)商”產(chǎn)生的，這樣就最大限度的保證了密鑰的安全。由于其效率高的特點(diǎn)，正文數(shù)據(jù)傳輸使用了該加密方式。

散列函數(shù)(Hash)

一種將任意長(zhǎng)度的消息壓縮到某一固定長(zhǎng)度的消息摘要的函數(shù)，常用于防止信息篡改并驗(yàn)證數(shù)據(jù)的完整性。

特點(diǎn)：

• 單向不可逆;
• 對(duì)輸入非常敏感，即一點(diǎn)輸入的改變都會(huì)導(dǎo)致結(jié)果不同;
• 輸出長(zhǎng)度固定。

在信息傳輸過程中，散列函數(shù)不能單獨(dú)實(shí)現(xiàn)信息防篡改，因?yàn)槊魑膫鬏敚虚g人可以修改信息之后重新計(jì)算信息摘要，因此需要對(duì)傳輸?shù)男畔⒁约靶畔⒄M(jìn)行加密。

在TLS/SSL中，“密鑰協(xié)商”的最后步驟和傳輸正文信息都會(huì)帶上散列函數(shù)計(jì)算出的信息摘要，他們一起經(jīng)過對(duì)稱加密后傳輸，用來(lái)驗(yàn)證完整性。

PKI體系

非對(duì)稱加密的隱患

前面講到“身份驗(yàn)證”和“密鑰協(xié)商”是TLS/SSL的基礎(chǔ)功能，要求的前提是合法的服務(wù)器掌握著對(duì)應(yīng)的私鑰。但非對(duì)稱加密算法無(wú)法確保服務(wù)器身份的合法性，因?yàn)楣€并不包含服務(wù)器的信息。

假定出現(xiàn)以下的情況：

• 客戶端C和服務(wù)器S進(jìn)行通信，中間節(jié)點(diǎn)M截獲了二者的通信;
• 節(jié)點(diǎn)M自己計(jì)算產(chǎn)生一對(duì)公鑰pub_M和私鑰pri_M;
• C向S請(qǐng)求公鑰時(shí)，M把自己的公鑰pub_M發(fā)給了C;
• C使用公鑰pub_M加密的數(shù)據(jù)能夠被M解密，因?yàn)镸掌握對(duì)應(yīng)的私鑰pri_M，而C無(wú)法根據(jù)公鑰信息判斷服務(wù)器的身份，從而C和M之間建立了"可信"加密連接。

 

 

 

 

如圖，中間節(jié)點(diǎn)M和服務(wù)器S之間再建立合法的連接，因此C和S之間通信被M完全掌握，M可以進(jìn)行信息的竊聽、篡改等操作，這類攻擊被稱為“中間人攻擊”。

身份驗(yàn)證CA和證書

為了解決上述的隱患，關(guān)鍵是確保獲取公鑰途徑是合法的，能夠驗(yàn)證服務(wù)器的身份信息，為此需要引入權(quán)威的第三方機(jī)構(gòu)CA。

CA全稱Certificate Authority(證書頒發(fā)機(jī)構(gòu))，它負(fù)責(zé)核實(shí)公鑰的擁有者的信息，并頒發(fā)認(rèn)證"證書"，同時(shí)能夠?yàn)槭褂谜咛峁┳C書驗(yàn)證服務(wù)，即PKI體系。

證書 = 公鑰 + 申請(qǐng)者與頒發(fā)者信息 + 有效時(shí)間 + 域名信息 + 簽名

CA認(rèn)證流程如下：

 

 

 

 

客戶端會(huì)內(nèi)置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對(duì)應(yīng)CA的證書，證書也會(huì)被判定非法。

也可以這樣理解，網(wǎng)站千千萬(wàn)，瀏覽器廠商沒辦法一家一家去認(rèn)證，于是跟CA合作，通過維護(hù)一個(gè)CA列表，只要網(wǎng)站有經(jīng)過這個(gè)列表里CA的認(rèn)證，就可以信任該網(wǎng)站的證書。

TLS/SSL握手過程

TLS/SSL握手過程也就是所謂的HTTPS四次握手(不含證書驗(yàn)證步驟)。

1.客戶端發(fā)起請(qǐng)求，以明文傳輸請(qǐng)求信息，包含版本信息，加密套件候選列表，壓縮算法候選列表，隨機(jī)數(shù)random_C(明文)，擴(kuò)展字段等信息。

2.服務(wù)端返回協(xié)商的信息結(jié)果，隨機(jī)數(shù)random_S(明文)，證書鏈等。

3.對(duì)證書進(jìn)行驗(yàn)證，包括證書可信性、有效性等，可能需要聯(lián)系CA。

4.細(xì)分為四步：

1. client_key_exchange：客戶端計(jì)算產(chǎn)生隨機(jī)數(shù)字Pre-master，并用證書公鑰加密，發(fā)送給服務(wù)器;
2. 客戶端根據(jù)random_C、random_S以及Pre-master，計(jì)算得到協(xié)商密鑰enc_key(即對(duì)稱加密用的密鑰);
3. change_cipher_spec：客戶端通知服務(wù)器后續(xù)的通信都采用協(xié)商的通信密鑰和加密算法進(jìn)行加密通信;
4. encrypted_handshake_message：結(jié)合之前所有通信參數(shù)的hash值與其它相關(guān)信息生成一段數(shù)據(jù)，采用協(xié)商密鑰enc_key進(jìn)行加密，然后發(fā)送給服務(wù)器用于數(shù)據(jù)與握手驗(yàn)證;

5.細(xì)分為四步：

1. 服務(wù)器使用私鑰解密Pre-master，根據(jù)random_C、random_S以及Pre-master，計(jì)算得到協(xié)商密鑰enc_key;
2. 計(jì)算之前所有接收信息的hash值，然后解密客戶端發(fā)送的encrypted_handshake_message，驗(yàn)證數(shù)據(jù)和密鑰正確性;
3. change_cipher_spec：驗(yàn)證通過之后，服務(wù)器同樣發(fā)送change_cipher_spec以告知客戶端后續(xù)的通信都采用協(xié)商的密鑰與算法進(jìn)行加密通信;
4. encrypted_handshake_message：服務(wù)器也結(jié)合所有當(dāng)前的通信參數(shù)信息生成一段數(shù)據(jù)并采用協(xié)商密鑰enc_key加密并發(fā)送到客戶端;

6.握手結(jié)束，開始使用協(xié)商密鑰enc_key進(jìn)行對(duì)稱加密通信(包含hash完整性驗(yàn)證)。

示意圖如下：

 

 

 

 

HTTPS的使用成本

• 證書費(fèi)用及維護(hù)更新

一般正規(guī)CA頒發(fā)的證書都是需要付費(fèi)購(gòu)買的，并且到期后還得續(xù)費(fèi)。

• 增加了訪問延遲

分析前面的握手過程，一次完整的握手至少需要兩端依次來(lái)回兩次通信，至少增加延時(shí)2RTT，利用會(huì)話緩存從而復(fù)用連接，延時(shí)也至少1RTT。

• 消耗較多CPU資源

加解密是需要消耗性能的，前面也有提到非對(duì)稱加密的特點(diǎn)，因此會(huì)成為性能瓶頸。

HTTPS的優(yōu)化

TLS False Start

在TLS/SSL協(xié)商第二階段，也就是瀏覽器生成最后一個(gè)隨機(jī)數(shù)并用公鑰加密發(fā)送給服務(wù)器后，立即發(fā)送加密的應(yīng)用層數(shù)據(jù)，而無(wú)需等待服務(wù)器的確認(rèn)。

Session Identifier(會(huì)話標(biāo)識(shí)符)

如果用戶的一個(gè)業(yè)務(wù)請(qǐng)求包含了多條的加密流，客戶端與服務(wù)器要反復(fù)握手，必定導(dǎo)致更多的時(shí)間損耗。或某些特殊情況導(dǎo)致會(huì)話中斷，需要重新握手。

服務(wù)器為每一次的會(huì)話生成并記錄一個(gè)sessionId，發(fā)送給客戶端，客戶端重新連接只需要提供這個(gè)id，不需要重新握手。

OCSP Stapling

OCSP全稱Online Certificate Status Protocol。由web服務(wù)器向OCSP server周期性地查詢證書狀態(tài)，獲得一個(gè)帶有時(shí)間戳和簽名的OCSP response并緩存它。當(dāng)有客戶端發(fā)起請(qǐng)求時(shí)，web服務(wù)器會(huì)把這個(gè)response在TLS握手過程中發(fā)給客戶端。

(谷歌瀏覽器默認(rèn)只使用內(nèi)置列表檢查，故這個(gè)優(yōu)化對(duì)谷歌無(wú)效)

HSTS(HTTP Strict-Transport-Security)

一個(gè)報(bào)文頭部字段，告訴瀏覽器，接下來(lái)的一段時(shí)間內(nèi)，當(dāng)前域名(及其子域名)的后續(xù)通信應(yīng)該強(qiáng)制性使用HTTPS，直到超過有效期為止。

形如：

 

 

Strict-Transport-Security: max-age=31536000;includeSubDomains 

【責(zé)任編輯：龐桂玉 TEL：（010）68476606】