那些關於ssl/tls的二三事四

那些關於ssl/tls的二三事四

Carl

May 1, 2018

1 min read

有了前面的基礎知識後, 現在可以來看一下憑證的結構了, 在寫這篇文章的當下, 我是用MAC, 所以接下來的指令操作都是以OSX為主.

首先, 先來看一下憑證的結構, 其概圖如下:

Structure of certificate

由此可知一個憑證基本上可以分成兩塊: 資料與簽章.

再來, 輸入以下指令以取得特定domain的憑證, 這邊以google.com為範例:

然後你就會看到以下內容:

可以跟上面那張簡圖對照著看, 有點冗長, 但其實還滿有條理的.

References

  • SSL/TLS Operations

在開始看SSL/TLS技術層面的內容之前, 先簡單介紹一下SSL certificates帶來的四個好處以及這些好處替我們解決了什麼問題:

Source identity verification
你現在看到的網站, 真的是該網站本身嗎?

當你登入到一些比較重要的網站時, 如銀行的網頁, 你會需要確認你所到達的頁面確實是這個銀行的網頁, 想想你在上面輸入password的時候, 若當下的網頁並不是這個銀行所提供的頁面, 那就很危險了. 換句話說, 你會想要避免任何在相同的domain name下看到相似的網站之可能性. 攻擊者通常會藉由攔截往來於正牌網站之間的流量來達到此目的. SSL可以協助我們驗證你正在存取的網站到底是正牌的還是假冒的. 這背後的機制是在瀏覽器上透過一些密碼學機制來達成的. 瀏覽器會通過驗證SSL憑證裡的簽章來確認其真實性. 一旦你的瀏覽器確定這個簽章是正確的, 你就可以在瀏覽器的address bar的左邊看到綠色的鎖頭:

有CA認證過的憑證

Security against Man-in-the-middle (MITM) attacks
會不會有人看到我在網站上輸入的信用卡卡號呢?

要想建立客人對你的信賴, 保護好線上的敏感資料是很重要的. 個人識別資訊(Personally Identifiable Information, a.k.a. PII)如信用卡卡號, 身分證字號, password, 生日, 醫療紀錄, 電話號碼, 地址等等. 這些都需要在各種的稽核標準/法律之下被安全的儲存/保護著. SSL通訊可以確保透過其傳輸的資料都是由某個secret key加密過的, 且此secret key只有client與server才知道, 並且對於每個唯一的session, 其secret key都是不同的.

Client/Server authentication
瀏覽器會識別與認證server的真實性, 那server也可以識別client嗎?

SSL允許雙向的認證. 瀏覽器可以驗證其正在存取的網站的身份, 網站也可以透過client憑證來驗證client的真實性. 在SSL通訊中, client憑證是一個選擇性的步驟, 其並不是那麼的常見. 不過對於封閉式網站來說, 這些就是必要的了, 畢竟對封閉式網站來說, 其必須確保從外界來存取其內容的client之身份.

Non-Repudiation
某個網站可能在某個時間點之後否定其之前所有的行為嗎?

在SSL連線建立後, 一旦瀏覽器驗證了server的SSL憑證中的簽章後, 這個server就被認為是已認證的了. 在這個時間點開始, 任何跟此server之間發生的通訊與行為都具有不可否定性, 即不管在未來的任何時間點, 該server都不可以否定其之前所做過的事.

最後要補充的一點就是: SSL的另一個目的是作為server的public key的載體. 對於SSL通訊中的”信任鏈驗證(chain of trust validation)”階段與金鑰交換過程來說, server的public key都扮演了非常重要的角色.

References

  • SSL/TLS Operations

HTTP 與 Cookie 都是明碼傳輸,這對做身分驗證並不是件有利的事。這就像是結帳刷卡的時候,大喊自己的帳號密碼一樣,路人聽到就能盜刷了。

最理想的情況當然是「天知地知,你知我知」。在網路世界裡,因為大家都在同一個載體上傳輸資料,因此任何資料都有被截取的機會,因此只能退而求其次:「我講只有你聽得懂的話,你講只有我聽得懂的話」。現實社會中,比較難做到這種程度,但電腦的世界裡,這正是密碼學主要在討論的。

今天會先討論密碼學實際的應用--SSL/TLS,後面再討論細節。

為何筆者這麼愛討論歷史呢?因為在挖歷史的過程總是能解決很多奇妙的問題。比方說 SSL 和 TLS 到底有何不同,挖完才發現它們之間的關係。

