HTTPS是如何保證連接安全的?

“HTTPS協議的工作原理是什麼?”這是我在數天前工作項目中需要解決的問題。

作爲一名Web開發者,我當然知道 HTTPS 協議是保障用戶敏感數據的好辦法,但並不知道這種協議的內在工作機制。

它怎麼保護數據?有人監聽線路的情況下,服務器與客戶端之間如何建立安全的連接?安全證書又是什麼,爲什麼還要花錢買呢?

 

一系列通道

在深入講解原理細節之前,讓我們首先簡單瞭解下HTTPS所防範的的問題,以及安全連接爲何如此重要吧。

在你訪問自己喜歡的站點時,從你的電腦發送的請求會在各個不同的網絡之間傳遞——這些網絡很有可能是用來偷聽,甚至篡改你的信息。

\加載中...

局域網中,信息從你的電腦傳輸到其他電腦,傳輸到接入點,到ISP的路由器、交換機,最後到達骨幹網線路。這樣的一個過程中,有許多不同的組織在傳送着你的請求。這時,如果不懷好意的用戶侵入這條線路之中的任何一個系統中時,他們將很有可能看到線路中傳送的內容。

而一般情況下,Web請求和相應都經由普通的HTTP協議明文傳送。HTTP協議默認不使用加密協議,都是由於這些原因:

  • 加密消耗了很多計算資源。
  • 加密佔用了更多的傳輸帶寬。
  • 加密後緩存機制會失效。

不過,Web開發者會時不時遇到在連接中傳送密碼、信用卡號等敏感信息的情況。所以,有必要爲這些頁面做好防嗅探的準備措施。

 

傳輸層安全協議(TLS)

雖然下面講解的內容和密碼學有關,但是這裏只是一個簡單的介紹,不熟悉相關知識也應該看得懂。在實踐中,是密碼學算法確保了通信過程的安全,同時也抵禦了潛在的信息黑手——干擾通信和監聽的人。

SSL協議的繼任者——TLS協議,常被用來實現安全HTTP連接(HTTPS)協議。在OSI網絡模型中,TLS協議比HTTP協議的工作更加底層。確切來說,就是TLS的那部分連接發生在HTTP的連接之前。

TLS是一種混合的加密機制。它具有多種範式,接下來所看到的是對於這兩種範式(用於共享祕密信息和身份認證(確保聲稱的身份和實際身份一致)的公鑰算法和用於加密請求與迴應機密信息的對稱式算法)的說明:

公鑰加密機制

使用公鑰加密機制,雙方各自擁有一份公鑰和一份私鑰,公鑰和私鑰通過數學演算聯繫在一起。公鑰用於將明文轉化爲密文(變成了一堆亂碼),私鑰用來解密這一堆亂碼般的信息。

一旦信息被公鑰加密,它將只能由相應的私鑰解密。兩者缺一不可,而且也不能反過來使用。公鑰可以自由傳播,無需擔心繫統安全性降低;但私鑰應妥善保管,不可將其泄露給未經授權解密的信息的用戶,這就是公鑰和私鑰這兩個名稱的由來。

公鑰機制相當酷的地方在於,通信雙方可以在最初不安全的通道上建立起安全可靠的通信連接。

客戶端和服務器都可以使用各自的私鑰,只要共享了一部分公開信息,也就是共用了同一個公鑰的情況下,就可以建立起相應的會話。

這意味着即使有人坐在客戶端或者服務器前查看連接過程,他們也不會知道客戶端或者服務的的私鑰,也不會知道會話所共享的密碼。

這得靠什麼實現?靠數學!

Diffie-Hellman

這種密鑰交換最常使用是Diffie-Hellman的密鑰交換法。這項過程允許服務器和客戶端雙方商定共同的保密信息,而不需要在傳輸過程中交換這個信息。這樣一來,即使嗅探者查看每個數據包,也不能確定連接上傳輸的共享密碼是什麼。

在最初的DH式密鑰交換髮生之後所生成的共享信息,可以在會話接下來的通信中使用更簡潔的對稱式加密法,我們之後就會看到對稱式加密法的說明。

一點點數學

公鑰算法的特點就是很容易由算子計算出結果,而基本上不可能作逆向運算。這也就是使用了兩個質數的所要達到的目的。

現在假設Alice和Bob分別是參與DH式密鑰交換過程的兩方,他們一開始會商議確定一個小質數(一般是2,3,5這樣的小數字)和一個大質數(有300位以上)作爲加密的原始信息。小質數和大質數都可以直接傳輸,不必擔心交換過程中的不安全。

需要明白的是,Alice和Bob各自都持有着自己的私鑰(100多位的數),而且也永遠不應該共享自己的私鑰。不光是兩人之間,也包括其他不相關的人都不應該擁有這兩組私鑰。網絡中傳輸的是他們的私鑰、小質數和大質數混合運算得到的結果。更確切來說,就是:

  • Alice的結果 = (小質數Alice的密碼)% 大質數
  • Bob的結果 = (小質數Bob的密碼)% 大質數
  • (“%” 符號表示取模運算,即取得除法運算的餘數)

