HTTPS基礎原理

前言:前段時間被問到HTTPS的相關問題,由于離看相關問題的時間很久了再加上自己也沒有實踐過,很多點沒有說出來,因此特地又溫習了一遍相關的知識,特此記錄下來以加強記憶

什么是HTTPS

我們知道HTTP是一種無狀態(tài)、明文的網絡傳輸協議,目前我們?yōu)g覽的很多網站都是基于這種協議進行客戶端和服務端信息交互的。但是由于HTTP明文傳輸的特點,很容易導致信息在傳輸過程中被截獲甚至被篡改造成嚴重的后果。在信息安全挑戰(zhàn)越來越頻繁的情景下,信息保護的需求越來越急迫。目前保護信息安全最常見和普及的就是加密技術,根據加密對象的不同可以分為兩種。

  • 通信加密
    顧名思義就是對通信進行加密,HTTP協議本身沒有加密的機制,但是可以通過和SSL的組合使用來達到加密通信通道的效果,在使用SSL建立安全的通信線路之后就可以在在這條線路上使用HTTP協議通信了,于SSL組合使用的HTTP協議就被成為HTTPS。
  • 內容加密
    另一種加密的方式就是對通信的內容本身進行加密,即把HTTP報文里面的內容加密處理后在進行傳輸,無論是客戶端還是服務端都需要對報文進行加密后再發(fā)送,同理兩端接收到的都是加密之后的報文,需要先對報文進行解密才能拿到真正的報文內容。這就要求客戶端和服務器端都要具有加解密的能力。這種方式可以防止通信內容被竊取但是無法阻止內容被篡改。

進一步了解前的準備知識

加密算法
  近代的加密方法中加密算法是公開的,而密鑰是保密的,通過這種方式得以保持加密算法的安全性。
  • 對稱加密
    加密解密使用同一個密鑰的加密方式稱之為對稱密鑰加密也被稱為共享密鑰加密。這種加密方式需要對密鑰特別保護,只要密鑰被竊取,信息就會完全暴露。在互聯網環(huán)境下,很難保證共享密鑰的安全性,如果在發(fā)送共享密鑰的過程中通信被監(jiān)聽,密鑰就會落在攻擊者手中,那么信息加密也就失去了意義。

  • 非對稱加密
    非對稱加密方法有兩個密鑰,一個是公開密鑰另一個是私有密鑰。公開密鑰可以隨意發(fā)布,任何人都可以獲取公開密鑰,私有密鑰只有信息接收方知道。
    使用非對稱加密方式,發(fā)送的密文的一方使用接收方的公開密鑰進行加密處理,接收方收到密文后再使用私有密鑰進行解密。利用這種方式,不需要發(fā)送用來解密的私有密鑰,也就不需要擔心密鑰被攻擊者竊取。另外,想要根據密文和公開密鑰恢復原文是很困難的,就目前的技術看來說很難辦到,就算能做到,付出的價值也會讓攻擊者得不償失。但是非對稱加密相對對稱加密速度要慢很多。

簽名和證書
  • 數字簽名
    數字簽名就是在信息的后面再加上一段內容,可以證明信息沒有被修改過,怎么樣可以達到這個效果呢?一般是對信息做一個HASH計算得到一個HASH值,注意,這個過程是不可逆的,也就是說無法通過HASH值得出原來的信息內容。在把信息發(fā)送出去時,把這個HASH值加密后做為一個簽名和信息一起發(fā)出去。 接收方在收到信息后,會重新計算信息的HASH值,并和信息所附帶的HASH值(解密后得到)進行對比,如果一致,就說明信息的內容沒有被修改過,因為這里HASH計算可以保證不同的內容一定會得到不同的HASH值,所以只要內容一被修改,根據信息內容計算的HASH值就會變化。當然,不懷好意的人也可以修改信息內容的同時也修改HASH值,從而讓它們可以相匹配,為了防止這種情況,HASH值一般都會加密后(也就是簽名)再和信息一起發(fā)送,以保證這個HASH值不被修改

  • 數字證書
    數字證書是由公認的權威公正性第三方機構(即CA中心)簽發(fā)的證書。數字證書一般包含以下主要內容:
    證書的發(fā)布機構
    證書的有效期
    公鑰
    證書所有者(Subject)
    簽名所使用的算法
    指紋以及指紋算法
    數字證書的作用基本可以概括為:數字證書可以保證數字證書里的公鑰確實是這個證書的所有者(Subject)的,或者證書可以用來確認對方的身份。
    數字證書首先由證書的發(fā)布機構制作發(fā)布具有一定的有效期限,過期后的證書不再具有安全效力。證書中的公鑰為證書發(fā)布機構的公鑰,和證書的簽名、指紋一起作用來確定證書的完整性,確保證書沒有被篡改過。
    為了保證證書的安全,證書發(fā)布機構在發(fā)布證書之前會對整個證書做一次HASH計算(此處的HASH算法即為證書中的指紋算法),并對得出的HASH值(指紋)做一次簽名加密(證書發(fā)布機構使用自己的私鑰以及證書中的簽名算法加密),并將簽名和證書放在一起發(fā)布。使用者在打開這個證書的時候會使用證書中的公鑰和簽名算法解出簽名加密的指紋,假設指紋為1,然后使用者會使用證書中聲明的指紋算法對整個證書做一次計算得出指紋2,最后比較指紋1和2是否相等,如果相等則可以保證證書完整性,證書沒有被中途篡改。

