蘋果強制使用HTTPS傳輸了怎麼辦？——關於HTTPS，APP開發者必須知道的事

WeTest 導讀

2017年1月1日起，蘋果公司將強制使用HTTPS協議傳輸。本文經過對HTTPS基礎原理和通訊過程內容的講解，介紹APP開發者在這個背景下的應對辦法。

---

 

幾周前，咱們在《https大勢已來？看騰訊專家如何在高併發壓測中支持https》中介紹了騰訊WeTest在基於epoll的高併發機器人框架中加入openssl的方法支持HTTPS接口測試的方法，不只介紹了具體的使用辦法，而且瞭解到HTTPS註定會是將來的主流趨勢。

 

而隨着2016年行將結束，咱們發現，這一天，已經愈來愈近了。

 

隨着全球互聯網安全意識的進一步覺醒，愈來愈多的公司意識到網絡信息安全的重要性，只有絕對的加密才能保證在線交易和商務活動的安全進行。互聯網無疑是我的信息和隱私泄露最頻繁的場合，各類以竊取信息爲方式而展開的網絡犯罪是互聯網發展所面臨的最大挑戰。在這樣一個大環境下，蘋果公司首先作出應對，在蘋果全球開發者大會（WWDC）的一場安全演示會上，蘋果公司公佈了一個最後期限——2017 年 1 月 1 日——即 App Store 當中的全部應用必須啓用 App Transport Security （ATS）安全功能。

 

1、這個舉措意味着什麼？

 

蘋果公司強制全部iOS App在2017年1月1日前使用HTTPS加密，這就意味着，若是您的APP若是仍採用HTTP傳輸，那麼，在Apple Store中您的APP將再也不能被用戶下載使用。

 

2、什麼是App Transport Security （ATS）安全功能？

 

App Transport Security，簡稱 ATS，是蘋果在 iOS 9 當中首次推出的一項安全功能。在啓用 ATS 以後，它會強制應用經過 HTTPS（而不是 HTTP）鏈接網絡服務，這可以經過加密來保障用戶數據安全。

 

HTTPS 當中的「S」表明的是「安全」（secure），在登陸銀行或電郵帳號時，你會經常看到它出如今瀏覽器地址欄。不過，移動應用在網絡鏈接安全性上面沒有那麼透明，用戶很難知道應用鏈接網絡時使用的是 HTTP 仍是 HTTPS。

 

ATS 由此登場，它在 iOS 9 當中是默認開啓的。然而，開發者仍然可以關閉 ATS，讓本身的應用經過 HTTP 鏈接傳輸數據——如今的狀況是，這招在年末以後就行不通了。（技術人員注意：ATS 要求使用 TLS v 1.2，但那些已經通過加密的批量數據例外，好比流媒體數據。）

 

在今年年末時，蘋果將要求全部提交到 App Store 的應用強制開啓 ATS。如今有了明確的最終期限，那些一直 想知道 HTTP 會在何時遭此重擊的應用開發者能夠鬆一口氣了，而用戶也能安心地知道，他們的 iPhone 和 iPad 應用將默認使用安全鏈接。

 

3、爲何這麼作？

 

企業對於網絡信息安全的也愈來愈高，只有保證絕對的加密傳輸才能確保在線交易及用戶我的隱私數據的安全性。因爲HTTP明文傳輸帶來的安全事件頻發，企業對於HTTP已無信任可言，只有經過HTTPS加密傳輸纔能有效的防釣魚，防篡改，防監聽，防劫持使網站安全可信。

 

4、開發者應該作什麼？

 

首先須要選擇合適的證書爲部署https證書作決策，而後調整後臺應用實現後臺應用全站https，協調運營及開發完成部署完善服務端應用部署及Web服務器配置，最後以安全方式發佈應用完成應用改造，從新發布應用。

爲了讓你們更好的理解上述措施，下面具體介紹一下相關的HTTPS基礎原理和通訊過程。

 

5、HTTPS的基礎原理和通訊過程

 

HTTPS(Secure Hypertext Transfer Protocol) 安全超文本傳輸協議 它是一個安全通訊通道，它基於 HTTP 開發，用於在客戶計算機和服務器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來講它是 HTTP 的安全版,是使用 TLS/SSL 加密的 HTTP 協議。

HTTP 協議採用明文傳輸信息，存在信息竊聽、信息篡改和信息劫持的風險，而協議 TLS/SSL 具備身份驗證、信息加密和完整性校驗的功能，能夠避免此類問題。

 

