透視HTTPS建造固若金湯的城堡

公衆號：碼哥字節，轉載請聯繫公衆號

爲何有 HTTPS？由於 HTTP 不安全！ 如今的互聯網已經再也不是 「田園時代」，「黑暗森林」 已經到來。上網的記錄會被輕易截獲，網站是否真實也沒法驗證，黑客能夠假裝成銀行網站，盜取真實姓名、密碼、銀行卡等敏感信息，威脅人身安全和財產安全。

上網的時候必須步步爲營、到處當心，不然就會被不知道埋伏在哪裏的黑客所「獵殺」。

HTTPS 如何實現安全通訊？如何構建出固若金湯的網絡城堡？主要涉及的知識點以下：

• 瞭解什麼是 HTTPS
• 什麼樣的纔是安全的通訊
• 對稱加密與非對稱加密、摘要算法、數字簽名、完整性校驗究竟是什麼
• 遷移 HTTPS 的必要性

什麼是安全

作事要穩，老司機【碼哥字節】開車要安全！無論是戴杜蕾斯仍是安全氣囊，「安全相當重要」！

在通訊過程當中，具有如下特性則認爲安全：機密性、完整性、不能否認、身份認證

機密性

數據必須保密，只能有信任的人讀取，其餘人是不可見的祕密。諸葛亮的密報總不能讓司馬懿知道呀，否則還玩個蛋。通俗的說：就是不能讓不相關的人看到不應看的東西。

完整性

也叫做一致性，也就是數據在傳輸過程當中沒有被非法篡改，內容不能多也不能少，一五一十的保持原狀。

打個比方，本來張無忌說：「趙敏，麼麼噠。」，傳信的飛鴿被周芷若抓到了，截取了消息，改爲了 「趙敏，去死吧！」。這麼子搞，倚天屠龍記可能就會被改寫了。

不能否認

也就作不可抵賴，不可否認已經發生過的事情。所謂 「君子一言，駟馬難追」。「老懶」 這種事情不能發生。

就像尹志平親密接觸了小龍女，過後一直隱瞞否定，裝做不知道，這是萬萬不可的。因此最終就嗝屁了。

身份驗證

也就是確認對方的真實身份，「證實你是真的是你」，保證消息發送到可信的人，而不是非法之徒。

好比令狐沖寫了一份情書給任盈盈：「盈盈，衝哥哥愛你喲」，可是嶽不羣看到快遞小哥，冒充是令狐沖，截取了情書後回覆：「傻逼，白日作夢」。令狐沖不知道這是嶽不羣的回覆，覺得是任盈盈的，笑傲江湖又要重寫了……

因此同時具有了機密性、完整性、身份認證、不可夠人四個特性，通訊雙方的安全才有保證，纔是真正的安全。

什麼是 HTTPS

到這裏，終於輪到 HTTPS 上臺了，也就是它爲 HTTP 增長了剛剛說的四大安全特性。

HTTPS 實際上是一個「很是簡單」的協議，規定了新的協議名「https」，默認端口號 443，至於其餘的什麼請求 - 應答模式、報文結構、請求方法、URI、頭字段、鏈接管理等等都徹底沿用 HTTP，沒有任何新的東西。惟一的差異就是端口號不一樣、去掉明文傳輸。

那 HTTPS 憑啥就變得安全了呢？

就是由於他在 TCP/IP 與 HTTP 之間加上了 SSL/TLS ，從原來的 HTTP over TCP/IP 變成了 HTTP over SSL/TLS，讓 HTTP 運行在 安全的 SSL/TLS 協議上，安全開車。

因此重點就是去掌握 SSL/TLS 究竟是什麼玩意成就了安全。

SSL/TLS

SSL 即安全套接層（Secure Sockets Layer），在 OSI 模型中處於第 5 層（會話層），由網景公司於 1994 年發明，有 v2 和 v3 兩個版本，而 v1 由於有嚴重的缺陷從未公開過。

