https加密流程

❶ https如何進行加密傳輸

HTTPS在傳輸數據之前需要客戶端（瀏覽器）與服務端（網站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數據的密碼信息。TLS/SSL協議不僅僅是一套加密傳輸的協議，更是一件經過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱加密，對稱加密以及HASH演算法。握手過程的具體描述如下：
1.瀏覽器將自己支持的一套加密規則發送給網站。
2.網站從中選出一組加密演算法與HASH演算法，並將自己的身份信息以證書的形式發回給瀏覽器。證書裡麵包含了網站地址，加密公鑰，以及證書的頒發機構等信息。
3.瀏覽器獲得網站證書之後瀏覽器要做以下工作：
a) 驗證證書的合法性（頒發證書的機構是否合法，證書中包含的網站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄裡面會顯示一個小鎖頭，否則會給出證書不受信的提示。
b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數的密碼，並用證書中提供的公鑰加密。
c) 使用約定好的HASH演算法計算握手消息，並使用生成的隨機數對消息進行加密，最後將之前生成的所有信息發送給網站。
4.網站接收瀏覽器發來的數據之後要做以下的操作：
a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發來的握手消息，並驗證HASH是否與瀏覽器發來的一致。
b) 使用密碼加密一段握手消息，發送給瀏覽器。
5.瀏覽器解密並計算握手消息的HASH，如果與服務端發來的HASH一致，此時握手過程結束，之後所有的通信數據將由之前瀏覽器生成的隨機密碼並利用對稱加密演算法進行加密。
這里瀏覽器與網站互相發送加密的握手消息並驗證，目的是為了保證雙方都獲得了一致的密碼，並且可以正常的加密解密數據，為後續真正數據的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH演算法如下：
非對稱加密演算法：RSA，DSA/DSS
對稱加密演算法：AES，RC4，3DES
HASH演算法：MD5，SHA1，SHA256

❷ https交互過程

https的交互過程如下：
1、客戶端將它所支持的老並演算法列表和一個用作產生密鑰的隨機數發送給伺服器。
2、伺服器從演算法列表中選擇一種加密演算法，並將它和一份包含伺服器公用密鑰的證書發送給客戶端;該證書還包含了用於認證目的的伺服器標識，伺服器同時還提供了一個用作產生密鑰的隨機數。
3、客戶端對伺服器的證書進行驗證，並抽取伺服器的公用密鑰;然後，再產生一個稱作pre_master_secret的隨機密碼串，並使用伺服器的公用密鑰對其進行加密(參考非對稱加/解密)，並將加密後的信息發送給伺服器;
4、客戶端與伺服器端根據pre_master_secret以及客戶端與伺服器的隨機數值獨立計算出加密和MAC密鑰知含晌搭鋒;
5、客戶端將所有握手消息的MAC值發送給伺服器;
6、伺服器將所有握手消息的MAC值發送給客戶端。

❸ HTTPS 加密演算法過程

1、HTTP 協議（HyperText Transfer Protocol，超文本傳輸協議）：是客戶端瀏覽器或其他程序與Web伺服器之間的應用層通信協議 。

2、HTTPS 協議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL，用於安全的 HTTP 數據傳輸。

3、SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各種應用層協議之間，為數據通訊提供安全支持。

4、TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）。

如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS。

1、對稱加密

有流式、分組兩種，加密和解密都是使用的同一個密鑰。

例如：DES、AES-GCM、ChaCha20-Poly1305等

2、非對稱加密

加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法性能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的數據長度也是有限的。

例如：RSA、DSA、ECDSA、 DH、ECDHE

3、哈希演算法

將任意長度的信息轉換為較短的固定長度的值，通常其長度要比信息小得多，且演算法不可逆。

例如：MD5、SHA-1、SHA-2、SHA-256 等

4、數字簽名

簽名就是在信息的後面再加上一段內容（信息經過hash後的值），可以證明信息沒有被修改過。hash值一般都會加密後（也就是簽名）再和信息一起發送，以保證這個hash值不被修改。

C++音視頻開發學習資料 ：點擊 音視頻開發（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）

HTTP協議在瀏覽器/伺服器間進行數據的傳輸是明文的，不做任何的加密，通俗來說，就是「裸奔」，這樣會產生什麼樣的問題那，我們來舉一個例子：

在這里插入圖片描述

上述我們通過兩個人物模仿了伺服器和客戶端的交互，我們可以看出，小明和小花之間進行數據通信的時候採用的是明文傳輸的、那麼此時很有可能被中間人獲取信息、並進行數據篡改，這種行為就叫 中間人攻擊。