TLS/SSL 全稱安全傳輸層協議 Transport Layer Security, 是介於 TCP 和 HTTP 之間的一層安全協議，不影響原有的 TCP 協議和 HTTP 協議，因此使用 HTTPS 基本上不須要對 HTTP 頁面進行太多的改造。

 

一、TLS/SSL 原理

HTTPS 協議的主要功能基本都依賴於 TLS/SSL 協議，本節分析安全協議的實現原理。

TLS/SSL 的功能實現主要依賴於三類基本算法：散列函數 Hash、對稱加密和非對稱加密，其利用非對稱加密實現身份認證和密鑰協商，對稱加密算法採用協商的密鑰對數據加密，基於散列函數驗證信息的完整性。

 

 

散列函數 Hash，常見的有 MD五、SHA一、SHA256，該類函數特色是函數單向不可逆、對輸入很是敏感、輸出長度固定，針對數據的任何修改都會改變散列函數的結果，用於防止信息篡改並驗證數據的完整性；對稱加密，常見的有 AES-CBC、DES、3DES、AES-GCM等，相同的密鑰能夠用於信息的加密和解密，掌握密鑰才能獲取信息，可以防止信息竊聽，通訊方式是1對1；非對稱加密，即常見的 RSA 算法，還包括 ECC、DH 等算法，算法特色是，密鑰成對出現，通常稱爲公鑰(公開)和私鑰(保密)，公鑰加密的信息只能私鑰解開，私鑰加密的信息只能公鑰解開。所以掌握公鑰的不一樣客戶端之間不能互相解密信息，只能和掌握私鑰的服務器進行加密通訊，服務器能夠實現1對多的通訊，客戶端也能夠用來驗證掌握私鑰的服務器身份。

 

在信息傳輸過程當中，散列函數不能單獨實現信息防篡改，由於明文傳輸，中間人能夠修改信息以後從新計算信息摘要，所以須要對傳輸的信息以及信息摘要進行加密；對稱加密的優點是信息傳輸1對1，須要共享相同的密碼，密碼的安全是保證信息安全的基礎，服務器和 N 個客戶端通訊，須要維持 N 個密碼記錄，且缺乏修改密碼的機制；非對稱加密的特色是信息傳輸1對多，服務器只須要維持一個私鑰就可以和多個客戶端進行加密通訊，但服務器發出的信息可以被全部的客戶端解密，且該算法的計算複雜，加密速度慢。

 

結合三類算法的特色，TLS 的基本工做方式是，客戶端使用非對稱加密與服務器進行通訊，實現身份驗證並協商對稱加密使用的密鑰，而後對稱加密算法採用協商密鑰對信息以及信息摘要進行加密通訊，不一樣的節點之間採用的對稱密鑰不一樣，從而能夠保證信息只能通訊雙方獲取。

 

二、PKI 體系

（1）RSA 身份驗證的隱患

身份驗證和密鑰協商是 TLS 的基礎功能，要求的前提是合法的服務器掌握着對應的私鑰。但 RSA 算法沒法確保服務器身份的合法性，由於公鑰並不包含服務器的信息，存在安全隱患：

客戶端 C 和服務器 S 進行通訊，中間節點 M 截獲了兩者的通訊；

 

節點 M 本身計算產生一對公鑰 pub_M 和私鑰 pri_M;

C 向 S 請求公鑰時，M 把本身的公鑰 pub_M 發給了 C;

C 使用公鑰 pub_M 加密的數據可以被 M 解密，由於 M 掌握對應的私鑰 pri_M，而 C 沒法根據公鑰信息判斷服務器的身份，從而 C 和 M 之間創建了」可信」加密鏈接；

中間節點 M 和服務器S之間再創建合法的鏈接，所以 C 和 S 之間通訊被M徹底掌握，M 能夠進行信息的竊聽、篡改等操做。

 

另外，服務器也能夠對本身的發出的信息進行否定，不認可相關信息是本身發出。

 

所以該方案下至少存在兩類問題：中間人攻擊和信息抵賴。

 

 

幾周前，咱們在《https大勢已來？看騰訊專家如何在高併發壓測中支持https》中介紹了騰訊WeTest在基於epoll的高併發機器人框架中加入openssl的方法支持HTTPS接口測試的方法，不只介紹了具體的使用辦法，而且瞭解到HTTPS註定會是將來的主流趨勢。

 

而隨着2016年行將結束，咱們發現，這一天，已經愈來愈近了。

 

