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

一、基本概念及理解

TLS/SSL 的功能實現主要依賴于三類基本算法

散列函數 、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法采用協商的密鑰對數據加密，基于散列函數驗證信息的完整性。

非對稱加密是實現身份認證和密鑰協商；

對稱加密是對信息進行加密；

image.png

SSL和TLS的區別？

SSL和TLS都是加密協議，有網絡請求的地方就可以使用這兩種協議在傳輸層進行加密，確保數據傳輸的安全，SSL是TLS的前身，網景在1995年發布了直接發布了SSL 2.0版本，1.0版本沒有對外發布。由于漏洞的原因，版本2.0也只是曇花一現，網景在1996年就發布了SSL3.0。隨后在1999年的時候，基于SSL3.0版本，網景發布了TLS1.0版本（雖然TLS1.0在SSL3.0基礎上的改動不太大，但是這些改動都是非常重要的）。

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

SSL Server Test：

https://globalsign.ssllabs.com/

現在TLS主流版本是1.2。

SSL/TLS協議和證書的關系

為保證網絡安全，我們需要給服務器頒發證書，這個證書可以自己生成，但是自己頒發證書是不安全的，可以被別人偽造，所以我們一般都是在第三方認證機構購買證書 。那么問題來了，證書到底和協議是否有關聯，我們是否需要區分SSL證書和TLS證書呢？答案是否定的，證書不依賴協議，和協議沒有太大關聯，我們也不需要去糾結是使用SSL證書和TLS證書，協議由服務器配置決定，證書是配合協議一塊使用的。

私鑰、公鑰、對稱密鑰的區別？分別是什么？

對稱密鑰只有一個，可以是字符串，也可以是數字，對應的加密方法是對稱加密。

公鑰和私鑰成對出現。公開的密鑰叫公鑰，只有自己知道的叫私鑰

舉個例子：

A，B雙方準備進行系統間的通信，基于安全的考慮，采用數據加密通信。這時候，A有自己的公私鑰，分別是A公和A私，B也有自己的公私鑰，分別是B公和B私。通信前，雙方需要交換公鑰，這時候，A手上的密鑰有：A私和B公，B手上的密鑰有：B私和A公

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

從上面可以總結：

1.公鑰和私鑰成對出現。公開的密鑰叫公鑰，只有自己知道的叫私鑰 2.公鑰用于敏感信息的加密，私鑰用于簽名。所以公鑰的作用是保證數據安全，私鑰的作用的標記信息的發送方。

3.用公鑰加密的數據只有對應的私鑰可以解密，用私鑰簽名只有對應的公鑰可以驗簽。

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

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

對稱加密

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

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

解決辦法：一個客戶端使用一個密鑰進行加密

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

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

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

解決辦法：非對稱加密

為什么使用非對稱加密

以對稱加密方式加密時必須將密鑰也發給對方。可究竟怎樣才能安全地轉交？在互聯網上轉發密鑰時，如果通信被監聽那么密鑰就可會落人攻擊者之手，同時也就失去了加密的意義。另外還得設法安全地保管接收到的密鑰，所以使用非對稱加密。

非對稱加密

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

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

具體做法

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

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

有一對秘鑰，【公鑰】和【私鑰】。

公鑰加密的內容，只有私鑰可以解開，私鑰加密的內容，所有的公鑰都可以解開，這里說的【公鑰都可以解開，指的是一對秘鑰】。

公鑰可以發送給所有的客戶端，私鑰只保存在服務器端。

信息傳輸一對多，服務器只需要維持一個私鑰就能夠和多個客戶端進行加密通信。

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

公鑰是公開的，所以針對私鑰加密的信息，黑客截獲后可以使用公鑰進行解密，獲取其中的內容；

公鑰并不包含服務器的信息，使用非對稱加密算法無法確保服務器身份的合法性，存在中間人攻擊的風險，服務器發送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改；

使用非對稱加密在數據加密解密過程需要消耗一定時間，降低了數據傳輸效率；

對稱加密和非對稱秘鑰的區別：

對稱加密需要發送生成的秘鑰給對方；非對稱加密不需要發送用來解密的私有秘鑰。

安全性：對稱加密發送秘鑰容易落入攻擊者之手，這樣就失去了加密的意義；非對稱加密的公開秘鑰可以隨意發布，任何人都可以獲得

對稱加密的好處是解密的效率比較快；非對稱加密的好處是可以使得傳輸的內容不能被破解，因為就算你攔截到了數據，但是沒有對應的私鑰，也是不能破解內容的

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

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

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

CA認證和第三方認證有什么區別

第三方認證是指與交易雙方沒有切實的利益關系并被國家認可授權的有資歷審核認證的單位，包括很多如，CA認證、CE認證、QA/QC認證等等。拿CE認證來說，產品要想在歐盟市場上自由流通，就必須經國CE認證，加貼“ CE ”標志，以表明產品符合歐盟《技術協調與標準化新方法》指令的基本要求，這是歐盟法律對產品提出的一種強制性要求。

CA認證是CA中心進行的認證。CA（Certificate Authority），稱為電子商務認證中心，是負責發放和管理數字證書的權威機構，并作為電子商務交易中受信任的第三方，承擔公鑰體系中公鑰的合法性檢驗的責任。CA認證是第三方認證的一種，應用于電子商務方面。

附：我覺得第三方認證也可以叫做第三方數字證書認證

二、數字簽名 + 第三方認證

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

網絡傳輸過程中需要經過很多中間節點，雖然數據無法被解密，但可能被篡改，那如何校驗數據的完整性呢？那就是校驗數字簽名。

先普及摘要的含義：對需要傳輸的文本，做一個HASH計算（SHA1，SHA2）

數字簽名如何生成

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

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

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

