[TOC]

一、Https介紹

1. 什么是Https

HTTPS（全稱：Hypertext Transfer Protocol over Secure Socket Layer），是以安全為目標(biāo)的HTTP通道，簡單講是HTTP的安全版。即HTTP下加入SSL層，HTTPS的安全基礎(chǔ)是SSL，因此加密的詳細內(nèi)容就需要SSL

2. Https的作用

• 內(nèi)容加密 建立一個信息安全通道，來保證數(shù)據(jù)傳輸?shù)陌踩?/li>
• 身份驗證 確認(rèn)網(wǎng)站的真實性；
• 數(shù)據(jù)完整性 防止內(nèi)容被第三方冒充或者篡改

3. Https的劣勢

對數(shù)據(jù)進行加密決定了它比http慢

需要進行非對稱的加解密，且需要三次握手。首次連接比較慢，當(dāng)然現(xiàn)在也有很多的優(yōu)化。
出于安全考慮，瀏覽器不會在本地保存HTTPS緩存。實際上，只要在HTTP頭中使用特定命令，HTTPS是可以緩存的。Firefox默認(rèn)只在內(nèi)存中緩存HTTPS。但是，只要頭命令中有Cache-Control: Public，緩存就會被寫到硬盤上。IE只要http頭允許就可以緩存https內(nèi)容，緩存策略與是否使用HTTPS協(xié)議無關(guān)。

4. HTTPS和HTTP的區(qū)別

• https協(xié)議需要到CA申請證書
• http是超文本傳輸協(xié)議，信息時明文傳輸；https則是具有安全性的ssl加密傳輸協(xié)議
• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443
• http的連接很簡單，是無狀態(tài)的；https協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比http協(xié)議安全
• 下面就是https的整個構(gòu)架，現(xiàn)在的https基本都使用TLS了，因為更加安全，所以下圖中SSL應(yīng)該換成SSL/TLS。

image

下面就上圖中的知識點進行一個大概的介紹。

二、加解密相關(guān)知識

1. 對稱加密

對稱加密（也叫私鑰加密）指加密和解密使用相同密鑰的加密算法。有時又叫傳統(tǒng)密碼算法，就是加密密鑰能夠從解密密鑰中推算出來，同時解密密鑰也可以從加密密鑰中推算出來。而在大多數(shù)的對稱算法中，加密秘鑰和解密密鑰是相同的，所以也稱這種加密算法為秘密密鑰算法或者單密鑰算法。
常見的對稱加密有：DES（Data Encryption Standard）、AES（Advanced Encryption Standard）、RC4、IDEA

2. 非對稱加密

與對稱加密算法不同，非對稱加密算法需要兩個密鑰：公開密鑰（publickey）和私有密鑰（privatekey）；并且加密密鑰和解密密鑰是成對出現(xiàn)的。非對稱加密算法在加密和解密過程使用了不同的密鑰，非對稱加密也稱為公鑰加密，在密鑰對中，其中一個密鑰是對外公開的，所有人都可以獲取到，稱為公鑰，另一個密鑰是不公開的稱為私鑰。

非對稱加密算法對加密內(nèi)容的長度有限制，不能超過公鑰長度。比如現(xiàn)在常用的公鑰長度是2048位，意味著加密內(nèi)容不能超過256個字節(jié)。

3. 摘要算法

數(shù)字摘要是采用單項Hash函數(shù)將需要加密的明文“摘要”成一串固定長度（128位）的密文，這一串密文又稱為數(shù)字指紋，它有固定的長度，而且不同的明文摘要成密文，其結(jié)果總是不同的，而同樣的明文其摘要必定一致?！皵?shù)字摘要”是https能確保數(shù)據(jù)完整性和防篡改的根本原因。

4. 數(shù)字簽名

數(shù)字簽名技術(shù)就和對“非對稱密鑰加解密”和“數(shù)字摘要”兩項技術(shù)的應(yīng)用，它將摘要信息用發(fā)送者的私鑰加密，與原文一起傳送給接收者。接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原文產(chǎn)生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性。

數(shù)字簽名的過程如下：
明文 ——> hash算法 ——> 摘要 ——> 私鑰加密 ——> 數(shù)字簽名

數(shù)字簽名有兩種功效：
一、能確定消息確實是由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。
二、數(shù)字簽名能確定消息的完整性。

