端對端加密不等於不留紀錄：三個常見誤解

「這個 App 有端對端加密」常被直接理解成「完全沒有任何紀錄留下」，但這中間其實有一些技術上的細節被簡化掉了。這篇文章想把端對端加密實際涵蓋的範圍講清楚。

誤解一：加密就代表什麼都看不到

端對端加密保護的是訊息內容本身，但時間戳記、路由等中繼資料通常不在加密範圍內。

端對端加密（End-to-End Encryption, E2EE）保護的核心是「訊息或通話的實際內容」——文字、語音、影像本身。但要讓通訊順利運作，還需要一些「中繼資料」（metadata），例如封包的時間戳記、序號、路由資訊，這些通常不在加密保護的範圍內，因為系統需要這些資訊來維持連線品質、進行封包轉發。也就是說，「聊了什麼」被保護，但「什麼時候聊、聊了多久、跟誰聊」這類中繼資料，不一定完全隱藏。

誤解二：「有加密」不等於「端對端加密」

視訊通話標榜「有加密」，但常是逐段加密，伺服器會先解密再轉發，不算真正端對端加密。

這是最容易被混淆的地方。很多視訊會議或通話服務會說自己「有加密」，但實際架構可能是「逐段加密」（hop-by-hop encryption）——資料在使用者裝置與媒體伺服器（SFU，Selective Forwarding Unit）之間是加密的，但伺服器本身會先解密才轉發給下一位參與者，這代表伺服器營運方技術上是可以存取到內容的。真正的端對端加密，是只有通訊的兩端（或所有端）能解密，中間經手的任何伺服器都無法讀取內容，這需要額外的技術設計（例如 WebRTC 的 Insertable Streams／Encoded Transform API）才能達成。

下表整理三種常見架構的差異：

架構	伺服器能否讀取訊息內容	說明
端對端加密（E2EE）	不能	只有通訊兩端能解密，需額外技術設計（如 WebRTC Insertable Streams）
逐段加密（Hop-by-hop，SFU）	能	媒體伺服器會先解密才轉發給其他參與者
TURN 中繼伺服器	不能讀取內容，但可能經手連線資訊	只轉發已加密封包，用於 NAT 穿透

誤解三：P2P 連線一定完全不經過任何伺服器

多數情況下 P2P 通訊確實不經伺服器，但某些網路環境仍需 TURN 中繼伺服器協助轉發。

點對點（P2P）通訊常被理解成「訊息直接在兩個裝置之間傳輸，完全不碰任何伺服器」，多數情況下確實如此。但在某些網路環境下（例如企業防火牆或特殊的 NAT 環境），兩個裝置可能沒辦法直接建立連線，這時候 WebRTC 技術會透過 TURN 中繼伺服器協助轉發資料——這是處理 NAT 穿透的標準機制。TURN 伺服器的角色只是轉發已經加密的封包、不會解密應用層的內容，但技術上它仍可能經手連線建立過程中的必要網路資訊，例如 IP 位址。

這些細節重要嗎

對多數人來說，端對端加密已經保護了最核心的隱私需求；但若你在意中繼資料，細節仍值得了解。

對多數人來說，「訊息內容被保護、不會被讀取」已經是最核心的隱私需求，端對端加密確實做到了這件事。但如果你的威脅模型包含「不希望任何人知道我跟誰聯繫、聯繫了多久」，那中繼資料與連線架構的細節就值得多了解一點，不要只看到「加密」兩個字就假設所有面向都被涵蓋了。

常見問題