欧美,精品,综合,亚洲,好吊妞视频免新费观看,免费观看三级吃奶,一级a片女人自慰免费看

您當前的位置是:  首頁 > 資訊 > 國內(nèi) >
 首頁 > 資訊 > 國內(nèi) >

新規(guī)范RFC8760對SIP UAS和UAC-B2BUA新加密機制的影響

2021-07-19 09:58:39   作者:james.zhu   來源:Asterisk開源派   評論:0  點擊:


  SIP協(xié)議已經(jīng)使用了幾十年,安全加密的框架來自于HTTP。SIP協(xié)議初期的關于認證加密的規(guī)范是RFC-2617, 包括一直更新支持的RFC7235,RFC7615,RFC7616和比較近的RFC7617。在1991年,Ronald Rives設計了了MD5,基于MD4基礎上改進的算法,基于當時的計算機處理器的計算能力,MD5算法相對來說是最安全的。隨著計算機處理能力的不斷加強和各種破解工具的改進,MD5的安全問題越來越多,MD5不再是一個安全的算法。自從前幾年爆出安全算法漏洞以來,人們確實發(fā)現(xiàn)以前MD5已經(jīng)不再作為一個非常安全的加密算法,開始發(fā)展使用了比較新的算法SHA-256和SHA-512/256,支持了更強大的256-bit證書簽名。
  RFC7216規(guī)范在2015年發(fā)布以后,正式支持了以上兩種算法,并且兼容了MD5算法。這樣的話,現(xiàn)在在安全算法加密方面,事實上,SIP技術架構層面需要同時支持三種算法(MD5/SHA-256和SHA-512/256)。另外,最近SIP協(xié)議規(guī)范RFC3261明確規(guī)定需要支持RFC8760。因此,在SIP安全加密中涉及了更多需要更新的處理流程。這些處理流程影響了SIP 服務器端,SIP代理服務器和SIP終端等關于認證加密的處理。
  在過去的基于SIP安全架構的處理中,比較簡單的辦法就是WWW-Authenticate header使用MD5來進行加密處理,SIP客戶端和SIP服務器端都相互發(fā)送一個WWW-Authenticate 頭來進行加密處理解析。如果SIP呼叫需要經(jīng)過SIP代理服務器的話,代理服務器一般僅做簡單處理或者透傳。隨著SIP語音逐漸實現(xiàn)云部署和跨網(wǎng)絡部署,特別是在SIP運營環(huán)境中,經(jīng)過多個SIP代理做呼叫流程處理是非常普遍的場景。如果需要支持RFC8760的話,UAC和UAS的處理就變得相對比較復雜。針對SIP代理和B2BUA需要做更細節(jié)更復雜處理。但是,RFC3261實際上大部分規(guī)范內(nèi)容是針對SIP proxy來說明的,B2BUA需要通過UAC/UAS之間的角色通過不同代理機狀態(tài)分別進行處理。因此,在呼叫過程中,用戶系統(tǒng)對B2BUA場景需要做更多的兼容性支持。
 
  現(xiàn)在,筆者接下來給大家介紹一下關于RFC8760中一些具體的需要關注的幾個問題。在RFC8760(The Session Initiation Protocol (SIP) Digest Access Authentication Scheme)-2對UAS,UAC和forking呼叫分叉呼叫做了更新說明,大家特別需要關注的幾點變化:
  • 支持了qop參數(shù),對UAS和UAC表示支持了多個SIP Authorization,WWW-Authenticate和Proxy- Authenticate 頭支持,并且包括了處理順序。對端需要按照qop順序處理這些頭。
  • UAS可以支持對同一realm實現(xiàn)多個WWW-Authenticate頭支持。如果發(fā)送多個頭時,每個頭必須有不同的安全算法(MD5/SHA-256和SHA-512/256其中之一),UAS端所推薦的必須首先發(fā)送。
  • UAS可以使用多個realm 響應。這個規(guī)定有點麻煩。從技術角度可以實現(xiàn),但是在實際環(huán)境中可能導致包頭數(shù)據(jù)增加的可能性。在實際的SIP響應回復中,如果一個UAS支持至少兩個響應的話,每個響應支持三種算法的話,那么,UAS至少最低支持6個WWW-Authenticate頭消息。頭包的數(shù)據(jù)量會非常大。
  • UAC應該首先處理一個realm中的每個WWW-Authenticate中的第一個到最后一個列表數(shù)值。此處理需要通過一定的數(shù)據(jù)庫流程支持才能完整處理所有的WWW-Authenticate頭值狀態(tài)。UAC需要針對realm的每個后續(xù)請求發(fā)送一個認證頭。
  • 針對Proxy,請求被分叉處理以后,代理服務器需要負責聚合分發(fā)各種認證方式和加密設置響應處理。分叉處理代理收到下游代理的多個WWW-Authenticate和Proxy- Authenticate頭的時候,如果這些WWW-Authenticate和 Proxy- Authenticate頭在一個響應中時,分叉處理代理必須維持其原有狀態(tài),不能中任何修改。SIP代理聚合這些消息需要耗費大量的系統(tǒng)資源,這是一個新的影響性能瓶頸。
  以上這些在RFC8760中的更新基本上涵蓋了規(guī)范中對SIP RFC3261更新的所有核心內(nèi)容。筆者的理解可能有誤,如果用戶需要關注很多具體細節(jié)的話,可以直接參考RFC8760。
  筆者提醒用戶,用戶需要另外注意一些SIP代理的呼叫場景。在實際SIP proxy的應用場景中,絕大部分的呼叫是針對call transaction(事務狀態(tài))進行處理的。事務狀態(tài)會影響很多的其他業(yè)務處理,筆者建議用戶針對SIP代理服務器關于有狀態(tài)呼叫和無狀態(tài)呼叫,以及關于dialog的處理做更多測試和關注。
  以上筆者分享的關于RFC8760更新對SIP應用場景的影響僅是對這種更新做的一點點初探,針對其最新版本的理解可能有誤,用戶可以進一步根據(jù)自己的應用場景以及未來在用戶終端和服務器端兼容性方面進行升級測試以后才能發(fā)現(xiàn)更多更有價值的思考。
  參考資料:
  • https://datatracker.ietf.org/doc/html/rfc8760
  • www.dinstar.cn
  • www.asterisk.org.cn
【免責聲明】本文僅代表作者本人觀點,與CTI論壇無關。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔全部責任。

專題

CTI論壇會員企業(yè)