Https協議原理總結

2021-08-14 17:59:05 字數 1822 閱讀 7976

文章是根據中科大郭燕老師的資訊保安實踐課程的lecture1 https的內容外加自己的理解改寫的。

眾所周知,http協議存在非常大的安全隱患,首先它在網路上傳輸明文,這樣導致其傳輸的內容非常容易在網路上被人竊聽;其次,它無法給伺服器或者客戶端提供有效的身份認證手段。因此而誕生了https協議彌補這些不足。

https在tcp與http協議之間新增了乙個ssl層,ssl層允許伺服器認證,客戶端認證與加密通訊。

rsa演算法的直觀理解:

所謂非對稱加密就是有一對金鑰,我們稱之為公鑰和私鑰,公鑰加密可以由私鑰解密,私鑰加密可以由公鑰解密,並且由公鑰推知私鑰是不可計算的,反之亦然。這個是如何做到的呢?舉個直觀的例子:

假如我有乙個三位數"123"需要加密,加密金鑰為"11",之後進行"加密"操作,即將這兩個數相乘,得到的加密後的值為"1353",收到這個加密資訊後,接收方要進行解密,解密金鑰是"91",進行"解密"操作,解密操作也是相乘,將"1353"乘"91"後得到"123123",我們只要取其低三位就可以得到原文了。剛剛的操作是用"11"加密,"91"解密,如果你嘗試一下會發現用"91"加密,"11"解密也是可行的,其實這一切都源於1001可以分解11和91這兩個因子所導致。

以上只是對rsa演算法的直觀理解,真正的rsa演算法比這個要複雜,如果想要進一步了解這個演算法以及它的證明的話,可以參考部落格

一般公鑰是公開的,私鑰是自己要妥善保管的,這種加密演算法出了可以用來進行加密通訊外,還可以進行數字簽名(即用私鑰加密)來進行身份驗證。

首先闡清圖中幾個概念:

根證書(root certificate):也就是ca機構的證書

工作流程:在流程中有四個角色,分別是ca機構,瀏覽器廠商,web站點和使用者瀏覽器。逐一解釋圖中的1,2,3標記的過程:

在ca機構建立之初,它便會將它自己的證書交給瀏覽器廠商讓廠商將這個證書打包在瀏覽器軟體中,之後瀏覽器廠商再將瀏覽器分發給使用者使用;

web站點會請求ca機構給自己進行認證,ca機構對該站點進行考察之後同意認證,於是就用自己的私鑰給該web站點的證書進行簽名(所謂簽名就是用私鑰加密);

當使用者請求web站點時,web站點會將它的證書發給使用者瀏覽器,使用者瀏覽器用ca的公鑰嘗試進行解密,如果能夠正確解密的的話,則認可這個**的安全性,否則的話就會展現出我們在chrom瀏覽器中經常看見的"您的連線不是私密連線"頁面,如下:

1.在使用者瀏覽器確認了**的安全性之後,通訊過程的加密是如何進行的?在通訊過程中使用的還是非對稱加密嗎?

答:使用者瀏覽器與站點之間會先使用非對稱加密商量乙個session key,之後的通訊就全部使用session key進行對稱加密通訊了。至於為什麼不一直採用非對稱加密,是因為對稱加密的效率要比非對稱加密高。

2.瀏覽器是如何確認證書是否與**匹配的?

答:瀏覽器在收到站點證書並且使用ca的公鑰成功解密之後,會比對當前瀏覽器網域名稱框中的網域名稱與站點證書中"使用者可選名稱"(如下圖中的站點證書的可選名稱就是*.csdn.net與csdn.net,其中*是萬用字元)進行比對,如果網域名稱在"使用者可選網域名稱"中,則認證通過,否則依舊會認證失敗。

3.https的主要功能?

乙個是保證通訊加密,另乙個是進行身份驗證。

Https協議原理

對稱加密 加密和解密同用乙個金鑰 非對稱加密 公開金鑰加密使用一對非對稱的金鑰。一把叫做私有金鑰,另一把叫做公開金鑰 使用公開金鑰加密方式,傳送密文的一方使用對方的公開金鑰進行加密處理,對方收到被加密的資訊後,再使用自己的私有金鑰進行解密 tls ssl 其利用非對稱加密實現身份認證和金鑰協商,對稱...

https協議總結

學習乙個東西或者用乙個東西的時候,就會想,它有什麼用,為什麼要用它,先說說傳統的http,傳統的http是一種可靠但不安全的超文字傳輸協議,說它可靠,是因為http是基於tcp實現的,確保了內容傳輸的可靠性,也就是說,它保證了內容的正確性,但它又是不安全的,因為http是明文傳輸的,有一點html5...

HTTPS協議原理透析

3 加密鏈結建立的核心基礎是ssl tls的握手過程,這個過程要比tcp協議建立鏈結的3次握手過程複雜一些。參考了wikipedia中描述的過程自己大概整理了一下這個握手過程,大概是下面這個樣子的 4 從上面的這個過程可以總結一下這個安全鏈結建立的過程 client和server通訊為了保證安全性,...