隨着全球互聯網安全意識的進一步覺醒，愈來愈多的公司意識到網絡信息安全的重要性，只有絕對的加密才能保證在線交易和商務活動的安全進行。互聯網無疑是我的信息和隱私泄露最頻繁的場合，各類以竊取信息爲方式而展開的網絡犯罪是互聯網發展所面臨的最大挑戰。在這樣一個大環境下，蘋果公司首先作出應對，在蘋果全球開發者大會（WWDC）的一場安全演示會上，蘋果公司公佈了一個最後期限——2017 年 1 月 1 日——即 App Store 當中的全部應用必須啓用 App Transport Security （ATS）安全功能。

 

（2）身份驗證-CA 和證書

解決上述身份驗證問題的關鍵是確保獲取的公鑰途徑是合法的，可以驗證服務器的身份信息，爲此須要引入權威的第三方機構 CA。CA 負責覈實公鑰的擁有者的信息，並頒發認證」證書」，同時可以爲使用者提供證書驗證服務，即 PKI 體系。

基本的原理爲，CA 負責審覈信息，而後對關鍵信息利用私鑰進行」簽名」，公開對應的公鑰，客戶端能夠利用公鑰驗證簽名。CA 也能夠吊銷已經簽發的證書，基本的方式包括兩類 CRL 文件和 OCSP。CA 使用具體的流程以下：

 

 

a.服務方 S 向第三方機構CA提交公鑰、組織信息、我的信息(域名)等信息並申請認證；

 

b.CA 經過線上、線下等多種手段驗證申請者提供信息的真實性，如組織是否存在、企業是否合法，是否擁有域名的全部權等；

 

c.如信息審覈經過，CA 會向申請者簽發認證文件-證書。

證書包含如下信息：申請者公鑰、申請者的組織信息和我的信息、簽發機構 CA 的信息、有效時間、證書序列號等信息的明文，同時包含一個簽名；

簽名的產生算法：首先，使用散列函數計算公開的明文信息的信息摘要，而後，採用 CA 的私鑰對信息摘要進行加密，密文即簽名；

 

d.客戶端 C 向服務器 S 發出請求時，S 返回證書文件；

 

e.客戶端 C 讀取證書中的相關的明文信息，採用相同的散列函數計算獲得信息摘要，而後，利用對應 CA 的公鑰解密簽名數據，對比證書的信息摘要，若是一致，則能夠確認證書的合法性，即公鑰合法；

 

f.客戶端而後驗證證書相關的域名信息、有效時間等信息；

 

g.客戶端會內置信任 CA 的證書信息(包含公鑰)，若是CA不被信任，則找不到對應 CA 的證書，證書也會被斷定非法。

 

在這個過程注意幾點：

1.申請證書不須要提供私鑰，確保私鑰永遠只能服務器掌握；

2.證書的合法性仍然依賴於非對稱加密算法，證書主要是增長了服務器信息以及簽名；

3.內置 CA 對應的證書稱爲根證書，頒發者和使用者相同，本身爲本身簽名，即自簽名證書；

4.證書=公鑰+申請者與頒發者信息+簽名；

 

6、HTTPS接口測試

 

那麼在完成了全站HTTPS，完成了後臺和服務器端的部署以後，如何快速的對「新站「進行快速的測試，檢測APP接口的承載能力？

騰訊WeTest提供了針對https的服務器性能測試功能，使用方法以下：

 

一、點擊服務器性能測試產品首頁（http://wetest.qq.com/gaps/ ）中的快捷入口：HTTP直壓。模式選擇簡單模式，名稱和描述能夠本身填寫。（圖中示例起始人數50人，每隔60秒增長50人，加到200人爲上限）

 

 

點擊左側「HTTP直壓「進入壓測

 

 

輸入合適的測試標題和測試設置

 

二、新建一個客戶端請求，接口壓測包括讀寫接口，讀接口基本是GET請求，寫接口基本是POST請求。GET請求使用url請求參數，填寫測試用例的基礎數值，選擇正確的URL

 

 

配置頁面header信息

 

三、隨後進行Header的配置，Header的名稱在選定URL的內，打開URL的連接（推薦使用chrome瀏覽器），敲擊F12並刷新頁面，選定Network-Name-Headers-Request Headers（Header的名稱與值均在內查看，以下圖所示）

 

查看頁面header信息

 

 

到這裏，基本就完成了對https的配置過程了，是否是很簡單？下面動圖能夠再回顧一下操做的流程：

 gif動態圖展現操做的流程

 

