Android-Https
上篇文章我們講到了Android-Http，這次我們緊接著講一下Https。
1. Https簡介
Https協議埠是443，與Http協議相比在早期加入了SSL加密，從而保證了我們的資料在網路上傳輸的安全性。不過現在主流的加密方式是SLL/TLS。TLS的前身就是SSL加密。
2. Http與Https的優缺點
我之前說到過Http協議，我們說他的特點的時候說其： 簡單，靈活，無狀態，無連線 ，正因為這些特點，Http的優點是：通訊速度快，節約時間。
那麼Http協議的缺點呢？我們來總結一下：
- 我們說Http是TCP/IP協議，TCP是確保可靠的協議，但TCP協議並不能保證每次都完整的傳輸資料，也就是可能導致Http層資料不完整，換句話說Http協議傳輸的過程中也並沒有進行資料完整性的校驗，容易被篡改。
- Http是明文傳輸，其傳輸內容容易被竊聽。
- http協議傳輸的過程中沒有身份驗證這一說，也容易被冒充。
不說不知道，一說嚇一跳，正是由於Http協議存在安全性問題，所以Https應運而生，針對於以上缺陷，https增加了兩種技術：加密技術和身份驗證。所以Https的優點是：
- 所有資訊加密傳輸，防止三方竊聽通訊內容
- 具有校驗機制，內容一旦被篡改，通訊雙發立刻會發現
- 配備身份證書，防止身份被冒充
3. Https的加密和身份驗證技術
3.1 Https的加密
因為對稱加密演算法不易保管，再加上安全性也不是很高，所以Https主要用到以DES為代表的對稱加密演算法和以RSA為代表的非對稱加密演算法的混合加密演算法。交換金鑰的時候採取非對稱的，建立通訊交換報文的時候採取對稱加密的方法。
關於對稱和非對稱加密我之前有寫過文章，參考Android-加解密
3.2 Https的身份驗證
所謂身份驗證就是要有數字證書。因為非對稱加密存在一個問題：就是沒法驗證拿到伺服器端公開的公鑰。數字證書可以解決這個問題，數字證書通常來說是由受信任的數字證書頒發機構CA，在驗證伺服器身份後頒發，證書中包含了一個金鑰對（公鑰和私鑰,我們用到公鑰，就包含在數字證書裡）和所有者識別資訊。數字證書被放到服務端，具有伺服器身份驗證和資料傳輸加密功能。這也就是數字證書的左右： 分發公鑰，驗證身份 。
再來一張數字證書的工作流程：
image.png
那麼如何生成數字證書呢？，CA應用而生（Certifity Authority），即數字證書認證機構。
3.3 CA
CA的使用流程：
1.相關人去CA機構進行公鑰申請。
2.CA機構會驗證申請者的資訊真實性，合法性。
3.通過稽核後，CA機構會做數字簽名，給其證書。證書裡面包含申請者的資訊，數字簽名後的公鑰，有效時間和簽名。
4.客戶端https建立連線的時候向服務端要證書。
5.讀取證書資訊，拿公鑰進行解密校驗。
6.客戶端會內建CA的資訊，如果不存在或者資訊不對，證明CA非法
備註：遵循私鑰永遠都是服務端一方掌握。
當然除了CA機構頒發的證書之外，還有 非CA機構頒發的證書和自簽名證書。
- 非CA機構即是不受信任的機構頒發的證書，理所當然這樣的證書是不受信任的。
- 自簽名證書，就是自己給自己頒發的證書。當然自簽名證書也是不受信任的。
比如我們上網經常遇到的情況：
image.png
此情況就是該網站的證書存在問題，不是正式CA機構認證的。
4 Https協議的誤區
誤區一：對於CA機構頒發的證書客戶端無須內建
很多人反映我們用的就是Https為什麼我的客戶端沒有配置證書呢？如：請求百度的網站 https://www.baidu.com/ ，和請求HTTP伺服器沒什麼區別？
答：因為在Android系統中已經內建了所有CA機構的根證書，也就是隻要是CA機構頒發的證書，Android是直接信任的。所以我們才可以在客戶端沒有配置證書的情況下正常請求。但這樣做會有一個安全隱患：比如某個黑客自家搭建了一個伺服器並申請到了CA證書，由於我們客戶端沒有內建伺服器證書，預設信任所有CA證書（客戶端可以訪問所有持有由CA機構頒發的證書的伺服器），那麼黑客仍然可以發起中間人攻擊劫持我們的請求到黑客的伺服器，實際上就成了我們的客戶端和黑客的伺服器建立起了連線，這也就是常說的中間人攻擊。
誤區二：對於非CA機構頒發的證書和自簽名證書，可以忽略證書校驗。
另外一種情況，如果我們伺服器的證書是非認證機構頒發的 或者自簽名證書，那麼我們是無法直接訪問到伺服器的，直接訪問通常會丟擲如下異常：網上很多解決SSLHandshakeException異常的方案是自定義TrustManager忽略證書校驗。對於這樣的處理方式雖然解決了SSLHandshakeException異常，但是卻存在更大的安全隱患。因為此種做法直接使我們的客戶端信任了所有證書（包括CA機構頒發的證書和非CA機構頒發的證書以及自簽名證書），因此，這樣配置將比第一種情況危害更大。
這兩種方式的解決辦法請參考： https://mp.weixin.qq.com/s/E75toyRukUHEtt34-snEgQ 。
5 Https協議的原理
協議的實現：
TLS，記錄協議負責在傳輸連線上交換底層資訊，並加以配置加密。每一條tls記錄包含標頭和訊息內容兩部分。標頭包含型別，版本和長度。和報文類似。盜圖一張：
image.png
TLS有四個核心協議：
- 握手協議：單項最常見，驗證服務端身份。雙向驗證，客戶端和服務端都需要驗證。
- 金鑰變更協議
- 應用協議
- 警報協議
SSL原理（Https加密原理）：
SSL/TLS協議基本思路是採用混合加密的方式。大概流程是，客戶端向伺服器發起請求，然後伺服器收到請求後，傳送伺服器端生成的公鑰給客戶端，客戶端收到加密的公鑰後做兩件事：(1)客戶端自己採用對稱加密生成祕鑰 key ，對傳輸資料進行加密。(2)客戶端用服務端給的公鑰對key進行加密，然後傳送用key加密的傳輸資料和用公鑰加密的key給伺服器(注意此時傳輸在網路的key是用公鑰加密後的)。伺服器端在收到客戶端的資料後用伺服器短的私鑰解密出客戶端用公鑰加密的key,然後用key在將key傳輸資料解密。
SSL詳細過程如下：
-
客戶端給出協議版本號、一個客戶端隨機數A（Client random）以及客戶端支援的加密方式
-
服務端確認雙方使用的加密方式，並給出數字證書(數字證書中包含公鑰P)、一個伺服器生成的隨機數B（Server random）
-
客戶端確認數字證書有效並且接收到隨機數B，自己生成對稱加密的祕鑰Key，對自己要傳給伺服器的資料用Key進行對稱加密。
-
.客戶端使用證書中的公鑰對Key在加密，連同之前用Key加密的資料一起傳送給服務端(注意此時在網路傳輸的Key是用公鑰加密的Key)。
-
服務端使用自己的私鑰解密出對稱加密的Key，之前又收到了隨機數A，客戶端和伺服器根據約定的加密方法，用這個祕鑰Key解密出客戶端要傳個伺服器的資料。
5. Http和Https的區別
最後我們總結一下Http和Https的區別：
-
https協議需要到CA申請證書，大多數情況下需要一定費用
-
Http是超文字傳輸協議，資訊採用明文傳輸，Https則是具有安全性SSL加密傳輸協議
-
Http和Https埠號不一樣，Http是80埠，Https是443埠
-
Http連線是無狀態的，而Https採用Http+SSL構建可進行加密傳輸、身份認證的網路協議，更安全。
-
Http協議建立連線的過程比Https協議快。因為Https除了Tcp三次握手，還要經過SSL握手。連線建立之後資料傳輸速度，二者無明顯區別
其實這篇文章主要是對大神文章的總結，和我個人的理解，再次感謝分享。