SSL 全名為 Secure Sockets Layer,TLS 全名為 Transport Layer Security。以下參考維基百科的資料。

  • SSL 1.0 是由 Netscape 設計的,但時間不詳。
  • SSL 2.0 1995 年發布,2011 年棄用。
  • SSL 3.0 1996 年發布,2015 年棄用。後來 IETF 也將此協定特別發布了 RFC 6101 作為歷史記錄。
  • TLS 1.0 1999 年 IETF 將 SSL 標準化,發布了 RFC 2246,同時改名為 TLS。也因此 SSL 3.0 和 TLS 1.0 其實沒有什麼太大差別,甚至可以說是一樣的東西。而 TLS 1.0 也支援相容 SSL 3.0 的功能,但這做法同時也降低了安全性。
  • TLS 1.1 2006 年發布 RFC 4346,雖然目前沒什麼問題,還是計劃於 2020 年棄用
  • TLS 1.2 2008 年發布 RFC 5246,可運作在 HTTP/2 上。
  • 2014 年,Google 發現了 SSL 3.0 有致命的安全性漏洞,加上 TLS 1.0 因為加密模式設計不良,會造成加密內容被解密,因此馬上變成主要的資安檢核項目之一,建議早日關閉。
  • TLS 1.3 2018 年發布 RFC 8446

注意看了一下,TLS 每個 RFC 都是 46 結尾,不知道是不是故意的。

值得一提的是,HTTP/2 協定是允許非加密的,同時也允許 TLS 1.2 或更新的版本,但目前主流瀏覽器都只實作加密的 HTTP/2,這讓 HTTP/2 + TLS 變成了強制標準。

TLS 運作原理

TLS 在 OSI 模型裡,它屬於傳輸層的協定,而簡介 HTTP 是有提到 HTTP 是應用層協定。而 OSI 模型在設計上是符合里氏替換原則與依賴反轉原則的,這代表傳輸層是否有 TLS 是不會影響應用層的 HTTP;反之,不管應用層是 HTTP、FTP 或 SMTP 等,都能使用 TLS 加密。

TCP Three-way Handshake

傳輸層上還有另一個廣泛使用的協定--RFC 793 - Transmission Control Protocol(TCP),裡面有提到一開始建立連線的方法,即為 Three-way Handshake。

時序圖如下:

@startuml
Alice -> Bob: SYN
Alice <- Bob: SYN-ACK
Alice -> Bob: ACK
@enduml

簡單來說,這過程有點像在打電話:

  1. Alice:「喂?」
  2. Bob:「喂?有聽到嗎?」
  3. Alice:「有聽到了!」

然後就可以開始正常講話了。

SSL Handshake

在 TCP Three-way Handshake 完成之後,如果 Alice 有希望使用 SSL 加密時就會開始做 SSL Handshake。時序圖如下:

@startuml
Alice -> Bob: (1) hello
note left
  Highest SSL version
  Cipher supported
  Data Compression Method
  etc.
end note
Alice <- Bob: (2) hello
note right
  Selected SSL version
  Selected Cipher
  Selected Data Compression Method
  Certificate
  etc.
end note
Alice -> Alice: (3) Validate Certificate
Alice -> Bob: (4) Certificate
Bob -> Bob: (5) Validate Certificate
Alice -> Bob: (6) Key exchange
Alice -> Bob: (7) Change Cipher Spec
Alice -> Bob: (8) Finished
Alice <- Bob: (9) Change Cipher Spec
Alice <- Bob: (10) Finished
Alice <-> Bob: (11) Encrypted Data Transfer
@enduml
  1. 首先第一步 Alice 跟 Bob 要求要用 SSL 加密,於是 Alice 先跟 Bob 說她支援什麼樣的版本與相關資訊等
  2. Bob 如果有支援的話,就會回傳他選了哪些版本,同時也會把 Certificate 傳送給 Alice 驗證
  3. Alice 拿到 Certificate 後,會先驗看看是不是合法的,若是不合法的,則會提出警告訊息給使用者
  4. 第二步 Bob 可以要求 Alice 也提供 Certificate,如果有的話就會傳給 Bob
  5. 同第三步驗證
  6. 再來就是金鑰(key)交換,這裡會隨機產生一組做為對稱式加密使用的密鑰(secret)
  7. Alice 會跟 Bob 說好,接下來要用什麼樣的方法來做資料加密
  8. Bob 收到訊息並確認這是 Alice 發送出來的
  9. Bob 也發送訊息通知 Alice 要用什麼方法做資料加密
  10. Alice 拿到訊息,也確認完成
  11. 到此為止,已可開始使用加密資料傳輸了

小結

以上是簡單版的 HTTP + TLS 傳輸流程,有省略非常多細節沒說明,如加密演算法或 Certificate 如何驗證等,未來會再補充說明這些細節,有興趣的讀者可以參考下面的補充資料了解。

參考資料

  • 傳輸層安全性協定 - 維基百科
  • HTTP/2 - 維基百科
  • 那些關於ssl-tls的二三事 - Carl