為什麼有 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 位元組的二進位制串。
加密演算法通常有兩大類：對稱加密和非對稱加密。
對稱加密
加密和解密使用的金鑰都是同一個，是 “對稱的”。雙方只要保證不會有洩露其他人知道這個金鑰，通訊就具有機密性。
對稱加密演算法常見的有 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）”。
比如諸葛亮使用上面提到的混合加密過程給關二爺發訊息：“明天攻城” + “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 實現安全，而安全我們又接觸了什麼是對稱加密與非對稱加密，非對稱加密效能較弱，所以我們使用非對稱加密來加密對稱加密的“會話金鑰”，利用會話金鑰加密明文解決了效能問題。
通過混合加密實現了機密性，利用摘要演算法實現了完整性，通過數字簽名使用非對稱加密的“私鑰”加密原文的摘要，對方則使用非對稱加密的公鑰解密出摘要，再比對解密出的原文通過摘要演算法計算摘要與解密出的摘要比對是否一致實現了身份認證與不可否認。
如果覺得閱讀後對你有幫助，希望多多分享、點贊與在看素質三連不做白嫖者。
關注 【碼哥位元組】解鎖更多硬核。
推薦閱讀
以下幾篇文章閱讀量與讀者反饋都很好，推薦大家閱讀：
公眾號後臺回覆 ”加群“，加入讀者技術群，裡面有阿里、騰訊的小夥伴一起探討技術。
參考內容
[透視 HTTP 協議]