SSL 發展到 v3 時已經證實了它自身是一個很是好的安全通訊協議，因而互聯網工程組 IETF 在 1999 年把它更名爲 TLS（傳輸層安全，Transport Layer Security），正式標準化，版本號從 1.0 從新算起，因此 TLS1.0 實際上就是 SSLv3.1。

TLS 由記錄協議、握手協議、警告協議、變動密碼規範協議、擴展協議等幾個子協議組成，綜合使用了對稱加密、非對稱加密、身份認證等許多密碼學前沿技術。

瀏覽器與服務器在使用 TLS 創建鏈接的時候實際上就是選了一組加密算法實現安全通訊，這些算法組合叫作 「密碼套件（cipher suite）」。

套件命名頗有規律，好比「ECDHE-RSA-AES256-GCM-SHA384」。按照 密鑰交換算法 + 簽名算法 + 對稱加密算法 + 摘要算法」組成的.

因此這個套件的意思就是：使用 ECDHE 算法進行密鑰交換，使用 RSA 簽名和身份驗證，握手後使用 AES 對稱加密，密鑰長度 256 位，分組模式 GCM，消息認證和隨機數生成使用摘要算法 SHA384。

對稱加密與非對稱加密

前面提到四個實現安全的必要條件，先說 機密性，也就是消息只能給想給的人看到而且看得懂。

實現機密性的手段就是 加密（encrypt），也就是將本來明文消息使用加密算法轉換成別人看不懂的密文，只有掌握特有的 密鑰 的人才能解密出原始內容。就好像是諸葛亮將發給關二爺密報的內容經過一種轉換算法轉成其餘的內容，司馬懿看不懂。關二爺持有解密該內容的關鍵鑰匙。

鑰匙也就是 密鑰（key），未加密的消息叫作 明文 （plain text/clear text），加密後的內容叫作 密文（cipher text），經過密鑰解密出原文的過程叫作 解密（decrypt），而加解密的整個過程就是 加密算法。

因爲 HTTPS、TLS 都運行在計算機上，因此「密鑰」就是一長串的數字，但約定俗成的度量單位是「位」（bit），而不是「字節」（byte）。好比，說密鑰長度是 128，就是 16 字節的二進制串，密鑰長度 1024，就是 128 字節的二進制串。

加密算法一般有兩大類：對稱加密和非對稱加密。

對稱加密

加密和解密使用的密鑰都是同一個，是 「對稱的」。雙方只要保證不會有泄露其餘人知道這個密鑰，通訊就具備機密性。

對稱加密算法常見的有 RC四、DES、3DES、AES、ChaCha20 等，但前三種算法都被認爲是不安全的，一般都禁止使用，目前經常使用的只有 AES 和 ChaCha20。

AES 的意思是「高級加密標準」（Advanced Encryption Standard），密鑰長度能夠是 12八、192 或 256。它是 DES 算法的替代者，安全強度很高，性能也很好，並且有的硬件還會作特殊優化，因此很是流行，是應用最普遍的對稱加密算法。

加密分組模式

對稱算法還有一個 「分組模式」的概念，目的是經過算法用固定長度的密鑰加密任意長度的明文。

最新的分組模式被稱爲 AEAD（Authenticated Encryption with Associated Data），在加密的同時增長了認證的功能，經常使用的是 GCM、CCM 和 Poly1305。

非對稱加密

有對稱加密，爲什麼還搞出一個非對稱加密呢？

對稱加密確實解決了機密性，只有相關的人才能讀取出信息。可是最大的問題是：如何安全的把密鑰傳遞對方，專業術語 「密鑰交換」。

這個很容易理解，對稱加密的密鑰在飛鴿傳書過程當中被打鳥的敵軍捕獲竊取，那麼就能隨意加解密收發做戰密報數據了，諸葛亮的密報沒有機密可言。