注意：
數(shù)字簽名只能驗證數(shù)據(jù)的完整性，數(shù)據(jù)本身是否加密不屬于數(shù)字簽名的控制范圍

5. 數(shù)字證書

1）為什么要有數(shù)字證書？
對于請求方來說，它怎么能確定它所得到的公鑰一定是從目標(biāo)主機那里發(fā)布的，而且沒有篡改過呢？亦或這請求的目標(biāo)主機本身就從事竊取用戶信息的不正當(dāng)行為呢？這時候，我們需要有一個權(quán)威的值得信賴的第三方機構(gòu)（一般由政府審核并授權(quán)的機構(gòu)）來統(tǒng)一對外發(fā)放主機機構(gòu)的公鑰，只要請求方這種機構(gòu)獲取公鑰，就避免了上述問題的發(fā)生。

2）數(shù)字證書的頒發(fā)過程
用戶首先產(chǎn)生自己的密鑰對，并將公鑰及部分個人身份信息傳送給認(rèn)證中心。認(rèn)證中心在核實身份后，將執(zhí)行一些必要的步驟，以確信請求確實由用戶發(fā)送而來，然后認(rèn)證中心將發(fā)給用戶一個數(shù)字證書，該證書包含用戶的個人信息和他的公鑰信息，同時還附有認(rèn)證中心的簽名信息（根證書私鑰簽名）。用戶就可以使用該證書進行相關(guān)的各種活動。數(shù)字證書由獨立的證書頒發(fā)機構(gòu)發(fā)布，數(shù)字證書各不相同，每種證書可提供不同級別的可信度。

3）證書包含哪些內(nèi)容

• 證書頒發(fā)機構(gòu)的名稱
• 證書本身的數(shù)字簽名
• 證書持有者公鑰
• 證書簽名用到的Hash算法（轉(zhuǎn)載者理解：原文轉(zhuǎn)摘要用到，參見下面驗證證書的有效性第3條）

4）驗證證書的有效性
瀏覽器默認(rèn)都會內(nèi)置CA根證書，其中根證書包含了CA的公鑰

1. 證書頒發(fā)的機構(gòu)時偽造的：瀏覽器不認(rèn)識，直接認(rèn)為是危險證書
2. 證書頒發(fā)的機構(gòu)確實存在，于是根據(jù)CA名，找到對應(yīng)內(nèi)置的CA根證書、CA的公鑰。用CA的公鑰，對偽造的證書的摘要進行解密，發(fā)現(xiàn)解不了，認(rèn)為是危險證書。
3. 對于篡改的證書，是喲CA的公鑰對數(shù)字簽名進行解密得到摘要A，然后再根據(jù)簽名的HASH算法計算出證書的摘要B，對比A與B，若相等則正常，否則就是被篡改過的。
4. 證書可在其過期前被吊銷，通常情況是該證書的私鑰已經(jīng)失密。較新的瀏覽器如Chrome、Firefox、Opera和Internet Explorer都實現(xiàn)了在線證書狀態(tài)協(xié)議（OCSP）以排除這種情況：瀏覽器將網(wǎng)站提供的證書的序列號通過OCSP發(fā)送給證書頒發(fā)機構(gòu)，后者會告訴瀏覽器證書是否還是有效的。

三、SSL與TLS

1. SSL（Secure Socket Layer，安全套接字層）

SSL為Netscape所研發(fā)，用以保障在Internet上數(shù)據(jù)傳輸之安全，利用數(shù)據(jù)加密技術(shù)，可確保數(shù)據(jù)在網(wǎng)絡(luò)上傳輸過程中不會被截取，當(dāng)前為3.0版本。

SSL協(xié)議可分為兩層：SSL記錄協(xié)議（SSL Recore Protocol）：它建立在可靠地傳輸協(xié)議（如TCP）之上，為高層協(xié)議提供數(shù)據(jù)封裝、壓縮、加密等基本功能的支持。SSL握手協(xié)議（SSL Handshake Protocol）：它建立在SSL記錄協(xié)議之上，用于在實際的數(shù)據(jù)傳輸開始前，通訊雙方進行身份證、協(xié)商加密算法、交換加密密鑰等。

2. TLS（Transport Layer Security，傳輸層安全協(xié)議）

