IM系統四大基本特性-安全性(及解決方案)

消息安全性的三個維度

 既然對於即時消息服務來說,安全性是如此的重要和不可妥協,那麼到底都有哪些環節可能導致消息安全方面的問題呢?

一般來說,從消息的產生和流轉的細分上,我們大概從三個維度來描述消息的安全性:

1.消息傳輸安全性

2.消息存儲安全性

3.消息內容安全性

如何保證消息傳輸安全性

傳輸安全性這個比較好理解,存在網絡交互的即時消息服務,大多需要通過開放網絡來進行消息和信令的傳輸。可能導致出現安全風險的地方相對也比較多,比如,DNS 劫持會導致發往 IM 服務的請求被攔截髮到其他服務器,導致內容泄露或失效;或者明文傳輸的消息內容被中間設備劫取後篡改內容,再發往 IM 服務器引起業務錯誤等問題。在消息傳輸過程中,我們主要關注兩個問題:“訪問入口安全”和“傳輸鏈路安全”,這也是兩個基於互聯網的即時消息場景下的重要防範點。

1.保證訪問入口安全:HttpDNS

對於即時消息服務,一般都會提供一個公網的“接入服務”,作爲用戶消息收發的出入口,並通過域名的方式提供給客戶端。對於這個出入口的訪問,經常也會由於各種原因導致“訪問不了”“地址錯誤”的問題。

關於訪問入口,我們比較常見的問題就是 DNS 劫持。針對接入域名的 DNS 劫持問題的常見原因有下面兩類。

第一類是路由器的 DNS 設置被非法侵入篡改了。這種問題常見於一些家用寬帶路由器,由於安全性設置不夠(比如使用默認密碼),導致路由器被黑客或者木馬修改了,DNS 設置爲惡意的 DNS 地址,這些有問題的 DNS 服務器會在你訪問某些網站時返回仿冒內容,或者植入彈窗廣告等。

第二類是運營商 LocalDNS 可能會導致接入域名的解析被劫持。

比如下面三種比較典型的情況。

(1).LocalDNS 是部分運營商爲了降低跨網流量,緩存部分域名的指向內容,把域名強行指向自己的內容緩存服務器的 IP 地址。

(2).運營商可能會修改 DNS 的 TTL(Time-To-Live,DNS 緩存時間),導致 DNS 的變更生效延遲,影響服務可用性。我們之前一個線上業務域名的 TTL 在某些省市能達到 24 小時。

(3).一些小運營商爲了減輕自身的資源壓力,把 DNS 請求轉發給其他運營商去解析,這樣分配的 IP 地址可能存在跨運營商訪問的問題,導致請求變慢甚至不可用。

解決方案:

(1).對於寬帶路由器的 DNS 設置被篡改的問題,一般,我們會重置一下路由器的配置,然後修改默認的路由管理登錄密碼,基本上都能解決,這裏不做細述。

(2).解決運營商 LocalDNS 的域名劫持和調度錯誤,業界比較常用的方案有 HttpDNS。HttpDNS 繞開了運營商的 LocalDNS,通過 HTTP 協議(而不是基於 UDP 的 DNS 標準協議)來直接和 DNS 服務器交互,能有效防止域名被運營商劫持的問題。而且由於 HttpDNS 服務器能獲取到真實的用戶出口 IP,所以能選擇離用戶更近的節點進行接入,或者一次返回多個接入 IP,讓客戶端通過測速等方式選擇速度更快的接入 IP,因此整體上接入調度也更精準。當然,調度精準的另一個前提是 HttpDNS 服務自身需要有比較全的 IP 庫來支持。目前很多大廠也基本都支持 HttpDNS 爲主,運營商 LocalDNS 爲輔的模式了,像很多第三方雲廠商也提供對外的 HttpDNS 解析服務。HttpDNS 的實現架構如下圖:

這裏介紹一下這張圖。用戶的請求不再通過運營商來查詢域名的解析,而是通過 HTTP 獨立提供的一個方法來進行查詢,這個 HTTP 接口後端再去向權威 DNS 請求,以及去做一個數據的同步。

2.保證傳輸鏈路安全:TLS 傳輸層加密協議