所以 HTTP 傳輸面臨的風險有：

（1） 竊聽風險：黑客可以獲知通信內容。

（2） 篡改風險：黑客可以修改通信內容。

（3） 冒充風險：黑客可以冒充他人身份參與通信。

哈哈、此時你是不是不能很愉快的上網沖浪了呀，別擔心，我們此時可以對明文進行加密：

這樣是不是比原來安全多了呀！但是這樣就足夠安全了嗎？顯然不是的，如果小明和小花在第一次聊天的時候，信息被中間人截取到了，那麼中間人是不是也就有密鑰了，同樣可以對數據進行加解密和修改了那

這可怎麼辦那？ 加密的數據還是不安全的啊？ 別急，上面我們採用的是對稱加密（換句話說就是我們發送的密鑰技能加密、也能解密，那麼中間人只要拿到密鑰消息對他而言就是透明的了），我們還可以採用非對稱加密方式進行加密數據(非對稱加密一般都會有一個私鑰和公鑰組成。可以通過公鑰加密，私鑰解密，也可以通過私鑰加密，公鑰解密兩種方式) ，對密鑰的傳送在格外加一層保護，當小明和小花在建立通信的時候，小花會把公鑰KEY發送給小明，當小明拿到公鑰KEY 後，會自己生成一個 密鑰 KEY2 , 並用 KEY 對KEY2 進行加密（此時小明用的是公鑰加密）

在通信過程中，即使中間人一開始就獲取到了公鑰KEY ,但是他不知道私鑰，就對數據無法進行解密，仍舊是沒辦法獲取KEY2。這樣加密後，數據是不是就安全多了呀。這種情況下就可以和妹子愉快的進行聊天了嗎？別急、所謂道高一尺魔高一丈，常言道：流氓不可怕，就怕流氓有文化。這種狀態下我們的數據，相當來說是比較安全的，但是如果此時中間人獲取公鑰後，發送給小明一個偽公鑰，又會產生什麼問題那？

好吧，說到這里，大家是不是快恨死這個中間人了啊，哈哈~~~還有據俗話別忘記了，魔高一尺道高一丈，對於這種情況。我們可以藉助與第三方證書平台，證書平台具備產生證書的功能，伺服器（小花）可以去證書機構申請證書，證書機構通過小花提供的信息（網址、機構、法人等、公鑰），生成公鑰和私鑰（證書機構的），通過私鑰進行數據的非對稱加密生成證書、將證書頒發給小花。那麼此時小花就可以在進行數據交互的時候，傳遞證書了。

小明只需要知道證書的發證機構、就可以很方便的獲取到證書的公鑰、從而對證書進行校驗並獲取公鑰、然後進行後續的操作。

那麼此時小夥伴是不是又有疑問了，如果 中間人 獲取到證書、並偽造證書給小明、怎麼破？？？

不錯不錯、如果大家有這個想法的話，說明大家都在認真思考了。那麼我們假設中間人獲取到了證書、中間人也可以在證書機構獲取公鑰，並通過證書機構公鑰獲取 伺服器發送的公鑰，中間人此時也可以自己生成公鑰，並向證書機構申請證書、並發送偽證書給小明，但是因為證書是經過簽名認證的，包含（網址、機構、法人等、公鑰）等信息，小明在拿到偽證書後，通過證書公鑰很容易就發現證書是不合法的(網址、法人的信息可定不符，否則申請不到證書的)。

上述我們分享的內容就是HTTPS的主體思想，HTTPS增加了SSL安全層，上述介紹的所有認證流程都是在SSL安全層完成驗證的。今天我就分享HTTPS的實現原理就說這么多了。 ﹏

HTTPS 缺點：

（1）SSL 證書費用很高，以及其在伺服器上的部署、更新維護非常繁瑣。

（2）HTTPS 降低用戶訪問速度（多次握手）。

（3）網站改用HTTPS 以後，由HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時（多數網站採用302跳轉）。

（4）HTTPS 涉及到的安全演算法會消耗 CPU 資源，需要增加大量機器（https訪問過程需要加解密）。

❹ https傳輸過程

HTTPS傳輸過程主要涉及到對稱加密和非對稱加密兩種方式，對稱加密用來加密數據內容，非對稱加密用來加密對稱加密的秘鑰。

加密和解密使用相同的密鑰

使用公鑰進行加密，私鑰進行解密；私鑰加密的話就使用公鑰解密

A向B發送消息 使用B的公鑰進行加密 B收到密文後使用自己的私鑰進行解密 反之亦然