7、HTTPS性能與優化

在對HTTPS協議頁面進行了測試以後，下面再介紹一些HTTPS頁面性能優化的方法。

 

一、HTTPS 性能損耗

HTTPS的優點在於進行完身份驗證、信息加密與完整性校驗等操做後，能夠不對 TCP 和 HTTP 協議作任何修改。但經過增長新協議以實現更安全的通訊必然須要付出代價，HTTPS 協議的性能損耗主要體現以下：

（1）增長延時

分析前面的握手過程，一次完整的握手至少須要兩端依次來回兩次通訊，至少增長延時2 RTT，利用會話緩存從而複用鏈接，延時也至少1 RTT*。

 

（2）消耗較多的 CPU 資源

除數據傳輸以外，HTTPS 通訊主要包括對對稱加解密、非對稱加解密(服務器主要採用私鑰解密數據)；壓測 TS8 機型的單核 CPU：對稱加密算法AES-CBC-256 吞吐量 600Mbps，非對稱 RSA 私鑰解密200次/s。不考慮其它軟件層面的開銷，10G 網卡爲對稱加密須要消耗 CPU 約17核，24核CPU最多接入 HTTPS 鏈接 4800；

 

靜態節點當前10G 網卡的 TS8 機型的 HTTP 單機接入能力約爲10w/s，若是將全部的 HTTP 鏈接變爲HTTPS鏈接，則明顯 RSA 的解密最早成爲瓶頸。所以，RSA 的解密能力是當前困擾 HTTPS 接入的主要難題。

 

二、HTTPS 接入優化

（1）CDN 接入

HTTPS 增長的延時主要是傳輸延時 RTT，RTT 的特色是節點越近延時越小，CDN 自然離用戶最近，所以選擇使用 CDN 做爲 HTTPS 接入的入口，將可以極大減小接入延時。CDN 節點經過和業務服務器維持長鏈接、會話複用和鏈路質量優化等可控方法，極大減小 HTTPS 帶來的延時。

 

（2）會話緩存

雖然前文提到 HTTPS 即便採用會話緩存也要至少1*RTT的延時，可是至少延時已經減小爲原來的一半，明顯的延時優化；同時，基於會話緩存創建的 HTTPS 鏈接不須要服務器使用RSA私鑰解密獲取 Pre-master 信息，能夠省去CPU 的消耗。若是業務訪問鏈接集中，緩存命中率高，則HTTPS的接入能力講明顯提高。當前 TRP 平臺的緩存命中率高峯時期大於30%，10k/s的接入資源實際能夠承載13k/的接入，收效很是可觀。

 

（3）硬件加速

爲接入服務器安裝專用的 SSL 硬件加速卡，做用相似 GPU，釋放 CPU，可以具備更高的 HTTPS 接入能力且不影響業務程序的。測試某硬件加速卡單卡能夠提供 35k 的解密能力，至關於175核 CPU，至少至關於7臺24核的服務器，考慮到接入服務器其它程序的開銷，一張硬件卡能夠實現接近10臺服務器的接入能力。

 

（4）遠程解密

本地接入消耗過多的 CPU 資源，浪費了網卡和硬盤等資源，考慮將最消耗 CPU 資源的RSA解密計算任務轉移到其它服務器，如此則能夠充分發揮服務器的接入能力，充分利用帶寬與網卡資源。遠程解密服務器能夠選擇 CPU 負載較低的機器充當，實現機器資源複用，也能夠是專門優化的高計算性能的服務器。當前也是 CDN 用於大規模HTTPS接入的解決方案之一。

 

（5）SPDY/HTTP2

前面的方法分別從減小傳輸延時和單機負載的方法提升 HTTPS 接入性能，可是方法都基於不改變 HTTP 協議的基礎上提出的優化方法，SPDY/HTTP2 利用 TLS/SSL 帶來的優點，經過修改協議的方法來提高 HTTPS 的性能，提升下載速度等。

 

---

騰訊WeTest服務器性能測試運用了沉澱十多年的內部實踐經驗總結，經過基於真實業務場景和用戶行爲進行壓力測試，幫助遊戲開發者發現服務器端的性能瓶頸，進行鍼對性的性能調優，下降服務器採購和維護成本，提升用戶留存和轉化率。

功能目前免費對外開放中，歡迎你們的體驗

體驗地址：http://WeTest.qq.com/gaps/

若是對使用當中有任何疑問，歡迎聯繫騰訊WeTest企業qq：800024531