HTTPS 是在 HTTP 和 TCP 之間建立了一個安全層，HTTP 與 TCP 通信的時候，必須先進(jìn)過一個安全層，對數(shù)據(jù)包進(jìn)行加密，然后將加密后的數(shù)據(jù)包傳送給 TCP，相應(yīng)的 TCP 必須將數(shù)據(jù)包解密，才能傳給上面的 HTTP。

一、基本概念及理解

TLS/SSL 的功能實現(xiàn)主要依賴于三類基本算法

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

非對稱加密是實現(xiàn)身份認(rèn)證和密鑰協(xié)商；

對稱加密是對信息進(jìn)行加密；

image.png

SSL和TLS的區(qū)別？

SSL和TLS都是加密協(xié)議，有網(wǎng)絡(luò)請求的地方就可以使用這兩種協(xié)議在傳輸層進(jìn)行加密，確保數(shù)據(jù)傳輸?shù)陌踩?，SSL是TLS的前身，網(wǎng)景在1995年發(fā)布了直接發(fā)布了SSL 2.0版本，1.0版本沒有對外發(fā)布。由于漏洞的原因，版本2.0也只是曇花一現(xiàn)，網(wǎng)景在1996年就發(fā)布了SSL3.0。隨后在1999年的時候，基于SSL3.0版本，網(wǎng)景發(fā)布了TLS1.0版本(雖然TLS1.0在SSL3.0基礎(chǔ)上的改動不太大，但是這些改動都是非常重要的)。

我們現(xiàn)在應(yīng)該使用TLS協(xié)議，因為在2011年和2015年的時候SSL2.0和SSL3.0就已經(jīng)分別被棄用了，而且由于漏洞的緣故，如果你的服務(wù)器配置了SSL的協(xié)議，還得手動將他們禁用掉。所以我們只給服務(wù)器配置TLS協(xié)議就好了，有的服務(wù)對TLS版本有要求，你可以在SSL Server Test查看服務(wù)器的證書及協(xié)議等配置。

SSL Server Test：

https://globalsign.ssllabs.com/

現(xiàn)在TLS主流版本是1.2。

SSL/TLS協(xié)議和證書的關(guān)系

為保證網(wǎng)絡(luò)安全，我們需要給服務(wù)器頒發(fā)證書，這個證書可以自己生成，但是自己頒發(fā)證書是不安全的，可以被別人偽造，所以我們一般都是在第三方認(rèn)證機構(gòu)購買證書 。那么問題來了，證書到底和協(xié)議是否有關(guān)聯(lián)，我們是否需要區(qū)分SSL證書和TLS證書呢？答案是否定的，證書不依賴協(xié)議，和協(xié)議沒有太大關(guān)聯(lián)，我們也不需要去糾結(jié)是使用SSL證書和TLS證書，協(xié)議由服務(wù)器配置決定，證書是配合協(xié)議一塊使用的。

私鑰、公鑰、對稱密鑰的區(qū)別？分別是什么？

對稱密鑰只有一個,可以是字符串,也可以是數(shù)字,對應(yīng)的加密方法是對稱加密。

公鑰和私鑰成對出現(xiàn).公開的密鑰叫公鑰，只有自己知道的叫私鑰

舉個例子:

A,B雙方準(zhǔn)備進(jìn)行系統(tǒng)間的通信，基于安全的考慮，采用數(shù)據(jù)加密通信。這時候，A有自己的公私鑰，分別是A公和A私，B也有自己的公私鑰，分別是B公和B私。通信前，雙方需要交換公鑰，這時候，A手上的密鑰有:A私和B公，B手上的密鑰有:B私和A公

通信時，A使用B公進(jìn)行敏感信息的加密，使用A私簽名。B收到信息后，使用B私進(jìn)行敏感信息解密，使用A公進(jìn)行驗簽。反之亦然。

從上面可以總結(jié):

1.公鑰和私鑰成對出現(xiàn).公開的密鑰叫公鑰，只有自己知道的叫私鑰 2.公鑰用于敏感信息的加密,私鑰用于簽名.所以公鑰的作用是保證數(shù)據(jù)安全,私鑰的作用的標(biāo)記信息的發(fā)送方.