注意:以上只能證實證書的完整性,并不能保證證書被整個替換掉,所以為了解決這種問題,數字證書的發(fā)布機構也有自己的證書來保證自己的真實性。那么證書發(fā)布機構的證書是哪里來的呢?原來這種證書會默認安裝在操作系統中,像微軟、蘋果等操作系統公司會根據一些權威安全機構的評估選取一些信譽很好并且通過一定的安全認證的證書發(fā)布機構,把這些證書發(fā)布機構的證書默認就安裝在操作系統里面了,并且設置為操作系統信任的數字證書。這些證書發(fā)布機構自己持有與他自己的數字證書對應的私鑰,他會用這個私鑰加密所有他發(fā)布的證書的指紋作為數字簽名。

HTTPS的工作流程

準備階段

  • 服務端
    服務端把自己的公鑰登錄至數字證書發(fā)布機構,數字證書發(fā)布機構使用自己的私鑰對服務端的公鑰做簽名加密并頒發(fā)此公鑰的證書。
  • 客戶端
    此處的客戶端一般是指瀏覽器,瀏覽器會事先內置大部分權威機構的公鑰數字證書。如果沒有該機構的公鑰數字證書則需要去該機構處下載安裝該證書,當然這樣做需要承擔一定的風險。

通信階段

客戶端和服務端協商

  1. 客戶端通過發(fā)送Client Hello報文開始SSL通信。報文中 包含客戶端支持的 SSL 的指定版本、加密??件(Cipher Suite)??表,里面包含所支持使用的加密??算法及密鑰??長度等。
  • 服務端接收到客戶端所有的Cipher后與自身支持的對比,如果不支持則連接斷開,反之則會從中選出一種加密算法和HASH算法以證書的形式返回給客戶端,以Server Hello報文作為響應 ??。
  • 之后服務端發(fā)送Certificate報文,報文中包含??公鑰??證書。
  • 最后服務端發(fā)送Server Hello Done報文通知客戶端,最初??段的 SSL 握手協商??部分結束。

客戶端生成隨機密碼

  1. 客戶端檢查頒發(fā)證書的機構是否合法與是否過期,證書中包含的網站地址是否與正在訪問的地址一致等。
  • 如果證書驗證通過,客戶端會生成一串隨機數即PreMaster Secret,然后用證書中的公鑰和加密算法對PreMaster Secret加密,以Client Key E??change報文形式發(fā)送給服務端。
  • 用證書的HASH算法把握手消息取HASH值,然后用PreMaster Secret加密 “握手消息+握手消息HASH值”,以Change Cipher Spec報文形式發(fā)送給服務端,該報文會提示服務端在此報文之后的通信會??用Pre-master secret加密。
  • 客戶端發(fā)送Finished報文,該報文包含??接??今全部報文的整體????校驗值,這??握手協??是否能??成功,要以服務端是否能??正確解密該報文作為??判定標準。

服務端確認隨機密碼

  1. 服務端拿到客戶端傳來的密文,用自己的私鑰取出PreMaster Secret,再用PreMaster Secret解密握手消息和握手消息的HASH值,并與自己計算的握手消息HASH值做對比確認是否一致,如果一致則表明握手消息在傳輸過程中沒有被篡改,然后服務端同樣發(fā)送Change Cipher Spec形式的報文。
  • 服務器同樣發(fā)送Finished報文。

正式通信

  1. 客戶端用隨機數解密報文并計算握手消息的HASH,如果與服務端發(fā)來的HASH一致則至此握手過程結束,SSL連接就??建立完成,之后所有的通信數據將由之前客戶端生成的隨機密碼利用對稱加密算法進行加密。
  • 開始進行應用??協議的通信,客戶端發(fā)送HTTP請求。
  • 應用??協議通信,即發(fā)送 HTTP 響應。
  • 最后由客戶端斷開??接,斷開??接時,發(fā)送 close??_notify報文。

為什么需要數字證書

因為由于加密算法是公開的,大家都可以生成自己的公鑰和私鑰,為了防止攻擊者冒充服務端做中間人攻擊,就需要一種手段證明通信方是預期的安全對象,因此需要數字證書。如果沒有數字證書,攻擊者很容易做出如下例子的攻擊:

// 黑客截獲“客戶”發(fā)給“服務器”的消息
“客戶”->“黑客”:你好

// 黑客自己生成一對公鑰和私鑰,把公鑰發(fā)給“客戶”,自己保留私鑰
“黑客”->“客戶”:你好,我是服務器,這個是我的公鑰

“客戶”->“黑客”:向我證明你就是服務器

 // 客戶收到“黑客”用私鑰加密的信息后,是可以用“黑客”發(fā)給自己的公鑰解密的,從而會誤認為“黑客”是“服務器”
“黑客”->“客戶”:你好,我是服務器

為什么需要生成對稱密鑰通信

因為服務端的公鑰是公開的,如果服務端直接使用私鑰加密報文通信是無法保證報文能安全的到達客戶端的。而且非對稱加密的耗時較長,通信效率不如對稱加密。

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

推薦閱讀更多精彩內容