用于兩個應(yīng)用程序之間提供保密性和數(shù)據(jù)完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任務(wù)組）制定的一種新的協(xié)議，它建立在SSL 3.0協(xié)議規(guī)范之上，是SSL 3.0的后續(xù)版本，可以理解為SSL 3.1，它是寫入了RFC的。該協(xié)議由兩層組成：TLS記錄協(xié)議（TLS Recore）和TLS握手協(xié)議（TLS Handshake）。較低的層為TLS記錄協(xié)議，位于某個可靠的傳輸協(xié)議（例如TCP）上面。

3. SSL/TLS協(xié)議作用：

• 認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機和服務(wù)器；（意思是HTTP的可能會發(fā)送到不正確的客戶機和服務(wù)器）
• 加密數(shù)據(jù)以防止數(shù)據(jù)中途被竊??；
• 維護數(shù)據(jù)的完整性，確保數(shù)據(jù)在傳輸過程中不被改變。

4. TLS比SSL的優(yōu)勢

1. 對于消息認(rèn)證使用密鑰散列法：TLS使用“消息認(rèn)證代碼的密鑰散列法”（HMAC），當(dāng)記錄在開放的網(wǎng)絡(luò)（如因特網(wǎng)）上傳送時，該代碼確保記錄不會被變更。SSLv3.0使用的是鍵控消息認(rèn)證（MAC），但HMAC比MAC功能更安全。
2. 增強的偽隨機功能（PRF）：PRF生成密鑰數(shù)據(jù)。在TLS中，HMAC定義PRF。PRF使用兩種散列算法保證其安全性。如果任一算法暴露了，只要第二種算法未暴露，則數(shù)據(jù)仍然是安全的。
3. 改進的已完成消息驗證：TLS和SSLv3.0都對兩個端點提供已完成的消息，該消息認(rèn)證交換的消息沒有被變更。然而，TLS將此已完成消息基于PRF和HMAC值之上，這也比SSLv3.0更安全。
4. 一致證書處理：與SSLv3.0不同，TLS試圖指定必須在TLS之間實現(xiàn)交換的證書類型。
5. 特定警報消息：TLS提供更多的特定和附加警報，以指示任一會話端點檢測到的問題。TLS還對何時應(yīng)該發(fā)送某些警報進行記錄。

5. SSL、TLS的握手過程

SSL與TLS握手整個過程如下圖所示，下面會詳細介紹每一步的具體內(nèi)容：

image

1）客戶端首次發(fā)出請求

由于客戶端（如瀏覽器）對一些加密算法的支持程度不一樣，但在TLS協(xié)議傳輸過程中必須使用同一套加解密算法才能保證數(shù)據(jù)能夠正常的加解密。在TLS握手階段，客戶端首先要告知服務(wù)器端，自己支持哪些加密算法，所以客戶端需要將本地支持的加密套件（Cipher Suite）的列表傳送給服務(wù)端。除此之外，客戶端還要產(chǎn)生一個隨機數(shù)，這個隨機數(shù)一方面需要在客戶端保存，另一方面需要傳送給服務(wù)端，客戶端的隨機數(shù)需要跟服務(wù)端產(chǎn)生的隨機數(shù)結(jié)合起來產(chǎn)生后邊要講的Master Secret。

客戶端需要提供如下信息：

• 支持的協(xié)議版本，比如TLS 1.0版本
• 一個客戶端生成的隨機數(shù)，稍后用于生成“對話密鑰”
• 支持的加密方法，比如RSA公鑰加密
• 支持的壓縮方法

2）服務(wù)端首次回應(yīng)

服務(wù)端在接收到客戶端的Client Hello之后，服務(wù)端需要確定加密協(xié)議的版本，以及加密的算法，然后也生成一個隨機數(shù)，以及將自己的證書發(fā)送給客戶端，這里的隨機數(shù)是整個過程的第二個隨機數(shù)。

服務(wù)端需要提供的信息：

• 協(xié)議的版本
• 加密的算法
• 隨機數(shù)
• 服務(wù)器證書

3）客戶端再次回應(yīng)

客戶端首先會對服務(wù)器下發(fā)的證書進行驗證，驗證通過后，則會繼續(xù)下面的操作，客戶端再次產(chǎn)生一個隨機數(shù)（第三個隨機數(shù)），然后使用服務(wù)器證書中的公鑰加密，以及放一個ChangeCipherSpec消息即編碼改變的消息，還有整個前面所有消息的hash值，進行服務(wù)器驗證，然后用新密鑰（轉(zhuǎn)載者的理解：使用第二次握手后服務(wù)器端返回的支持的加密算法隨機生成的對稱密鑰）加密一段數(shù)據(jù)一并發(fā)送到服務(wù)器，確保正式通信前無誤。
客戶端使用前面的兩個隨機數(shù)以及剛剛生成的新隨機數(shù)，使用與服務(wù)器確定的加密算法，生成一個Session Secret。