因此非對稱加密誕生了。

由兩個密鑰組成，分別是 公鑰（public key） 和 「私鑰（private key）」，兩個密鑰是不同的，這也就是不對稱的由來，公鑰能夠任何人使用，私鑰則本身保密。

這裏須要注意的是：公鑰和私鑰均可以用來加密解密，公鑰加密的密文只能用私鑰解密，反之亦然。

服務端保存私鑰，在互聯網上分發公鑰，當訪問服務器網站的時候使用授予的公鑰加密明文便可，服務端則使用對應的私鑰來解密。敵軍沒有私鑰也就沒法破解密文了。

TLS 中常見的加密算法有 DH、RSA、ECC、DSA 等。其中的 RSA 最經常使用，它的安全性基於「整數分解」的數學難題，使用兩個超大素數的乘積做爲生成密鑰的材料，想要從公鑰推算出私鑰是很是困難的。

ECC（Elliptic Curve Cryptography）是非對稱加密裏的「後起之秀」，它基於「橢圓曲線離散對數」的數學難題，使用特定的曲線方程和基點生成公鑰和私鑰，子算法 ECDHE 用於密鑰交換，ECDSA 用於數字簽名。

比起 RSA，ECC 在安全強度和性能上都有明顯的優點。160 位的 ECC 至關於 1024 位的 RSA，而 224 位的 ECC 則至關於 2048 位的 RSA。由於密鑰短，因此相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了，對於如今的移動互聯網很是有吸引力。

如今咱們爲了機密性從對稱加密到非對稱加密，而非對稱加密還解決了密鑰交換不安全的問題。那麼是否能夠直接使用非對稱加密來實現機密性呢？

答案是否認的！

由於非對稱加密運算速度比較慢。因此須要二者結合，混合模式實現機密性問題，同時又有很好的性能。

加密流程以下所示：

1. 先建立一個隨機數的對稱加密密鑰，會話密鑰（session key）；
2. 使用會話密鑰加密須要傳輸的明文消息，由於對稱加密性能較好，接着再使用非對稱加密的公鑰對會話密鑰加密，由於會話密鑰很短，一般只有 16 字節或 32 字節，因此加密也不會太慢。這裏主要就是解決了非對稱加密的性能問題，同時實現了會話密鑰的機密交換。
3. 另外一方接收到密文後使用非對稱加密的私鑰解密出上一步加密的 會話密鑰，接着使用會話密鑰解密出加密的消息明文。

總結一下就是使用非對稱加密算法來加密會話密鑰，使用對稱加密算法來加密消息明文，接收方則使用非對稱加密算法的私鑰解密出會話密鑰，再利用會話密鑰解密消息密文。

這樣混合加密就解決了對稱加密算法的密鑰交換問題，並且安全和性能兼顧，完美地實現了機密性。

後面還有完整性、身份認證、不能否認等特性沒有實現，因此如今的通訊還不是絕對安全。

摘要算法與完整性

摘要算法的主要目的就是實現完整性，經過常見的散列函數、哈希函數實現。

咱們能夠簡單理解成這事一種特殊的壓縮算法，將任意長度的明文數據處理成固定長度、又是獨一無二的「摘要」字符串，就是該數據的指紋。

同時摘要算法是單向加密算法，沒有密鑰，加密後的數據也沒法解密，也就是不能從「摘要」推導出明文。

好比咱們聽過或者用過的 MD5（Message-Digest 5）、SHA-1（Secure Hash Algorithm 1），它們就是最經常使用的兩個摘要算法，可以生成 16 字節和 20 字節長度的數字摘要。

完整性實現

有了摘要算法生成的數字摘要，那麼咱們只須要在明文數據附上對應的摘要，就能保證數據的完整性。

可是因爲摘要算法不具備機密性，不能明文傳輸，不然黑客能夠修改消息後把摘要也一塊兒改了，網站仍是鑑別不出完整性。

