五月婷婷在线观看|国产成人精品3p人妻网站|日本老熟妇maturebbw|日韩 欧美 综合

        SIP協議已經使用了幾十年，安全加密的框架來自于HTTP。SIP協議初期的關于認證加密的規范是RFC-2617, 包括一直更新支持的RFC7235，RFC7615，RFC7616和比較近的RFC7617。在1991年，Ronald Rives設計了了MD5，基于MD4基礎上改進的算法，基于當時的計算機處理器的計算能力，MD5算法相對來說是最安全的。隨著計算機處理能力的不斷加強和各種破解工具的改進，MD5的安全問題越來越多，MD5不再是一個安全的算法。自從前幾年爆出安全算法漏洞以來，人們確實發現以前MD5已經不再作為一個非常安全的加密算法，開始發展使用了比較新的算法SHA-256和SHA-512/256，支持了更強大的256-bit證書簽名。

        RFC7216規范在2015年發布以后，正式支持了以上兩種算法，并且兼容了MD5算法。這樣的話，現在在安全算法加密方面，事實上，SIP技術架構層面需要同時支持三種算法（MD5/SHA-256和SHA-512/256）。另外，最近SIP協議規范RFC3261明確規定需要支持RFC8760。因此，在SIP安全加密中涉及了更多需要更新的處理流程。這些處理流程影響了SIP 服務器端，SIP代理服務器和SIP終端等關于認證加密的處理。

        在過去的基于SIP安全架構的處理中，比較簡單的辦法就是WWW-Authenticate header使用MD5來進行加密處理，SIP客戶端和SIP服務器端都相互發送一個WWW-Authenticate 頭來進行加密處理解析。如果SIP呼叫需要經過SIP代理服務器的話，代理服務器一般僅做簡單處理或者透傳。隨著SIP語音逐漸實現云部署和跨網絡部署，特別是在SIP運營環境中，經過多個SIP代理做呼叫流程處理是非常普遍的場景。如果需要支持RFC8760的話，UAC和UAS的處理就變得相對比較復雜。針對SIP代理和B2BUA需要做更細節更復雜處理。但是，RFC3261實際上大部分規范內容是針對SIP proxy來說明的，B2BUA需要通過UAC/UAS之間的角色通過不同代理機狀態分別進行處理。因此，在呼叫過程中，用戶系統對B2BUA場景需要做更多的兼容性支持。

        現在，筆者接下來給大家介紹一下關于RFC8760中一些具體的需要關注的幾個問題。在RFC8760（The Session Initiation Protocol (SIP) Digest Access Authentication Scheme）-2對UAS，UAC和forking呼叫分叉呼叫做了更新說明，大家特別需要關注的幾點變化：

支持了qop參數，對UAS和UAC表示支持了多個SIP Authorization，WWW-Authenticate和Proxy- Authenticate 頭支持，并且包括了處理順序。對端需要按照qop順序處理這些頭。

        UAS可以支持對同一realm實現多個WWW-Authenticate頭支持。如果發送多個頭時，每個頭必須有不同的安全算法（MD5/SHA-256和SHA-512/256其中之一），UAS端所推薦的必須首先發送。UAS可以使用多個realm 響應。這個規定有點麻煩。從技術角度可以實現，但是在實際環境中可能導致包頭數據增加的可能性。在實際的SIP響應回復中，如果一個UAS支持至少兩個響應的話，每個響應支持三種算法的話，那么，UAS至少最低支持6個WWW-Authenticate頭消息。頭包的數據量會非常大。

UAC應該首先處理一個realm中的每個WWW-Authenticate中的第一個到最后一個列表數值。此處理需要通過一定的數據庫流程支持才能完整處理所有的WWW-Authenticate頭值狀態。UAC需要針對realm的每個后續請求發送一個認證頭。

針對Proxy，請求被分叉處理以后，代理服務器需要負責聚合分發各種認證方式和加密設置響應處理。分叉處理代理收到下游代理的多個WWW-Authenticate和Proxy- Authenticate頭的時候，如果這些WWW-Authenticate和 Proxy- Authenticate頭在一個響應中時，分叉處理代理必須維持其原有狀態，不能中任何修改。SIP代理聚合這些消息需要耗費大量的系統資源，這是一個新的影響性能瓶頸。

        以上這些在RFC8760中的更新基本上涵蓋了規范中對SIP RFC3261更新的所有核心內容。筆者的理解可能有誤，如果用戶需要關注很多具體細節的話，可以直接參考RFC8760。

        筆者提醒用戶，用戶需要另外注意一些SIP代理的呼叫場景。在實際SIP proxy的應用場景中，絕大部分的呼叫是針對call transaction（事務狀態）進行處理的。事務狀態會影響很多的其他業務處理，筆者建議用戶針對SIP代理服務器關于有狀態呼叫和無狀態呼叫，以及關于dialog的處理做更多測試和關注。