Android HTTPS導讀
概述：在客戶端和服務器之間協商出一套對稱祕鑰，每次發送信息之前將內容加密，收到之後解密，達到內容的加密傳輸。
寫這篇的目的，本來是想研究 Android 的簽名機制，其中涉及到數字簽名和數字證書，於是索性把 HTTPS 也研究下。
本文主要是對其他文章的一個理解註釋。
對稱加密
非對稱加密
消息摘要
數字簽名
數字證書
以上這幾個概念需要提前理解，可參考這幾篇文章：Android安全加密專題 ，Android 應用程序簽名過程分析
正文
爲什麼需要 https？客戶端與服務器之間通過 http 協議傳輸數據，這本身沒問題，但是網絡環境不是安全可靠的，總會有不法分子想要竊取篡改數據。那麼如何防止這種情況呢？我們第一想法把數據加密起來，這樣別人就看不懂了。那麼怎樣的加密是安全的呢，我們不管，有高人會。他們的做法就是 https，https 是什麼？http 是一個應用層協議，會把要發送的消息交給 TCP 傳輸層，將消息可靠的交付出去。這個時候我們想把應用層的數據進行加密後再傳輸，怎麼做？簡單，再加一層協議好了，於是這一層叫 TLS（Transport Layer Security 傳輸層安全），這一層是在應用層和傳輸層之間的。這樣子 https 就出來了。
確保可靠通信的原則
確定消息的來源確實是其申明的那個人。
保證信息在傳遞過程中不被篡改，即使被篡改了，也可以發覺出來。
那麼 TLS 層是怎麼進行加密的？
在客戶端和服務器之間協商出一套對稱祕鑰，每次發送信息之前將內容加密，收到之後解密，達到內容的加密傳輸。
也就是說是通過對稱加密來實現的，那這個對稱祕鑰怎麼保證安全呢？
在客戶端與服務器通過非對稱加密交換祕鑰。
非對稱加密中，接收方如何保證公鑰的正確性呢？
通過 數字簽名 + 數字證書。
Android 安全加密：數字簽名和數字證書 在這篇文章中 簽名過程 那個圖，可以很好的理解數字簽名到底是怎麼回事的。
“發送報文時，發送方用一個哈希函數從報文文本中生成報文摘要,然後用自己的私鑰對這個摘要進行加密，這個加密後的摘要將作爲報文的數字簽名和報文一起發送給接收方，接收方首先用與發送方一樣的哈希函數從接收到的原始報文中計算出報文摘要，接着再用發送方的公鑰來對報文附加的數字簽名進行解密，如果這兩個摘要相同、那麼接收方就能確認該數字簽名是發送方的。
數字簽名有兩種功效：一是能確定消息確實是由發送方簽名併發出來的，因爲別人假冒不了發送方的簽名。二是數字簽名能確定消息的完整性。因爲數字簽名的特點是它代表了文件的特徵，文件如果發生改變，數字摘要的值也將發生變化。不同的文件將得到不同的數字摘要。一次數字簽名涉及到一個哈希函數、發送者的公鑰、發送者的私鑰。”
問題：在發送過程中，被第三方攻擊者攔截了怎麼辦。攻擊者能幹嘛？接收方如何通過數字簽名校驗是否被攔截了。
攻擊者直接修改消息（明文）。由於有數字簽名的存在，接收方最後計算出的 Hash 值肯定與發送方的不一致，因此接收方可以判斷出消息有問題。
攻擊者直接修改簽名。接收方用發送方的公鑰肯定解不開，因此也能判斷。
攻擊者修改消息（明文），然後利用自己的私鑰做簽名，同時把自己的公鑰給接收方。這時接收方無法判斷出消息有問題了。
由此可見，在數字簽名這種機制中，最重要的一件事就是接收方必須持有正確的公鑰，否則一切白搭。
那麼如何保證呢？數字證書
數字證書也用到了數字簽名的技術，只不過要簽名的內容是發送方的公鑰。發送方通過把自己的公鑰進行數字簽名發送給接收方，這樣可以防止第三方修改發送方公鑰。那麼誰來對這個公鑰進行簽名呢？CA。CA 用自己的私鑰對發送方的公鑰進行簽名，那麼接收方需要 CA 的公鑰來對這個數字證書進行驗證。 又回到了公鑰的問題上，CA 的公鑰哪來呢？一般來說，CA 的根證書已經在設備出廠前預先就安裝到你的設備上了的。所以這就保證了 CA 的公鑰是正確的。
由此我們可以知道數字簽名+數字證書可以保證 發送方的身份以及發送方所發數據的完整性。而數字簽名中又用到了非對稱加密以及消息摘要。
因此我們可以保證公鑰能夠被正確的發送到客戶端手中。
爲什麼不全程使用非對稱加密？
非對稱加密由於使用了複雜的數學原理，因此計算相當複雜，如果完全使用非對稱加密來加密通信內容，會嚴重影響網絡通信的性能。