iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 3
2
Security

網路安全概述系列 第 3

HTTPS/SSL/TLS 概述,整體流程、憑證、數位簽章

HTTPS 的整體流程

在上一篇中,我們提到了 非對稱加密 的機制,能夠安全的來進行金鑰交換。不過,整體上 HTTPS 的進行流程,不只是這樣而已。

首先照慣例,附上一張圖。

整體上來說,HTTPS 的流程是:

  1. Hello - 客戶端和伺服器官表示想要發起 HTTPS 連線,說明自己支持的 SSL/TLS 版本和加密算法。伺服器端會回應客戶端說可以使用哪一種組合。
  2. 憑證交換 - 伺服器必須照明_自己是誰_。伺服器會拿出一張憑證,基本上這張憑證記載了伺服器的身份、位置(網址)、憑證的公鑰、有效日期和數位簽章。客戶端會確認是否要相信這張憑證,要麼這張憑證是被設定要信任,要麼這張憑證是由某個信任的機構 (CA) 簽署的。另外,這個機制其實可以雙向使用,伺服器端驗證客戶端的身份,不過這個機制很少用到。
  3. 金鑰交換 - 上一篇提到的機制。通過 Hello 步驟中獲得的資訊,雙方開始進行金鑰交換。交換成功之後,就能夠以對稱加密的方式來做通訊。

憑證

憑證的信任機制

一般來說,憑證要被信任,要滿足以下兩種需求之一:

  1. 這張憑證是由某一個你信任的組織 (CA, Certificate Authority, 憑證授權中心) 簽發的 (root certificate, 根憑證)
  2. 憑證本身的 CA,又能夠證明是被 #1 裡面的 CA 信任的 (intermidiate certificate, 中介證書)

通常 #1 比較單純,各家瀏覽器都會內建一份清單,記載有什麼 CA 是可以被相信的。要進入這個名單的流程非常的嚴謹,而且,由於事關重大,若 CA 做了什麼不太好的事情,那很快就會從這個清單內驅逐出去。不過實務上,除了看瀏覽器裡面的清單以外,也會看作業系統內帶的清單。兩份清單都可以自己做增減。

名單的控管,可以參考一下 Mozilla CA Certificate Store,至於從名單內被驅逐出的範例,可以參考一下 WoSign中國官方的CA, CNNIC

至於 #2 的部分,會需要「數位簽章」的機制來做驗證。

數位簽章

一張憑證可以被另一個授權中心做簽章的動作。正常狀況下,簽章代表著授權中心已經確認過原憑證持有方是真的擁有這個位置(網址)。實務上,這個授權中心會拿自己的私鑰去幫這張憑證的內容做加密,然後把這個密文嵌在憑證當中,當作數位簽章。這個流程和前述非對稱加密的流程是相反的,在數位簽章的狀況下,任何人都能拿這家憑證中心的公鑰去解開這張憑證,來確認這簽章是正常的。

所以流程是這樣:

  1. 你要進行 HTTPS 連線,雙方做 Hello
  2. 伺服器丟一張憑證給你,憑證上面寫說他被某 CA 簽了
  3. 你剛好有這家 CA 的公鑰,拿公鑰解他的憑證,看是不是解的出來,內容是否正常
  4. 繼續下一步

另外,這個方式可以連結很多張憑證,不過憑證一多,就要多花一點時間去檢查(重複2和3)。

常見的狀況:自簽憑證

因為之前提過,任何人都能夠隨便生憑證,重點是「這張憑證是否被大家相信」。有時候,在開發流程中,你會需要用 HTTPS,但你生不出一張正常的憑證(例如你根本沒網域,或是沒錢買,或是來不及弄),所以你就必須要自己當自己的 CA,然後自己用那個 CA 私鑰去生一張憑證出來。因為你自己的 CA 通常不會在信任名單裡面,所以大家跟你連線的時候,都會出現警示。

這種狀況下,你還是正在使用 HTTPS,所以資料傳輸過程有加密。不過,除非你將這張憑證加入信任清單,不然你沒有辦法防止別人做「中間人攻擊(即假裝他是那台伺服器)」。

機制弱點

前述提到,曾經發生過授權中心被除名的狀況。因為這些授權中心是可以讓任何憑證在大家的裝置上變得可用,因此,他們需要以非常嚴謹的態度來對待每一個憑證申請。被除名的 CNNIC,是因為某一間公司用中介證書簽了幾個 Google 網域底下的證書給其他人,而這張中介證書的根憑證是來自 CNNIC 的。因此,CNNIC 沒有做好管控措施,且這家公司是把憑證拿來做「竄改連線」的用途,因此就被除名了。

HTTPS 或是任何一個系統,都不是完全安全的。他防止不了有 CA 違規的情形、也防止不了你在服務裡面寫 shit logic。但是它還是一個很有效的資料傳輸方式。


上一篇
HTTPS/SSL/TLS 概述,Diffie-Hellman 算法(金鑰交換)
下一篇
ARP Spoofing,簡單講述 OSI 模型和網路上資料傳輸的流程
系列文
網路安全概述31

尚未有邦友留言

立即登入留言