iT邦幫忙

2022 iThome 鐵人賽

DAY 19
0
Modern Web

快還要更快,讀作 quick 的下一代傳輸層協定: QUIC系列 第 19

【Day 19】Connection Migration(四): 可能會出現的安全問題

  • 分享至 

  • xImage
  •  

前言

前幾天的文章中大致講解了 Connection Migration 的流程,也知道一些它依賴的特性是怎麼交互的,今天我們會來簡單看一下 RFC 中所提到關於 Connection Migration 可能會發生的安全議題。

Peer Address Spoofing

Connection Migration 的過程中有可能會出現惡意的使用者把 Client 端的 Source IP 填入受害者的 IP,讓 Server 誤傳大量的封包給對方,Connection Migration 也有遭到放大流量攻擊的風險,所以 QUIC 規定如果對方的地址還沒有經過驗證的情況下遷移(實際要看 lib 實作),必須要限制發送新的地址的流量。

如上圖所示, Client 遷移地址後是可以持續發送 Non-probing Packet 的,但根據實作可能會馬上 or 在遷移之前就必須要用 Probing Packet 來進行 Path Validation 的驗證。

如果某些情況下選擇不做 validation 直接遷移的話, Server 端可以不進行流量限制,這是一個可以選用的功能。

On-Path Address Spoofing

On-Path 攻擊就是假冒成 Client 端進行連線遷移,使得 Server 跟錯誤的人建立連線,詳細解說可以參考以下兩個連結

但這種攻擊通常會被 Path validation 擋下來,因為它沒辦法回傳正確的 PATH_RESPONSE frame。

Off-Path Packet Forwarding

這種攻擊我看了一下覺得發動條件好像有點困難..? 攻擊者是必須要觀察的到封包的路徑,並試圖在真實的 Client 封包還沒有抵達 Server 的時候先發送偽造的封包(要比真正的封包早抵達),這時候可憐的受害者封包可以都會被歸類為重複發送而導致丟棄。

這類型的攻擊主要依賴攻擊者與 Client 有差不多的路徑,所以一般情況下應該比較少發生,然後這類型的攻擊也有不少防治手段,詳情可以看一下 RFC 的簡介,因為安全的議題實在是沒有很熟悉,所以就不再多贅述。


上一篇
【Day 18】Connection Migration(四): ngtcp2 connection migration 片段導讀
下一篇
【Day 20】Connection Migration(五): 遷移後的擁塞控制
系列文
快還要更快,讀作 quick 的下一代傳輸層協定: QUIC23
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言