https協議採用的就是這種加密方式

為了解決在對稱加密/非對稱加密中公鑰被竊取的情況。

A先生成一個對話密鑰，然後把對話密鑰發送給B。但是這個對話密鑰要經過B的公鑰進行加密，B收到後用自己的私鑰進行解密。這樣就解決了對稱加密時公鑰容易被截取的缺陷。

實際上就是對稱加密的密鑰進行非對稱加密

B的公鑰是在最開始連接建立的時候發送給A的。假如這個時候有一個中間人截取了B的公鑰，然後將自己的公鑰發送給A。A在給B發送消息時，想用B的公鑰進行加密。但實際上用的是中間人的公鑰。中間人截取了A給B發送的消息，然後用自己的私鑰解密。就可以隨意讀取消息的內容。
此外，中間人也可以使用B的公鑰來加密一些消息傳輸給B，讓B以為中間人就是A

用於防止中間人攻擊

數字證書是由專業的機構頒發的CA（Certificate Authority）機構

CA機構通過服務端提供的相關信息生成證書，證書的主要內容有：公鑰（Public Key）、ISSUER（證書的發布機構）、Subject（證書持有者）、證書有效期、簽名演算法、指紋及指紋演算法。

數字證書是如何保證公鑰來自請求的伺服器呢？數字證書上由持有人的相關信息，通過這點可以確定其不是一個中間人；但是證書也是可以偽造的，如何保證證書為真呢？

瀏覽器接收到證書以後，就要開始進行驗證工作了。首先從證書中得知證書的頒發機構，然後從瀏覽器系統中去尋找此頒發機構的根證書。上面我們也看到，世界上權威CA機構的根證書都是預先嵌入到瀏覽器中的，如果在瀏覽器系中沒有找到對應的根證書，就代表此機構不是受信任的，那麼就會警告無法確認證書的真假，比如以前打開12360網站就會提示，現在不會了

如果我們找到了證書頒發機構的根證書，那麼就從根證書中取得那個根公鑰，用根公鑰去解密此證書的數字簽名，成功解密的話就得到證書的指紋和指紋演算法，指紋是證書內容通過指紋演算法計算得到的一個hash值，這里我們稱之為h1，h1代表證書的原始內容；然後用指紋演算法對當前接收到的證書內容再進行一次hash計算得到另一個值h2，h2則代表當前證書的內容，如果此時h1和h2是相等的，就代表證書沒有被修改過。如果證書被篡改過，h2和h1是不可能相同的，因為hash值具有唯一性，不同內容通過hash計算得到的值是不可能相同的

有人說假如證書上的指紋是不法分子偽造的，偽造是沒有用的，因為你偽造的指紋不可能用CA機構的根私鑰去加密（根私鑰是CA機構絕對保密的），偽造者只能拿自己的秘鑰去加密這個偽造的指紋，但當我們拿機構的根公鑰去解密偽造指紋的時候是不可能成功的（加密內容只能由一對公鑰私鑰解密）

在證書沒有被修改過的基礎上，再檢查證書上的使用者的URL（比如csdn.net）和我們請求的URL是否相等，如果相等，那麼就可以證明當前瀏覽器鏈接的網址也是正確的，而不是一些釣魚網之類的

但如果瀏覽器的連接被某個中間人截取了，中間人也可以發一個由權威的CA機構頒發的證書給瀏覽器，然後也可以通過證書沒有被篡改的驗證，但是在證書沒有被篡改的前提下，通過對比證書上的URL和我們請求的URL是否相同，我們還是可以判斷當前證書是不是伺服器發的證書。可以這么理解，因為URL具有唯一性，所以中間人的證書的上的URL和我們的證書的URL是不可能相同的，如果中間人修改了自己證書上的URL，那麼就通過不了證書沒有被篡改的驗證，所以中間人的證書也是欺騙不了我們的

到這里我們認證了三點信息：

https就是在http和tcp之間加入了一層SSL層。https的安全基礎就是ssl。

https協議就是由http+ssl組成的可以進行加密傳輸和身份認證的網路協議。https的作用：

所以在證書驗證階段使用的是非對稱加密（即生成會話密鑰的階段），在內容傳輸的時候還是對稱加密

握手階段我們需要注意三點：

從上面可以得知，整個會話過程中（包括握手以及之後的數據傳輸）伺服器的公鑰和私鑰只用到了一次

❺ 網站如何添加https：//加密認證教程

網站想實現https加密訪問，必須申請部署SSL證書。SSL證書的申請流程如下：

第一步，生成並提交CSR（證書簽署請求）文件

