HTTPS學習總結

寫在前面

最近在看了解HTTP相關的一些知識,主要在看《圖解HTTP》這本書,感覺還不錯。所以結合自己的理解,做一下筆記。話說之前還大概過了下《HTTP權威指南》,感覺這本書內容過多了,不太適合新手看。新手還是建議看《圖解HTTP》。

什么是HTTPS

HTTPS(全稱:Hyper Text Transfer Protocol over Secure Socket Layer),是以安全為目標的HTTP通道,簡單講是HTTP的安全版。

HTTPS在應用層(HTTP)和傳輸層(TCP)之間加入了一個安全層(SSL或TLS)。目的是為了解決HTTP協議的幾個缺點:

  • 通信使用明文(不加密),內容可能會被竊聽。
  • 無法證明報文的完整性,所以有可能早已篡改。
  • 不驗證通信方的身份,因此有可能遭遇偽裝。
HTTPS是位于安全層之上的HTTP,這個安全層位于TCP之上

HTTP的幾個缺點

  • 通信使用明文(不加密),內容可能會被竊聽。
    HTTP協議并沒有對通信以及數據進行加密,是明文發送的。而我們使用HTTP請求的時候,數據會經過許多個路由器,代理之類的設備,在這個過程中,只要有人在某一個環節抓取了數據包(這個操作并不難),那這個請求的數據就會被看到。如果請求里面有一些重要的數據,比如銀行卡賬號、手機號、密碼等信息,就會有泄露的風險。

  • 無法證明報文的完整性,所以有可能早已篡改。
    由于HTTP協議無法證明通信的報文完整性,因此,在請求或響應送出之后直到對方接收之前的這段時間內,即使請求或響應遭到篡改,也沒有辦法獲悉。
    換句話說,沒有任何辦法確認,發出的請求/響應和接收到的請求/響應是相同的。


    數據在傳輸過程中可能會遭到篡改
  • 不驗證通信方的身份,因此有可能遭遇偽裝。
    HTTP協議的實現本身非常簡單,不論是誰發過來的請求都會返回響應,因此不確認通信方,會存在以下隱患:

    • 無法確認請求發送至目標的Web服務器是否是按真實意圖返回響應的那臺服務器。有可能是偽裝的Web服務器。
    • 無法確認響應返回到的客戶端是否是按真實意圖接收響應的那個客戶端,有可能是偽裝的客戶端。
    • 無法確定正在通信的對方是否具備訪問權限,因為某些Web服務器上保存著重要的信息,只想發給特定用戶通信的權限。
    • 無法判斷請求是來自何方,出自何手。
    • 即使是無意義的請求也會照單全收。無法阻止海量請求下的DoS攻擊。

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

我們來看下HTTPS是如何解決上面的問題的。

使用通信加密解決HTTP的明文發送問題

不同于HTTP的明文通信,HTTPS的通信是經過加密的。所以,就算有人在通信的過程中抓取到了數據包,因為沒有密鑰,所以無法知道數據包的具體內容,這樣可以對傳輸的數據進行保護。


HTTPS中,網絡傳輸的數據(請求和響應)都是經過加密的

HTTPS通信中,客戶端和服務器都會有兩個相同的通信密鑰(設為密鑰A),客戶端發送請求時,會使用密鑰A對請求進行加密成密文,服務器接收到請求之后,會使用密鑰A對請求內容進行解密,得到客戶端發送的明文,進行處理。響應過程也相似。
因此,在網絡傳輸的過程中,因為數據被加密了,所以就算有人獲取到了數據包,因為沒有密鑰A,所以就無法解密出數據包的內容,看到的是一堆亂碼。

像這種加密和解密都是使用同一個密鑰的加密方式叫做對稱加密(也叫共享加密,共同擁有一個密鑰)。使用密鑰A加密的內容,只能用密鑰A來解密,其他的密鑰都無法解密。常用的對稱加密算法有DES,3DES,AES。
還有一種加密方式叫非對稱加密(也叫公開密鑰加密)。非對稱加密需要使用兩個密鑰,公開密鑰(public key)和私有密鑰(private key)。公開密鑰是公開的,所有人都知道。私有密鑰是保密的,除了自己,不讓任何人知道。
使用公開密鑰加密的數據,只有使用私有密鑰才能解密。
使用私有密鑰加密的數據,只有使用公開密鑰才能解密。

