標籤:

蘋果強制使用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)安全功能。

一、這個舉措意味著什麼?

蘋果公司強制所有iOS App在2017年1月1日前使用HTTPS加密,這就意味著,如果您的APP如果仍採用HTTP傳輸,那麼,在Apple Store中您的APP將不再能被用戶下載使用。

二、什麼是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 應用將默認使用安全連接。

三、為什麼這麼做?

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

四、開發者應該做什麼?

首先需要選擇合適的證書為部署https證書做決策,然後調整後台應用實現後台應用全站https,協調運營及開發完成部署完善服務端應用部署及Web伺服器配置,最後以安全方式發布應用完成應用改造,重新發布應用。

為了讓大家更好的理解上述措施,下面具體介紹一下相關的HTTPS基礎原理和通信過程。

五、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 頁面進行太多的改造。

1、TLS/SSL 原理

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

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

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

在信息傳輸過程中,散列函數不能單獨實現信息防篡改,因為明文傳輸,中間人可以修改信息之後重新計算信息摘要,因此需要對傳輸的信息以及信息摘要進行加密;對稱加密的優勢是信息傳輸1對1,需要共享相同的密碼,密碼的安全是保證信息安全的基礎,伺服器和 N 個客戶端通信,需要維持 N 個密碼記錄,且缺少修改密碼的機制;非對稱加密的特點是信息傳輸1對多,伺服器只需要維持一個私鑰就能夠和多個客戶端進行加密通信,但伺服器發出的信息能夠被所有的客戶端解密,且該演算法的計算複雜,加密速度慢。

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

2、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.證書=公鑰+申請者與頒發者信息+簽名;

六、HTTPS介面測試

那麼在完成了全站HTTPS,完成了後台和伺服器端的部署之後,如何快速的對「新站「進行快速的測試,檢測APP介面的承載能力?

騰訊WeTest提供了針對https的伺服器性能測試功能,使用方法如下:

1、點擊伺服器性能測試產品首頁(WeTest伺服器性能|壓力|負載測試 高並發,實時性能報表,專家級性能優化建議【騰訊WeTest】 )中的快捷入口:HTTP直壓。模式選擇簡單模式,名稱和描述可以自己填寫。(圖中示例起始人數50人,每隔60秒增加50人,加到200人為上限)

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

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

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

配置頁面header信息

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

查看頁面header信息

到這裡,基本就完成了對https的配置過程了,是不是很簡單?下面動圖可以再回顧一下操作的流程:

gif動態圖展示操作的流程

七、HTTPS性能與優化

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

1、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 接入的主要難題。

2、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


推薦閱讀:

如何用機器學習方法,提升另一半的滿意指數?
直擊阿里雙11神秘技術:PB級大規模文件分發系統「蜻蜓」

TAG:HTTPS |