TLS,SSL,HTTPS with Python（轉）

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協議運行機制的概述