當咱們談網絡時，咱們談些什麼(3)Https

最近參與的項目中，因爲使用了自簽名的Https，因爲以前的項目中並無接觸過Https，因此在接入以後出現了一些問題。在進行網絡請求的時候拋出了以下異常。

java.security.cert.CertPathValidatorException:
 Trust anchor for certification path not found

同時在使用WebView進行裝載頁面的時候，也出現了頁面空白的問題。藉此機會，準備對Https進行一個系統的學習。從爲何要使用Https，Https的實現原理，在Android中Https的應用。

爲何須要Https

• 內容劫持

上面的幾個圖，在平時咱們使用手機的過程當中是常常出現的一個現象。產生上述問題的緣由是咱們在數據傳輸的時候經過http進行傳輸致使了被運營商劫持，而後修改了其中的內容。

• 敏感數據

同時也會有一些我的開啓wifi，而後對其中內容作嗅探，獲取其中的敏感數據。爲了提高用戶體驗，採用Https是一個不錯的方式，相比於採用本身的協議方便不少。

補充知識

Https是什麼？

HTTPS經由HTTP進行通訊，但利用SSL/TLS來加密數據包。
HTTPS的主要思想是在不安全的網絡上建立一安全信道，並可在使用適當的加密包和服務器證書可被驗證且可被信任時，對竊聽和中間人攻擊提供合理的防禦。

SSL協議在通訊過程當中起了兩個做用：

一、確保通訊雙方身份沒有僞造，經過數字證書實現。

二、確保與服務器之間的通信不能被第三方竊取、修改。

瞭解https通訊過程還需知道兩種加密方式：非對稱加密和對稱加密。客戶端與服務器進行安全數據交互以前，需在非對稱祕鑰的加密保護下生成用於會話期數據加密的對稱祕鑰。

3.1 對稱加密算法
對稱加密是指：加密和解密使用相同密鑰的算法。它要求發送方和接收方在安全通訊以前，商定一個對稱密鑰。對稱算法的安全性徹底依賴於密鑰，密鑰泄漏就意味着任何人均可以對他們發送或接收的消息解密，因此密鑰的保密性對通訊相當重要。

3.1.1 對稱加密又分爲兩種模式：流加密和分組加密

流加密是將消息做爲字節流對待，而且使用數學函數分別做用在每個字節位上。使用流加密時，每加密一次，相同的明文位會轉換成不一樣的密文位。流加密使用了密鑰流生成器，它生成的字節流與明文字節流進行異或，從而生成密文。

分組加密是將消息劃分爲若干個分組，這些分組隨後會經過數學函數進行處理，每次一個分組。假設使用64位的分組密碼，此時若是消息長度爲640位，就會被劃分紅10個64位的分組（若是最後一個分組長度不到64，則用0補齊以後加到64位），每一個分組都用一系列數學公式進行處理，最後獲得10個加密文本分組。而後，將這條密文消息發送給對端。對端必須擁有相同的分組密碼，以相反的順序對10個密文分組使用前面的算法解密，最終獲得明文消息。比較經常使用的分組加密算法有DES、3DES、AES。其中DES是比較老的加密算法，如今已經被證實不安全。而3DES是一個過渡的加密算法，至關於在DES基礎上進行三重運算來提升安全性，但其本質上仍是和DES算法一致。而AES是DES算法的替代算法，是如今最安全的對稱加密算法之一。

3.1.2 對稱加密算法的優缺點：

優勢：計算量小、加密速度快、加密效率高。

缺點：

（1）交易雙方都使用一樣密鑰，安全性得不到保證；

（2）每次使用對稱加密算法時，都須要使用其餘人不知道的唯一密鑰，這會使得發收信息雙方所擁有的鑰匙數量呈幾何級數增加，密鑰管理成爲負擔。

在非對稱密鑰交換算法出現之前，對稱加密的最主要缺陷就是不知道如何在通訊雙方之間傳輸對稱密鑰，而又不讓中間人竊取。非對稱密鑰交換算法誕生以後，專門針對對稱密鑰傳輸作加解密，使得對稱密鑰的交互傳輸變得很是安全了。
非對稱密鑰交換算法自己很是複雜，密鑰交換過程涉及到隨機數生成，模指數運算，空白補齊，加密，簽名等等一系列極其複雜的過程，做者本人也沒有研究徹底透徹。常見的密鑰交換算法有RSA，ECDHE，DH，DHE等算法。涉及到比較複雜的數學問題。其中，最經典也是最經常使用的是RSA算法。

3.2.1 非對稱加密相比對稱加密更加安全，但也存在兩個致命的缺點：
（1）CPU計算資源消耗很是大。一次徹底TLS握手，密鑰交換時的非對稱解密計算量佔整個握手過程的90%以上。而對稱加密的計算量只至關於非對稱加密的0.1%。若是後續的應用層數據傳輸過程也使用非對稱加解密，那麼CPU性能開銷太龐大，服務器是根本沒法承受的。賽門特克給出的實驗數據顯示，加解密同等數量的文件，非對稱算法消耗的CPU資源是對稱算法的1000倍以上。

（2）非對稱加密算法對加密內容的長度有限制，不能超過公鑰長度。好比如今經常使用的公鑰長度是2048位，意味着待加密內容不能超過256個字節。

因此非對稱加解密（極端消耗CPU資源）目前只能用來做對稱密鑰交換或者CA簽名，不適合用來作應用層內容傳輸的加解密。

SSL介紹：

安全套接字（Secure Socket Layer，SSL）協議是Web瀏覽器與Web服務器之間安全交換信息的協議，提供兩個基本的安全服務：鑑別與保密。

SSL是Netscape於1994年開發的，後來成爲了世界上最著名的web安全機制，全部主要的瀏覽器都支持SSL協議

目前有三個版本：二、三、3.1，最經常使用的是第3版，是1995年發佈的。

SSL協議的三個特性

① 保密：在握手協議中定義了會話密鑰後，全部的消息都被加密。

② 鑑別：可選的客戶端認證，和強制的服務器端認證。

③ 完整性：傳送的消息包括消息完整性檢查（使用MAC）。

SSL的位置

SSL介於應用層和TCP層之間。應用層數據再也不直接傳遞給傳輸層，而是傳遞給SSL層，SSL層對從應用層收到的數據進行加密，並增長本身的SSL頭。

Https創建過程？

SSL鏈接創建過程
客戶端和服務器交換數據以前有個握手協議，具體過程是：

一、客戶端初始化支持的加密算法、壓縮算法、SSL協議版本，並向服務器發起消息結構體爲client hello的鏈接

二、服務端收到消息，根據客戶端提供的加密算法列表、壓縮算法列表來選取後續使用的對稱加密算法、壓縮算法和SSL協議版本，並返回結構體爲server hello的消息。

三、若是客戶端須要服務器身份認證，服務器在返回server hello的消息後需馬上返回數字證書信息（一般服務器認證是必須的），併發送hello done的消息。

四、客戶端驗證證書是否有效，併發送用證書公鑰加密的對稱祕鑰。

五、服務器收到加密的對稱祕鑰，使用本身的私鑰解密，併發送經過對稱祕鑰加密的的會話完成信息 （finish信息）。

證書校驗過程

頒發證書的機構會將證書內容使用指定的哈希函數生成內容hash，而後用本身的私鑰加密哈希造成簽名。證書指紋用於肯定證書沒有被修改。解密驗證過程如上右圖，若是最終獲得的簽名與客戶端使用指定的簽名算法獲得的簽名不一致，則證書是不可信的。

參考資料

Android安全開發之安全使用HTTPS
https通訊原理