HTTP與HTTPS區別/HTTPS知識點

時間 2019-11-06

原文原文鏈接

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

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

HTTP與HTTPS區別算法

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

HTTP未加密，易受「中間人」攻擊和信息竊取，攻擊者能夠獲取網站帳號、敏感信息，修改網頁注入惡意軟件或者廣告。服務器

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

通訊加密網絡

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

層次關係上，TLS\SSL位於HTTP層之下，由於網絡通訊須要一層層的走，因此保護之下的HTTP內的一切消息都是加密的，包括header、request、response、cookie等。app

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報文。
安全的通訊創建了。