https原理通俗瞭解
來源:翟志軍
showme.codes/2017-02-20/understand-https/
如有好文章投稿,請點選 → 這裡瞭解詳情
摘要:本文嘗試一步步還原HTTPS的設計過程,以理解為什麼HTTPS最終會是這副模樣。但是這並不代表HTTPS的真實設計過程。在閱讀本文時,你可以嘗試放下已有的對HTTPS的理解,這樣更利於“還原”過程。
我們先不了聊HTTP,HTTPS,我們先從一個聊天軟體說起,我們要實現A能發一個hello訊息給B:
如果我們要實現這個聊天軟體,本文只考慮安全性問題,要實現
A發給B的hello訊息包,即使被中間人攔截到了,也無法得知訊息的內容
如何做到真正的安全?
這個問題,很多人馬上就想到了各種加密演算法,什麼對稱加密、非對稱加密、DES、RSA、XX、噼裡啪啦~
而我想說,加密演算法只是解決方案,我們首先要做的是理解我們的問題域——什麼是安全?
我個人的理解是:
A與B通訊的內容,有且只有A和B有能力看到通訊的真正內容
好,問題域已經定義好了(現實中當然不止這一種定義)。對於解決方案,很容易就想到了對訊息進行加密。
題外話,但是隻有這一種方法嗎?我看未必,說不定在將來會出現一種物質打破當前世界的通訊假設,實現真正意義上的保密。
對於A與B這樣的簡單通訊模型,我們很容易做出選擇:
這就是對稱加密演算法,其中圖中的金鑰S同時扮演加密和解密的角色。具體細節不是本文範疇。
只要這個金鑰S不公開給第三者,同時金鑰S足夠安全,我們就解決了我們一開始所定問題域了。因為世界上有且只有A與B知道如何加密和解密他們之間的訊息。
但是,在WWW環境下,我們的Web伺服器的通訊模型沒有這麼簡單:
如果伺服器端對所有的客戶端通訊都使用同樣的對稱加密演算法,無異於沒有加密。那怎麼辦呢?即能使用對稱加密演算法,又不公開金鑰?請讀者思考21秒鐘。??
答案是:Web伺服器與每個客戶端使用不同的對稱加密演算法:
如何確定對稱加密演算法
慢著,另一個問題來了,我們的伺服器端怎麼告訴客戶端該使用哪種對稱加密演算法?
當然是通過協商。
但是,你協商的過程是沒有加密的,還是會被中間人攔截。那我們再對這個協商過程進行對稱加密就好了,那你對協商過程加密的加密還是沒有加密,怎麼辦?再加密不就好了……好吧,進行雞生蛋蛋生雞的問題了。
如何對協商過程進行加密
新問題來了,如何對協商過程進行加密?密碼學領域中,有一種稱為“非對稱加密”的加密演算法,特點是私鑰加密後的密文,只要是公鑰,都可以解密,但是公鑰加密後的密文,只有私鑰可以解密。私鑰只有一個人有,而公鑰可以發給所有的人。
雖然伺服器端向A、B……的方向還是不安全的,但是至少A、B向伺服器端方向是安全的。
好了,如何協商加密演算法的問題,我們解決了:使用非對稱加密演算法進行對稱加密演算法協商過程。
這下,你明白為什麼HTTPS同時需要對稱加密演算法和非對稱加密演算法了吧?
協商什麼加密演算法
要達到Web伺服器針對每個客戶端使用不同的對稱加密演算法,同時,我們也不能讓第三者知道這個對稱加密演算法是什麼,怎麼辦?
使用隨機數,就是使用隨機數來生成對稱加密演算法。這樣就可以做到伺服器和客戶端每次互動都是新的加密演算法、只有在互動的那一該才確定加密演算法。
這下,你明白為什麼HTTPS協議握手階段會有這麼多的隨機數了吧。
如何得到公鑰?
細心的人可能已經注意到瞭如果使用非對稱加密演算法,我們的客戶端A,B需要一開始就持有公鑰,要不沒法開展加密行為啊。
這下,我們又遇到新問題了,如何讓A、B客戶端安全地得到公鑰?
我能想到的方案只有這些:
方案1. 伺服器端將公鑰傳送給每一個客戶端
方案2. 伺服器端將公鑰放到一個遠端伺服器,客戶端可以請求得到
我們選擇方案1,因為方案2又多了一次請求,還要另外處理公鑰的放置問題。
公鑰被調包了怎麼辦?又是一個雞生蛋蛋生雞問題?
但是方案1有個問題:如果伺服器端傳送公鑰給客戶端時,被中間人調包了,怎麼辦?
我畫了張圖方便理解:
顯然,讓每個客戶端的每個瀏覽器預設儲存所有網站的公鑰是不現實的。
使用第三方機構的公鑰解決雞生蛋蛋生雞問題
公鑰被調包的問題出現,是因為我們的客戶端無法分辨返回公鑰的人到底是中間人,還是真的伺服器。這其實就是密碼學中提的身份驗證問題。
如果讓你來解決,你怎麼解決?如果你瞭解過HTTPS,會知道使用數字證書來解決。但是你想過證書的本質是什麼麼?請放下你對HTTPS已有的知識,自己嘗試找到解決方案。
我是這樣解決的。既然伺服器需要將公鑰傳給客戶端,這個過程本身是不安全,那麼我們為什麼不對這個過程本身再加密一次?可是,你是使用對稱加密,還是非對稱加密?這下好了,我感覺又進了雞生蛋蛋生雞問題了。
問題的難點是如果我們選擇直接將公鑰傳遞給客戶端的方案,我們始終無法解決公鑰傳遞被中間人調包的問題。
所以,我們不能直接將伺服器的公鑰傳遞給客戶端,而是第三方機構使用它的私鑰對我們的公鑰進行加密後,再傳給客戶端。客戶端再使用第三方機構的公鑰進行解密。
下圖就是我們設計的第一版“數字證書”,證書中只有伺服器交給第三方機構的公鑰,而且這個公鑰被第三方機構的私鑰加密了:
如果能解密,就說明這個公鑰沒有被中間人調包。因為如果中間人使用自己的私鑰加密後的東西傳給客戶端,客戶端是無法使用第三方的公鑰進行解密的。
話到此,我以為解決問題了。但是現實中HTTPS,還有一個數字簽名的概念,我沒法理解它的設計理由。
原來,我漏掉了一個場景:第三方機構不可能只給你一家公司製作證書,它也可能會給中間人這樣有壞心思的公司發放證書。這樣的,中間人就有機會對你的證書進行調包,客戶端在這種情況下是無法分辨出是接收的是你的證書,還是中間人的。因為不論中間人,還是你的證書,都能使用第三方機構的公鑰進行解密。像下面這樣:
第三方機構向多家公司頒發證書的情況:
客戶端能解密同一家第三機構頒發的所有證書:
最終導致其它持有同一家第三方機構證書的中間人可以進行調包:
數字簽名,解決同一機構頒發的不同證書被篡改問題
要解決這個問題,我們首先要想清楚一個問題,辨別同一機構下不同證書的這個職責,我們應該放在哪?
只能放到客戶端了。意思是,客戶端在拿到證書後,自己就有能力分辨證書是否被篡改了。如何才能有這個能力呢?
我們從現實中找靈感。比如你是HR,你手上拿到候選人的學歷證書,證書上寫了持證人,頒發機構,頒發時間等等,同時證書上,還寫有一個最重要的:證書編號!我們怎麼鑑別這張證書是的真偽呢?只要拿著這個證書編號上相關機構去查,如果證書上的持證人與現實的這個候選人一致,同時證書編號也能對應上,那麼就說明這個證書是真實的。
我們的客戶端能不能採用這個機制呢?像這樣:
可是,這個“第三方機構”到底是在哪呢?是一個遠端服務?不可能吧?如果是個遠端服務,整個互動都會慢了。所以,這個第三方機構的驗證功能只能放在客戶端的本地了。
客戶端本地怎麼驗證證書呢?
客戶端本地怎麼驗證證書呢?答案是證書本身就已經告訴客戶端怎麼驗證證書的真偽。
也就是證書上寫著如何根據證書的內容生成證書編號。客戶端拿到證書後根據證書上的方法自己生成一個證書編號,如果生成的證書編號與證書上的證書編號相同,那麼說明這個證書是真實的。
同時,為避免證書編號本身又被調包,所以使用第三方的私鑰進行加密。
這地方有些抽象,我們來個圖幫助理解:
證書的製作如圖所示。證書中的“編號生成方法MD5”就是告訴客戶端:你使用MD5對證書的內容求值就可以得到一個證書編號。
當客戶端拿到證書後,開始對證書中的內容進行驗證,如果客戶端計算出來的證書編號與證書中的證書編號相同,則驗證通過:
但是第三方機構的公鑰怎麼跑到了客戶端的機器中呢?世界上這麼多機器。
其實呢,現實中,瀏覽器和作業系統都會維護一個權威的第三方機構列表(包括它們的公鑰)。因為客戶端接收到的證書中會寫有頒發機構,客戶端就根據這個頒發機構的值在本地找相應的公鑰。
題外話:如果瀏覽器和作業系統這道防線被破了,就沒辦法。想想當年自己裝過的非常規XP系統,都害怕。
說到這裡,想必大家已經知道上文所說的,證書就是HTTPS中數字證書,證書編號就是數字簽名,而第三方機構就是指數字證書籤發機構(CA)。
CA如何頒發數字證書給伺服器端的?
當我聽到這個問題時,我誤以為,我們的SERVER需要髮網絡請求到CA部門的伺服器來拿這個證書。?? 到底是我理解能力問題,還是。。
其實,問題應該是CA如何頒發給我們的網站管理員,而我們的管理員又如何將這個數字證書放到我們的伺服器上。
我們如何向CA申請呢?每個CA機構都大同小異,我在網上找了一個:
拿到證書後,我們就可以將證書配置到自己的伺服器上了。那麼如何配置?這是具體細節了,留給大家google了。
也許我們需要整理一下思路
我們通過推算的方式嘗試還原HTTPS的設計過程。這樣,我們也就明白了為什麼HTTPS比HTTP多那麼多次的互動,為什麼HTTPS的效能會差,以及找到HTTPS的效能優化點。
而上面一大堆工作都是為了讓客戶端與伺服器端安全地協商出一個對稱加密演算法。這就是HTTPS中的SSL/TLS協議主要乾的活。剩下的就是通訊時雙方使用這個對稱加密演算法進行加密解密。
以下是一張HTTPS協議的真實互動圖(從網上copy的,忘了從哪了,如果侵權麻煩告知):
能不能用一句話總結HTTPS?
答案是不能,因為HTTPS本身實在太複雜。但是我還是嘗試使用一段話來總結HTTPS:
HTTPS要使客戶端與伺服器端的通訊過程得到安全保證,必須使用的對稱加密演算法,但是協商對稱加密演算法的過程,需要使用非對稱加密演算法來保證安全,然而直接使用非對稱加密的過程本身也不安全,會有中間人篡改公鑰的可能性,所以客戶端與伺服器不直接使用公鑰,而是使用數字證書籤發機構頒發的證書來保證非對稱加密過程本身的安全。這樣通過這些機制協商出一個對稱加密演算法,就此雙方使用該演算法進行加密解密。從而解決了客戶端與伺服器端之間的通訊安全問題。
好長的一段話。
後記
以上是個人為理解HTTPS而編造出來的自圓其說的看法。頂多只能算是HTTPS的科普文章。如有錯誤,請指出,萬分感謝。
那麼,我為什麼會覺得以這種方式理解HTTPS會更容易呢?我個人給出的答案是:當你自己為一家人做一次菜時,你就會理解媽媽天天做菜的不易了。
相關推薦
https原理通俗瞭解
來源:翟志軍 showme.codes/2017-02-20/understand-https/ 如有好文章投稿,請點選 → 這裡瞭解詳情 摘要:本文嘗試一步步還原HTTPS的設計過程,以理解為什麼HTTPS最終會是這副模樣。但是這並不代表HTTPS的真實設計過程。在閱
https原理
算法 銀行 自己 包含 無法 機構 信息 開始 信任 ---恢復內容開始--- 我們都知道HTTPS能夠加密信息,以免敏感信息被第三方獲取。所以很多銀行網站或電子郵箱等等安全級別較高的服務都會采用HTTPS協議。 HTTPS簡介HTTPS其實是有兩部分組成:HTTP + S
https原理及實踐
ron 普通 erl key 配置 獲取 blog 種類型 uil 轉自 https://www.cnblogs.com/lyq863987322/p/8424253.html 作者 酷酷的二連長 目錄 網絡安全問題 數據機密性 數據完整性 身份驗證 網絡
HTTPS原理解析-轉
個人 服務器安裝 ons cdn 告警 hang cpu 負載 相關信息 SSL/TLS 這篇文章關於Https的講解真的是太透徹了,轉過來備忘。 來源:騰訊bugly 基於此文章的學習總結:下一篇文章 1.HTTPS 基礎 HTTPS(Secure Hyper
HTTPS原理與證書生成
HTTPS HTTPS與HTTP是什麼關係呢?我們可以對比下HTTP與HTTPS的請求過程: HTTPS 在 TCP 和 HTTP 之間增加了 TLS(Transport Layer Security,傳輸層安全),提供了內容加密、身份認證和資料完整性三大功能。
Spring---IOC原理 Spring的IOC原理[通俗解釋一下]
Spring的IOC原理(轉載) 在網上看到一篇文章,感覺寫得挺不錯的,轉載一下,本文轉載自:http://blog.csdn.net/m13666368773/article/details/7802126 Spring的IOC原理[通俗解釋
https原理簡述
為什麼要使用https? 因為http協議下,資料都是明文傳輸的,容易被截獲、修改轉發。 https實現原理: 概要:通過非對稱加密資料進行互動協商獲得對稱加密演算法與金鑰的過程 1)瀏覽器將自己支援的一套加密規則請求伺服器。 2)伺服器從中選出一組加密演算法與HASH
迴圈神經網路(RNN)原理通俗解釋
1.RNN怎麼來的? 2.RNN的網路結構及原理 3.RNN的改進1:雙向RNN 4.RNN的改進2:深層雙向RNN 4.1 Pyramidal RNN
HTTP和HTTPS原理
HTTP:超文字傳輸協議 URL:統一資源定位符。 HTTP的連線方式和無狀態性 1.非永續性連線 當請求完成後,就釋放連線。即每次重新整理訪問頁面都重新建立連線。 2.永續性連線 在伺服器傳送完響應後,不會立即釋放連線。 3.無狀態性 客戶端第二次訪問同一個web伺服器時,伺服器無法識別這
Https原理總結及抓取Https的工作原理
Https原理: a.Https == Http + SSL(TSL),SSL是網景公司的命名,TSL為OSI組織接手名的命名 b.要解決的問題:傳統HTTP協議可能有三大風險: b.1 被截獲並獲取內容(因為是明文傳輸) &n
Docker原理 ---- 深入瞭解容器映象
我講解了 Linux 容器的 最基礎的兩種技術:Namespace 和 Cgroups。希望此時,你已經徹底理解了“容器的本質是一種特殊的程序”這個最重要的概念。 而正如我前面所說的,Namespace 的作用是“隔離”,它讓應用程序只能看到該 Namespace 內的“世
HTTPS 原理
HTTPS時序圖 #1: HTTPS時序圖 #2: 流程: 1. 客戶端發起HTTPS請求 這個沒什麼好說的,就是使用者在瀏覽器裡輸入一個https網址,然後連線到server的443埠。 2. 服務端的配置 採用HTTPS協議的伺服器
HTTPS 原理解析
一 前言 在說HTTPS之前先說說什麼是HTTP,HTTP就是我們平時瀏覽網頁時候使用的一種協議。HTTP協議傳輸的資料都是未加密的,也就是明文的,因此使用HTTP協議傳輸隱私資訊非常不安全。為了保證這些隱私資料能加密傳輸,於是網景公司設計了SSL(Secure Sockets Layer)協議用於對H
從Select語句看Oracle查詢原理(瞭解Oracle的查詢機制)
第一步:客戶端把語句發給伺服器端執行 當我們在客戶端執行select語句時,客戶端會把這條SQL語句傳送給伺服器端,讓伺服器端的程序來處理這語句。也就是說,Oracle客戶端是不會做任何的操作,他的主要任務就是把客戶端產生的一些SQL語句傳送給伺服器端。雖然在客戶端也有一個數
SSL、數字簽名、CA 工作原理通俗描述
SSL(Secure Socket Layer) 是一種加密技術,可以提供對稱加密和非對稱加密。由於它在協議層里正好是在傳輸層與應用層之間,這就決定了上層應用必須經過它,這就是它廣泛流行和易於實現的原因。 對稱加密有md5,sha1。由於md5已被學者證明可以計算出加密衝突
Https原理的簡單描述
對Https的原理有點不清楚,研究了下,總結如下, 首先是幾個關鍵字: Certification, RSA, Symmetric key Https使用了SSL/TSL通訊協議來實現網際網路上的通訊加密。 SSL(Secure Sockets Layer)是TSL
【HTTP】HTTPS 原理詳解
【HTTP】HTTPS 原理詳解 HTTPS(全稱:HyperText Transfer Protocol over Secure Socket Layer),其實 HTTPS 並不是一個新鮮協議,Google 很早就開始啟用了,初衷是為了保證資料安全。 近兩年,Google、Baidu
使用WireShark深入理解HTTPS原理
前端開發,移動開發,後臺開發,都應該知道HTTP通訊,而且現在一些大廠都已經使用HTTPS進行通訊,那HTTPS到底是什麼呢,有什麼好處呢? 一.為什麼要使用HTTPS http是一種通訊上極為簡便的協議,他本身不帶有安全功能,http包在網路上傳輸的過程中難免會被人
Java 反射機制和動態代理是基於什麼原理,瞭解過嗎?
工作多年以及在面試中,我經常能體會到,有些面試者確實是認真努力工作,但坦白說表現出的能力水平卻不足以通過面試,通常是兩方面原因: 1、“知其然不知其所以然”。 做了多年技術,開發了很多業務應用,但似乎並未思考過種種技術選擇背後的邏輯。坦白說,我並不放心把具有一定深度的任務交給他。 2、
HTTPS原理,以及加密、解密的原理。
www 實的 對稱加密 tls 最重要的 進行 des 加密、解密 等等 摘要:本文用圖文的形式一步步還原HTTPS的設計過程,進而深入了解原理。 A在向B進行通信時,如果是以明文的方式進行通信,中