三、 android借鑑
參考文獻
我們也都知道，一般 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 和 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 證書的有效時間和網域名稱匹配等。除此之外，還會校驗 ca 證書的有效時間和網域名稱匹配等。
在 https 加密原理的過程中把對稱加密和非對稱加密都利用了起來，ssl協議是用非對稱密碼演算法來協商金鑰，並使用金鑰加密明文並傳輸的
假設現在有客戶端 a 和伺服器 b ：
這時候客戶端 a 會生成乙個隨機數1，把隨機數1 、自己支援的 ssl 版本號以及支援的加密演算法(譬如說，對稱加密演算法有des,rc5,金鑰交換演算法有rsa和dh，摘要演算法有md5和sha)等這些資訊告訴伺服器 b。
伺服器 b 知道這些資訊後，然後確認一下雙方的加密演算法，」用des－rsa－sha這對組合好了「，然後服務端也生成乙個隨機數 b ，並將隨機數 b 和 ca 頒發給自己的證書一同返回給客戶端 a。
客戶端 a 得到 ca 證書後，會去校驗該 ca 證書的有效性，校驗方法在上面已經說過了。校驗通過後，客戶端生成乙個隨機數3 ，然後用證書中的公鑰加密隨機數3 並傳輸給服務端 b。
服務端b 得到加密後的隨機數3，然後利用私鑰進行解密，得到真正的隨機數3。
最後，客戶端 a 和服務端 b 都有隨機數1、隨機數2、隨機數3，然後雙方利用這三個隨機數生成乙個對話金鑰。之後傳輸內容就是利用對話金鑰來進行加解密了。這時就是利用了對稱加密，一般用的都是 aes 演算法，也就是上文約定好的協議。
客戶端 a 通知服務端 b ，指明後面的通訊用對話金鑰來完成，同時通知伺服器 b 客戶端 a 的握手過程結束。
服務端 b 通知客戶端 a，指明後面的通訊用對話金鑰來完成，同時通知客戶端 a 伺服器 b 的握手過程結束。
ssl 的握手部分結束，ssl 安全通道的資料通訊開始，客戶端 a 和伺服器 b 開始使用相同的對話金鑰進行資料通訊。
到此，ssl 握手過程就講完了。可能上面的流程太過於複雜，我們簡單地來講：
先由伺服器建立rsa金鑰對，rsa公鑰儲存在安卓的so檔案裡面，伺服器儲存rsa私鑰。
安卓建立aes金鑰（這個金鑰也是在so檔案裡面），並用該aes金鑰加密待傳送的明文資料安卓傳送資訊時，用儲存的rsa公鑰加密aes金鑰，最後把用rsa公鑰加密後的aes金鑰同密文一起通過internet傳輸傳送到伺服器。
當伺服器收到這個被加密的aes金鑰和密文後，首先呼叫伺服器儲存的rsa私鑰，並用該私鑰解密加密的aes金鑰，得到aes金鑰。最後用該aes金鑰解密密文得到明文。
HTTPS加密原理
字數 2314 閱讀 630 喜歡 90 http https在我們日常開發中是經常會接觸到的。我們也都知道，一般 android 應用開發，在請求 api 網路介面的時候，很多使用的都是 http 協議 使用瀏覽器開啟網頁，也是利用 http 協議。看來 http 真是使用廣泛啊，但是，http ...
HTTPS加密原理
http是超文字傳輸協議，是一種客戶端和伺服器端請求和應答的標準，可以使瀏覽器更加高效。https是以安全為目標的http通道，https是在http基礎上加上ssl層 https協議需要ca證書認證，費用較高 http是超文字傳輸協議，資訊是明文傳輸 https是具有安全性的ssl加密傳輸協議 使...
https 加密原理
最近因為專案需求，需要將http公升級到https，所以抽空 了下其中的加密原理。為什麼要使用https http 明文傳輸，不夠安全。竊聽風險 黑客可以獲知通訊內容。篡改風險 黑客可以修改通訊內容。冒充風險 黑客可以冒充他人身份參與通訊。為了保障訊息的保密性，後面出現了對稱加密以及非對稱加密 對稱...