因此完整性仍是要創建在機密性上，咱們結合以前提到的混合加密使用 」會話密鑰「 加密明文消息 + 摘要，這樣的話黑客也就沒法獲得明文，沒法作修改了。這裏有個專業術語叫「哈希消息認證碼（HMAC）」。

好比諸葛亮使用上面提到的混合加密過程給關二爺發消息：「明天攻城」 + 「SHA-2 摘要」，關二爺收到後使用密鑰將解密出來的會話密鑰解密出明文消息，同時對明文消息使用解密出來的摘要算法進行摘要計算，接着比對兩份「摘要」字符串是否一致，若是一致就說明消息完整可信，沒有被敵軍修改過。

消息被修改是很危險的，要以史爲鑑，好比趙高與李斯僞造遺詔，直接把扶蘇給送西天了，這太可怕了。

總結下就是經過摘要比對防止篡改，同時利用混合加密實現密文與摘要的安全傳輸。

數字簽名和 CA

到這裏已經很安全了，可是仍是有漏洞，就是通訊的兩頭。黑客能夠假裝成網站來竊取信息。而反過來，他也能夠假裝成你，向網站發送支付、轉帳等消息，網站沒有辦法確認你的身份，錢可能就這麼被偷走了。

如今如何實現身份認證呢？

現實生活中，解決身份認證的手段是簽名和印章，只要在紙上寫下簽名或者蓋個章，就可以證實這份文件確實是由本人而不是其餘人發出的。

非對稱加密依然能夠解決此問題，只不過跟以前反過來用，使用私鑰再加上摘要算法，就可以實現「數字簽名」，同時實現「身份認證」和「不能否認」。

就是把公鑰私鑰的用法反過來，以前是公鑰加密、私鑰解密，如今是私鑰加密、公鑰解密。但又由於非對稱加密效率過低，因此私鑰只加密原文的摘要，這樣運算量就小的多，並且獲得的數字簽名也很小，方便保管和傳輸。

重點就是使用非對稱加密的「私鑰」加密原文的摘要，對方則使用非對稱加密的公鑰解密出摘要，再比對解密出的原文經過摘要算法計算摘要與解密出的摘要比對是否一致。這樣就能像簽署文件同樣證實消息確實是你發送的。

只要你和網站互相交換公鑰，就能夠用「簽名」和「驗籤」來確認消息的真實性，由於私鑰保密，黑客不能僞造簽名，就可以保證通訊雙方的身份。

CA

到這裏彷佛已經大功告成，惋惜還不是。

綜合使用對稱加密、非對稱加密和摘要算法，咱們已經實現了安全的四大特性，是否是已經完美了呢？

不是的，這裏還有一個「公鑰的信任」問題。由於誰均可以發佈公鑰，咱們還缺乏防止黑客僞造公鑰的手段，也就是說，怎麼來判斷這個公鑰就是你或者張三丰的公鑰呢？

這個「第三方」就是咱們常說的CA（Certificate Authority，證書認證機構）。它就像網絡世界裏的公安局、教育部、公證中心，具備極高的可信度，由它來給各個公鑰簽名，用自身的信譽來保證公鑰沒法僞造，是可信的。

CA 對公鑰的簽名認證也是有格式的，不是簡單地把公鑰綁定在持有者身份上就完事了，還要包含序列號、用途、頒發者、有效時間等等，把這些打成一個包再簽名，完整地證實公鑰關聯的各類信息，造成「數字證書」（Certificate）。

OpenSSL

它是一個著名的開源密碼學程序庫和工具包，幾乎支持全部公開的加密算法和協議，已經成爲了事實上的標準，許多應用軟件都會使用它做爲底層庫來實現 TLS 功能，包括經常使用的 Web 服務器 Apache、Nginx 等。

