HTTPS 的原理是什么，與HTTP有什么區(qū)別

這篇文章主要介紹“HTTPS 的原理是什么，與HTTP有什么區(qū)別”，在日常操作中，相信很多人在HTTPS 的原理是什么，與HTTP有什么區(qū)別問題上存在疑惑，小編查閱了各式資料，整理出簡(jiǎn)單好用的操作方法，希望對(duì)大家解答”HTTPS 的原理是什么，與HTTP有什么區(qū)別”的疑惑有所幫助！接下來，請(qǐng)跟著小編一起來學(xué)習(xí)吧！

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

一、基本概念及理解

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

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

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

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

image.png

SSL和TLS的區(qū)別？

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

我們現(xiàn)在應(yīng)該使用TLS協(xié)議，因?yàn)樵?011年和2015年的時(shí)候SSL2.0和SSL3.0就已經(jīng)分別被棄用了，而且由于漏洞的緣故，如果你的服務(wù)器配置了SSL的協(xié)議，還得手動(dòng)將他們禁用掉。所以我們只給服務(wù)器配置TLS協(xié)議就好了，有的服務(wù)對(duì)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ā)證書，這個(gè)證書可以自己生成，但是自己頒發(fā)證書是不安全的，可以被別人偽造，所以我們一般都是在第三方認(rèn)證機(jī)構(gòu)購買證書 。那么問題來了，證書到底和協(xié)議是否有關(guān)聯(lián)，我們是否需要區(qū)分SSL證書和TLS證書呢？答案是否定的，證書不依賴協(xié)議，和協(xié)議沒有太大關(guān)聯(lián)，我們也不需要去糾結(jié)是使用SSL證書和TLS證書，協(xié)議由服務(wù)器配置決定，證書是配合協(xié)議一塊使用的。

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

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

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

舉個(gè)例子:

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

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

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

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

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

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

5.其實(shí)通信雙方使用同一對(duì)公私鑰也是可以的.

對(duì)稱加密

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

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

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

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

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

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

解決辦法：非對(duì)稱加密

為什么使用非對(duì)稱加密

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

非對(duì)稱加密

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

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

具體做法

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

非對(duì)稱加密，有以下特點(diǎn)：

•  有一對(duì)秘鑰，【公鑰】和【私鑰】。

•  公鑰加密的內(nèi)容，只有私鑰可以解開，私鑰加密的內(nèi)容，所有的公鑰都可以解開，這里說的【公鑰都可以解開，指的是一對(duì)秘鑰】。

•  公鑰可以發(fā)送給所有的客戶端，私鑰只保存在服務(wù)器端。

•  信息傳輸一對(duì)多，服務(wù)器只需要維持一個(gè)私鑰就能夠和多個(gè)客戶端進(jìn)行加密通信。

非對(duì)稱加密，有以下缺點(diǎn)：

•  公鑰是公開的，所以針對(duì)私鑰加密的信息，黑客截獲后可以使用公鑰進(jìn)行解密，獲取其中的內(nèi)容；

•  公鑰并不包含服務(wù)器的信息，使用非對(duì)稱加密算法無法確保服務(wù)器身份的合法性，存在中間人攻擊的風(fēng)險(xiǎn)，服務(wù)器發(fā)送給客戶端的公鑰可能在傳送過程中被中間人截獲并篡改；

•  使用非對(duì)稱加密在數(shù)據(jù)加密解密過程需要消耗一定時(shí)間，降低了數(shù)據(jù)傳輸效率；

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

•  對(duì)稱加密需要發(fā)送生成的秘鑰給對(duì)方；非對(duì)稱加密不需要發(fā)送用來解密的私有秘鑰。

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

•  對(duì)稱加密的好處是解密的效率比較快；非對(duì)稱加密的好處是可以使得傳輸?shù)膬?nèi)容不能被破解，因?yàn)榫退隳銛r截到了數(shù)據(jù)，但是沒有對(duì)應(yīng)的私鑰，也是不能破解內(nèi)容的

