HTTPS基礎知識介紹

• 2020 年 3 月 15 日
• 筆記

HTTPS基礎知識介紹

為什麼要用HTTPS

一 介紹 HTTPS 之前，我們先回顧一下 HTTP 協議。HTTP 超文本傳輸協議，它是無狀態的、簡單快速、基於 TCP 的可靠傳輸協議。既然 HTTP 協議這麼好，那為什麼又冒出來了一個 HTTPS ？主要是因為 HTTP 明文傳輸的數據，這就造成了很大的安全隱患。在網路傳輸過程中，只要數據包被人劫持，那就相當於赤身全裸的暴露在他人面前，毫無半點隱私可言。想像一下，假設你連了一個不可信的 WIFI，正好又使用了某個支付軟體進行了支付操作，那麼你的密碼可能就到別人手裡去了，後果可想而知。公共網路環境就是這樣，給你帶來便利的同時，也充滿了挑戰與風險。對於小白用戶，你不能期望他有多高的網路安全意識。這樣的問題產品應該通過技術手段，讓我們的產品變得更安全，從源頭來控制風險。這就是HTTPS協議誕生的背景。

二 2016年6月，在全球開發者大會上，蘋果公司宣布App Store中所有的iOS應用都必須啟用App Transport Security（ATS）安全功能，確保應用通過安全的HTTPS連接進行通訊。

App Transport Security，簡稱 ATS，是蘋果在 iOS 9 當中首次推出的一項安全功能。在開啟 ATS 安全特性之後，它會強制App應用及網頁通訊自動通過HTTPS加密傳輸連接網路服務， 通過加密App及網頁通訊來保障用戶數據安全。即App的後端伺服器必須部署SSL證書，啟用HTTPS加密協議，否則您的App應用將不能通過蘋果商店的審核發布，導致App應用無法正常使用。

ATS功能解讀

蘋果對安全性的要求及說明，其中詳細介紹ATS，目前在ATS中使用TLS1.2版本。

https://developer.apple.com/cn/security/

您的業務是否符合ATS安全規則可以用下面的工具進行測試。

https://myssl.com/ats.html

相信通過上面的兩段描述，你已經了解為什麼要用HTTPS了，下面我們開始揭開HTTPS神秘的面紗。

HTTPS協議組成

HTTPS = HTTP over TLS（transport layer security），TLS早期命名為SSL，目前TLS版本1.0 1.1 1.2 1.3 主流版本為1.2。

TLS (Transport Layer Security) : 組成包含Handshake Protocol和Record Protocol。

Handshake Protocol 用來協商密鑰，協議的大部分內容就是通訊雙方如何利用它來安全的協商出一份密鑰。

Record Protocol 定義傳輸的格式，由於非對稱加密的速度比較慢，所以它一般用於密鑰交換，雙方通過公鑰演算法協商出一份密鑰，然後通過對稱加密來通訊，為了保證數據的完整性，在加密前要先經過HMAC的處理。

TLS協議的組成及格式如下圖

HTTPS如何實現數據加密傳輸：通過下圖可以清晰了解，HTTP和HTTPS數據傳輸的區別，HTTPS數據傳輸在TCP握手成功後，還要TLS握手完成再傳輸HTTP數據，這樣HTTP數據就被封裝加密進行傳輸，保證安全。

網站部署HTTPS後客戶端訪問網站流程

站點部署HTTPS後一次客戶端請求網站相對完整的HTTPS流程：

通過上面的流程我們了解了HTTPS一次完整的訪問過程。

這裡我們思考一下HTTPS會不會提升用戶訪問網站的延遲呢？

HTTPS為什麼安全？

HTTPS安全是由一套安全機制來保證的，主要包含這4個特性：機密性、完整性、真實性和不可否認性。

機密性是指傳輸的數據是採用Session Key（會話密鑰）加密的，在網路上是看不到明文的。

完整性是指為了避免網路中傳輸的數據被非法篡改，使用MAC演算法來保證消息的完整性。

真實性是指通訊的對方是可信的，利用了PKI（Public Key Infrastructure 即『公鑰基礎設施』）來保證公鑰的真實性。

不可否認性是這個消息就是你給我發的，無法偽裝和否認，使用簽名的技術來保證。

數據加密

HTTPS協議有對稱加密和非對稱加密兩種演算法，目的都是把明文加密成密文，區別是密鑰的個數不一樣，對稱加密是一把密鑰，這把密鑰可以加密明文，也可以解密加密後的密文。

對稱加密演算法

對稱加密演算法，如其名，就是使用同一個秘鑰進行加密和解密。

優點是速度較快，適合對數據量比較大的數據進行加密。

缺點是密鑰的保存方式需要保證，一旦加密或者解密的哪一方泄漏了密鑰，都會導致資訊的泄漏。

常用的對稱加密演算法有:DES、3DES、DESX、Blowfish、IDEA、RC4、RC5、RC6、AES。

非對稱加密

非對稱加密需要兩個密鑰，一個公開密鑰（Public Key）,一個私有密鑰（Private Key）。公鑰和私鑰是一對，如果使用公鑰進行加密的數據，只有對應的私鑰才能解密。如果是使用私鑰加密的數據，只有對應的公鑰才能解密。

優點是公鑰可以被任何人知道，而公鑰的泄漏也不會導致資訊泄漏，但是一旦私鑰泄漏了就會導致資訊泄漏。

常用的非對稱加密演算法有：RSA、ECC（移動設備用）、Diffie-Hellman、El Gamal、DSA（數字簽名用）。

身份認證

TLS使用非對稱加密的地方是簽名，簽名的目的是讓對方相信這個數據是我發送的，而不是其他人發送的。

數字證書的作用

