巨乳美女午夜福利av,337p噜噜噜噜,亚洲熟女av中文字幕

隨著互聯(lián)網(wǎng)的快速發(fā)展，安全性的問題越來越重要，加之人類是“貪婪”的，遠(yuǎn)遠(yuǎn)不滿足對于 HTTP 的安全性，于是有了 HTTPS。而 HTTPS 在安全性上是怎樣遠(yuǎn)遠(yuǎn)勝于 HTTP 的呢？

微信截圖_20210406142017.png

HTTP 存在的問題

數(shù)據(jù)沒有加密：HTTP 的傳遞是明文，不會加密這些信息，只要攻擊者能夠獲取到這些明文，用戶的隱私就完全暴露了。解決的方法就是信息加密。

微信截圖_20210406142059.png

無法驗證身份：在 HTTP 應(yīng)用中，客戶端和服務(wù)端并不能確認(rèn)對方的身份，因為在 HTTP 標(biāo)準(zhǔn)中，沒有校驗對端身份的標(biāo)準(zhǔn)。解決的方法就是用證書來驗證對方的身份。

微信截圖_20210406142135.png

數(shù)據(jù)容易被篡改：HTTP 數(shù)據(jù)在傳輸過程中，會經(jīng)過很多節(jié)點，這些節(jié)點都可以修改原始數(shù)據(jù)，而對于客戶端和服務(wù)端來說，沒有任何技術(shù)來確保接受的數(shù)據(jù)就是發(fā)送者發(fā)送的原始數(shù)據(jù)。解決方法就是利用一些算法來檢驗數(shù)據(jù)。

微信截圖_20210406142205.png

HTTP 存在的這些問題，導(dǎo)致了很大的安全性問題。所以便有了 HTTPS 的誕生。

HTTPS

HTTPS 并不是一個新的協(xié)議，本質(zhì)上還是 HTTP，只是 HTTPS 在 HTTP 的基礎(chǔ)上增加了一些網(wǎng)絡(luò)安全的東西。HTTPS 是建立在安全 socket 層次上的超文本傳輸協(xié)議，可以認(rèn)為 HTTPS = HTTP + SSL/TLS

SSL/TLS 是安全協(xié)議。SSL(Secure Sockets Layer)：安全套接字層協(xié)議；TLS(Transport Layer Security)：安全傳輸層協(xié)議。TLS 是從 SSL 發(fā)展而來的，SSL 是最早期的安全層協(xié)議，后來發(fā)現(xiàn)了一些漏洞后，便有了 TLS?，F(xiàn)階段使用最多的版本是 TLS1.2、TLS1.3版本。

安全協(xié)議版本需要雙方通信協(xié)商之后，確定雙方使用相同版本的協(xié)議，才能建立安全連接。

在講瀏覽器使用 HTTPS 傳輸數(shù)據(jù)的流程之前，我們先來了解幾個知識。

加密算法

在上面說 HTTP 存在「數(shù)據(jù)沒有加密」這個問題的時候說到，要解決的方法就是信息加密。然而加密算法也有很多種。

密鑰：一種參數(shù)，在明文轉(zhuǎn)換為密文，或者密文轉(zhuǎn)換為明文時使用的

1、對稱算法
對稱算法顧名思義，就是加密和解密數(shù)據(jù)時，使用相同的密鑰。

優(yōu)點：就是效率很高，可以對長數(shù)據(jù)進(jìn)行加密。

缺點：最大的問題就是，通信雙方難以確保拿到安全的密鑰。因為第一步總是需要通過通信來協(xié)商密鑰的，那么在這個協(xié)商的過程，也有可能被黑客監(jiān)聽、篡改。如果使用一個固定的密鑰，那這個算法也失去了意義。

2、非對稱算法

與對稱算法不一樣的是，非對稱算法使用的是不用的密鑰。

非對稱算法有兩把密鑰：公鑰與私鑰。
公鑰是公開給所有人的，私鑰是自己保密的，不能給別人知道。
使用公鑰加密，只有私鑰才能解開。同樣，使用私鑰加密，只有公鑰才能解開

優(yōu)點：完美解決了對稱算法存在“無法安全交換密鑰”的問題

缺點：性能很差，效率遠(yuǎn)遠(yuǎn)不及對稱算法。

3、對稱 + 非對稱算法
對稱算法的效率高，但是無法安全交換密鑰；而非對稱算法可以安全交換密鑰，但是效率非常低。所以我們可以：第一次通信協(xié)商的時候使用非對稱算法來交換密鑰，后面就使用對稱算法來繼續(xù)通話，那這樣是不是取其優(yōu)點整合呢？如下圖所示：

