參考鏈接：

HTTP 與 HTTPS 的區(qū)別

HTTPS科普掃盲帖

HTTPS小結

HTTP 和 HTTPS 區(qū)別

• HTTP是明文傳輸未加密，安全性差，HTTPS（HTTP + SSL）數(shù)據(jù)傳輸是加密的，安全性較好

• HTTPS協(xié)議需要到CS申請——收費

• HTTP頁面響應速度比HTTPS快，主要是因為 HTTP 使用 TCP 三次握手建立連接，客戶端和服務器需要交換 3 個包，而 HTTPS除了 TCP 的三個包，還要加上 ssl 握手需要的 9 個包，所以一共是 12 個包。

• 默認端口不同

• HTTPS 其實就是建構在 SSL/TLS 之上的 HTTP 協(xié)議，所以，要比較 HTTPS 比 HTTP 要更耗費服務器資源。

HTTPS基礎

HTTPS = HTTP + 加密 + 認證 + 完整性保護

HTTPS 經(jīng)由 HTTP 進行通信，但是利用SSL/TLS來進行加密數(shù)據(jù)包。

SSL 提供 加密處理 和 認證 以及 摘要功能

HTTPS開發(fā)的主要目的，是提供對網(wǎng)站服務器的身份認證，保護交換數(shù)據(jù)的隱私與完整性。

一般，HTTP是與TCP直接通信，現(xiàn)在使用SSL，HTTP先與SSL通信，SSL和TCP通信。

SSL 和 TLS

通俗的講，TLS、SSL其實是類似的東西，SSL是個加密套件，負責對HTTP的數(shù)據(jù)進行加密。TLS是SSL的升級版。現(xiàn)在提到HTTPS，加密套件基本指的是TLS。

SSL 是獨立于 HTTP 的協(xié)議， 所以不光是 HTTP 協(xié)議， 其他運行在應用層的 SMTP和 Telnet 等協(xié)議均可配合 SSL 協(xié)議使用。

傳輸流程：原先是應用層將數(shù)據(jù)直接給到TCP進行傳輸，現(xiàn)在改成應用層將數(shù)據(jù)給到TLS/SSL，將數(shù)據(jù)加密后，再給到TCP進行傳輸。如圖：

HTTPS 的工作原理

HTTPS 默認工作在 TCP 協(xié)議443端口，它的工作流程一般如以下方式：

客戶端發(fā)起 HTTPS 請求 ——TCP 三次握手之后（傳輸層上的TCP和UDP（三次握手））

服務端的配置 ，客戶端驗證服務器數(shù)字證書（這套證書其實就是一對公鑰和私鑰 ）

傳送證書，這個證書就是公鑰，其中包含了證書的頒布機構，過期時間等

客戶端解析證書，這個部分的工作是客戶端的TLS來完成的，首先會驗證公鑰是否有效，比如頒發(fā)機構，過期時間等，如果發(fā)現(xiàn)異常，則會彈出一個警告框，提示證書存在問題。

如果證書沒有問題，那么就生成一個隨機值，然后用證書對改隨機值進行加密

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

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

傳輸加密后的信息，這部分信息是服務器端用私鑰加密后的信息，可以在客戶端還原。

客戶端解密信息，客戶端用之前生成的私鑰解密服務端傳過來的信息，于是獲取了解密后的內容，整個過程第三方即使監(jiān)聽到了數(shù)據(jù)，也束手無策。

?

HTTPS如何加密數(shù)據(jù)（看不懂）

加密分為：對稱加密和非對稱加密

對稱加密

流程：客戶端和服務器端進行一次私密對話：

1.每次對話時，服務器端都要給客戶端一個秘鑰

2.客戶端把數(shù)據(jù)加密以后，發(fā)送給服務器端

3.服務器端使用秘鑰解密接收到的數(shù)據(jù)

優(yōu)點：效率高

缺點：不夠安全，萬一黑客把秘鑰和密文截取了，他就可以解密這段數(shù)據(jù)了

非對稱加密

流程：客戶端和服務器端進行一次私密對話：

1.服務器端要給客戶端一個公鑰（全世界都知道），服務器端保留這個服務器對應的的私鑰

2.客戶端用公鑰把數(shù)據(jù)加密以后，發(fā)送給服務器端

3.服務器端使用對應的的私鑰解密接收到的數(shù)據(jù)

優(yōu)點：效率低

缺點：不夠安全，萬一黑客把密文截取了（公鑰早就知道了），他就可以解密這段數(shù)據(jù)了

?

HTTPS 采用共享密鑰加密和公開密鑰加密兩者并用的混合加密機制。 若密鑰能夠實現(xiàn)安全交換， 那么有可能會考慮僅使用公開密鑰加密來通信。 但是公開密鑰加密與共享密鑰加密相比， 其處理速度要慢。所以應充分利用兩者各自的優(yōu)勢， 將多種方法組合起來用于通信。 在交換密鑰環(huán)節(jié)使用公開密鑰加密方式， 之后的建立通信交換報文階段則使用共享密鑰加密方式。

?

另一種解釋（一人一種理解? -.-'）：