3.用公鑰加密的數(shù)據(jù)只有對應(yīng)的私鑰可以解密,用私鑰簽名只有對應(yīng)的公鑰可以驗簽.

4.用公私鑰加解密的方式叫作非對稱加密.

5.其實通信雙方使用同一對公私鑰也是可以的.

對稱加密

這種方式加密和解密同用一個密鑰。加密和解密都會用到密鑰。以對稱加密方式加密時必須將密鑰也發(fā)給對方。

Q1：許許多多的客戶端，不可能都用同一秘鑰進(jìn)行信息加密，該怎么辦呢？

解決辦法：一個客戶端使用一個密鑰進(jìn)行加密

Q2：既然不同的客戶端使用不同的密鑰，那么對稱加密的密鑰如何傳輸？

解決辦法：只能是「一端生成一個秘鑰，然后通過HTTP傳輸給另一端」

Q3：這個傳輸密鑰的過程，又如何保證加密？「如果被中間人攔截，密鑰也會被獲取,」 那么你會說對密鑰再進(jìn)行加密，那又怎么保存對密鑰加密的過程，是加密的過程？

解決辦法：非對稱加密

為什么使用非對稱加密

以對稱加密方式加密時必須將密鑰也發(fā)給對方?？删烤乖鯓硬拍馨踩剞D(zhuǎn)交？在互聯(lián)網(wǎng)上轉(zhuǎn)發(fā)密鑰時，如果通信被監(jiān)聽那么密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設(shè)法安全地保管接收到的密鑰，所以使用非對稱加密。

非對稱加密

采用的算法是RSA、ECC、DH等

加密使用一對非對稱的密鑰。一把叫做私有密鑰，另一把叫做公開密鑰。顧名思義，私有密鑰不能讓其他任何人知道，而公開密鑰則可以隨意發(fā)布，任何人都可以獲得。

具體做法

發(fā)送密文的一方使用公鑰進(jìn)行加密處理“密鑰”，對方收到被加密的信息后，再使用自己的私有密鑰進(jìn)行解密。這樣可以確保交換的密鑰是安全的前提下，之后使用對稱加密方式進(jìn)行通信交換報文。利用這種方式，不需要發(fā)送用來解密的私有密鑰，也不必?fù)?dān)心密鑰被攻擊者竊聽而盜走。

非對稱加密，有以下特點：

•  有一對秘鑰，【公鑰】和【私鑰】。
•  公鑰加密的內(nèi)容，只有私鑰可以解開，私鑰加密的內(nèi)容，所有的公鑰都可以解開，這里說的【公鑰都可以解開，指的是一對秘鑰】。
•  公鑰可以發(fā)送給所有的客戶端，私鑰只保存在服務(wù)器端。
•  信息傳輸一對多，服務(wù)器只需要維持一個私鑰就能夠和多個客戶端進(jìn)行加密通信。

非對稱加密，有以下缺點：

•  公鑰是公開的，所以針對私鑰加密的信息，黑客截獲后可以使用公鑰進(jìn)行解密，獲取其中的內(nèi)容；
•  公鑰并不包含服務(wù)器的信息，使用非對稱加密算法無法確保服務(wù)器身份的合法性，存在中間人攻擊的風(fēng)險，服務(wù)器發(fā)送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改；
•  使用非對稱加密在數(shù)據(jù)加密解密過程需要消耗一定時間，降低了數(shù)據(jù)傳輸效率；

對稱加密和非對稱秘鑰的區(qū)別：

•  對稱加密需要發(fā)送生成的秘鑰給對方；非對稱加密不需要發(fā)送用來解密的私有秘鑰。
•  安全性：對稱加密發(fā)送秘鑰容易落入攻擊者之手，這樣就失去了加密的意義；非對稱加密的公開秘鑰可以隨意發(fā)布，任何人都可以獲得
•  對稱加密的好處是解密的效率比較快；非對稱加密的好處是可以使得傳輸?shù)膬?nèi)容不能被破解，因為就算你攔截到了數(shù)據(jù)，但是沒有對應(yīng)的私鑰，也是不能破解內(nèi)容的