微信截圖_20210406142514.png

1、客戶端發(fā)起請求的時候，服務(wù)端首先明文返回一個公鑰給客戶端
2、客戶端拿到了服務(wù)端的公鑰后，利用服務(wù)端的公鑰來加密客戶端自己的密鑰，然后發(fā)給服務(wù)端。
3、服務(wù)端拿到了客戶端用自己公鑰加密的數(shù)據(jù)后，用私鑰進(jìn)行解密，拿到了客戶端的密鑰
4、服務(wù)端用剛剛拿到的客戶端密鑰進(jìn)行加密自己的密鑰，然后發(fā)給客戶端。
5、客戶端拿到來服務(wù)端的密鑰

這就是對稱算法 + 非對稱算法的通信過程。

數(shù)字證書

在上面說 HTTP 存在「無法驗證對方身份」這個問題的時候說到，要解決的方法就是用證書來驗證。那么什么是證書呢？又是如何利用證書來驗證身份的呢？

1、什么是數(shù)字證書？

數(shù)字證書是指在互聯(lián)網(wǎng)通訊中標(biāo)志通訊各方身份信息的一個數(shù)字認(rèn)證，人們可以在網(wǎng)上用它來識別對方的身份，是由電子商務(wù)認(rèn)證中心（簡稱CA中心）所頒發(fā)的一種較為權(quán)威與公正的證書。

數(shù)字證書好比我們的身份證，用來驗證信息的一個認(rèn)證

數(shù)字證書里面包括服務(wù)器信息：公鑰、證書簽名、證書機(jī)構(gòu)信息等等?？蛻舳四玫椒?wù)端的證書，進(jìn)行證書驗證后，可以準(zhǔn)備拿到服務(wù)器的公鑰，利用這個公鑰，就可以實現(xiàn) 對稱 + 非對稱算法加密了。

數(shù)字證書的作用就是：驗證數(shù)據(jù)來源，安全獲取服務(wù)器的公鑰進(jìn)行加密通信。

2、證書的生成

數(shù)字證書是由認(rèn)證中心（CA）或者認(rèn)證中心的下級認(rèn)證中心頒發(fā)的。根證書是認(rèn)證中心與用戶建立信任關(guān)系的基礎(chǔ)。在用戶使用數(shù)字證書之前必須先下載和安裝。

微信截圖_20210406142723.png

證書的產(chǎn)生：認(rèn)證中心把用戶證書的基本信息做哈希算法，然后用自己的私鑰對哈希值進(jìn)行加密。如下圖所示：

微信截圖_20210406142751.png

服務(wù)端產(chǎn)生了自己的密鑰對，并將公共密鑰及部分服務(wù)器身份信息傳送給一家認(rèn)證中心（CA機(jī)構(gòu)認(rèn)證）。
證書機(jī)構(gòu)對服務(wù)器的信息使用 hash 算法得出一份128位的摘要，并對這份摘要使用自己的私鑰進(jìn)行非對稱加密得到證書數(shù)字簽名。
證書機(jī)構(gòu)把服務(wù)器信息（明文）+數(shù)字簽名+證書機(jī)構(gòu)信息（包含證書機(jī)構(gòu)公鑰）發(fā)送給服務(wù)器
客戶端請求服務(wù)器時，服務(wù)器把證書返回給客戶端。

3、證書的分發(fā)

CA 將證書分發(fā)給用戶的途徑有多種。

帶外分發(fā)(Out-of-band Distribution)，即離線方式。例如，密鑰對是由軟件運營商代替客戶生成，證書也是由運營商代替客戶從 CA 下載，然后把私鑰和下載的證書一起儲存在軟盤里，再交給用戶的。這樣做的好處是免去了用戶上網(wǎng)下載證書的麻煩。
帶內(nèi)分發(fā)(In-band distribution)，即用戶從網(wǎng)上下載數(shù)字證書到自己的電腦中。下載時，用戶要向CA出示“參考號”和“授權(quán)碼”，以向CA證明自己的身份。這樣做成本較低。
查詢公共數(shù)據(jù)庫。CA 還把證書集中放置在公共的數(shù)據(jù)庫中公布，用戶可以隨用隨查詢隨調(diào)用。

4、如何驗證數(shù)字證書？？？
舉個例子：
A 同學(xué)驗證 B 同學(xué)的證書

