為什么有 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 協議上，安全開車。

http與https

所以重點就是去掌握 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 字節的二進制串。

加密算法通常有兩大類：對稱加密和非對稱加密。

對稱加密

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

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

AES 的意思是“高級加密標準”（Advanced Encryption Standard），密鑰長度可以是 128、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。因為密鑰短，所以相應的計算量、消耗的內存和帶寬也就少，加密解密的性能就上去了，對于現在的移動互聯網非常有吸引力。

現在我們為了機密性從對稱加密到非對稱加密，而非對稱加密還解決了密鑰交換不安全的問題。那么是否可以直接使用非對稱加密來實現機密性呢？

答案是否定的！

因為非對稱加密運算速度比較慢。所以需要兩者結合，混合模式實現機密性問題，同時又有很好的性能。

加密流程如下所示：

• 先創建一個隨機數的對稱加密密鑰，會話密鑰（session key）；
• 使用會話密鑰加密需要傳輸的明文消息，因為對稱加密性能較好，接著再使用非對稱加密的公鑰對會話密鑰加密，因為會話密鑰很短，通常只有 16 字節或 32 字節，所以加密也不會太慢。這里主要就是解決了非對稱加密的性能問題，同時實現了會話密鑰的機密交換。
• 另一方接收到密文后使用非對稱加密的私鑰解密出上一步加密的 會話密鑰，接著使用會話密鑰解密出加密的消息明文。

混合加密

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

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

后面還有完整性、身份認證、不可否認等特性沒有實現，所以現在的通信還不是絕對安全。

摘要算法與完整性

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

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

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

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

完整性實現

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

但是由于摘要算法不具有機密性，不能明文傳輸，否則黑客可以修改消息后把摘要也一起改了，網站還是鑒別不出完整性。

所以完整性還是要建立在機密性上，我們結合之前提到的混合加密使用 ”會話密鑰“ 加密明文消息 + 摘要，這樣的話黑客也就無法得到明文，無法做修改了。這里有個專業術語叫“哈希消息認證碼（HMAC）”。

哈希消息認證碼（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 實現安全，而安全我們又接觸了什么是對稱加密與非對稱加密，非對稱加密性能較弱，所以我們使用非對稱加密來加密對稱加密的“會話密鑰”，利用會話密鑰加密明文解決了性能問題。

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