HTTPS在傳輸數(shù)據(jù)之前需要客戶端（瀏覽器）與服務端（網(wǎng)站）之間進行一次握手，在握手過程中將確立雙方加密傳輸數(shù)據(jù)的密碼信息。TLS/SSL協(xié)議不僅僅是一套加密傳輸?shù)膮f(xié)議，更是一件經(jīng)過藝術家精心設計的藝術品，TLS/SSL中使用了非對稱加密，對稱加密以及HASH算法。握手過程的簡單描述如下：
1.瀏覽器將自己支持的一套加密規(guī)則發(fā)送給網(wǎng)站。
2.網(wǎng)站從中選出一組加密算法與HASH算法，并將自己的身份信息以證書的形式發(fā)回給瀏覽器。證書里面包含了網(wǎng)站地址，加密公鑰，以及證書的頒發(fā)機構等信息。
3.獲得網(wǎng)站證書之后瀏覽器要做以下工作：

a) 驗證證書的合法性（頒發(fā)證書的機構是否合法，證書中包含的網(wǎng)站地址是否與正在訪問的地址一致等），如果證書受信任，則瀏覽器欄里面會顯示一個小鎖頭，否則會給出證書不受信的提示。

b) 如果證書受信任，或者是用戶接受了不受信的證書，瀏覽器會生成一串隨機數(shù)的密碼，并用證書中提供的公鑰加密。

c) 使用約定好的HASH計算握手消息，并使用生成的隨機數(shù)對消息進行加密，最后將之前生成的所有信息發(fā)送給網(wǎng)站。
4.網(wǎng)站接收瀏覽器發(fā)來的數(shù)據(jù)之后要做以下的操作：

a) 使用自己的私鑰將信息解密取出密碼，使用密碼解密瀏覽器發(fā)來的握手消息，并驗證HASH是否與瀏覽器發(fā)來的一致。

b) 使用密碼加密一段握手消息，發(fā)送給瀏覽器。
5.瀏覽器解密并計算握手消息的HASH，如果與服務端發(fā)來的HASH一致，此時握手過程結束，之后所有的通信數(shù)據(jù)將由之前瀏覽器生成的隨機密碼并利用對稱加密算法進行加密。
這里瀏覽器與網(wǎng)站互相發(fā)送加密的握手消息并驗證，目的是為了保證雙方都獲得了一致的密碼，并且可以正常的加密解密數(shù)據(jù)，為后續(xù)真正數(shù)據(jù)的傳輸做一次測試。另外，HTTPS一般使用的加密與HASH算法如下：
非對稱加密算法：RSA，DSA/DSS
對稱加密算法：AES，RC4，3DES
HASH算法：MD5，SHA1，SHA256
其中非對稱加密算法用于在握手過程中加密生成的密碼，對稱加密算法用于對真正傳輸?shù)臄?shù)據(jù)進行加密，而HASH算法用于驗證數(shù)據(jù)的完整性。由于瀏覽器生成的密碼是整個數(shù)據(jù)加密的關鍵，因此在傳輸?shù)臅r候使用了非對稱加密算法對其加密。非對稱加密算法會生成公鑰和私鑰，公鑰只能用于加密數(shù)據(jù)，因此可以隨意傳輸，而網(wǎng)站的私鑰用于對數(shù)據(jù)進行解密，所以網(wǎng)站都會非常小心的保管自己的私鑰，防止泄漏。

HTTPS 的安全通信機制/SSL過程（看不懂）

步驟 1： 客戶端通過發(fā)送 Client Hello 報文開始 SSL 通信。 報文中包含客戶端支持的 SSL 的指定版本、 加密組件（ Cipher Suite） 列表（ 所使用的加密算法及密鑰長度等） 。步驟 2： 服務器可進行 SSL 通信時， 會以 Server Hello 報文作為應答。 和客戶端一樣， 在報文中包含 SSL 版本以及加密組件。 服務器的加密組件內容是從接收到的客戶端加密組件內篩選出來的。

步驟 3： 之后服務器發(fā)送 Certificate 報文。 報文中包含公開密鑰證書。

步驟 4： 最后服務器發(fā)送 Server Hello Done 報文通知客戶端， 最初階段的 SSL 握手協(xié)商部分結束。

步驟 5： SSL 第一次握手結束之后， 客戶端以 Client KeyExchange 報文作為回應。報文中包含通信加密中使用的一種被稱為 Pre-master secret 的隨機密碼串。 該報文已用步驟 3 中的公開密鑰進行加密。

步驟 6： 接著客戶端繼續(xù)發(fā)送 Change Cipher Spec 報文。 該報文會提示服務器， 在此報文之后的通信會采用 Pre-master secret 密鑰加密。

步驟 7： 客戶端發(fā)送 Finished 報文。 該報文包含連接至今全部報文的整體校驗值。這次握手協(xié)商是否能夠成功， 要以服務器是否能夠正確解密該報文作為判定標準。

步驟 8： 服務器同樣發(fā)送 Change Cipher Spec 報文。

步驟 9： 服務器同樣發(fā)送 Finished 報文。

步驟 10： 服務器和客戶端的 Finished 報文交換完畢之后， SSL 連接就算建立完成。當然， 通信會受到 SSL 的保護。 從此處開始進行應用層協(xié)議的通信， 即發(fā)送 HTTP請求。

步驟 11： 應用層協(xié)議通信， 即發(fā)送 HTTP 響應。

步驟 12： 最后由客戶端斷開連接。 斷開連接時， 發(fā)送 close_notify。這步之后再發(fā)送 TCP FIN 報文來關閉與 TCP 的通信。

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

轉載于:https://www.cnblogs.com/houfee/p/9816994.html

總結

以上是生活随笔為你收集整理的HTTPS（身披SSL协议的HTTP）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內容還不錯，歡迎將生活随笔推薦給好友。