蜜桃一区二区av大片免费观看,欧美刺激日韩一区,mm131午夜视频

這一次，讓你完全理解 HTTPS 到底是如何做到數(shù)據(jù)傳輸安全的

完全理解 HTTPS 如何做到傳輸安全

原作者：fi3ework

原文鏈接：https://github.com/fi3ework/blog/issues/17

概念

HTTPS：是以安全為目標(biāo)的 HTTP 通道，簡(jiǎn)單講是 HTTP 的安全版，即 HTTP 下加入 SSL 層，HTTPS 的安全基礎(chǔ)是 SSL，因此加密的詳細(xì)內(nèi)容就需要 SSL。

HTTPS 協(xié)議的主要作用可以分為兩種：一種是建立一個(gè)信息安全通道，來(lái)保證數(shù)據(jù)傳輸?shù)陌踩涣硪环N就是確認(rèn)網(wǎng)站的真實(shí)性。

名詞解釋

公鑰（yuè）私鑰（yuè）

公開(kāi)密鑰加密（英語(yǔ)：Public-key cryptography），也稱為非對(duì)稱加密（英語(yǔ)：asymmetric cryptography），是 密碼學(xué)[1] 的一種 算法[2]，它需要兩個(gè)密鑰[3]，一個(gè)是公開(kāi)密鑰，另一個(gè)是私有密鑰；一個(gè)用作加密的時(shí)候，另一個(gè)則用作解密。使用其中一個(gè)密鑰把明文[4] 加密后所得的密文[5]，只能用相對(duì)應(yīng)的另一個(gè)密鑰才能解密得到原本的明文；甚至連最初用來(lái)加密的密鑰也不能用作解密。由于加密和解密需要兩個(gè)不同的密鑰，故被稱為非對(duì)稱加密；不同于加密和解密都使用同一個(gè)密鑰的對(duì)稱加密[6]。雖然兩個(gè)密鑰在數(shù)學(xué)上相關(guān)，但如果知道了其中一個(gè)，并不能憑此計(jì)算出另外一個(gè)；因此其中一個(gè)可以公開(kāi)，稱為公鑰，任意向外發(fā)布；不公開(kāi)的密鑰為私鑰，必須由用戶自行嚴(yán)格秘密保管，絕不通過(guò)任何途徑向任何人提供，也不會(huì)透露給要通信的另一方，即使他被信任。

以上是來(lái)自維基百科的公鑰私鑰的定義，HTTPS 是基于非對(duì)稱加密的，公鑰和私鑰是整個(gè) HTTPS 的基礎(chǔ)。簡(jiǎn)單來(lái)說(shuō)，公鑰是公開(kāi)的（要不叫公鑰），比如小 A 想給我發(fā)送加密信息就要他我的公鑰，讓他用我的公鑰對(duì)信息進(jìn)行加密，這個(gè)信息只有我的私鑰能打開(kāi)。所以私鑰是絕對(duì)不能泄漏的，那么私鑰只能用來(lái)解開(kāi)公鑰嗎？并不是，公鑰私鑰都可以加密和用對(duì)方來(lái)解密，私鑰用來(lái)簽發(fā)數(shù)字簽名，我用獨(dú)一無(wú)二的私鑰簽發(fā)了一個(gè)數(shù)字簽名，你們都有我的公鑰，只有我簽發(fā)的數(shù)字簽名能用我的公鑰解開(kāi)，才能證明這個(gè)簽名發(fā)自我。

知乎上有個(gè)回答特別精辟：

不要去硬記。你只要想：既然是加密，那肯定是不希望別人知道我的消息，所以只有我才能解密，所以可得出公鑰負(fù)責(zé)加密，私鑰負(fù)責(zé)解密；同理，既然是簽名，那肯定是不希望有人冒充我發(fā)消息，只有我才能發(fā)布這個(gè)簽名，所以可得出私鑰負(fù)責(zé)簽名，公鑰負(fù)責(zé)驗(yàn)證。

Diffie--Hellman

迪菲 - 赫爾曼密鑰交換（英語(yǔ)：Diffie--Hellman key exchange，縮寫為 D-H）是一種 安全協(xié)議[7]。它可以讓雙方在完全沒(méi)有對(duì)方任何預(yù)先信息的條件下通過(guò)不安全信道[8] 創(chuàng)建起一個(gè) 密鑰[9]。這個(gè)密鑰可以在后續(xù)的通訊中作為對(duì)稱密鑰[10] 來(lái)加密[11]通訊內(nèi)容。