校驗（比對）數字簽名流程

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

步驟：

1. 數字簽名 ----發送者的公鑰解密----》 消息摘要1

2. 原文 ----hash函數----》 消息摘要2

3. 消息摘要1 與 消息摘要2 比對

如果相同，則說明收到的信息是完整的，在傳輸過程中沒有被修改，

否則說明信息被修改過，因此數字簽名能夠驗證信息的完整性。

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

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

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

為什么是發送者的公鑰？請求公鑰的過程是數字簽名的過程還是校驗數字簽名的過程？

下面的【數字證書認證機構的業務流程】能給與答案，請繼續看。

解決通信方身份可能被偽裝的問題 —— 數字證書（第三方認證）

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

數字證書認證機構處于客戶端與服務器雙方都可信賴的第三方機構的立場上。

數字證書認證機構的業務流程

服務器的運營人員向第三方機構CA提交公鑰、組織信息、個人信息（域名）等信息并申請認證;

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

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

客戶端 Client 向服務器 Server 發出請求時，Server 返回證書文件;

客戶端 Client 讀取證書中的相關的明文信息，采用相同的散列函數計算得到信息摘要，然后，利用對應 CA的公鑰解密簽名數據，對比證書的信息摘要，如果一致，則可以確認證書的合法性，即服務器的公開密鑰是值得信賴的。【校驗數字簽名的過程】

客戶端還會驗證證書相關的域名信息、有效時間等信息; 客戶端會內置信任CA的證書信息（包含公鑰），如果CA不被信任，則找不到對應 CA的證書，證書也會被判定非法。

如果僅僅是第三方認證，沒有數字簽名（只是對網站信息進行第三方機構私鑰加密）

第三方認證機構是一個公開的平臺，中間人可以去獲取。

數字簽名：將網站的信息，通過特定的算法加密，比如MD5，加密之后，再通過服務器的私鑰進行加密，形成「加密后的數字簽名」。

可能會發生以下情況

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

數字簽名的作用

能確定消息確實是由發送方簽名并發出來的，因為別人假冒不了發送方的簽名。

數字簽名能確定消息的完整性，證明數據是否未被篡改過。

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

瀏覽器會去安裝一些比較權威的第三方認證機構的公鑰，比如VeriSign、Symantec以及GlobalSign等等。

驗證數字簽名的時候，會直接從本地拿到相應的第三方的公鑰，對私鑰加密后的數字簽名進行解密得到真正的簽名。

然后客戶端利用簽名生成規則進行簽名生成，看兩個簽名是否匹配，如果匹配認證通過，不匹配則獲取證書失敗。

小結

CA是頒發證書機構（Certificate Authority）的簡稱

客戶端會內置信任CA的證書信息（包含公鑰），服務端返回的證書中有申請者公鑰。

證書的合法性取決于對比信息摘要

CA是否信任依賴于客戶端內置信任的CA

公鑰是從服務器請求來的

數字簽名的生成：網站信息通過特定的算法加密，比如MD5， 加密之后，用第三方機構的私鑰（Server的私鑰）再次加密

數字證書包含兩個特別重要的信息：網站公鑰、數字簽名

通信方身份可能被偽裝 —— 第三方證書

數據無法被解密，但可能被篡改，解決報文可能遭篡改問題 —— 校驗數字簽名

如果僅僅是第三方認證，沒有數字簽名（只是對網站信息進行第三方機構私鑰加密） ，造成數據泄露，所以HTTPS通過【證書 + 數字簽名】來保證安全

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

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

Server端收到請求后，會把申請好的數字證書（也可以認為是公鑰證書）返回給Client。

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

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

5.服務器Server通過自己的私鑰，對信息解密，至此得到了【對稱密鑰】，此時兩者都擁有了相同的【對稱密鑰】，接下來，就可以通過該對稱密鑰對傳輸的信息加密/解密啦。

Server使用對稱密鑰加密“明文內容A”，發送給Client。

Client使用對稱密鑰解密響應的密文，得到“明文內容A”。

Client再次發起HTTPS的請求，使用對稱密鑰加密請求的“明文內容B”，然后Server使用對稱密鑰解密密文，得到“明文內容B”。

請求到的公鑰的作用：

解密數字簽名（匹配的公鑰是服務器拿到的跟瀏覽器自帶的第三方機構公鑰匹配成功的公鑰）

加密Client使用偽隨機數隨機生成的一對稱秘鑰（這步驟開始對稱加密，把對稱秘鑰發送給Server，這個步驟經過非對稱加密之后變成安全的了）

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

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

四、HTTP 與 HTTPS 的區別

HTTP 是明文傳輸協議，HTTPS 協議是由 SSL+HTTP 協議構建的可進行加密傳輸、身份認證的網絡協議，比 HTTP 協議安全。

HTTPS比HTTP更加安全，對搜索引擎更友好，利于SEO，谷歌、百度優先索引HTTPS網頁;

HTTPS需要用到SSL證書，而HTTP不用【（HTTPS是安裝SSL的服務器，HTTP是未安裝SSL的服務器）】;

HTTPS標準端口443，HTTP標準端口80;

HTTPS基于傳輸層，HTTP基于應用層;

HTTPS在瀏覽器顯示綠色安全鎖，HTTP沒有顯示;

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

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

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

除此之外，想要節約購買證書的開銷也是原因之一。要進行HTTPS通信，證書是必不可少的。而使用的證書必須向認證機構（CA）購買。

最后是安全意識。相比國內，國外互聯網行業的安全意識和技術應用相對成熟，HTTPS部署趨勢是由社會、企業、政府共同去推動的。

總結

HTTPS就是使用SSL/TLS協議進行加密傳輸大致流程：

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

編輯：jq