所以Alice使用大質數和小質數加上自己的私鑰運算,就會得出結果,而Bob做同樣的計算,也能得到相同的結果。當他們接收到對方的運算結果時,他們可以由數學計算導出會話中所要傳輸的信息,也就是說:

Alice計算的是

  • (Bob的結果Alice的密碼)% 大質數

而Bob則計算

  • (Alice的結果Bob的密碼)% 大質數

Alice和Bob得出來的數字相同,這個數字也就是會話中所要共享的密碼。請注意,雙方都沒有向對方傳輸各自的私鑰,而連接過程中也沒有明文傳遞保密信息。這一點真是太棒了!

對數學不好的人而言,維基百科上有一張混合顏料的圖可以用來說明情況:

\

請注意圖中一開始的顏色(黃色)最後都會有Alice和Bob的顏色參與計算。這就是雙方會得到同樣結果的原因。對於觀看中間過程的人來說,唯一在連接中發送的半合成信息是毫無意義的。

對稱式加密機制

每次會話中只需要產生一次公鑰交換的過程。在接受了同一個共享保密信息以後,服務器和客戶端之間會使用更爲高效的對稱式加密機制進行通信,省去了來回交換的額外花銷。

在接受了之前的共享保密信息之後,還會使用一套密碼機制(一般是一組加密算法),使用共享的密碼安全地通信,加密解密各自的信息。而竊聽者只會看到一堆亂碼在傳來傳去。

身份認證

DH式密鑰交換允許雙方創建私有的,共有的密碼,但通信雙方怎麼確保是真正想要對話的人呢?這裏就涉及到了身份認證的問題。

假設我拿起電話,跟我的朋友進行DH式密鑰交換,在電話已經被幹擾的情況,實際上是在跟其他人交換信息。在使用共享密碼了以後,我仍然可以安全地與“朋友”交換信息,沒有人可以解密我們的通信信息,但是“朋友”並不真的是我的朋友,這可是十分不安全的!

要解決身份認證問題,需要有配套的公鑰基本設施,來覈實用戶的真實身份。這些設施用來創建,管理,發佈,收回數字證書。而數字證書正是你需要爲站點使用HTTPS協議付費的惱人事項。

但是,什麼是數字證書,數字證書又是如何保證信息更加安全的呢?

證書

從更高的層次來講,數字證書是將機器上的公鑰和身份信息綁在一起的數字簽名。數字簽名擔保某份公鑰屬於某個特定的組織和機構。

證書將域名(身份信息)和特定公鑰關聯起來。這就避免了竊聽者將自己的服務器僞裝成用戶將要連接的服務器,並進行攻擊的行爲。

在上面打電話的例子中,攻擊者可以嘗試展示自己的公鑰,裝作是你的“朋友”,但是證書上面的簽名信息便顯示出:這份證書不是來自我信任的人的。

要受到一般瀏覽器的信任,證書本身還應當受到CA的信任。CA公司對認證會進行人工覈查,確定申請主體滿足以下兩個條件:

  1.  在公共記錄中存在着這個人/這家公司。
  2. 需要簽名的證書上標明的域名的確由申請主體實際控制。

當CA查證,得出申請人屬實,並且的確擁有這個域名的結果,CA便會爲證書頒發簽證,蓋上“已覈准”的戳記,表明網站的公鑰屬於這個網站,而且可以信任。

你的瀏覽器中會內置一系列受信任的CA列表。如果服務器返回的是未經過受信任CA簽證的證書,瀏覽器會彈出大大的警告,這就在系統中多了一層安全措施,如果不然,任何人都可以四處籤售僞造的證書。

\

這樣一來,即使攻擊者將自己的公鑰拿出來,生成這份密鑰,聲稱自己的僞造服務器就是“facebook.com”,瀏覽器也會因爲檢查到“未經受信任CA簽名的證書”而彈出提示。

一些關於證書的其他事項

增強式認證

在常規的X.509 證書之外,增強式認證證書提供了更強力的認證。

要授予增強式認證證書,CA會對域名持有着做更加深入的查驗(通常需要提供護照和水電費賬單等信息)。

這種類型的證書,瀏覽器中大鎖圖標的顯示位置背景也會變成綠色。

在同一臺服務器上運行的多個網站

在HTTP協議連接開始之前進行的TLS協議握手流程,很有可能存在着多個網站存放在同一個服務器,使用相同IP地址的情況。

虛擬主機的Web路由是由Web服務器分發,但是TCP握手的過程,卻是發生在連接之前。整個系統的單張證書會被髮送到服務器的所有請求之中,這種流程會在共享主機的環境中發生問題。

如果你正在使用Web主機上提供的服務,他們會在你使用HTTPS協議之前要求使用獨立的IP地址。不然主體提供商就需要每次在服務器上有新站點的時候,取得新證書(並且向CA重新申請認證)。


原文鏈接: hartley brody   翻譯: 伯樂在線
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章