對稱加密+非對稱加密（HTTPS采用這種方式）

HTTPS將對稱加密與非對稱加密結(jié)合起來，充分利用兩者各自的優(yōu)勢。在交換密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式。

具體做法是：發(fā)送密文的一方使用公鑰進(jìn)行加密處理“密鑰”，對方收到被加密的信息后，再使用自己的私有密鑰進(jìn)行解密。這樣可以確保交換的密鑰是安全的前提下，之后使用對稱加密方式進(jìn)行通信交換報文。所以，HTTPS采用對稱加密和非對稱加密兩者并用的混合加密機制。

CA認(rèn)證和第三方認(rèn)證有什么區(qū)別

第三方認(rèn)證是指與交易雙方?jīng)]有切實的利益關(guān)系并被國家認(rèn)可授權(quán)的有資歷審核認(rèn)證的單位，包括很多如，CA認(rèn)證、CE認(rèn)證、QA/QC認(rèn)證等等。拿CE認(rèn)證來說，產(chǎn)品要想在歐盟市場上自由流通，就必須經(jīng)國CE認(rèn)證，加貼“ CE ”標(biāo)志，以表明產(chǎn)品符合歐盟《技術(shù)協(xié)調(diào)與標(biāo)準(zhǔn)化新方法》指令的基本要求，這是歐盟法律對產(chǎn)品提出的一種強制性要求。

CA認(rèn)證是CA中心進(jìn)行的認(rèn)證。CA（Certificate Authority），稱為電子商務(wù)認(rèn)證中心，是負(fù)責(zé)發(fā)放和管理數(shù)字證書的權(quán)威機構(gòu)，并作為電子商務(wù)交易中受信任的第三方，承擔(dān)公鑰體系中公鑰的合法性檢驗的責(zé)任。CA認(rèn)證是第三方認(rèn)證的一種，應(yīng)用于電子商務(wù)方面。

附：我覺得第三方認(rèn)證也可以叫做第三方數(shù)字證書認(rèn)證

二、數(shù)字簽名 + 第三方認(rèn)證

數(shù)據(jù)無法被解密，但可能被篡改，解決報文可能遭篡改問題 —— 比對數(shù)字簽名

網(wǎng)絡(luò)傳輸過程中需要經(jīng)過很多中間節(jié)點，雖然數(shù)據(jù)無法被解密，但可能被篡改，那如何校驗數(shù)據(jù)的完整性呢？那就是校驗數(shù)字簽名。

先普及摘要的含義：對需要傳輸?shù)奈谋?，做一個HASH計算（SHA1，SHA2）

數(shù)字簽名如何生成

一段文本 ----hash函數(shù)----》 消息摘要 ----私鑰加密----》 數(shù)字簽名

將一段文本先用Hash函數(shù)生成消息摘要，然后用發(fā)送者的私鑰加密生成數(shù)字簽名，與原文一起傳送給接收者。接下來就是接收者校驗數(shù)字簽名的流程了。

其實此處的發(fā)送者就是Sever，接受者是Client。

校驗（比對）數(shù)字簽名流程

收到原文和數(shù)字簽名之后，需要比對校驗。 

步驟：  
1. 數(shù)字簽名 ----發(fā)送者的公鑰解密----》 消息摘要1    
2. 原文  ----hash函數(shù)----》 消息摘要2     
3. 消息摘要1 與 消息摘要2 比對  
如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，  
否則說明信息被修改過，因此數(shù)字簽名能夠驗證信息的完整性。 

接收者只有用發(fā)送者的公鑰才能解密被加密的摘要信息，然后用HASH函數(shù)對收到的原文產(chǎn)生一個摘要信息，與上一步得到的摘要信息對比。