筆者本人并沒(méi)很仔細(xì)理解這個(gè)算法的原理，但是作為前端在實(shí)際應(yīng)用中只需要知道這個(gè)加密算法的作用就好了，中間就是黑箱。簡(jiǎn)單來(lái)說(shuō)這個(gè)算法的作用就是：Alice 和 Bob 各自有對(duì)方的公鑰（當(dāng)然其他人也有），Alice 和 Bob 再產(chǎn)生一個(gè)隨機(jī)數(shù)（不告訴別人），然后用兩個(gè)人的公鑰和自己手里的隨機(jī)數(shù)產(chǎn)生兩個(gè)數(shù) A B，然后它們交換這兩個(gè)數(shù)，每個(gè)人可以用自己手頭的隨機(jī)數(shù)和交換得來(lái)的數(shù)再次計(jì)算，兩個(gè)人得到的數(shù)是一樣的，就得到了一個(gè)共享密鑰。

在 知乎[12] 上找到一個(gè)這個(gè)共享秘鑰計(jì)算過(guò)程的描述

Alice 與 Bob 確定兩個(gè)大素?cái)?shù) n 和 g，這兩個(gè)數(shù)不用保密
Alice 選擇另一個(gè)大隨機(jī)數(shù) x，并計(jì)算 A 如下：A=gxmod n
Alice 將 A 發(fā)給 Bob
Bob 選擇另一個(gè)大隨機(jī)數(shù) y，并計(jì)算 B 如下：B=gymod n
Bob 將 B 發(fā)給 Alice
計(jì)算秘密密鑰 K1 如下：K1=Bxmod n
計(jì)算秘密密鑰 K2 如下：K2=Aymod n K1=K2，因此 Alice 和 Bob 可以用其進(jìn)行加解密

因此，client 和 server 可以 "離線" 計(jì)算出一份只有對(duì)方知道的秘鑰。

數(shù)字證書

公開(kāi)密鑰認(rèn)證（英語(yǔ)：Public key certificate），又稱公開(kāi)密鑰證書、公鑰證書、數(shù)字證書（digital certificate）、數(shù)字認(rèn)證、身份證書（identity certificate）、電子證書或安全證書，是用于 公開(kāi)密鑰基礎(chǔ)建設(shè)[13] 的電子文件，用來(lái)證明 公開(kāi)密鑰[14] 擁有者的身份[15]。此文件包含了公鑰信息、擁有者身份信息（主體）、以及數(shù)字證書認(rèn)證機(jī)構(gòu)[16]（發(fā)行者）對(duì)這份文件的數(shù)字簽名[17]，以保證這個(gè)文件的整體內(nèi)容正確無(wú)誤[18]。

包含的內(nèi)容有：

版本：現(xiàn)行通用版本是 V3
序號(hào)：用以辨識(shí)每一張證書，特別在撤消證書的時(shí)候有用
主體：擁有此證書的法人或自然人身份或機(jī)器，包括：
國(guó)家（C，Country）
州 / 省（S，State）
地域 / 城市（L，Location）
組織 / 單位（O，Organization）
通用名稱（CN，Common Name）：在 TLS 應(yīng)用上，此字段一般是網(wǎng)域
發(fā)行者：以數(shù)字簽名形式簽署此證書的數(shù)字證書認(rèn)證機(jī)構(gòu)
有效期開(kāi)始時(shí)間：此證書的有效開(kāi)始時(shí)間，在此前該證書并未生效
有效期結(jié)束時(shí)間：此證書的有效結(jié)束時(shí)間，在此后該證書作廢
公開(kāi)密鑰用途：指定證書上公鑰的用途，例如數(shù)字簽名、服務(wù)器驗(yàn)證、客戶端驗(yàn)證等
公開(kāi)密鑰
公開(kāi)密鑰指紋
數(shù)字簽名
數(shù)字簽名算法
主體別名：例如一個(gè)網(wǎng)站可能會(huì)有多個(gè)網(wǎng)域（www.wikipedia.org, zh.wikipedia.org, zh.m.wikipedia.org 都是維基百科）、一個(gè)組織可能會(huì)有多個(gè)網(wǎng)站（_.wikipedia.org, _.wikibooks.org, *.wikidata.org 都是維基媒體基金會(huì)旗下的網(wǎng)域），不同的網(wǎng)域可以一并使用同一張證書，方便實(shí)現(xiàn)應(yīng)用及管理

