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

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

公司主營(yíng)業(yè)務(wù):成都網(wǎng)站設(shè)計(jì)、網(wǎng)站制作、移動(dòng)網(wǎng)站開發(fā)等業(yè)務(wù)。幫助企業(yè)客戶真正實(shí)現(xiàn)互聯(lián)網(wǎng)宣傳,提高企業(yè)的競(jìng)爭(zhēng)能力。成都創(chuàng)新互聯(lián)是一支青春激揚(yáng)、勤奮敬業(yè)、活力青春激揚(yáng)、勤奮敬業(yè)、活力澎湃、和諧高效的團(tuán)隊(duì)。公司秉承以“開放、自由、嚴(yán)謹(jǐn)、自律”為核心的企業(yè)文化,感謝他們對(duì)我們的高要求,感謝他們從不同領(lǐng)域給我們帶來的挑戰(zhàn),讓我們激情的團(tuán)隊(duì)有機(jī)會(huì)用頭腦與智慧不斷的給客戶帶來驚喜。成都創(chuàng)新互聯(lián)推出婁底免費(fèi)做網(wǎng)站回饋大家。

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)行加密;

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

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)證)

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

image.png

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

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

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

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ù)器的公開密鑰是值得信賴的?!拘r?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ā)生以下情況

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

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 握手過程)

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

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)注創(chuàng)新互聯(lián)網(wǎng)站,小編會(huì)繼續(xù)努力為大家?guī)砀鄬?shí)用的文章!

分享文章:HTTPS的原理是什么,與HTTP有什么區(qū)別
文章源于:http://muchs.cn/article8/jcjoip.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供App設(shè)計(jì)、品牌網(wǎng)站建設(shè)網(wǎng)站設(shè)計(jì)公司、移動(dòng)網(wǎng)站建設(shè)網(wǎng)站導(dǎo)航、自適應(yīng)網(wǎng)站

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)