對於消息在傳輸鏈路中的安全隱患,基本可以總結爲以下幾種。

(1)中斷,攻擊者破壞或者切斷網絡,破壞服務可用性。

(2)截獲,攻擊者非法竊取傳輸的消息內容,屬於被動攻擊。

(3)篡改,攻擊者非法篡改傳輸的消息內容,破壞消息完整性和真實語義。

(4)僞造,攻擊者僞造正常的通訊消息來模擬正常用戶或者模擬 IM 服務端。

解決方案:

1.關於消息鏈路中斷,我們採取多通道方式進行解決。

在即時消息系統中,對於“中斷傳輸“這種主動攻擊,破壞服務可用性的行爲,一般可以採取多通道方式來提升鏈路可用性,比如很多 IM 系統的實現中,如果主鏈路連接不通或者連接不穩定,就會嘗試自動切換到 failover 通道,這個 failover 通道可以是:

(1)從 HttpDNS 服務返回的多個“接入 IP”中選擇性進行切換,防止某一個“接入 IP”的中間鏈路被破壞。

(2)從當前數據傳輸協議切換到其他傳輸協議,比如從基於 UDP 協議的 QUIC 協議切換到基於 TCP 協議的私有協議;或者針對 TCP 的私有協議提供 HTTP Tunnel 來對數據進行二次封裝(微博目前支持這種方式),防止某些針對特定協議的中斷攻擊。

2.關於消息傳輸過程被截獲、篡改、僞造,我們則利用私有協議和 TLS 的技術,來進行防控。

對於消息傳輸過程中被第三方截獲消息內容、消息內容被惡意篡改,以及第三方僞造 IM 服務端或者僞造客戶端來獲取消息或者執行惡意操作的情況,業界也有很多應對策略來進行防護。

(1)私有協議:對於採用二進制私有協議的即時消息系統本身由於編碼問題天然具備一定的防竊取和防篡改的能力,相對於使用 JSON、XML、HTML 等明文傳輸系統,被第三方截獲後在內容破解上相對成本更高,因此安全性上會更好一些。

(2)TLS

因此,爲了解決上面一系列的安全問題,業界一般採用 TLS 協議來對業務數據進行保護,TLS 巧妙地把“對稱加密算法”“非對稱加密算法”“祕鑰交換算法”“消息認證碼算法”“數字簽名證書”“CA 認證”進行結合,有效地解決了消息傳輸過程中的截獲、篡改、僞造問題。

TLS加密過程:

(1)非對稱加密算法和祕鑰交換算法用於保證消息加密的密鑰不被破解和泄露。

(2)對稱加密算法對消息進行加密,保證業務數據傳輸過程被截獲後無法破解,也無法篡改消息。

(3)數字簽名和 CA 認證能驗證證書持有者的公鑰有效性,防止服務端身份的僞造。

TLS 本身相對於原本的 TCP 三次握手,需要更多算法確認、祕鑰協商交換、證書驗證等環節,因此在握手環節會多出 1-2 個 RTT(Round-Trip Time 往返時延),所以 TLS 在連接效率和傳輸性能上有一定的額外開銷。

針對這個問題,最新的 TLS 1.3 版本進行了優化,可以支持 1-RTT 甚至 0-RTT 的握手環節,能較大幅度降低 TLS 的額外消耗,TLS 1.3 在 2018 年 8 月才定稿最終版本(RFC 8446),大規模鋪開使用還需一定時間,像微信早在幾年前 TLS 1.3 的草案階段,就自行實現了“基於 TLS1.3 的 MMTLS 協議”來保護消息傳輸中的安全。

如何保證消息存儲安全性

由於消息漫遊和離線消息等業務需要,大部分即時消息服務會將消息暫存在 IM 服務器端的數據庫,並保留一定的時間,對於一些私密的消息內容和用戶隱私數據,如果出現內部人員非法查詢或者數據庫被“拖庫”,可能會導致隱私信息的泄露。賬號密碼存儲安全:“單向散列”算法

解決方案:

1.賬號密碼存儲安全:“單向散列”算法