ChangeCipherSpec是一個獨立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。

4）服務(wù)器再次響應(yīng)

服務(wù)端在接收到客戶端傳過來的第三個隨機數(shù)的加密數(shù)據(jù)后，使用私鑰對解密這段加密數(shù)據(jù)，并對數(shù)據(jù)進行驗證，也會使用和客戶端同樣的方式生成密鑰。一切準(zhǔn)備好后，也會給客戶端發(fā)送一個ChangeCipherSpec，告知客戶端已經(jīng)切換到協(xié)商過的加密套件狀態(tài)，準(zhǔn)備使用加密套件和Session Secret加密數(shù)據(jù)了。之后，服務(wù)端也會使用Session Secret加密一段Finish消息發(fā)送給客戶端，以驗證之前通過握手建立起來的加解密通道是否成功。

轉(zhuǎn)載者疑問：這里的Session Secret是不是就是對稱密鑰？
會話密鑰：https://baike.baidu.com/item/%E4%BC%9A%E8%AF%9D%E5%AF%86%E9%92%A5/8831495?fr=aladdin

5）后續(xù)客戶端與服務(wù)期間通信

確定密鑰后，服務(wù)器與客戶端之間就會通過商定的密鑰加密數(shù)據(jù)，進行通訊了。這個握手過程也就基本完成了。

6. 其他補充

對于非常重要的保密數(shù)據(jù)，服務(wù)端還需要對客戶端進行驗證，以保證數(shù)據(jù)傳送給了安全的合法客戶端。服務(wù)端可以向客戶端發(fā)出Cerficate Request消息，要求客戶端發(fā)送證書對客戶端的合法性進行驗證。比如，金融機構(gòu)往往只允許認(rèn)證客戶連入自己的網(wǎng)絡(luò)，就會向正式客戶提供USB密鑰，里面就包含了一張客戶端證書。
PreMaster Secret前兩個字節(jié)是TLS的版本號，這是一個比較重要的用來核對握手?jǐn)?shù)據(jù)的版本號，因為在Client Hello階段，客戶端會發(fā)送一份加密套件列表和當(dāng)前支持的SSL/TLS的版本號給服務(wù)端，而且是使用明文傳送的，如果握手的數(shù)據(jù)包被破解之后，攻擊者很有可能篡改數(shù)據(jù)包，選擇一個安全性較低的加密套件和版本給服務(wù)端，從而對數(shù)據(jù)進行破解。所以，服務(wù)端需要對密文中解密出來的PreMaster版本號跟之前Client Hello階段的版本號進行對比，如果版本號變低，則說明被篡改，則立即停止發(fā)送任何消息。
session的恢復(fù)
有兩種方法可以恢復(fù)原來的session：一種叫做session ID，另一種叫做session ticket。

1）session ID

session ID的思想很簡單，就是每一次對話都有一個編號（session ID）。如果對話中斷，下次重連的時候，只要客戶端給出這個編號，且服務(wù)器有這個編號的記錄，雙方就可以重新使用已有的“對話密鑰”，而不必重新生成一把。

session ID是目前所有瀏覽器都支持的方法，但是它的缺點在于session ID往往只保留在一臺服務(wù)器上。所以，如果客戶端的請求發(fā)送到另一臺服務(wù)器，就無法恢復(fù)對話。

2）session ticket

客戶端發(fā)送一個服務(wù)器在上一次對話中發(fā)送過來的session ticket。這個session ticket是加密的，只有服務(wù)器才能解密，其中包括本次對話的主要信息，比如對話密鑰和加密方法。當(dāng)服務(wù)器收到session ticket以后，解密后就不必重新生成對話密鑰了。

目前只有Firefox和Chrome瀏覽器支持。

總結(jié)

https實際上就是在TCP層與http層之間加入了SSL/TLS來為上層的安全保駕護航，主要用到對稱加密、非對稱加密、證書等技術(shù)進行客戶端與服務(wù)器的數(shù)據(jù)加密傳輸，最終達到保證整個通信的安全性。