iOS ：HTTPS簡析

前言

App的安全問題是咱們在開發過程當中每一個人都會遇到的，而因爲iOS平臺的封閉性，遭遇到的安全問題相比於Android來講要少得多。但除系統安全以外，咱們仍是面臨不少的安全問題：好比網絡安全，下面就簡單的瞭解一下HTTPS是怎麼處理網絡安全問題的。

HTTPS

下面就來了解一下HTTPS;😺

HTTPS的重要性

咱們知道HTTP自己是不具有加密功能的，因此也沒法作到對通訊總體(使用 HTTP 協議通訊的請求和響應的內 容)進行加密。即，HTTP 報文使用明文方式發送。但是不光在HTTP協議中，在其餘未加密的協議中都會存在相似問題：

1️⃣：通訊過程當中使用的是未加密的明文，內容會被取抓。

2️⃣：對於服務器或者客戶端來講，不會驗證通訊方的身份，所以有可能遭到中間人的假裝。

3️⃣：沒法驗證所發送報文的完整性和安全性，並且報文的內容也有多是中間人篡改以後發送過來的。

爲了統一解決上述這些問題，須要在 HTTP 上再加入加密處理和認證等機制。咱們把添加了加密及認證機制 的 HTTP 稱爲 HTTPS。HTTPS開發的主要目的，是提供對網絡服務器的身份認證，保護交換數據的隱私與完整性。

HTTPS介紹

HTTPS超文本傳輸安全協議是一種網絡安全傳輸協議。在計算機網絡上，HTTPS經由超文本傳輸協議HTTP進行通訊，但利用SSL/TLS來加密數據包。TLS/SSL全稱安全傳輸層協議Transport Layer Security, 是介於TCP和HTTP之間的一層安全協議，不影響原有的TCP協議和HTTP協議，具備身份驗證、信息加密和完整性校驗的功能。

以前的 HTTP協議直接放置在 TCP協議之上，而 HTTPS則是在 HTTP和 TCP中間加上一層加密層 SSL。從發送端看，這一層負責把 HTTP的內容加密後送到下層的 TCP，從接收方看，這一層負責將 TCP送來的數據解密還原成 HTTP的內容。因此嚴格地講， HTTPS並非一個單獨的協議，而是對工做在一加密鏈接 TLS/SSL上的常規 HTTP協議的稱呼。

HTTP + 加密 + 證書 + 完整性保護 = HTTPS

加密方式

在瞭解HTTPS通訊加密過程以前先來了解幾個基本概念：

密鑰

密碼學中：密鑰是一種參數，它是在明文轉換爲密文或將密文轉換爲明文的算法中輸入的參數。密鑰分爲對稱密鑰與非對稱密鑰。

對稱加密(共享密鑰加密)

加密和解密同用一個祕鑰的方式稱爲對稱加密

也就是說在發送密文的同時，也會把密鑰發送給對方。

舉個小例子🌰：好比我想寄一些貴重的東西給女友，而後我就搞了個保險櫃，而後把物品存在保險櫃裏（💰💰💰），而後我在鎖好保險櫃以後，把保險櫃郵寄出去，而後把保險櫃密碼告訴女友，但是不當心隔牆有耳👂，有人聽到了這個密碼，那麼完蛋了，個人保險櫃有危險了。這裏物品就是明文信息，保險櫃就是加密後的密文，保險櫃密碼就是密鑰，你看這樣是否是不安全？

⚠️⚠️：注意這裏有個危險，若是不發送密鑰給對方，對方就沒法解密，可是若是在發送密鑰的過程當中，密鑰有可能會被截獲，一旦密鑰泄漏，密碼也就有可能被破解。那麼怎麼解決這個問題呢？🤔🤔🤔

那就是下面這個非對稱加密了！！！👇👇👇

非對稱加密(公開密鑰加密)

非對稱加密使用一對非對稱密鑰，一個叫私有密鑰，另外一個叫公開密鑰公有密鑰隨意發送，任何人均可以得到，私有密鑰不讓任何人知道。

也就是說，發送密文方使用對方的公開密鑰進行加密，對方接受到加密信息後，再使用本身的私有密鑰進行解密。利用這種方式再也不須要發送密鑰，也不用擔憂密鑰被中間人獲取。重要的是在不使用私有密鑰狀況下很難還原被加密的信息。（就比如把熟雞蛋🥚還原成生雞蛋🥚）

再來舉個例子🌰：通過上次的事情以後，我學聰明瞭，我買了一個高級的保險櫃，這個保險櫃有兩個密碼，一個鎖上的密碼，一個打開的密碼，而後女友設置完這兩個密碼以後，把鎖上的密碼告訴我了，而後我把物品裝到保險櫃以後，再次寄出去，此次就不怕別人知道密碼了，由於打開保險櫃的密碼，只有女友知道，其餘人便是知道保險櫃鎖上的密碼也沒有任何用。

HTTPS混合加密

從上面咱們能夠了解到，對稱加密解密的速度比較快，適合數據比較長時的使用，可是缺少安全性，非對稱加密和解密花費的時間長、速度相對較慢，只適合對少許數據的使用，可是相對安全，任何一種方式都沒法知足HTTPS:因此HTTPS採起混合加密的方式；

利用兩種加密方式互補，也就是說，利用非對稱加密方式安全地交換在對稱密鑰加密中要使用的密鑰，在確保密鑰安全前提下，使用對稱密鑰加密方式進行通訊。