其中，在加密過(guò)程中最重要的是公開(kāi)密鑰和數(shù)字簽名算法，前者用來(lái)生成 session key，后者是驗(yàn)算 hash 的方法。

CA

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

在 CA 給服務(wù)端頒發(fā)證書的同時(shí)會(huì)產(chǎn)生一個(gè)私鑰和公鑰。私鑰由服務(wù)端自己保存，不可泄漏。公鑰則是附帶在證書的信息中，可以公開(kāi)的。證書本身也附帶一個(gè)證書電子簽名，這個(gè)簽名用來(lái)驗(yàn)證證書的完整性和真實(shí)性，可以防止證書被串改。

流程

SSL 協(xié)議分為兩部分：Handshake Protocol 和 Record Protocol。其中 Handshake Protocol 用來(lái)協(xié)商密鑰，協(xié)議的大部分內(nèi)容就是通信雙方如何利用它來(lái)安全的協(xié)商出一份密鑰。 Record Protocol 則定義了傳輸?shù)母袷健?/p>

相比對(duì)稱加密，非對(duì)稱加密的速度比較慢，所以它一般用于密鑰交換，雙方通過(guò)公鑰算法協(xié)商出一份密鑰，然后通過(guò)這個(gè)密鑰對(duì)稱加密來(lái)通信，充分結(jié)合這兩者的優(yōu)勢(shì)。

STEP 1: ClientHello

首先，由客戶端向服務(wù)端發(fā)起一個(gè)明文的無(wú)保護(hù)的請(qǐng)求，用來(lái)初始化 SSL（這里的客戶端只是一個(gè)職責(zé)的代號(hào)，代表 "首先發(fā)送信息的一方"，對(duì)前端來(lái)說(shuō)，就是瀏覽器）。

          messageclinet +---------------> server

message 中包含以下內(nèi)容：

客戶端最高能支持的協(xié)議
一個(gè)隨機(jī)數(shù)，稱為 client_random
session ID（以防客戶端想在握手階段回復(fù) session）
客戶端支持的 cipher suite[19]
客戶端支持的壓縮方法
一些其他信息

這個(gè)隨機(jī)數(shù)是會(huì)在后面中用到的，其他的是用來(lái)標(biāo)明客戶端支持的特性的。

STEP 2: ServerHello

         ServerHello         Certificate*         ServerKeyExchange*         CertificateRequest*         ServerHelloDoneclinet <---------------------+ server

服務(wù)端收到客戶端發(fā)來(lái)的信息，返回給客戶端自己的信息，message 中包括

客戶端和服務(wù)端將使用的協(xié)議
一個(gè)隨機(jī)數(shù)，稱為 server_random
這次會(huì)話的 session ID
雙方將會(huì)使用的 cipher suite
雙方將會(huì)使用的壓縮方法
服務(wù)器的證書 + 數(shù)字簽名（證書中包含服務(wù)端的公鑰）
ServerKeyExchange: 在服務(wù)端向客戶端發(fā)送的證書中沒(méi)有提供足夠的信息（證書公鑰）的時(shí)候，用來(lái)驗(yàn)證身份。
ServerHelloDone（表示 Server Hello 完成）

這里要說(shuō)一下數(shù)字證書與數(shù)字簽名，數(shù)字證書這個(gè)東西是向第三方機(jī)構(gòu)去申請(qǐng)的。

數(shù)字簽名用來(lái)保證數(shù)字證書沒(méi)有被篡改過(guò)，因?yàn)閿?shù)字簽名是用 CA 的私鑰來(lái)加密的，如果第三方篡改了簽名是無(wú)法用 CA 的公鑰解密的（就偽裝不下去了），數(shù)字簽名也是 CA 給的。

數(shù)字簽名的過(guò)程如下，使用證書中的數(shù)字簽名算法計(jì)算證書的一個(gè) HASH 值，然后 CA 用私鑰給加密，然后給服務(wù)端，服務(wù)端保管好即可。

          數(shù)字簽名算法           CA 私鑰加密數(shù)字證書 +-------------> HASH +-------------> 數(shù)字簽名

