iT邦幫忙

第 11 屆 iT 邦幫忙鐵人賽

DAY 6
1
Security

我是誰?我在哪?系列 第 6

簡介 SSL、TLS 協定

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

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

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

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、FTPSMTP 等,都能使用 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 如何驗證等,未來會再補充說明這些細節,有興趣的讀者可以參考下面的補充資料了解。

參考資料


上一篇
Cookie 的安全隱患
下一篇
簡介密碼學
系列文
我是誰?我在哪?30

尚未有邦友留言

立即登入留言