身份認證：在網路中傳遞資訊的雙方互相不能見面，利用數字證書可確認雙方身份，而不是他人冒充的。

保密性：通過使用數字證書對資訊加密，只有接收方才能閱讀加密的資訊，從而保證資訊不會被他人竊取。

完整性：利用數字證書可以校驗傳送的資訊在傳遞的過程中是否被篡改過或丟失。

防抵賴：利用數字證書進行數字簽名，可準確標示簽名人身份及驗證簽名內容，因此簽名人對簽名及簽名內容具有不可否認性，其作用與手寫簽名具有同樣的法律效力。

介紹到這裡不得不提的是PKI公鑰基礎設施

公鑰基礎設施（英語：Public Key Infrastructure，縮寫：PKI），又稱公開密鑰基礎架構、公鑰基礎建設、公鑰基礎設施、公開密碼匙基礎建設或公鑰基礎架構，是一組由硬體、軟體、參與者、管理政策與流程組成的基礎架構，其目的在於創造、管理、分配、使用、存儲以及撤銷數字證書。

密碼學上，公開密鑰基礎建設借著數字證書認證機構(Certificate Authority，CA)將用戶的個人身份跟公開密鑰鏈接在一起。對每個證書中心用戶的身份必須是唯一的。鏈接關係通過註冊和發布過程創建，取決於擔保級別，鏈接關係可能由CA的各種軟體或在人為監督下完成。PKI的確定鏈接關係的這一角色稱為註冊管理中心（Registration Authority，RA）。RA確保公開密鑰和個人身份鏈接，可以防抵賴。

可信賴的第三者（Trusted third party，TTP）也常被用來指證書中心。

PIK公鑰基礎設施組成

Certificate Authority(CA) 證書頒發機構(or系統)，CA是PKI的基礎，它管理著證書的整個生命周期，其作用包括：發放證書，規定證書有效期，廢棄不良信用證書。

Registration Authority(RA) 證書註冊，登記機構(or系統)，RA提供一個用戶和CA之前的橋樑，用戶通過RA進行證書的申請，RA獲取用戶的身份資訊並確認用戶的資訊，向CA提出證書申請。它接受用戶的註冊申請，審查用戶的申請資格，並決定是否同意CA給其簽發數字證書。註冊機構並不給用戶簽發證書，而只是對用戶進行資格審查。因此，RA可以設置在直接面對客戶的業務部門，如銀行的營業部、機構認識部門等。當然，對於一個規模較小的PKI應用系統來說，可把註冊管理的職能由認證中心CA來完成，而不設立獨立運行的RA。但這並不是取消了PKI的註冊功能，而只是將其作為CA的一項功能而已。PKI國際標準推薦由一個獨立的RA來完成註冊管理的任務，可以增強應用系統的安全。

證書申請人 是指將要申請證書的客戶，可以是個人，集團或團體，政府機構等。

Validation Authority(VA) 證書驗證機構在PKI中 VA是一個實體，它用於驗證數字證書有效性的服務常用方式CRL及OCSP。

證書存儲-證書和私鑰存儲位置證書管理中心-管理證書的申請，下發，存儲機構可信度-PKI系統就本身的證書進行說明，其目的是允許外部分析PKI的可信度。

客戶端證書 客戶端證書是相對於伺服器端而言，用於證明客戶端用戶身份的數字證書，使客戶端用戶在與伺服器端通訊時可以證明其真實身份，也可對電子郵件進行數字簽名及加密。適用於各種涉密系統、網上應用和網路資源的客戶端強身份認證。  

伺服器證書 伺服器證書是SSL數字證書的一種形式，意指通過提交數字證書來證明您的身份或表明您有權訪問在線服務。再者簡單來說，通過使用伺服器證書可為不同站點提供身份鑒定並保證該站點擁有高強度加密安全。然而，並不是所有網站都需要添加伺服器證書，但強烈建議只要是與用戶、伺服器進行交互連結操作，以及涉及到密碼、隱私等內容的網站頁面，都申請伺服器安全認證證書。

數字簽名過程

客戶端證書校驗過程

(1) 當client端訪問baidu.com的時候，baidu的server會將baidu.com證書發送給client端。

(2) client端的作業系統或者瀏覽器中內置了根證書，但是client端收到baidu.com這個證書後，發現這個證書不是根證書籤發，無法根據本地已有的根證書中的公鑰去驗證baidu.com證書是否可信。於是client端根據baidu.com證書中的Issuer找到該證書的頒發機構GlobalSign Organization Validation CA – SHA256 – G2，去CA請求baidu.com證書的頒發機構GlobalSign Organization Validation CA – SHA256 – G2的證書。

(3) 請求到證書後發現GlobalSign Organization Validation CA – SHA256 – G2證書是由根證書籤發，而本地剛好有根證書，於是可以利用根證書中的公鑰去驗證（驗證方法見上一節）GlobalSign Organization Validation CA – SHA256 – G2證書，發現驗證通過，於是信任GlobalSign Organization Validation CA – SHA256 – G2證書。

(4) GlobalSign Organization Validation CA – SHA256 – G2證書被信任後，可以使用GlobalSign Organization Validation CA – SHA256 – G2證書中的公鑰去驗證baidu.com證書的可信性。驗證通過，於是信任baidu.com證書。

在這四個步驟中，最開始client端只信任根證書GlobalSign Root CA證書的，然後GlobalSign Root CA證書信任GlobalSign Organization Validation CA – SHA256 – G2證書，而GlobalSign Organization Validation CA – SHA256 – G2證書又信任baidu.com證書，於是client端也信任baidu.com證書。這樣的一個過程就構成了一條信任鏈路，整個證書信任鏈驗證流程如下圖所示。