最后服務(wù)器發(fā)送 Server Hello Done 報(bào)文通知客戶端，最初階段的 SSL 握手協(xié)商部分結(jié)束，客戶端應(yīng)該發(fā)送信息了。

STEP 3: 客戶端回應(yīng)

驗(yàn)證證書

client:+---------------------------------------------------------------------+|                CA 公鑰解密                                            || 數(shù)字簽名 +--------------------> 服務(wù)端的 HASH   +-----+                ||                                                     |                ||                                                     +-----> 是否相同  ||         數(shù)字證書中的數(shù)字簽名算法                      |                || 數(shù)字證書 +--------------------> 客戶端計(jì)算的 HASH  +-- +                ||                                                                      |+----------------------------------------------------------------------+

客戶端根據(jù)證書中的數(shù)字簽名算法計(jì)算出數(shù)字證書的 HASH，再用本地的 CA 公鑰（瀏覽器廠商會(huì)內(nèi)置根證書，可以通過(guò)證書鏈將服務(wù)端的證書用內(nèi)置的根證書認(rèn)證）。解密出數(shù)字簽名的 HASH，比較一致則表明這確實(shí)是未被篡改過(guò)的數(shù)字證書。到這一步，客戶端已經(jīng)成功拿到了服務(wù)端的證書。

回應(yīng)服務(wù)端

         Certificate*         ClientKeyExchange         CertificateVerify*         [ChangeCipherSpec]         Finishedclinet +---------------------> server

證書

客戶端的證書，如果服務(wù)端需要的話會(huì)發(fā)送（比如某些網(wǎng)銀需要 U 盾來(lái)生成證書驗(yàn)證客戶端的身份）。

ClientKeyExchange

如果服務(wù)端需要對(duì)客戶端進(jìn)行驗(yàn)證，在客戶端收到服務(wù)端的 Server Hello 消息之后，首先需要向服務(wù)端發(fā)送客戶端的證書，讓服務(wù)端來(lái)驗(yàn)證客戶端的合法性。

CertificateVerify

如果證書沒(méi)有問(wèn)題，客戶端就會(huì)從服務(wù)器證書中取出服務(wù)器的公鑰來(lái)加密以下信息回應(yīng)服務(wù)端：

一個(gè)隨機(jī)數(shù)。該隨機(jī)數(shù)用服務(wù)器公鑰加密，防止被竊聽(tīng)（稱為 pre-master key）
編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發(fā)送
客戶端握手結(jié)束通知，表示客戶端的握手階段已經(jīng)結(jié)束。這一項(xiàng)同時(shí)也是前面發(fā)送的所有內(nèi)容的 hash 值，用來(lái)供服務(wù)器校驗(yàn)

ChangeCipherSpec

ChangeCipherSpec 是一個(gè)獨(dú)立的協(xié)議，體現(xiàn)在數(shù)據(jù)包中就是一個(gè)字節(jié)的數(shù)據(jù)，用于告知服務(wù)端，客戶端已經(jīng)切換到之前協(xié)商好的加密套件（Cipher Suite）的狀態(tài)，準(zhǔn)備使用之前協(xié)商好的加密套件加密數(shù)據(jù)并傳輸了。它標(biāo)志著從客戶端之后發(fā)出的信息將使用 shared secret 來(lái)進(jìn)行加密。

Finished

在 ChangecipherSpec 傳輸完畢之后，客戶端會(huì)使用之前協(xié)商好的加密套件和 shared secret 加密一段 Finish 的數(shù)據(jù)傳送給服務(wù)端，此數(shù)據(jù)是為了在正式傳輸應(yīng)用數(shù)據(jù)之前對(duì)剛剛握手建立起來(lái)的加解密通道進(jìn)行驗(yàn)證。

STEP 4: 服務(wù)端回應(yīng)

         [ChangeCipherSpec]         Finishedclinet <---------------------+ server

在這一步，服務(wù)端無(wú)論如何將得到 pre-master key，但是 SSL 有幾種不同的交換密鑰的算法，由 cipher suite 來(lái)決定，每種密鑰交換算法需要不同的公鑰來(lái)推倒，這里介紹兩種：