使用摘要驗證保證數據完整性

HTTPS不僅僅使用了對稱加密的方式,還使用了非對稱加密的方式。事實上,HTTPS通信過程中,客戶端會持有一個公鑰,服務器會持有一個私鑰。使用非對稱加密可以完成好幾個關鍵的操作。比如驗證身份,比如協商通信的對稱密鑰,比如數據傳輸過程中加密摘要。


HTTPS中使用摘要算法來驗證數據完整性,使用非對稱密鑰加解密摘要,使用對稱密鑰對數據進行加解密

如上圖所示,在請求和響應過程中,除了加密后的數據,還會發送一個報文摘要,通過這個摘要,可以驗證數據是否被篡改。
拿響應為例,

  • 服務器會將明文的響應用摘要算法計算摘要,跟數據一起發送給客戶端。
  • 客戶端將接收到的響應數據解密出來后,計算摘要。
  • 然后客戶端會將自己計算出來的摘要跟服務器發送過來的摘要進行對比,如果兩個是相同的,那么證明服務器發出的響應數據跟客戶端收到的響應數據是相同的。也就是數據是完整的,沒有丟失,也沒有遭到篡改。

但是這里的前提是,服務器發過來的摘要沒有被篡改,如果有人在篡改了數據之后,連摘要也改了,那就有點坑了。所以HTTTPS會使用非對稱加密對摘要進行加密,防止摘要被篡改。

  • 服務器會將明文的響應用摘要算法計算摘要。
  • 將摘要使用私鑰進行加密,跟數據一起發送給客戶端。
  • 客戶端將接收到的響應數據解密出來后,計算摘要。
  • 客戶端將接收到的摘要使用公鑰進行解密。
  • 然后客戶端會將自己計算出來的摘要跟解密出來的服務器發送過來的摘要進行對比,如果兩個是相同的,那么證明服務器發出的響應數據跟客戶端收到的響應數據是相同的。也就是數據是完整的,沒有丟失,也沒有遭到篡改。

為什么非對稱加密可以保證服務器發送的摘要不被修改呢?
因為私鑰只有服務器有,也就是說,只有服務器能夠使用私鑰進行加密。而使用私鑰加密的數據,只有公鑰可以解密。換句話說,用公鑰能夠解密出來的數據,就是使用私鑰加密過的。所以,只要客戶端使用公鑰能夠解密出來加密過的摘要,那么這個摘要就是服務器使用私鑰加密的。而且私鑰只有服務器知道,別人無法篡改加密后的摘要。

這里其實我有個疑問,反過來,在請求過程中,客戶端使用公鑰加密摘要,然后服務器私有私鑰解密摘要。貌似只有證明這個摘要是使用公鑰加密的,但是,公鑰是公開的,別人也能知道,那別人不就可以篡改這個摘要?

使用數字證書驗證服務器的身份