因爲 OpenSSL 是開源的，因此它還有一些代碼分支，好比 Google 的 BoringSSL、OpenBSD 的 LibreSSL，這些分支在 OpenSSL 的基礎上刪除了一些老舊代碼，也增長了一些新特性，雖然背後有「大金主」，但離取代 OpenSSL 還差得很遠。

總結下就是：OpenSSL 是著名的開源密碼學工具包，是 SSL/TLS 的具體實現。

遷移 HTTPS 必要性

若是你作移動應用開發的話，那麼就必定知道，Apple、Android、某信等開發平臺在 2017 年就相繼發出通知，要求全部的應用必須使用 HTTPS 鏈接，禁止不安全的 HTTP。

在臺式機上，主流的瀏覽器 Chrome、Firefox 等也早就開始「強推」HTTPS，把 HTTP 站點打上「不安全」的標籤，給用戶以「心理壓力」。

Google 等搜索巨頭還利用自身的「話語權」優點，下降 HTTP 站點的排名，而給 HTTPS 更大的權重，力圖讓網民只訪問到 HTTPS 網站。

這些手段都逐漸「擠壓」了純明文 HTTP 的生存空間，「遷移到 HTTPS」已經不是「要不要作」的問題，而是「要怎麼作」的問題了。HTTPS 的大潮沒法阻擋，若是仍是死守着 HTTP，那麼無疑會被沖刷到互聯網的角落裏。

顧慮

阻礙 HTTPS 實施的因素還有一些這樣、那樣的顧慮，我總結出了三個比較流行的觀點：「慢、貴、難」。

而「慢」則是慣性思惟，拿之前的數據來評估 HTTPS 的性能，認爲 HTTPS 會增長服務器的成本，增長客戶端的時延，影響用戶體驗。

其實如今服務器和客戶端的運算能力都已經有了很大的提高，性能方面徹底沒有擔憂的必要，並且還能夠應用不少的優化解決方案

所謂「貴」，主要是指證書申請和維護的成本過高，網站難以承擔。

這也屬於慣性思惟，在早幾年的確是個問題，向 CA 申請證書的過程不只麻煩，並且價格昂貴，每一年要交幾千甚至幾萬元。

但如今就不同了，爲了推廣 HTTPS，不少雲服務廠商都提供了一鍵申請、價格低廉的證書，並且還出現了專門頒發免費證書的 CA，其中最著名的就是「Let’s Encrypt」。

所謂的「難」，是指 HTTPS 涉及的知識點太多、太複雜，有必定的技術門檻，不能很快上手。

總結

從什麼是安全咱們延展出 HTTPS，解釋了什麼是 HTTPS，以及與 HTTP 的區別。HTTPS 主要就是經過 SSL/TLS 實現安全，而安全咱們又接觸了什麼是對稱加密與非對稱加密，非對稱加密性能較弱，因此咱們使用非對稱加密來加密對稱加密的「會話密鑰」，利用會話密鑰加密明文解決了性能問題。

經過混合加密實現了機密性，利用摘要算法實現了完整性，經過數字簽名使用非對稱加密的「私鑰」加密原文的摘要，對方則使用非對稱加密的公鑰解密出摘要，再比對解密出的原文經過摘要算法計算摘要與解密出的摘要比對是否一致實現了身份認證與不能否認。

若是以爲閱讀後對你有幫助，但願多多分享、點贊與在看素質三連不作白嫖者。

關注 【碼哥字節】解鎖更多硬核。

推薦閱讀

如下幾篇文章閱讀量與讀者反饋都很好，推薦你們閱讀：

• RESTful 最佳實踐
• Tomcat 架構原理解析到架構設計借鑑
• Tomcat 高併發之道原理拆解與性能調優
• 數據庫系統設計概述

公衆號後臺回覆 」加羣「，加入讀者技術羣，裏面有阿里、騰訊的小夥伴一塊兒探討技術。

參考內容

[透視 HTTP 協議]