HTTPS 是最常見的 HTTP 安全版本。它得到了很廣泛的應用，所有主要的商業瀏覽器和服務器上都提供 HTTPS。HTTPS 將 HTTP 協議與一組強大的對稱、非對稱和基於證書的加密技術結合在一起，使得 HTTPS 不僅很安全，而且很靈活，很容易在處於無序狀態的、分散的全球互聯網上進行管理
HTTPS 加速了因特網應用程序的成長，已經成爲基於 Web 的電子商務快速成長的主要推動力。在廣域網中對分佈式 Web 應用程序的安全管理方面，HTTPS 也是非常重要的
HTTPS 總體步驟 （來自ChatGPT的介紹）
HTTPS的具體過程可以分爲以下幾個步驟：
客戶端向服務器發送連接請求。
服務器將自己的公鑰和數字證書返回給客戶端。
客戶端驗證服務器的證書是否合法，如果證書驗證通過，客戶端會生成一個隨機的對稱加密密鑰，並使用服務器公鑰進行加密，然後將加密後的密鑰發送給服務器。
服務器使用自己的私鑰進行解密，得到客戶端生成的對稱加密密鑰。
客戶端和服務器使用對稱加密密鑰對後續的數據進行加密和解密。
客戶端向服務器發送加密後的請求數據。
服務器接收到請求數據後，使用對稱加密密鑰進行解密，然後對請求進行處理，並將處理後的數據加密後返回給客戶端。
客戶端接收到服務器返回的加密數據，使用對稱加密密鑰進行解密，然後進行處理。
在HTTPS中，握手階段使用不對稱加密算法進行通信，協商出對稱加密所需要的密鑰，通信階段使用協商好的對稱加密算法進行通信，以保證通信的機密性和完整性。同時，數字證書可以用於驗證服務器的身份，避免中間人攻擊等安全問題。
HTTPS 概述
HTTPS 就是在安全的傳輸層上發送的 HTTP。HTTPS 沒有將未加密的 HTTP 報文發送給 TCP，並通過世界範圍內的因特網進行傳輸，它在將 HTTP 報文發送給 TCP 之前，先將其發送給了一個安全層，對其進行加密
現在，HTTP 安全層是通過 SSL 及其現代替代協議 TLS 來實現的。我們遵循常見的用法，用術語 SSL 來表示 SSL 或者 TLS
HTTPS 方案
現在，安全 HTTP 是可選的。因此，對 Web 服務器發起請求時，我們需要有一種方式來告知 Web 服務器去執行 HTTP 的安全協議版本。這是在 URL 的方案中實現的。通常情況下，非安全 HTTP 的 URL 方案前綴爲 http，如下所示：
在安全 HTTPS 協議中，URL 的方案前綴爲 https，如下所示：
請求一個客戶端（比如 Web 瀏覽器）對某 Web 資源執行某事務時，它會去檢查 URL 的方案
- 如果 URL 的方案爲 http，客戶端就會打開一條到服務器端口 80（默認情況下）
的連接，並向其發送老的 HTTP 命令 - 如果 URL 的方案爲 https，客戶端就會打開一條到服務器端口 443（默認情況下）
的連接，然後與服務器“握手”，以二進制格式與服務器交換一些 SSL 安全參數，
附上加密的 HTTP 命令
SSL 是個二進制協議，與 HTTP 完全不同，其流量是承載在另一個端口上的（SSL 通常是由端口 443 承載的）。如果 SSL 和 HTTP 流量都從端口 80 到達，大部分 Web 服務器會將二進制 SSL 流量理解爲錯誤的 HTTP 並關閉連接。將安全服務進一步整合到 HTTP 層中去就無需使用多個目的端口了，在實際中這樣不會引發嚴重的問題
建立安全傳輸
在未加密 HTTP 中，客戶端會打開一條到 Web 服務器端口 80 的 TCP 連接，發送一條請求報文，接收一條響應報文，關閉連接
由於 SSL 安全層的存在，HTTPS 中這個過程會略微複雜一些。在 HTTPS 中，客戶端首先打開一條到 Web 服務器端口 443（安全 HTTP 的默認端口）的連接。一旦建立了 TCP 連接，客戶端和服務器就會初始化 SSL 層，對加密參數進行溝通，並交換密鑰。握手完成之後，SSL 初始化就完成了，客戶端就可以將請求報文發送給安全層了。在將這些報文發送給 TCP 之前，要先對其進行加密
SSL 握手
在發送已加密的 HTTP 報文之前，客戶端和服務器要進行一次 SSL 握手，在這個握手過程中，它們要完成以下工作
- 交換協議版本號
- 選擇一個兩端都瞭解的密碼
- 對兩端的身份進行認證
- 生成臨時的會話密鑰，以便加密信道
在通過網絡傳輸任何已加密的 HTTP 數據之前，SSL 已經發送了一組握手數據來建立通信連接了
這是 SSL 握手的簡化版本。根據 SSL 的使用方式，握手過程可能會複雜一些，但總
的思想就是這樣
服務器證書
SSL 支持雙向認證，將服務器證書承載回客戶端，再將客戶端的證書回送給服務器。而現在，瀏覽時並不經常使用客戶端證書。大部分用戶甚至都沒有自己的客戶端證書。服務器可以要求使用客戶端證書，但實際中很少出現這種情況。
另一方面，安全 HTTPS 事務總是要求使用服務器證書的。在一個 Web 服務器上執行安全事務，比如提交信用卡信息時，你總是希望是在與你所認爲的那個組織對話。由知名權威機構簽發的服務器證書可以幫助你在發送信用卡或私人信息之前評估你對服務器的信任度。
服務器證書是一個顯示了組織的名稱、地址、服務器 DNS 域名以及其他信息的 X.509 v3 派生證書。你和你所用的客戶端軟件可以檢查證書，以確保所有的信息都是可信的
站點證書的有效性
SSL 自身不要求用戶檢查 Web 服務器證書，但大部分現代瀏覽器都會對證書進行簡單的完整性檢查，併爲用戶提供進行進一步徹查的手段。網景公司提出的一種 Web 服務器證書有效性算法是大部分瀏覽器有效性驗證技術的基礎。
- 日期檢測
首先，瀏覽器檢查證書的起始日期和結束日期，以確保證書仍然有效。如果證書過期了，或者還未被激活，則證書有效性驗證失敗，瀏覽器顯示一條錯誤信息
- 簽名頒發者可信度檢測
每個證書都是由某些證書頒發機構（CA）簽發的，它們負責爲服務器擔保。證書有不同的等級，每種證書都要求不同級別的背景驗證。比如，如果申請某個電子商務服務器證書，通常需要提供一個營業的合法證明
任何人都可以生成證書，但有些 CA 是非常著名的組織，它們通過非常清晰的流程來驗證證書申請人的身份及商業行爲的合法性。因此，瀏覽器會附帶一個簽名頒發機構的受信列表。如果瀏覽器收到了某未知（可能是惡意的）頒發機構簽發的證書，那它通常會顯示一條警告信息。有些證書會攜帶到受信 CA 的有效簽名路徑，瀏覽器可能會選擇接受所有此類證書。換句話說，如果某受信 CA 爲“Sam 的簽名商店”簽發了一個證書，而 Sam 的簽名商店也簽發了一個站點證書，瀏覽器可能會將其作爲從有效 CA 路徑導出的證書接受
- 簽名檢測
一旦判定簽名授權是可信的，瀏覽器就要對簽名使用簽名頒發機構的公開密鑰，並將其與校驗碼進行比較，以查看證書的完整性
- 站點身份檢測
爲防止服務器複製其他人的證書，或攔截其他人的流量，大部分瀏覽器都會試着去驗證證書中的域名與它們所對話的服務器的域名是否匹配。服務器證書中通常都包含一個域名，但有些 CA 會爲一組或一羣服務器創建一些包含了服務器名稱列表或通配域名的證書。如果主機名與證書中的標識符不匹配，面向用戶的客戶端要麼就去通知用戶，要麼就以表示證書不正確的差錯報文來終止連接