HTTPS是如何確認服務器的真實性的呢?也就說,怎樣確認跟客戶端通信的服務器就是我們的域名指向的服務器,而不是其他服務器冒充的?
HTTPS采用非對稱加密方式解決問題。
服務器擁有私鑰,這個私鑰只有服務器有,所以,只要客戶端擁有服務器的公鑰,那么,當服務器使用私鑰加密數據發送給客戶端,而客戶端能夠解密出數據,說明公鑰和私鑰是配對的,而公鑰是對應著我們想要的那個服務器的,所以就代表服務器是真的。
那么問題又來了,我們怎么拿到該服務器的公鑰呢?在客戶端內置?怎么多網站,怎么看都不現實。
那我們就在建立連接的時候發送給客戶端。
嗯,HTTPS就是這么做的。
不對,那發送公鑰的時候,公鑰也可能被篡改啊,要是被篡改成其他服務器的公鑰,以后就是跟其他冒充的服務器通信了,那怎么玩?
嗯,HTTPS引入了權威的第三方機構來確保這個公鑰確實是該服務器的。
如果要使用HTTPS,服務器管理人員需要向CA(權威的證書頒發機構)購買證書。CA會將該服務器的域名、公鑰、公司信息等內容封裝到證書中。并且使用CA自己的私鑰對證書進行簽名。那么,服務器將證書發給客戶端,客戶端如果驗證出證書是有效的,并且證書的域名跟目前通信的域名一致,那么這個證書里面的公鑰就是有效的。而且當前是域名指向的服務器的公鑰。所以,我們就能確保拿到的公鑰是真的了。
嗯,這個CA機構頒發的證書就叫做數字證書。
問題又來了,客戶端如何驗證服務器發過來證書是有效的呢?
證書上有CA用其私鑰做的簽名,而一般客戶端都會內置這些權威機構(CA)的公鑰的,所以能夠直接拿到CA的公鑰對證書上的簽名進行解密,然后自己根據證書上的說明計算摘要,兩個摘要一致的話,代表證書是有效。因為只有CA自己才有私鑰,別人是不可能冒充這個簽名的。
說了那么多,HTTPS在連接建立時會發給客戶端一個數字證書,客戶端驗證了數字證書之后,就能確認服務器的身份。同時還可以用數字證書上的公鑰加密隨機生成的共享密鑰A,與服務器協商接下來通信過程中加密數據所用的共享密鑰A。

HTTPS握手過程

HTTPS握手過程

SSL 協議既用到了公鑰加密技術又用到了對稱加密技術,對稱加密技術雖然比公鑰加密技術的速度快,可是公鑰加密技術提供了更好的身份認證技術。SSL 的握手協議非常有效的讓客戶和服務器之間完成相互之間的身份認證,其主要過程如下:

  • ①客戶端向服務器請求HTTPS連接。
    客戶端向服務器傳送客戶端SSL 協議的版本號,加密算法的種類,產生的隨機數,以及其他服務器和客戶端之間通訊所需要的各種信息。

  • ②服務器確認并返回證書。
    服務器向客戶端傳送SSL 協議的版本號,加密算法的種類,隨機數以及其他相關信息,同時服務器還將向客戶端傳送自己的證書。

  • ③客戶端驗證服務器發來的證書。
    客戶端利用服務器傳過來的信息驗證服務器的合法性,服務器的合法性包括:證書是否過期,發行服務器證書的CA 是否可靠,發行者證書的公鑰能否正確解開服務器證書的“發行者的數字簽名”,服務器證書上的域名是否和服務器的實際域名相匹配。如果合法性驗證沒有通過,通訊將斷開;如果合法性驗證通過,將繼續進行第四步。

  • ④信息驗證通過,客戶端生成隨機密鑰A,用公鑰加密后發給服務器。
    從第③步驗證過的證書里面可以拿到服務器的公鑰,客戶端生成的隨機密鑰就使用這個公鑰來加密,加密之后,只有擁有該服務器(持有私鑰)才能解密出來,保證安全。

  • ⑤服務器用私鑰解密出隨機密鑰A,以后通信就用這個隨機密鑰A來對通信進行加密。

我們這個握手過程并沒有將驗證客戶端身份的邏輯加進去。因為在大多數的情況下,HTTPS只是驗證服務器的身份而已。如果要驗證客戶端的身份,需要客戶端擁有證書,在握手時發送證書,而這個證書是需要成本的。

參考

《圖解HTTP》書籍
《HTTP權威指南》書籍
百度百科:HTTPS
也許,這樣理解HTTPS更容易
關于HTTPS,你需要知道的全部

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,401評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,011評論 3 413
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,263評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,543評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,323評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 54,874評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,968評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,095評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,605評論 1 331
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,551評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,720評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,242評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 43,961評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,358評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,612評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,330評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,690評論 2 370

推薦閱讀更多精彩內容