舉個例子：假設(shè)消息傳遞在Kobe，James兩人之間發(fā)生。James將消息連同數(shù)字簽名一起發(fā)送給Kobe，Kobe接收到消息后，通過校驗數(shù)字簽名，就可以驗證接收到的消息就是James發(fā)送的。當(dāng)然，這個過程的前提是Kobe知道James的公鑰。問題來了，和消息本身一樣，公鑰不能在不安全的網(wǎng)絡(luò)中直接發(fā)送給Kobe，或者說拿到的公鑰如何證明是James的？

此時就需要引入了證書頒發(fā)機構(gòu)（Certificate Authority，簡稱CA），CA數(shù)量并不多，Kobe客戶端內(nèi)置了所有受信任CA的證書。CA對James的公鑰（和其他信息）數(shù)字簽名后生成證書。

為什么是發(fā)送者的公鑰？請求公鑰的過程是數(shù)字簽名的過程還是校驗數(shù)字簽名的過程？

下面的【數(shù)字證書認(rèn)證機構(gòu)的業(yè)務(wù)流程】能給與答案，請繼續(xù)看。

解決通信方身份可能被偽裝的問題 —— 數(shù)字證書（第三方認(rèn)證）

image.png

客戶端無法識別傳回公鑰是中間人的，還是服務(wù)器的，也就是客戶端可能拿到的公鑰是假的，這是問題的根本，我們可以通過某種規(guī)范可以讓客戶端和服務(wù)器都遵循某種約定，那就是通過「第三方認(rèn)證的方式」

數(shù)字證書認(rèn)證機構(gòu)處于客戶端與服務(wù)器雙方都可信賴的第三方機構(gòu)的立場上。

image.png

數(shù)字證書認(rèn)證機構(gòu)的業(yè)務(wù)流程

    1.  服務(wù)器的運營人員向第三方機構(gòu)CA提交公鑰、組織信息、個人信息(域名)等信息并申請認(rèn)證;

    2.  CA通過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業(yè)是否合法，是否擁有域名的所有權(quán)等;

    3.  如信息審核通過，CA會向申請者簽發(fā)認(rèn)證文件-證書。證書包含以下信息：申請者公鑰、申請者的組織信息和個人信息、簽發(fā)機構(gòu) CA的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名。其中簽名的產(chǎn)生算法：首先，使用散列函數(shù)計算公開的明文信息的信息摘要，然后，采用 CA的私鑰對信息摘要進(jìn)行加密，密文即簽名; 【數(shù)字簽名生成的過程】

    4.  客戶端 Client 向服務(wù)器 Server 發(fā)出請求時，Server 返回證書文件;

    5.  客戶端 Client 讀取證書中的相關(guān)的明文信息，采用相同的散列函數(shù)計算得到信息摘要，然后，利用對應(yīng) CA的公鑰解密簽名數(shù)據(jù)，對比證書的信息摘要，如果一致，則可以確認(rèn)證書的合法性，即服務(wù)器的公開密鑰是值得信賴的?！拘ｒ灁?shù)字簽名的過程】

    6.  客戶端還會驗證證書相關(guān)的域名信息、有效時間等信息; 客戶端會內(nèi)置信任CA的證書信息(包含公鑰)，如果CA不被信任，則找不到對應(yīng) CA的證書，證書也會被判定非法。

如果僅僅是第三方認(rèn)證，沒有數(shù)字簽名（只是對網(wǎng)站信息進(jìn)行第三方機構(gòu)私鑰加密）

第三方認(rèn)證機構(gòu)是一個公開的平臺，中間人可以去獲取。

數(shù)字簽名：將網(wǎng)站的信息，通過特定的算法加密，比如MD5,加密之后，再通過服務(wù)器的私鑰進(jìn)行加密，形成「加密后的數(shù)字簽名」。

可能會發(fā)生以下情況

image.png

從上面我們知道，因為沒有比對過程，所以中間人也向第三方認(rèn)證機構(gòu)進(jìn)行申請，然后攔截后把所有的信息都替換成自己的，客戶端仍然可以解密，并且無法判斷這是服務(wù)器的還是中間人的，最后造成數(shù)據(jù)泄露