針對賬號密碼的存儲安全一般比較多的採用“高強度單向散列算法”(比如:SHA、MD5 算法)和每個賬號獨享的“鹽”(這裏的“鹽”是一個很長的隨機字符串)結合來對密碼原文進行加密存儲。“單向散列”算法在非暴力破解下,很難從密文反推出密碼明文,通過“加鹽”進一步增加逆向破解的難度。當然,如果“密文”和“鹽”都被黑客獲取到,這些方式也只是提升破解成本,並不能完全保證密碼的安全性。因此還需要綜合從網絡隔離、DB 訪問權限、存儲分離等多方位綜合防治。

2.消息內容存儲安全:端到端加密

針對消息內容的存儲安全,如果存儲在服務端,不管消息內容的明文或者密文都存在泄漏的風險。因此保證消息內容存儲安全的最好方式是:

(1)消息內容採用“端到端加密”(E2EE),中間任何鏈路環節都不對消息進行解密。

(2)消息內容不在服務端存儲。

採用“端到端加密”方式進行通信,除了收發雙方外,其他任何中間環節都無法獲取消息原文內容,即使是研發者也做不到“破解”並且獲取數據,頂多停止這種加密方式。業界很多聊天軟件如 WhatsApp、Telegram 就採用了“端到端加密”方式來保證消息內容的安全。但國內的大部分即時消息軟件如 QQ、微信等由於網絡安全要求,目前暫時還沒有采用“端到端加密”。“端到端加密”之所以更加安全是因爲:是由於和服務端 TLS 加密不一樣,“端到端加密”的通信雙方各自生成祕鑰對並進行公鑰的交換,私鑰各自保存在本地不給到 IM 服務端。發送方的消息使用接收方的公鑰來進行加密,因此即使是 IM 服務端拿到了加密信息,由於沒有接收方的私鑰,也無法解密消息。

消息內容安全性

內容安全性主要是指針對消息內容的識別和傳播的控制,比如一些惡意的鏈接通過即時消息下發到直播間或者羣,可能會導致點擊的用戶被引誘到一些釣魚網站;另外一些反政、淫穢的圖片、視頻等消息的傳播會引起不良的負面影響,需要進行識別處置並避免二次傳播。針對消息內容的安全性一般都依託於第三方的內容識別服務來進行”風險內容“的防範。

解決方案:

1.建立敏感詞庫,針對文字內容進行安全識別。

2.依託圖片識別技術來對色情圖片和視頻、廣告圖片、涉政圖片等進行識別處置。

3.使用“語音轉文字”和 OCR(圖片文本識別)來輔助對圖片和語音的進一步挖掘識別。

4.通過爬蟲技術來對鏈接內容進行進一步分析,識別“風險外鏈”。

一般來說,針對內容安全的識別的方式和途徑很多,也有很多成熟的第三方 SaaS 服務可以接入使用。對於 IM 服務端來說,更多要做的是要建立和“識別”配套的各種懲罰處置機制,比如:識別到羣裏有個別人髮色情視頻或者圖片,可以聯動針對該用戶進行“禁言處理”,如果一個羣裏出現多人發違規視頻,可以針對該羣“禁止發多媒體消息”或者進行“解散羣”等操作。

總結:

即時消息中,消息安全性是各種私密社交場景的核心需求,一般可以從三個維度來對安全性進行評價。

1.消息傳輸安全性。“訪問入口安全”和“傳輸鏈路安全”是基於互聯網的即時消息場景下的重要防範點。針對“訪問入口安全”可以通過 HttpDNS 來解決路由器被惡意篡改和運營商的 LocalDNS 問題;而 TLS 傳輸層加密協議是保證消息傳輸過程中不被截獲、篡改、僞造的常用手段。

2.消息存儲安全性。針對賬號密碼的存儲安全可以通過“高強度單向散列算法”和“加鹽”機制來提升加密密碼可逆性;對於追求極致安全性的即時消息場景並且政策允許的情況下,服務端應該儘量不存儲消息內容,並且採用“端到端加密”方式來提供更加安全的消息傳輸保護。

3.消息內容安全性。針對消息內容的安全識別可以依託“敏感詞庫”“圖片識別”“OCR 和語音轉文字”“外鏈爬蟲抓取分析”等多種手段,並且配合“聯動懲罰處置”來進行風險識別的後置閉環。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章