對(duì)稱加密+非對(duì)稱加密（HTTPS采用這種方式）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

校驗(yàn)（比對(duì)）數(shù)字簽名流程

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

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

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

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

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

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

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

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

image.png

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

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

image.png

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

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

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

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

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

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

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

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

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

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

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

image.png

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

數(shù)字簽名的作用

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  能確定消息確實(shí)是由發(fā)送方簽名并發(fā)出來的，因?yàn)閯e人假冒不了發(fā)送方的簽名。

3.  數(shù)字簽名能確定消息的完整性,證明數(shù)據(jù)是否未被篡改過。

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

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2. 瀏覽器會(huì)去安裝一些比較權(quán)威的第三方認(rèn)證機(jī)構(gòu)的公鑰，比如VeriSign、Symantec以及GlobalSign等等。

3.  驗(yàn)證數(shù)字簽名的時(shí)候，會(huì)直接從本地拿到相應(yīng)的第三方的公鑰，對(duì)私鑰加密后的數(shù)字簽名進(jìn)行解密得到真正的簽名。

4.  然后客戶端利用簽名生成規(guī)則進(jìn)行簽名生成，看兩個(gè)簽名是否匹配，如果匹配認(rèn)證通過，不匹配則獲取證書失敗。

小結(jié)

•  CA是頒發(fā)證書機(jī)構(gòu)（Certificate Authority）的簡(jiǎn)稱

•  客戶端會(huì)內(nèi)置信任CA的證書信息(包含公鑰)，服務(wù)端返回的證書中有申請(qǐng)者公鑰。

•  證書的合法性取決于對(duì)比信息摘要

•  CA是否信任依賴于客戶端內(nèi)置信任的CA

•  公鑰是從服務(wù)器請(qǐng)求來的

•  數(shù)字簽名的生成：網(wǎng)站信息通過特定的算法加密，比如MD5， 加密之后，用第三方機(jī)構(gòu)的私鑰（Server的私鑰）再次加密

•  數(shù)字證書包含兩個(gè)特別重要的信息：網(wǎng)站公鑰、數(shù)字簽名

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

•  數(shù)據(jù)無法被解密，但可能被篡改，解決報(bào)文可能遭篡改問題 —— 校驗(yàn)數(shù)字簽名

•  如果僅僅是第三方認(rèn)證，沒有數(shù)字簽名（只是對(duì)網(wǎng)站信息進(jìn)行第三方機(jī)構(gòu)私鑰加密） ，造成數(shù)據(jù)泄露，所以HTTPS通過【證書 + 數(shù)字簽名】來保證安全

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

image.png

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

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

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

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

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

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

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

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

請(qǐng)求到的公鑰的作用：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  解密數(shù)字簽名（匹配的公鑰是服務(wù)器拿到的跟瀏覽器自帶的第三方機(jī)構(gòu)公鑰匹配成功的公鑰）

3.   加密Client使用偽隨機(jī)數(shù)隨機(jī)生成的一對(duì)稱秘鑰（這步驟開始對(duì)稱加密，把對(duì)稱秘鑰發(fā)送給Server，這個(gè)步驟經(jīng)過非對(duì)稱加密之后變成安全的了）

HTTPS工作中啥時(shí)候是非對(duì)稱加密，啥時(shí)候是對(duì)稱加密？

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

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

•  HTTP 是明文傳輸協(xié)議，HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，比 HTTP 協(xié)議安全。

•  HTTPS比HTTP更加安全，對(duì)搜索引擎更友好，利于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.  首先，很多人還是會(huì)覺得HTTPS實(shí)施有門檻，這個(gè)門檻在于需要權(quán)威CA頒發(fā)的SSL證書。從證書的選擇、購買到部署，傳統(tǒng)的模式下都會(huì)比較耗時(shí)耗力。

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

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

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

總結(jié)

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

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

到此，關(guān)于“HTTPS 的原理是什么，與HTTP有什么區(qū)別”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實(shí)踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識(shí)，請(qǐng)繼續(xù)關(guān)注億速云網(wǎng)站，小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章！