數(shù)字簽名的作用

1.  能確定消息確實是由發(fā)送方簽名并發(fā)出來的，因為別人假冒不了發(fā)送方的簽名。
2.  數(shù)字簽名能確定消息的完整性,證明數(shù)據(jù)是否未被篡改過。

Client是如何去對比兩者數(shù)字簽名的呢？

1. 瀏覽器會去安裝一些比較權(quán)威的第三方認(rèn)證機構(gòu)的公鑰，比如VeriSign、Symantec以及GlobalSign等等。
2.  驗證數(shù)字簽名的時候，會直接從本地拿到相應(yīng)的第三方的公鑰，對私鑰加密后的數(shù)字簽名進(jìn)行解密得到真正的簽名。
3.  然后客戶端利用簽名生成規(guī)則進(jìn)行簽名生成，看兩個簽名是否匹配，如果匹配認(rèn)證通過，不匹配則獲取證書失敗。

小結(jié)

•  CA是頒發(fā)證書機構(gòu)（Certificate Authority）的簡稱
•  客戶端會內(nèi)置信任CA的證書信息(包含公鑰)，服務(wù)端返回的證書中有申請者公鑰。
•  證書的合法性取決于對比信息摘要
•  CA是否信任依賴于客戶端內(nèi)置信任的CA
•  公鑰是從服務(wù)器請求來的
•  數(shù)字簽名的生成：網(wǎng)站信息通過特定的算法加密，比如MD5， 加密之后，用第三方機構(gòu)的私鑰（Server的私鑰）再次加密
•  數(shù)字證書包含兩個特別重要的信息：網(wǎng)站公鑰、數(shù)字簽名
•  通信方身份可能被偽裝 —— 第三方證書
•  數(shù)據(jù)無法被解密，但可能被篡改，解決報文可能遭篡改問題 —— 校驗數(shù)字簽名
•  如果僅僅是第三方認(rèn)證，沒有數(shù)字簽名（只是對網(wǎng)站信息進(jìn)行第三方機構(gòu)私鑰加密） ，造成數(shù)據(jù)泄露，所以HTTPS通過【證書 + 數(shù)字簽名】來保證安全

三、HTTPS工作流程（TLS 1.2 握手過程）

image.png

    1.  Client發(fā)起一個HTTPS請求，連接443端口。這個過程可以理解成是【請求公鑰的過程】。

    2.  Server端收到請求后，會把申請好的數(shù)字證書（也可以認(rèn)為是公鑰證書）返回給Client。

    3.  瀏覽器安裝后會自動帶一些權(quán)威第三方機構(gòu)公鑰，使用匹配的公鑰對數(shù)字簽名進(jìn)行解密。根據(jù)簽名生成的規(guī)則對網(wǎng)站信息進(jìn)行本地簽名生成，然后兩者比對【（解密后的簽名和對網(wǎng)站信息用hash函數(shù)生成的簽名比對，其實這也是數(shù)字簽名校驗的過程，上面寫的數(shù)字簽名校驗實例沒有經(jīng)過CA）】。通過比對兩者簽名，匹配則說明認(rèn)證通過【（也可以說是證書合法，并且客戶端內(nèi)置的CA是信任的）】，不匹配則獲取證書失敗。

    4.  在安全拿到服務(wù)器公鑰后，客戶端Client使用偽隨機數(shù)生成器隨機生成一個對稱密鑰，使用【服務(wù)器公鑰】（證書的公鑰）加密這個【對稱密鑰】，發(fā)送給Server(服務(wù)器)。

    5.服務(wù)器Server通過自己的私鑰，對信息解密，至此得到了【對稱密鑰】，此時兩者都擁有了相同的【對稱密鑰】，接下來，就可以通過該對稱密鑰對傳輸?shù)男畔⒓用?解密啦。

    6.  Server使用對稱密鑰加密“明文內(nèi)容A”，發(fā)送給Client。

    7.  Client使用對稱密鑰解密響應(yīng)的密文，得到“明文內(nèi)容A”。

    8.  Client再次發(fā)起HTTPS的請求，使用對稱密鑰加密請求的“明文內(nèi)容B”，然后Server使用對稱密鑰解密密文，得到“明文內(nèi)容B”。