RSA：服務(wù)端的加密方式為 RSA，客戶端產(chǎn)生一個(gè)隨機(jī)數(shù)，就上上一步中的 pre-master key，然后用服務(wù)端的公鑰加密，如果是這樣的話就不需要傳輸 ServerKeyExchange。
DHE_RSA：服務(wù)端的加密方式為 RSA，不過(guò)只是用來(lái)簽名。真正需要的密鑰是用上面介紹的 DH 算法推倒的。ServerKeyExchange 中包含 DH 需要的參數(shù)和一個(gè)更新過(guò)的 DH 公鑰，然后服務(wù)端對(duì)其進(jìn)行加密發(fā)送給客戶端。客戶端更新這個(gè) DH 公鑰返回給服務(wù)端。這個(gè) DH 公鑰會(huì)產(chǎn)生 pre-master key。

不管用哪種方法，服務(wù)端和客戶端現(xiàn)在都已經(jīng)持有 pre-master key 后，使用私鑰進(jìn)行解密獲得 pre-master key。再加上自己手上的 server_random 和 client_random，然后客戶端和服務(wù)端會(huì)使用一個(gè) PRF (Pseudo-Random Function) 算法來(lái)產(chǎn)生 master-secret。

master_secret = PRF(pre_master_secret,  "master secret",  ClientHello.random + ServerHello.random)

再由 master-secret 推導(dǎo)出 session-key（也稱 shared-secret），這是雙方后續(xù)通信用來(lái)最終加密的對(duì)稱密鑰。

一切準(zhǔn)備好之后，服務(wù)端也回應(yīng)客戶端一個(gè)自己的用 session-key 加密的 ChangeCipherSpec，標(biāo)明自己之后的信息也將使用 session-key 來(lái)加密。之后，服務(wù)端也會(huì)使用 session-key 加密一段 Finish 消息發(fā)送給客戶端，以驗(yàn)證之前通過(guò)握手建立起來(lái)的加解密通道是否成功。

STET 6: HTTPS 通信

根據(jù)之前的握手信息，服務(wù)器和客戶端的 Finished 報(bào)文交換完畢之后，如果客戶端和服務(wù)端都能對(duì) Finish 信息進(jìn)行正常加解密且消息正確的被驗(yàn)證，則說(shuō)明 SSL 連接就算建立完成。接下來(lái)，雙方可以進(jìn)行應(yīng)用層的通信，使用上面產(chǎn)生的 session-key 對(duì) HTTP 進(jìn)行加密傳輸了。

在以上流程中，應(yīng)用層發(fā)送數(shù)據(jù)時(shí)會(huì)附加一種叫做 mac（ Message Authentication Code）的報(bào)文摘要。 MAC 能夠查知報(bào)文是否遭到篡改，從而保護(hù)報(bào)文的完整性。

總結(jié)

最后放上一張圖來(lái)總結(jié)整個(gè) SSL 的過(guò)程，其中加密方式采用的是 RSA，但是整個(gè)流程是思路是一致的。
其實(shí) HTTPS 要復(fù)雜的多，本文介紹的過(guò)程是簡(jiǎn)化了的，主要是理清如何安全獲得對(duì)稱公鑰。
via The SSL/TLS Handshake: an Overview[20]

這一次，讓你完全理解 HTTPS 到底是如何做到數(shù)據(jù)傳輸安全的

ssltls_handshake

GOOD & BAD

放上 HTTPS 的好處與壞處，via https 是什么？使用 https 的好處與不足？[21]

好處

正是由于 HTTPS 非常的安全，攻擊者無(wú)法從中找到下手的地方，從站長(zhǎng)的角度來(lái)說(shuō)，HTTPS 的優(yōu)點(diǎn)有以下 2 點(diǎn)：

seo 方面
谷歌曾在 2014 年 8 月份調(diào)整搜索引擎算法，并稱 "比起同等 HTTP 網(wǎng)站，采用 HTTPS 加密的網(wǎng)站在搜索結(jié)果中的排名將會(huì)更高"。
安全性
盡管 HTTPS 并非絕對(duì)安全，掌握根證書的機(jī)構(gòu)、掌握加密算法的組織同樣可以進(jìn)行中間人形式的攻擊，但 HTTPS 仍是現(xiàn)行架構(gòu)下最安全的解決方案，主要有以下幾個(gè)好處：使用 HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器；HTTPS 協(xié)議是由 SSL + HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比 HTTP 協(xié)議安全，可防止數(shù)據(jù)在傳輸過(guò)程中不被竊取、改變，確保數(shù)據(jù)的完整性。HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻擊的成本。

