現在打開各大知名網站,你有沒有發現地址欄都已經加了個綠色的小鎖?
是的,這就是https,這就是https的時代。然而,你了解https嗎?簡單來說,https就是套在SSL/TLS內的http,也就是安全的http。何為安全?一個安全的網絡通信環境要解決3個問題:
1.通信內容的保密性
2.通信雙方身份的真實性
3.通信內容的完整性
而https就是為了解決這3大問題而誕生的(準確來說應該是ssl),下面分別看看這3個問題的解決方案。
通信內容的保密性
通信內容的保密需要通過加密來實現。我們的互聯網環境是非常透明的,通信需要經過很多中轉才能到接收方手中。這個情形有點像你上課的時候給第一排的小紅遞紙條一樣,紙條上你肯定不會直接寫今夜三更操場見,而是機靈地寫了老地方見。這個老地方只有你和小紅知道,這樣就算小明小李看到了紙條,他們也不知道老地方是圖書館還是英語角,這就是加密,而老地方就是所謂的密鑰。
當然,這個例子并不是很準確。簡單來說,加解密就是一個函數,而密鑰則是這個函數的參數。比如我們定義一個簡單的加密函數,f(x)=x+b,x就是輸入的明文,而b是密鑰;解密函數就是加密函數的反函數,也就是g(x)=x-b。當不知道b的時候,你就算看到了密文也猜不出真實內容,這樣就實現了加密。這種加解密都用同一個密鑰,叫對稱加密。
但這里有個問題,這里的參數b是怎么協商出來的?
你和小紅可以花前月下約好b值,但是在真實網絡環境中你和小紅根本沒有直接溝通的可能,所有溝通都要靠小明小李去傳紙條的話,怎么做才能躲過他們呢?這里就需要用到非對稱加密算法了,這種算法有公鑰和私鑰一對鑰匙,公鑰是所有人都能獲取到的鑰匙,私鑰則是服務器私自保存的鑰匙。非對稱加密算法中公鑰加密的內容只能用私鑰解密,私鑰加密的內容則只有公鑰才能解密。所以當你使用小紅的公鑰加密你的紙條之后,幫你傳遞紙條小明小李等人看到紙條也無法讀取內容了,只有擁有私鑰的小紅才能讀出你的信息。
對稱加密算法在加密和解密時使用的是同一個秘鑰;而非對稱加密算法需要兩個密鑰來進行加密和解密,這兩個秘鑰是公開密鑰(public key,簡稱公鑰)和私有密鑰(private key,簡稱私鑰)。你可能比較好奇非對稱加密算法的原理,但是我這里不展開講算法,有興趣的同學可以自行搜索。
那么問題來了,小紅給你的回應也想加密怎么辦?如果小紅用她的私鑰加密的話,班上所有人都知道公鑰,而公鑰可以解私鑰的加密,也意味著所有人都能解密小紅的回應消息。聰明的你一定想到了解決方案:利用非對稱加密算法加密出一個對稱密鑰給小紅,小紅用她的私鑰讀取對稱密鑰,然后你們就用這個對稱密鑰來做對稱加密,然后就可以愉快地約約約了。當然,https也是這么干的。
通信雙方身份的真實性
加密之后貌似通信過程就完美了?且慢,小紅的公鑰是怎么公告天下的呢?
要知道在網絡環境中所有信息交互都是通過傳紙條的方式來進行的,小紅的公鑰也不例外,萬一在經過小明手里的時候被掉包了怎么辦?怎么保證你手上的小紅公鑰是就是真正的小紅公鑰呢?看到班上的癡男怨女的紙條被各種掉包,文娛委員鳳姐決定挺身而出。鳳姐想出了一個辦法,所有加密通信都要帶上一本證,用來證明自己的身份。這本證是鳳姐特意為班上所有單身狗做的,公鑰就放在證書里面返回給紙條的發送者,證書里面除了公鑰還有學號、人名、甚至星座身高三圍等各種信息。證書上蓋了一個大大的鑒定章,這是鳳姐獨有的章,表示證上的信息真實性由鳳姐保證,看到這個章就可以認為對方是個真·單身狗。
通過這些信息你就可以知道對方是小紅還是如花了,這就是證書機制。顯然你會懷疑證書上鳳姐的公章是有可能被偽造的,懷疑有理!所以證書上的公章也是非對稱加密過的,加密方式跟上面提到的剛好相反:用鳳姐的私鑰加密,用鳳姐公鑰就可以解密,這樣就可以鑒定證書的真偽。這個公章就是證書的數字簽名,具體來說就是先將證書用哈希算法提取摘要,然后對摘要進行加密的過程。另外你也可以直接拿著證書去找鳳姐,鳳姐就會幫你驗證證書的有效性。(證書是有期限的,所以即使是真證書也會可能過期,需要注意)
這個機制看起來相當完善,但是我們要以懷疑一切的態度去做安全機制,鳳姐保證的東西是可信任的了,但是,鳳姐真的是鳳姐嗎???
所以,鳳姐本身也要由證書來保證,鳳姐的證書由班主任頒發,而班主任的證書由校長頒發……這個鏈一直到最權威的幾個機構,這些機構在https體系中就是所謂的根CA。根是不可懷疑的權威,他們為自己帶鹽,自己證明自己是自己。在https證書體系里面,根證書是操作系統/瀏覽器自帶的,我們可以相信被這些機構認證的證書的,從而一層一層推導到鳳姐這個級別。
另外,由于證書其實很容易做,地鐵口10塊一本,無論哈佛還是斯坦福,統統10塊!所以有些公司會自己做證書,根本不去找根CA機構,比如著名的12306。你也可以自己做證書放到網上讓用戶下載導入瀏覽器,但因為你沒有鳳姐的影響力,所以沒人會相信你,當然也有人連鳳姐都不相信……
通信內容的完整性
密也加了,鳳姐也保證了,是不是這套機制就perfect了呢?
NoNoNo,想一下暗戀著你的小明看到你給小紅傳紙條,心里肯定不爽,雖然看不懂但是還是可以改密文呀。本來你是要約小紅半夜三更操場見,結果小明刪掉了前半部分的密文,解密后恰好變成了“操場見”,然后小紅下課馬上往操場跑,而你卻跑回宿舍好好洗了個澡……然后,然后小紅就跟小明跑了。。。
這種篡改通信內容的場景相信大家都深有體會,我們訪問一些站點的時候無緣無故就出現了運營商的廣告,這都是運營商給加的!!所以內容的完整性也需要保證,這比較簡單:先用哈希算法提取內容摘要,然后對摘要進行加密生成數字簽名,驗證數字簽名就可以判斷出通信內容的完整性了。
以上幾點就是https用到技術的簡化版,結合起來一個http通信流程如下:
大體步驟:客戶端發送Client Hello報文開始SSL通信,報文中包含SSL版本、可用算法列表、密鑰長度等。服務器支持SSL通信時,會以Server Hello報文作為應答,報文中同樣包括SSL版本以及加密算法配置,也就是協商加解密算法。然后服務器會發送Certificate報文,也就是將證書發送給客戶端。客戶端發送Client Key Exchange報文,使用3中的證書公鑰加密Pre-master secret隨機密碼串,后續就以這個密碼來做對稱加密進行通信。服務器使用私鑰解密成功后返回一個響應提示SSL通信環境已經搭建好了。然后就是常規的http c/s通信。
根據前文所述,在步驟3和步驟6都會使用摘要和簽名算法來保證傳遞的證書和通信內容不被篡改。通過這個流程可以看出,https的核心在于加密,尤其是非對稱加密算法被多次使用來傳送關鍵信息。
理解了加密,認識到網絡的透明性,抱著懷疑一切的態度,理解https這套體系就變得簡單了。
結語
最近在系統地重溫http相關的東西,這一篇先介紹了https的基本原理,才疏學淺,文中有不當之處,還望斧正!后續會介紹實際應用、靜態服務器的配置等~
附錄
Q1:https如何避免中間人攻擊?
如果有人劫持了你的dns服務器,將http://wwe.icbc.com解析到他的非法網站,或者代理服務器將你導向他的非法網站去,這都是中間人攻擊。如果沒有https,那么攻擊就這樣發生了。那https怎么避免這類攻擊?
答案是通過證書鑒別。
1. 在申請證書的時候CA會對所要申請的域名進行控制權認證,所以你是不可能用隔壁老王的網站來申請證書的。就算你黑了他的站點,只要老王去申請證書就能發現了。
2. 如果偽造一個證書,這個證不是權威CA簽發的,那么瀏覽器檢查的時候會報警提示用戶證書非法。當然用戶仍然可以繼續操作,比如搶火車票什么的。
3. 如果你把真正站點的證書搞下來,證書上的域名不變,只是將公鑰替換掉,那么瀏覽器比對證書數字簽名的時候就能發現對不上了,二話不說,報警。
4. 如果中間人直接用www.icbc.com的真實證書,那么他雖然能收到客戶端的消息,但是無法解密,所以也無法響應客戶端的請求,攻擊無效!
Q2:證書的數字簽名
之前對哈希算法和數字簽名了解不多,了解之后發現其實原理還是挺簡單的。哈希算法可以將大量的數據轉換成定長的摘要,而且摘要是與輸入對應的,輸入變化后摘要也會發生變化。所以對數據應用哈希算法求出摘要,比對摘要就可以判斷數據是否被篡改過了。證書使用了私鑰加密摘要,然后客戶端就可以用公鑰解密得到摘要,對比哈希算法算出來的摘要就可以判斷證書是否被篡改過。另一方面,因為公私鑰是成對的,篡改后的證書雖然能求出摘要,但是無法加密出簽名,所以摘要和加密組合使用就可以保證證書的真實性了。這里的私鑰是證書的發證機構的私鑰,也就是CA鏈上CA加密用戶服務器證書,上級CA加密下級CA的證書,從而形成一個信任環。
本文由今科科技用戶上傳并發布,今科科技僅提供信息發布平臺。文章代表作者個人觀點,不代表今科科技立場。未經作者許可,不得轉載,有涉嫌抄襲的內容,請通過 反饋中心 進行舉報。
售前咨詢:0760-2332 0168
售后客服:400 830 7686
1998~2024,今科26年專注于企業信息化服務
立 即 注 冊 / 咨 詢
上 線 您 的 網 站 !