CSR文件一般都可以通過在線生成（或伺服器上生成），申請人在製作的同時系統會產生兩個秘鑰，公鑰CSR和密鑰KEY。選擇了SSL證書申請之後，提交訂單並將製作生成的CSR文件一起提交到證書所在的CA頒發機構。

第二步，CA機構進行驗證

CA機構對提交的SSL證書申請有兩種驗證方式：

第一種是域名認證。系統自動會發送驗證郵件到域名的管理員郵箱（這個郵箱是通過WHOIS信息查詢到的域名聯系人郵箱）。管理員在收到郵件之後，確認無誤後點擊我確認完成郵件驗證。所有型號的SSL證書都必須進行域名認證。

第二種是企業相關信息認證。對於SSL證書申請的是OV SSL證書或者EV SSL證書的企業來說，除了域名認證，還得進行人工核實企業相關資料和信息，確保企業的真實性。

第三步，CA機構頒發證書

由於SSL證書申請的型號不同，所驗證的材料和方式有些區別，所以頒發時間也是不同的。

如果申請的是DV SSL證書最快10分鍾左右就能頒發。如果申請的是OV SSL證書或者EV SSL證書，一般3-7個工作日就能頒發。
等SSL證書頒發之後，將其正確部署到伺服器上就可以實現https加密訪問了。

❻ https是如何加密的

HTTPS其實是有兩部分組成：HTTP + SSL / TLS，也就是在HTTP上又加了一層處理加密信息的模塊。服務端和客戶端的信息傳輸都會通過TLS進行加密，所以傳輸的數據都是加密後的數據。具體是如何進行加密，解密，驗證的，且看下圖。

1. 客戶端發起HTTPS請求

這個沒什麼好說的，就是用戶在瀏覽器里輸入一個https網址，然後連接到server的443埠。

2. 服務端的配置

採用HTTPS協議的伺服器必須要有一套數字證書，可以自己製作，也可以向組織申請。區別就是自己頒發的證書需要客戶端驗證通過，才可以繼續訪問，而使用受信任的公司申請的證書則不會彈出提示頁面(startssl就是個不錯的選擇，有1年的免費服務)。這套證書其實就是一對公鑰和私鑰。如果對公鑰和私鑰不太理解，可以想像成一把鑰匙和一個鎖頭，只是全世界只有你一個人有這把鑰匙，你可以把鎖頭給別人，別人可以用這個鎖把重要的東西鎖起來，然後發給你，因為只有你一個人有這把鑰匙，所以只有你才能看到被這把鎖鎖起來的東西。

3. 傳送證書

這個證書其實就是公鑰，只是包含了很多信息，如證書的頒發機構，過期時間等等。

4. 客戶端解析證書

這部分工作是有客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發機構，過期時間等等，如果發現異常，則會彈出一個警告框，提示證書存在問題。如果證書沒有問題，那麼就生成一個隨機值。然後用證書對該隨機值進行加密。就好像上面說的，把隨機值用鎖頭鎖起來，這樣除非有鑰匙，不然看不到被鎖住的內容。

5. 傳送加密信息

這部分傳送的是用證書加密後的隨機值，目的就是讓服務端得到這個隨機值，以後客戶端和服務端的通信就可以通過這個隨機值來進行加密解密了。

6. 服務段解密信息

服務端用私鑰解密後，得到了客戶端傳過來的隨機值(私鑰)，然後把內容通過該值進行對稱加密。所謂對稱加密就是，將信息和私鑰通過某種演算法混合在一起，這樣除非知道私鑰，不然無法獲取內容，而正好客戶端和服務端都知道這個私鑰，所以只要加密演算法夠彪悍，私鑰夠復雜，數據就夠安全。

7. 傳輸加密後的信息

這部分信息是服務段用私鑰加密後的信息，可以在客戶端被還原。

8. 客戶端解密信息

客戶端用之前生成的私鑰解密服務段傳過來的信息，於是獲取了解密後的內容。整個過程第三方即使監聽到了數據，也束手無策。

❼ 基於國密演算法SM2 SSL證書的https加密, 如何實現

SSL握手協議的過程
國密SSL握手協議過程如下：
(1)交換Hello消息來協商密碼套件，交換隨機數，決定是否會話重用；
(2)交換必要的參數，協商預主密鑰
(3)交換證書信息，用於驗證對方
(4)使用預主密鑰和交換的隨機數生成主密鑰
(5)向記錄層提供安全參數
(6)驗證雙方計算的安全參數的一致性、握手過程的真實性和完整性