『壹』 HTTPS加密原理
HTTP、HTTPS在我們日常開發中是經常會接觸到的。
我們也都知道，一般 Android 應用開發，在請求 API 網路介面的時候，很多使用的都是 HTTP 協議；使用瀏覽器打開網頁，也是利用 HTTP 協議。看來 HTTP 真是使用廣泛啊，但是，HTTP 是不安全的。利用網路抓包工具就可以知道傳輸中的內容，一覽無余。比如我經常會使用 Fiddler 來抓包，搜集一些有趣的 API 介面。
那麼問題來了，如何保證 HTTP 的安全性呢？基本上所有的人都會脫口而出：使用 HTTPS 協議。99.9% 的人都知道 HTTPS 會將傳輸的內容進行加密，但是接著問具體加密的過程和步驟，很多人就啞口無言了。
為了防止出現這種尷尬的局面，所以今天你就要好好看看這篇的內容了。以後就可以裝個逼，哈哈！
先科普一下，加密演算法的類型基本上分為了兩種：
對稱加密的意思就是說雙方都有一個共同的密鑰，然後通過這個密鑰完成加密和解密，這種加密方式速度快，但是安全性不如非對稱加密好。
舉個例子，現在學霸小明這里有一道數學題的答案：123 。他想把答案傳給自己一直暗戀的小紅。所以他們雙方在考試開考前，約定了一把密鑰：456 。那麼小明就把答案內容經過密鑰加密，即 123 + 456 = 579 ，將 579 寫在小紙條上扔給小紅。如果此時別人撿到了小紙條，不知道他們是加密傳輸的，看到上面的 579 ，會誤以為答案就是 579 ；如果是小紅撿到了，她拿出密鑰解密，579 - 456 = 123 ，得到了正確的答案。
這就是所謂的對稱加密，加解密效率高，速度快，但是雙方任何一方不小心泄露了密鑰，那麼任何人都可以知道傳輸內容了。
講完了對稱加密，我們看看啥是非對稱加密。
非對稱加密就是有兩把密鑰，公鑰和私鑰。私鑰自己藏著，不告訴任何人；而公鑰可以公開給別人。
經過了上次作弊後，小紅發現了對稱加密如果密鑰泄露是一件可怕的事情。所以她和小明決定使用非對稱加密。小紅生成了一對公鑰和私鑰，然後把公鑰公開，小明就得到了公鑰。小明拿到公鑰後，把答案經過公鑰加密，然後傳輸給小紅，小紅再利用自己的私鑰進行解密，得到答案結果。如果在這個過程中，其他人得到傳輸的內容，而他們只有小紅公鑰，是沒有辦法進行解密的，所以也就得不到答案，只有小紅一個人可以解密。
因此，相比較對稱加密而言，非對稱加密安全性更高，但是加解密耗費的時間更長，速度慢。
對稱加密和非對稱加密的具體應用我還是深有體會的，因為所在的公司是做金融支付方面的，所以加解密基本上算是天天見了。
說完加密類型後，我們再來看看 HTTPS 。
我們先來看一個公式：
HTTPS = HTTP + SSL
從這個公式中可以看出，HTTPS 和 HTTP 就差在了 SSL 上。所以我們可以猜到，HTTPS 的加密就是在 SSL 中完成的。
所以我們的目的就是要搞懂在 SSL 中究竟幹了什麼見不得人的事了？
這就要從 CA 證書講起了。CA 證書其實就是數字證書，是由 CA 機構頒發的。至於 CA 機構的權威性，那麼是毋庸置疑的，所有人都是信任它的。CA 證書內一般會包含以下內容：
正好我們把客戶端如何校驗 CA 證書的步驟說下吧。
CA 證書中的 Hash 值，其實是用證書的私鑰進行加密後的值（證書的私鑰不在 CA 證書中）。然後客戶端得到證書後，利用證書中的公鑰去解密該 Hash 值，得到 Hash-a ；然後再利用證書內的簽名 Hash 演算法去生成一個 Hash-b 。最後比較 Hash-a 和 Hash-b 這兩個的值。如果相等，那麼證明了該證書是對的，服務端是可以被信任的；如果不相等，那麼就說明該證書是錯誤的，可能被篡改了，瀏覽器會給出相關提示，無法建立起 HTTPS 連接。除此之外，還會校驗 CA 證書的有效時間和域名匹配等。
接下來我們就來詳細講一下 HTTPS 中的 SSL 握手建立過程，假設現在有客戶端 A 和伺服器 B ：
到此，SSL 握手過程就講完了。可能上面的流程太過於復雜，我們簡單地來講：
我們可以發現，在 HTTPS 加密原理的過程中把對稱加密和非對稱加密都利用了起來。即利用了非對稱加密安全性高的特點，又利用了對稱加密速度快，效率高的好處。真的是設計得非常精妙，令人贊不絕口。
好了，HTTPS 加密原理到這就講的差不多了，不知道電腦前的你有沒有看懂呢？
如果有哪裡不明白的地方，可以在底下留言交流。
bye ~~
『貳』 URL內 參數加密解密
javascript對URL中的參數進行簡單加密處理
javascript的api本來就支持Base64，因此我笑笑們可以很方便的來進行編碼和解碼。
var encodeData = window.btoa("name=xiaoming&age=10")//衡升敗編碼
var decodeData = window.atob(encodeData)//解碼。
下面來個具體的例子來說明如何對url中參數進行轉碼，並取得解碼後的參數
假如要跳轉的url = "stu_info.html?name=xiaoming&age=10"
轉碼：url = "stu_info.html?"+window.btoa("name=xiaoming&age=10");
跳轉：window.open(url)或者window.locaton.href = url;
解碼：解碼時我們首先要從url中獲得參數列表，
我們可以通過var paramsString = window.location.search來獲取url中?號開始的內容（url的咐顫查詢部分）即"?name=xiaoming&age=10"；
然後去掉?號 paramsString = paramsString.substring(1) //"name=xiaoming&age=10"
去掉& paramsString = paramsString.split("&");//["name=xiaoming","age=10"]
需要指出的是 window.btoa這中編碼方式不能直接作用於Unicode字元串。只能將ascci字元串或二進制數據轉換成Base64編碼過的字元串。如果要對Unicode字元進行編碼可以將做如下轉換。
var encodeData = window.btoa(window.encodeURIComponent("name=小明&age=10"))//編碼
var decodeData = window.decodeURIComponent(window.atob(encodeData))//解碼。
獲取url參數
//獲取url參數
function getQueryString(name) {
var reg = new RegExp("(^|&)" + name + "=([^&]*)(&|$)", "i");
var params = window.location.search.substr(1);
params = window.decodeURIComponent(window.atob(params));
var r = params.match(reg);
if (r != null) {
return decodeURI(r[2]);
}
return null;
}
『叄』 HTTPS 加密演算法過程
1、HTTP 協議（HyperText Transfer Protocol，超文本傳輸協議）：是客戶端瀏覽器或其他程序與Web伺服器之間的應用層通信協議 。
2、HTTPS 協議（HyperText Transfer Protocol over Secure Socket Layer）：可以理解為HTTP+SSL/TLS， 即 HTTP 下加入 SSL 層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL，用於安全的 HTTP 數據傳輸。
3、SSL（Secure Socket Layer，安全套接字層）：1994年為 Netscape 所研發，SSL 協議位於 TCP/IP 協議與各種應用層協議之間，為數據通訊提供安全支持。
4、TLS（Transport Layer Security，傳輸層安全）：其前身是 SSL，它最初的幾個版本（SSL 1.0、SSL 2.0、SSL 3.0）。
如上圖所示 HTTPS 相比 HTTP 多了一層 SSL/TLS。
1、對稱加密
有流式、分組兩種，加密和解密都是使用的同一個密鑰。
例如：DES、AES-GCM、ChaCha20-Poly1305等
2、非對稱加密
加密使用的密鑰和解密使用的密鑰是不相同的，分別稱為：公鑰、私鑰，公鑰和演算法都是公開的，私鑰是保密的。非對稱加密演算法性能較低，但是安全性超強，由於其加密特性，非對稱加密演算法能加密的數據長度也是有限的。
例如：RSA、DSA、ECDSA、 DH、ECDHE
3、哈希演算法
將任意長度的信息轉換為較短的固定長度的值，通常其長度要比信息小得多，且演算法不可逆。
例如：MD5、SHA-1、SHA-2、SHA-256 等
4、數字簽名
簽名就是在信息的後面再加上一段內容（信息經過hash後的值），可以證明信息沒有被修改過。hash值一般都會加密後（也就是簽名）再和信息一起發送，以保證這個hash值不被修改。
C++音視頻開發學習資料 ：點擊 音視頻開發（資料文檔+視頻教程+面試題）（FFmpeg+WebRTC+RTMP+RTSP+HLS+RTP）
HTTP協議在瀏覽器/伺服器間進行數據的傳輸是明文的，不做任何的加密，通俗來說，就是「裸奔」，這樣會產生什麼樣的問題那，我們來舉一個例子：
在這里插入圖片描述
上述我們通過兩個人物模仿了伺服器和客戶端的交互，我們可以看出，小明和小花之間進行數據通信的時候採用的是明文傳輸的、那麼此時很有可能被中間人獲取信息、並進行數據篡改，這種行為就叫 中間人攻擊。
所以 HTTP 傳輸面臨的風險有：
（1） 竊聽風險：黑客可以獲知通信內容。
（2） 篡改風險：黑客可以修改通信內容。
（3） 冒充風險：黑客可以冒充他人身份參與通信。
哈哈、此時你是不是不能很愉快的上網沖浪了呀，別擔心，我們此時可以對明文進行加密：
這樣是不是比原來安全多了呀！但是這樣就足夠安全了嗎？顯然不是的，如果小明和小花在第一次聊天的時候，信息被中間人截取到了，那麼中間人是不是也就有密鑰了，同樣可以對數據進行加解密和修改了那
這可怎麼辦那？ 加密的數據還是不安全的啊？ 別急，上面我們採用的是對稱加密（換句話說就是我們發送的密鑰技能加密、也能解密，那麼中間人只要拿到密鑰消息對他而言就是透明的了），我們還可以採用非對稱加密方式進行加密數據(非對稱加密一般都會有一個私鑰和公鑰組成。可以通過公鑰加密，私鑰解密，也可以通過私鑰加密，公鑰解密兩種方式) ，對密鑰的傳送在格外加一層保護，當小明和小花在建立通信的時候，小花會把公鑰KEY發送給小明，當小明拿到公鑰KEY 後，會自己生成一個 密鑰 KEY2 , 並用 KEY 對KEY2 進行加密（此時小明用的是公鑰加密）
在通信過程中，即使中間人一開始就獲取到了公鑰KEY ,但是他不知道私鑰，就對數據無法進行解密，仍舊是沒辦法獲取KEY2。這樣加密後，數據是不是就安全多了呀。這種情況下就可以和妹子愉快的進行聊天了嗎？別急、所謂道高一尺魔高一丈，常言道：流氓不可怕，就怕流氓有文化。這種狀態下我們的數據，相當來說是比較安全的，但是如果此時中間人獲取公鑰後，發送給小明一個偽公鑰，又會產生什麼問題那？
好吧，說到這里，大家是不是快恨死這個中間人了啊，哈哈~~~還有據俗話別忘記了，魔高一尺道高一丈，對於這種情況。我們可以藉助與第三方證書平台，證書平台具備產生證書的功能，伺服器（小花）可以去證書機構申請證書，證書機構通過小花提供的信息（網址、機構、法人等、公鑰），生成公鑰和私鑰（證書機構的），通過私鑰進行數據的非對稱加密生成證書、將證書頒發給小花。那麼此時小花就可以在進行數據交互的時候，傳遞證書了。
小明只需要知道證書的發證機構、就可以很方便的獲取到證書的公鑰、從而對證書進行校驗並獲取公鑰、然後進行後續的操作。
那麼此時小夥伴是不是又有疑問了，如果 中間人 獲取到證書、並偽造證書給小明、怎麼破？？？
不錯不錯、如果大家有這個想法的話，說明大家都在認真思考了。那麼我們假設中間人獲取到了證書、中間人也可以在證書機構獲取公鑰，並通過證書機構公鑰獲取 伺服器發送的公鑰，中間人此時也可以自己生成公鑰，並向證書機構申請證書、並發送偽證書給小明，但是因為證書是經過簽名認證的，包含（網址、機構、法人等、公鑰）等信息，小明在拿到偽證書後，通過證書公鑰很容易就發現證書是不合法的(網址、法人的信息可定不符，否則申請不到證書的)。
上述我們分享的內容就是HTTPS的主體思想，HTTPS增加了SSL安全層，上述介紹的所有認證流程都是在SSL安全層完成驗證的。今天我就分享HTTPS的實現原理就說這么多了。 ﹏
HTTPS 缺點：
（1）SSL 證書費用很高，以及其在伺服器上的部署、更新維護非常繁瑣。
（2）HTTPS 降低用戶訪問速度（多次握手）。
（3）網站改用HTTPS 以後，由HTTP 跳轉到 HTTPS 的方式增加了用戶訪問耗時（多數網站採用302跳轉）。
（4）HTTPS 涉及到的安全演算法會消耗 CPU 資源，需要增加大量機器（https訪問過程需要加解密）。
『肆』 加密、簽名、證書的作用及運用場景
本文主要是簡單介紹了常見的加密類型、各自的運用場景、為什麼需要數字簽名和數字證書、HTTPS涉及到的加密流程等。這里主要從使用者的角度出發，對演算法本身不做過多介紹。
對稱/非對稱加密均屬於 可逆加密，可以通過密鑰將密文還原為明文 。
有時候，我們希望明文一旦加密後，任何人（包括自己）都無法通過密文逆推回明文，不可逆加密就是為了滿足這種需求。
不可逆加密主要通過 hash演算法實現：即對目標數據生成一段特定長度hash值 ；無論你的數據是1KB、1MB、1GB，都是生成特定長度的一個Hash值（比如128bit）。這里大家應該能感受到一點 不可逆 的味道，加密後128bit的hash值顯然無法還原出1個G甚至更大的不規則數據的， hash可以看做是原來內容的一個摘要 。
常見演算法：
小明給小紅寫信：
經過九轉十八彎後，信的內容有可能：1. 被窺視 2. 被篡改（冒充小明發送假消息） ：
小紅先 生成對稱加密的密鑰key1 ，然後通過一個安全的渠道交予小明。
傳輸數據時，小明 使用key1加密 ，而小紅收到後再 使用key1解密 。
這時候 中間者既看不到原來的內容，也沒辦法篡改 （因為沒有密鑰）：
【對稱加密】實現簡單，性能優秀 ，演算法本身安全級別高。然而對 密鑰的管理 卻是個很頭疼的問題：一旦密鑰交到對方手裡，對方對密鑰的保管能力 我方是沒辦法控制 的，一旦對方泄露的話，加密就形同虛設了。
相對而言，【非對稱加密】的公鑰就沒有這個憂慮，因為 公鑰 的設計就是為了 可以公開的 ，盡管對方泄露，我方也不會有任何損失。
小紅生成一對公私鑰，自己持有私鑰（pri_key1），將公鑰（pub_key1）交予小明。
傳輸數據時，小明使用 公鑰加密 ，小紅使用 私鑰解密 。
因為 中間者沒有私鑰，公鑰加密的內容是無法獲取的 。此時達到了 防窺視 的效果：
然而因為 公鑰是可以公開的 ，如果 中間者知曉公鑰 的話，盡管沒有辦法看到原來的內容，卻 可以冒充小明發送假消息 ：
這時小紅在想，如果小明發送消息時，能帶上 只有他自己才能生成 的數據（字元串），我就能 驗證是不是小明發的真實消息 了。
通常這個 能證實身份的數據（字元串） 被稱之為 數字簽名（Signature）
小明再生成一對公私鑰 ，自己持有私鑰（pri_key2），將公鑰交予小紅（pub_key2）。
當小明傳輸數據時（可能很大），除了公鑰加密明文之外，還要帶上簽名：(1) 對明文做一個hash摘要 (2)對摘要進行私鑰加密，加密結果即簽名（傳輸內容=內容密文+簽名）
小紅收到後：(1) 解密簽名獲取hash (2)解密內容密文，對解密後的明文進行hash；如果兩個hash一致，說明驗簽通過。
盡管中間者修改了傳輸內容，但因為簽名無法冒認（沒有私鑰），小紅驗簽失敗，自然不會認可這份數據：
通常 非對稱加密要做到防窺視和防篡改，需要有兩對公私鑰 ：對方的公鑰用於內容加密，自己的私鑰用於簽名（讓對方驗證身份）。
因為HTTP協議明文通信的安全問題，引入了HTTPS：通過建立一個安全通道（連接），來保證數據傳輸的安全。
伺服器是 沒辦法直接將密鑰傳輸到瀏覽器的 ，因為在 安全連接建立之前，所有通信內容都是明文的 ，中間者可窺視到密鑰信息。
或許這時你想到了非對稱加密，因為公鑰是不怕公開的：
然而在第2步， 中間者可以截取伺服器公鑰，並替換成了自己的公鑰 ，此時加密就沒意義了：
為了 防止公鑰被假冒，數字證書（digital certificate ）便誕生了 。
當伺服器需要告訴瀏覽器公鑰時，並不是簡單地返回公鑰，而是響應 包含公鑰信息在內的數字證書 。
證書主要包含以下內容：
瀏覽器通過 【頒發機構的公鑰】進行解密驗簽 ，驗簽通過即說明證書的真實性，可以放心取 證書擁有者的公鑰 了。（ 常用CA機構的公鑰都已經植入到瀏覽器裡面 ）
數字證書只做一件事： 保證 伺服器響應的 公鑰是真實的 。
以上保證了 [瀏覽器⇒伺服器] 是加密的，然而 [伺服器⇒瀏覽器] 卻沒有（上圖第4步）；另外一個是 性能問題 ，如果所有數據都使用非對稱加密的話，會消耗較多的伺服器資源，通信速度也會受到較大影響。
HTTPS巧妙地結合了非對稱加密和對稱加密，在保證雙方通信安全的前提下，盡量提升性能。
HTTPS（SSL/TLS）期望 建立安全連接後，通信均使用【對稱加密】 。
建立安全連接的任務就是讓 瀏覽器-伺服器協商出本次連接使用的【對稱加密的演算法和密鑰】 ；協商過程中會使用到【非對稱加密】和數字證書。
特別注意的是：協商的密鑰必須是不容易猜到（足夠隨機的）：
其中比較核心的是隨機數r3（pre-master secret），因為之前的r1、r2都是明文傳輸的， 只有r3是加密傳輸 的。至於為什麼需要三個隨機數，可以參考：
以上是一個比較簡單的HTTPS流程，詳細的可以參考文末的引用。
參考資料：
[1] 數字證書應用綜合揭秘
[2] SSL/TLS協議運行機制的概述
[3] 圖解SSL/TLS協議
[4] 《圖解HTTP》