HTTPS

關於2017年AppStore新提交應用必須打開ATS的要求只剩下一個多月了，相信大部分開發者都已經完成了從http到https的升級。當然了，現在誰也不知道如果依舊關閉ATS，審核的時候會發生什麼。挑戰apple的事，還是不要做比較好…

最近看完了《HTTPS圖解》，借花獻佛，簡要分享下相關知識點。

HTTP與HTTPS區別

HTTPS的URL以https開頭，默認端口443。HTTP的URL以http開頭，默認端口80。

HTTP未加密，易受“中間人”攻擊和信息竊取，攻擊者可以獲取網站賬號、敏感信息，修改網頁注入惡意軟件或者廣告。

HTTP（超文本傳輸協議）位於應用層，運行在TCP/IP模型的最上層。很重要的一點，HTTPS並不是一個新的或者單獨的協議，而是在一個加密的TLS\SSL鏈接上使用HTTP協議。（HTTP over TLS,HTTP over SSL）

通信加密

HTTP與TLS（Transport Layer Security）、SSL（Secure Sockets Layer）組合使用。

層次關系上，TLS\SSL位於HTTP層之下，因為網絡通信需要一層層的走，所以保護之下的HTTP內的一切消息都是加密的，包括header、request、response、cookie等。

SSL誕生於Netscape，是TLS的前輩，都是保障通信安全的加密協議。現在主流的是TLS 1.0和SSL 3.0。更多歷史故事不在闡述。

內容加密

這裡是說對HTTP的報文進行加密，同時客戶端和服務器之間有協商好的加密解密機制。HTTP自身沒有加密功能，由SSL進行加密的工作。

共享密鑰加密（Common key crypto sytem）

這種方式也稱之為對稱密鑰加密。加密算法是公開，通信雙方都需要一個密鑰，密鑰是為每個連接單獨生成的（The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session），加密解密的時候都得用到這個密鑰。這種方式加密時必須把密鑰也給對方，危險地方在於一旦通信被監聽，被攻擊者拿到密鑰，加密算法就算被攻破了。

公開密鑰加密（public-key cryptography）

非對稱密鑰加密。有兩把密鑰，一個私有密鑰，一個公開密鑰，私有密鑰是嚴格保密的，公開密鑰是公開的。首先發送方使用公開密鑰進行加密，接收方收到信息後，在用自己的私有密鑰進行解密。過程中，不需要發送用來解密的私有密鑰。安全系數較高。不過處理速度要比共享密鑰加密慢。

證書

還有一個風險，通信過程中的公開密鑰可能已經被攻擊者替換了。為了證明服務器的公開密鑰是真的，證書認證機構（CA）和公開密鑰證書就上場了。服務器運營人員向CA申請公開密鑰，CA審核通過後，對申請的公開密鑰做數字簽名，然後就會把該簽名和證書做捆綁。

公鑰證書 = 數字簽名 + 公鑰

服務器再把這份證書發給客戶端，已進行公開密鑰加密通信。

HTTPS通信步驟

先放一張圖，都很熟悉的TCP\IP三次握手

再來一張msdn的SSL握手。

下面客戶端用C表示，服務器用S表示。

• C向S發出Client Hello報文，附帶SSL協議版本號、會話id、加密組件列表（密鑰長度、加密方式）

• S向C發出Server Hello報文，附帶SSL協議版本號、會話id、服務器證書（包含公鑰）、選擇後的加密組件列表（從客戶端發來的篩選的）

• 第一次握手結束後，C向S發出Client Key Exchange報文， 包含一個名叫Pre Master Secret的隨機碼（已用公鑰進行加密），目的提示服務器接下來的報文都用Pre Master Secret機密。

• C繼續發Change Clipher Spec，Finished報文。

• S回應 Change Clipher Spec，Finished報文。

• 安全的通信建立了。

參考資料

• HTTP圖解

• https://en.wikipedia.org/wiki/HTTPS

• https://blogs.msdn.microsoft.com/kaushal/2013/08/02/ssl-handshake-and-https-bindings-on-iis/