進行到這裏會不會以爲一切都結束了，HTTPS安全加密的問題搞定了，其實這裏還存在另一個安全隱患😨😨😨：因爲公鑰是透明公開的，在公鑰的傳輸過程當中，正確的公鑰有可能會被中間人攻擊而替換掉，則可能形成數據的篡改。那麼如何證實收到的公開密鑰是本來預想那臺服務器發行的密鑰呢？🤔🤔🤔

數字證書

爲了解決上述問題，可使用由數字證書認證機構(CA，Certificate Authority)和其相關機關頒發的公開密鑰證書。 https協議中身份認證的部分是由CA數字證書完成的，證書由公鑰、證書主體、數字簽名等內容組成。在客戶端發起SSL請求後，服務端會將數字證書發給客戶端，客戶端會對證書進行驗證（驗證這張證書是不是僞造的？也就是公鑰是不是僞造的），若是證書不是僞造的，客戶端就獲取用於對稱密鑰交換的非對稱密鑰（獲取公鑰）.

數字證書有三個做用：

1️⃣：身份受權，確保瀏覽器訪問的網站是通過CA驗證的可信任的網站。

2️⃣分發公鑰，每一個數字證書都包含了註冊者生成的公鑰（驗證確保是合法的，非僞造的公鑰）。在SSL握手時會經過certificate消息傳輸給客戶端。

3️⃣：驗證證書合法性，客戶端接收到數字證書後，會對證書合法性進行驗證。只有驗證經過後的證書，纔可以進行後續通訊過程。

那麼怎麼就能保證這個公開密鑰是一個正確的公鑰，而不是由中間人僞造的呢？

下面來看一下CA證書的申請流程：

下面經過瀏覽器看一下 web網站的證書：

這裏：

• GlobalSign Root CA是指受信任的根證書頒發機構
• GlobalSign Domain Validation CA - SHA256 - G2 是指受信任的根證書頒發機構下的中級證書頒發機構
• juejin.in是指用戶的SSL證書（是在"受信任的根證書頒發機構"下的"中級證書頒發機構"下頒發的證書）

這個三級證書是咱們將本身生成的CSR提交給簽名商，他們用中級證書機構的私鑰Private Key給咱們的簽名成證書。而他們的的證書又是經過Root CA頒發的（即Root CA經過它的私鑰對中級機構提交的CSR進行了簽名）。

HTTPS通訊機制

通過上面的簡單瞭解，大概已經知道了HTTPS的一個簡單流程，在HTTPS的實際應用中，使用的就是數字證書這種校驗方式。 下面經過一個流程圖來了解一下HTTPS通訊機制：

以上流程圖能夠總結爲一下幾個步驟：

1️⃣：客戶端發起請求，以明文傳輸請求信息，包含SSL版本信息，加密套件候選列表，隨機數random_c，擴展字段等信息。

2️⃣：服務端返回選擇使用的協議版本，選擇的加密套件，選擇的壓縮算法、隨機數random_s等，其中隨機數用於後續的密鑰協商。服務端也會配置並返回對應的證書Certificate，用於身份驗證與密鑰交換。而後會發送Server Hello Done信息用於通知服務端信息發送結束。

3️⃣：客戶端對收到的證書進行校驗，校驗其合法性。

4️⃣：證書驗證合法後， 客戶端計算產生隨機數字Pre-master Key（預設主密鑰），並用服務端證書中的公鑰加密，而後發送給服務端。同時客戶端會根據已有的三個隨機數根據相應的生成協商的通訊密鑰（預主密鑰+兩個隨機數經過複雜算法生成真正的傳輸密鑰）。客戶端會通知服務端後續的通訊都採用協商的通訊密鑰和加密算法進行加密通訊。而後客戶端發送Finished消息用於通知客戶端信息發送結束。

5️⃣：服務端利用私鑰解密獲得預主密鑰，也會根據已有的兩個隨機數使用相應的算法生成通訊密鑰，而後會通知客戶端後續的通訊都採用協商的通訊密鑰和加密算法進行加密通訊。而後發送Finished消息用於通知服務端信息發送結束。

6️⃣：客戶端和服務器數據傳輸開始使用通訊密鑰進行加密通訊。直到客戶端發送斷開鏈接的報文。

爲何不一直使用 HTTPS

這裏可能會有疑問，既然 HTTPS 那麼安全可靠，那什麼還會見到有網站使用HTTP呢，爲什麼全部的 Web網站不一直使用 HTTPS?

由於加密通訊會消耗更多的 CPU及內存資源。若是每次通訊都 加密解密，會消耗至關多的資源。這對於訪問量較大的網站來講是有必定的壓力的。所以，若是是非敏感信息則使用 HTTP 通訊，只有在包含我的信息，密碼等敏感數據時，才利用 HTTPS 加密通訊。好比http://www.zhenai.com/

除此以外，想要節約購買證書的開銷也是緣由之一。 要進行 HTTPS通訊，證書是必不可少的。而使用的證書必須向認證機構(CA)購買。證書價格可能會 根據不一樣的認證機構略有不一樣。那些購買證書並不合算的服務以及一些我的網站，可能只會選擇採用 HTTP的通訊方式。

總結

HTTPS就是要使客戶端與服務器端的通訊過程獲得安全保證。HTTPS利用非對稱加密創建鏈接，利用對稱加密進行數據通訊,數字認證等等，雖然過程很複雜,在保證安全的同時，也提升訪問速度。因此爲了保證數據的安全，維護網絡穩定，仍是要多使用HTTPS協議。 文中若有錯誤還請各位大佬指出。

感謝《圖解HTTP》一書