From:?掃盲 HTTPS 和 SSL/TLS 協議[0]：引子

需要了解的背景知識：

• 術語 HTTPS,SSL,TLS
• 長連接與短連接的關系
• 了解 CA 證書
• 基本流程

一.術語掃盲

1.什么是SSL？

SSL(Secure Sockets Layer, 安全套接字)，因為原先互聯網上使用的 HTTP 協議是明文的，存在很多缺點——比如傳輸內容會被偷窺（嗅探）和篡改。發明 SSL 協議，就是為了解決這些問題。

2.那么什么是TLS呢？

到了1999年，SSL 因為應用廣泛，已經成為互聯網上的事實標準。IETF 就在那年把 SSL 標準化。標準化之后的名稱改為 TLS（是“Transport Layer Security”的縮寫），中文叫做“傳輸層安全協議”。

很多相關的文章都把這兩者并列稱呼（SSL/TLS），因為這兩者可以視作同一個東西的不同階段。

3.那么什么是HTTPS呢？

HTTPS = HTTP + SSL/TLS, 也就是 HTTP over SSL 或 HTTP over TLS.這是后面加?S?的由來?

相對于HTTP:

• http和https使用的是完全不同的連接方式，用的端口也不一樣，前者是80，后者是443。
• http的連接很簡單，是無狀態的；HTTPS協議是由SSL+HTTP協議構建的可進行加密傳輸、身份認證的網絡協議，比http協議安全。

二.長連接VS短連接

HTTP對TCP的連接使用分為：

• 短連接
• 長連接(又稱“持久連接”，或“Keep-Alive”或“Persistent Connection”)

如果是短連接的話，針對每個HTML資源，就會針對每一個外部資源，分別發起一個個 TCP 連接。相反，如果是“長連接”的方式，瀏覽器也會先發起一個 TCP 連接去抓取頁面。但是抓取頁面之后，該 TCP 連接并不會立即關閉，而是暫時先保持著（所謂的“Keep-Alive”）。然后瀏覽器分析 HTML 源碼之后，發現有很多外部資源，就用剛才那個 TCP 連接去抓取此頁面的外部資源。

注意：

• 在 HTTP 1.0 版本，【默認】使用的是“短連接”（那時候是 Web 誕生初期，網頁相對簡單，“短連接”的問題不大）
• 在 HTTP 1.1 中，【默認】采用的是“Keep-Alive”的方式。

三.HTTPS的設計

HTTPS的設計要兼容HTTP

• HTTPS 還是要基于 TCP 來傳輸
• 單獨使用一個新的協議，把 HTTP 協議包裹起來（所謂的“HTTP over SSL”，實際上是在原有的 HTTP 數據外面加了一層 SSL 的封裝。HTTP 協議原有的 GET、POST 之類的機制，基本上原封不動）

關于HTTPS的性能，為了確保性能，SSL 的設計者至少要考慮如下幾點：

• 如何選擇加密算法（“對稱”or“非對稱”）？
• 如何兼顧 HTTP 采用的“短連接”TCP 方式？

四.簡單運行過程

SSL/TLS協議的基本思路是采用公鑰加密法，也就是說，客戶端先向服務器端索要公鑰，然后用公鑰加密信息，服務器收到密文后，用自己的私鑰解密。

問題：

• 如何保證公鑰不被篡改？:解決方法：將公鑰放在數字證書中。只要證書是可信的，公鑰就是可信的。
• 公鑰加密計算量太大，如何減少耗用的時間？解決方法：每一次對話（session），客戶端和服務器端都生成一個”對話密鑰”（session key），用它來加密信息。由于”對話密鑰”是對稱加密，所以運算速度非常快，而服務器公鑰只用于加密”對話密鑰”本身，這樣就減少了加密運算的消耗時間。

因此，SSL/TLS協議的基本過程是這樣的：

• 客戶端向服務器端索要并驗證公鑰。
• 雙方協商生成”對話密鑰”。
• 雙方采用”對話密鑰”進行加密通信。

如下圖解:

五.詳解運行過程

如下圖示：

注意的是，”握手階段”的所有通信都是明文的

1.客戶端發出請求（ClientHello）

C向S提供信息如下：

• 支持的協議版本，比如TLS 1.0版。
• 一個客戶端生成的隨機數，稍后用于生成”對話密鑰”。
• 支持的加密方法，比如RSA公鑰加密。
• 支持的壓縮方法。

2.服務器回應（SeverHello）

服務器收到客戶端請求后，向客戶端發出回應，這叫做SeverHello。服務器的回應包含以下內容。

• 確認使用的加密通信協議版本，比如TLS 1.0版本。如果瀏覽器與服務器支持的版本不一致，服務器關閉加密通信。
• 一個服務器生成的隨機數，稍后用于生成”對話密鑰”。
• 確認使用的加密方法，比如RSA公鑰加密。
• 服務器證書。

除了上面這些信息，如果服務器需要確認客戶端的身份，就會再包含一項請求，要求客戶端提供”客戶端證書”。

3.客戶端回應

客戶端收到服務器回應以后，首先驗證服務器證書。如果證書不是可信機構頒布、或者證書中的域名與實際域名不一致、或者證書已經過期，就會向訪問者顯示一個警告，由其選擇是否還要繼續通信。

如果證書沒有問題，客戶端就會從證書中取出服務器的公鑰。然后，向服務器發送下面三項信息。

• 一個隨機數。該隨機數用服務器公鑰加密，防止被竊聽。
• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 客戶端握手結束通知，表示客戶端的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供服務器校驗。

現在總共有3個隨機數，第三個又稱”pre-master key”，有了它以后，客戶端和服務器就同時有了三個隨機數，接著雙方就用事先商定的加密方法，各自 生成 本次會話 所用的 同一把 “會話密鑰”。

4.服務器的最后回應

服務器收到客戶端的第三個隨機數pre-master key之后，計算生成本次會話所用的”會話密鑰”。然后，向客戶端最后發送下面信息。

• 編碼改變通知，表示隨后的信息都將用雙方商定的加密方法和密鑰發送。
• 服務器握手結束通知，表示服務器的握手階段已經結束。這一項同時也是前面發送的所有內容的hash值，用來供客戶端校驗。

至此，整個握手階段全部結束。接下來，客戶端與服務器進入加密通信，就完全是使用普通的HTTP協議，只不過用”會話密鑰”加密內容。

六.Https的劣勢

不完整總結如下：

• 對數據進行加解密決定了它比http慢
• https協議需要到CA申請證書。

七.Python操作SSL

首先創建證書

openssl req -new -x509 -days 365 -nodes -out cert.pem -keyout key.pem

實例代碼在：?ssl_demo

八.參考：

• 聊聊HTTPS和SSL/TLS協議
• 圖解HTTPS
• SSL/TLS協議運行機制的概述

轉載于:https://www.cnblogs.com/xiaoerlang/p/7783635.html

總結

以上是生活随笔為你收集整理的TLS,SSL,HTTPS with Python（转）的全部內容，希望文章能夠幫你解決所遇到的問題。

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