請求到的公鑰的作用：

1.  解密數(shù)字簽名（匹配的公鑰是服務(wù)器拿到的跟瀏覽器自帶的第三方機構(gòu)公鑰匹配成功的公鑰）
2.   加密Client使用偽隨機數(shù)隨機生成的一對稱秘鑰（這步驟開始對稱加密，把對稱秘鑰發(fā)送給Server，這個步驟經(jīng)過非對稱加密之后變成安全的了）

HTTPS工作中啥時候是非對稱加密，啥時候是對稱加密？

Server安全拿到對稱秘鑰之后，也就是Client和Server都擁有了相同的【對稱秘鑰】之后，開始對稱加密；認(rèn)之前是非對稱加密。換句話說，在交換密鑰環(huán)節(jié)使用非對稱加密方式，之后的建立通信交換報文階段則使用對稱加密方式。

四、HTTP 與 HTTPS 的區(qū)別

•  HTTP 是明文傳輸協(xié)議，HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。
•  HTTPS比HTTP更加安全，對搜索引擎更友好，利于SEO,谷歌、百度優(yōu)先索引HTTPS網(wǎng)頁;
•  HTTPS需要用到SSL證書，而HTTP不用【（HTTPS是安裝SSL的服務(wù)器，HTTP是未安裝SSL的服務(wù)器）】;
•  HTTPS標(biāo)準(zhǔn)端口443，HTTP標(biāo)準(zhǔn)端口80;
•  HTTPS基于傳輸層，HTTP基于應(yīng)用層;
•  HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

五、既然HTTPS那么安全可靠，那為何不所有的Web網(wǎng)站都使用HTTPS

    1.  首先，很多人還是會覺得HTTPS實施有門檻，這個門檻在于需要權(quán)威CA頒發(fā)的SSL證書。從證書的選擇、購買到部署，傳統(tǒng)的模式下都會比較耗時耗力。

    2.  其次，HTTPS普遍認(rèn)為性能消耗要大于HTTP，因為與純文本通信相比，加密通信會消耗更多的CPU及內(nèi)存資源。如果每次通信都加密，會消耗相當(dāng)多的資源，平攤到一臺計算機上時，能夠處理的請求數(shù)量必定也會隨之減少。但事實并非如此，用戶可以通過性能優(yōu)化、把證書部署在SLB或CDN，來解決此問題。舉個實際的例子，“雙十一”期間，全站HTTPS的淘寶、天貓依然保證了網(wǎng)站和移動端的訪問、瀏覽、交易等操作的順暢、平滑。通過測試發(fā)現(xiàn)，經(jīng)過優(yōu)化后的許多頁面性能與HTTP持平甚至還有小幅提升，因此HTTPS經(jīng)過優(yōu)化之后其實并不慢。

    3.  除此之外，想要節(jié)約購買證書的開銷也是原因之一。要進(jìn)行HTTPS通信，證書是必不可少的。而使用的證書必須向認(rèn)證機構(gòu)（CA）購買。

    4.  最后是安全意識。相比國內(nèi)，國外互聯(lián)網(wǎng)行業(yè)的安全意識和技術(shù)應(yīng)用相對成熟，HTTPS部署趨勢是由社會、企業(yè)、政府共同去推動的。

總結(jié)

HTTPS就是使用SSL/TLS協(xié)議進(jìn)行加密傳輸大致流程：

客戶端拿到服務(wù)器的公鑰（是正確的），然后客戶端隨機生成一個「對稱加密的秘鑰」，使用「該公鑰」加密，傳輸給服務(wù)端，服務(wù)端再通過解密拿到該「對稱秘鑰」，后續(xù)的所有信息都通過該「對稱秘鑰」進(jìn)行加密解密，完成整個HTTPS的流程。「第三方認(rèn)證」，最重要的是「數(shù)字簽名」，避免了獲取的公鑰是中間人的。