A 同學(xué)拿到了 B 同學(xué)的證書（B 同學(xué)的證書、CA 簽發(fā) B 同學(xué)的證書、證書機(jī)構(gòu)信息）
A 同學(xué)用 CA 的公鑰解密對 CA 簽發(fā) B 同學(xué)的證書進(jìn)行解密，得到一份摘要 S1
A 同學(xué)對 B 同學(xué)的信息用 hash 算法得到一份摘要S2
對比S1、S2，看看信息是否被篡改過
校驗 B 同學(xué)證書的有效期、證書作廢列表（CRL,OCSP）以及簽發(fā)者簽名（證書鏈）

證書有效期：證書頒發(fā)的時候，就已經(jīng)確定了過期時間，個人一般是一年時間，企業(yè)是三年。這樣定期更新產(chǎn)生新的密鑰對，對安全性上是有好處的

證書作廢列表：當(dāng)我們申請證書注銷的時候，因為證書一旦頒發(fā)，就不能收回，所以 CA 只能出一張告示，宣布這張證書已作廢。這個“告示”稱為證書作廢列表。

5、證書鏈

剛剛在驗證數(shù)字證書的時候，我們提到了證書鏈，那么什么是證書鏈呢？證書鏈又有什么作用呢？

回憶一下剛剛數(shù)字簽名的生成與驗證過程：CA 利用自己的私鑰加密生產(chǎn)證書，然后用戶用 CA 公鑰去解密驗證。過程中是拿不到 CA 的密鑰的。如果中途被劫持了（黑客使用自己的私鑰加密，同時把證書機(jī)構(gòu)的公鑰修改成自己的公鑰），我們怎么得知呢？這時候就需要證書鏈了！！

隨便打開一個 HTTPS 的網(wǎng)站，在地址欄的左側(cè)有一個小鎖，點開可以看到里面的證書信息。

微信截圖_20210406143029.png

可以看到證書的層次是 GlobalSign Root CA --> GlobalSign Organization Validation CA --> baidu.com

end-user：即 baidu.com，該證書包含百度的公鑰，訪問者就是使用該公鑰將數(shù)據(jù)加密后再傳輸給百度，即在 HTTPS 中使用的證書
intermediates：即上文提到的簽發(fā)人 Issuer，用來認(rèn)證公鑰持有者身份的證書，負(fù)責(zé)確認(rèn) HTTPS 使用的 - - end-user 證書確實是來源于百度。這類 intermediates 證書可以有很多級，也就是說簽發(fā)人 Issuer 可能會有很多級
root：可以理解為最高級別的簽發(fā)人 Issuer，負(fù)責(zé)認(rèn)證 intermediates 身份的合法性

這其實代表了一個信任鏈條，最終的目的就是為了保證 end-user 證書是可信的，該證書的公鑰也就是可信的。證書鏈如下圖所示：

微信截圖_20210406143131.png

前面說了證書的驗證過程，那么證書鏈又是怎么個驗證流程呢？

獲取 end-user 的公鑰，需要獲取 end-user 的證書，因為公鑰就保存在該證書中
為了證明獲取到的 end-user 證書是可信的，就要看該證書是否被 intermediate 權(quán)威機(jī)構(gòu)認(rèn)證，等價于是否有權(quán)威機(jī)構(gòu)的數(shù)字簽名
有了權(quán)威機(jī)構(gòu)的數(shù)字簽名，而權(quán)威機(jī)構(gòu)就是可信的嗎？需要繼續(xù)往上驗證，即查看是否存在上一級權(quán)威認(rèn)證機(jī)構(gòu)的數(shù)字簽名
信任鏈條的最終是Root CA，他采用自簽名，對他的簽名只能無條件的信任

微信截圖_20210406143222.png

以上就是關(guān)于證書鏈的基本知識了，這里有一篇外文是關(guān)于證書鏈的，有興趣的可以觀看一下點一點

6、散列算法
散列算法，也稱之為摘要算法或哈希算法，可以將任一數(shù)據(jù)對象壓縮成數(shù)據(jù)摘要，對于同一散列算法，壓縮后的數(shù)據(jù)摘要具有特定的長度和格式，以此形成數(shù)據(jù)的"指紋"。原始數(shù)據(jù)對象的任一細(xì)小的改動，都可能使得新的"數(shù)字指紋"有著很大不同。