不足

雖然說(shuō) HTTPS 有很大的優(yōu)勢(shì)，但其相對(duì)來(lái)說(shuō)，還是有些不足之處的，具體來(lái)說(shuō)，有以下 2 點(diǎn)：

SEO 方面
據(jù) ACM CoNEXT 數(shù)據(jù)顯示，使用 HTTPS 協(xié)議會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近 50%，增加 10% 到 20% 的耗電，此外，HTTPS 協(xié)議還會(huì)影響緩存，增加數(shù)據(jù)開(kāi)銷和功耗，甚至已有安全措施也會(huì)受到影響也會(huì)因此而受到影響。而且 HTTPS 協(xié)議的加密范圍也比較有限，在黑客攻擊、拒絕服務(wù)攻擊、服務(wù)器劫持等方面幾乎起不到什么作用。最關(guān)鍵的，SSL 證書的信用鏈體系并不安全，特別是在某些國(guó)家可以控制 CA 根證書的情況下，中間人攻擊一樣可行。
經(jīng)濟(jì)方面 SSL 證書需要錢，功能越強(qiáng)大的證書費(fèi)用越高，個(gè)人網(wǎng)站、小網(wǎng)站沒(méi)有必要一般不會(huì)用。SSL 證書通常需要綁定 IP，不能在同一 IP 上綁定多個(gè)域名，IPv4 資源不可能支撐這個(gè)消耗（SSL 有擴(kuò)展可以部分解決這個(gè)問(wèn)題，但是比較麻煩，而且要求瀏覽器、操作系統(tǒng)支持，windows XP 就不支持這個(gè)擴(kuò)展，考慮到 XP 的裝機(jī)量，這個(gè)特性幾乎沒(méi)用）。HTTPS 連接緩存不如 HTTP 高效，大流量網(wǎng)站如非必要也不會(huì)采用，流量成本太高。HTTPS 連接服務(wù)器端資源占用高很多，支持訪客稍多的網(wǎng)站需要投入更大的成本，如果全部采用 HTTPS，基于大部分計(jì)算資源閑置的假設(shè)的 VPS 的平均成本會(huì)上去。HTTPS 協(xié)議握手階段比較費(fèi)時(shí)，對(duì)網(wǎng)站的相應(yīng)速度有負(fù)面影響，如非必要，沒(méi)有理由犧牲用戶體驗(yàn)。

參考

RSA 的公鑰和私鑰到底哪個(gè)才是用來(lái)加密和哪個(gè)用來(lái)解密？[22]
Diffie-Hellman 密碼交換是如何運(yùn)作的？[23]
迪菲 - 赫爾曼密鑰交換[24]
公開(kāi)密鑰認(rèn)證[25]
SSL/TLS 原理詳解[26]
https 的 pre-master-secret 到 master-secret 的過(guò)程？[27]
Differences between the terms 'pre-master secret', 'master secret', 'private key', and 'shared secret'?[28]
How does SSL/TLS work?[29]
What's the point of the pre-master key? [duplicate][30]
The SSL/TLS Handshake: an Overview[31]
圖解 HTTP

關(guān)注我

大家好，這里是 FEHub，每天早上 9 點(diǎn)更新，為你嚴(yán)選優(yōu)質(zhì)文章，與你一起進(jìn)步。

如果喜歡這篇文章，記得點(diǎn)贊，轉(zhuǎn)發(fā)。讓你的好基友和你一樣優(yōu)秀。

微信后臺(tái)回復(fù)關(guān)鍵字：「092c388d6169e78d」，即可參與紅包抽獎(jiǎng)，每晚 10 點(diǎn)開(kāi)獎(jiǎng)。

感謝大家的支持
吃飯時(shí)加個(gè)雞腿
咱們明天見(jiàn) & emsp;:)

歡迎關(guān)注「FEHub」，每天進(jìn)步一點(diǎn)點(diǎn)

日日操夜夜添-日日操影院-日日草夜夜操-日日干干-精品一区二区三区波多野结衣-精品一区二区三区高清免费不卡