往往通過散列算法，可以判斷兩個數(shù)據(jù)對象是否相同，因為相同的數(shù)據(jù)對象，通過散列算法形成的"數(shù)字指紋"必定是相同的，但是相同的"數(shù)字指紋"，對應(yīng)的原始數(shù)據(jù)對象不一定是相同，因為可能存在散列沖突問題。在現(xiàn)實中就有廣泛的使用場景，例如最常用的對兩個文件對象進(jìn)行MD5，判斷其內(nèi)容是否相同。

散列算法與加密算法區(qū)別：

加密算法：對應(yīng)的是可以解密的，目的是進(jìn)行數(shù)據(jù)加密后的安全存儲或傳輸，是可以通過密鑰得到原文的，是可逆的過程。
散列算法：本質(zhì)上"數(shù)字指紋"的范疇，通過散列算法形成的"數(shù)字簽名"，直接在算法層面是不能得到原文的，是不可逆的。當(dāng)然，通過彩虹表和數(shù)據(jù)字典這種形式的所謂解密，本質(zhì)上只是暴力破解的過程。

HTTPS 連接過程

有了上面的知識了解后，我們來看看 HTTPS 連接的過程。

image.png

由上圖的可知流程：

1、首先客戶端（client）發(fā)起請求，并帶上本地的 TLS 版本，客戶端支持的加密算法套件，并生成一個客戶端的隨機(jī)數(shù) R1 也一同發(fā)送過去
2、服務(wù)端（server）收到請求后，確認(rèn)了 TLS 版本，并從客戶端支持的算法套件中選擇一個，并生成一個服務(wù)端的隨機(jī)數(shù) R2，然后返回給客戶端選擇的加密套件，隨機(jī)數(shù) R2，還有 CA 證書（包括公鑰）以及證書簽名。
3、客戶端（client）收到了服務(wù)端的證書后，驗證證書的合法性（具體可以往上看如何驗證證書的合法性）。利用兩個隨機(jī)數(shù)R1、R2，生成pre-master secret，并使用服務(wù)器的公鑰加密發(fā)送給服務(wù)器。并且客戶端生成會話密鑰和p1-p6
4、服務(wù)端（server）利用私鑰解密得到pre-master secret。并生成會話密鑰和p1-p6
5、客戶端（client）利用第三步生成的 p1 對握手信息的 hash 加密生成 Encrypted handshake message，然后發(fā)送給服務(wù)端，并發(fā)送FIN報文，表示結(jié)束。
6、服務(wù)端（server）利用第四步生成的 p1 驗證客戶端的 Encrypted handshake message。
7、驗證通過后，利用 p2 對握手信息的 hash 加密生成 Encrypted handshake message，然后發(fā)送給服務(wù)端，并發(fā)送FIN報文，表示結(jié)束。
8、客戶端（client）利用 p2 驗證完服務(wù)端的 Encrypted handshake message后，HTTPS 的連接流程結(jié)束

至此、雙方可以安全進(jìn)行通信了。

疑惑點：

1、客戶端的隨機(jī)數(shù) R1、服務(wù)端的隨機(jī)數(shù) R2 的作用是什么？
答：雙方通過交互各自的隨機(jī)數(shù)后，雙方都擁有了 R1、R2?？蛻舳耍╟lient）利用 R1、R2 生成一個 pre-master secret，然后利用這三個數(shù)，生成會話密鑰。
同樣的服務(wù)端（server）也是利用這三個數(shù)生成會話密鑰。

2、p1-p6 的作用是什么？
答：6個密鑰 p1-p6 是用作后續(xù)的身份認(rèn)證

3、Encrypted handshake message 是什么？ 有什么用？
答：Encrypted handshake message 把當(dāng)前自己收到的數(shù)據(jù)和發(fā)送的數(shù)據(jù)進(jìn)行一次簡單運算（hash+加密）。

這個報文的目的就是告訴對端自己在整個握手過程中收到了什么數(shù)據(jù)，發(fā)送了什么數(shù)據(jù)。來保證中間沒人篡改報文。
其次，這個報文作用就是確認(rèn)秘鑰的正確性。因為Encrypted handshake message是使用對稱秘鑰進(jìn)行加密的第一個報文，如果這個報文加解密校驗成功，那么就說明對稱秘鑰是正確的。

Charles 抓取 HTTPS 原理

做個小拓展，說一下 Charles 抓包工具抓 HTTPS 的原理

Charles 相當(dāng)于一個中間人，對于客戶端（client）來說，服務(wù)端是 Charles。而對于服務(wù)端（server）來說，客戶端是 Charles。如下圖所示：