2013-08-17 20 views
2

約WebSocket的protocal,你可以閱讀這裏的細節,http://tools.ietf.org/html/rfc6455#section-5.3有關的WebSocket的掩膜場

在屏框部

,它說:

掩蔽關鍵是隨機選擇的32位值由客戶。
準備掩碼幀時,客戶端必須從允許的32位值集合中挑選新的掩碼
密鑰。掩碼鍵需要
是不可預知的;因此,掩碼密鑰務必從熵的強源派生而來,並且對於給定幀的掩碼密鑰必須不是
使服務器/代理服務器能夠簡單地預測後續幀的掩碼密鑰。屏蔽密鑰的不可預測性是防止惡意應用程序的作者選擇線上顯示的字節所必不可少的。 RFC 4086 [RFC4086]討論了什麼是 需要一個適合安全敏感的應用程序的熵源。

我不知道爲什麼必須掩碼關鍵字是不可預測的,更何況是真的面膜是必要的嗎?因爲你每一次發送,嗅探器可以得到它,輕鬆地解密後援唯一有用我可以想到的是,這使得人們首先無法讀取playload數據,並且需要更多時間來處理接收的數據。

回答

5

這不是關於有效載荷數據的安全性,而是使得發送者不可能數據能夠預測出現在線路上的實際字節數。

屏蔽WebSocket客戶端到服務器的流量是必需的,因爲惡意代碼不太可能會導致一些破壞的代理做錯誤的事情並將其用作某種攻擊。沒有人證明這實際上可能會發生,但是由於事實可能發生這一事實足以讓瀏覽器廠商變得t,不安,所以添加了屏蔽以消除它被用作攻擊的可能性。

這個想法是因爲生成WebSocket框架的API級別代碼可以選擇屏蔽鍵並屏蔽應用程序代碼提供的數據,所以應用程序代碼不能以任何有意義的方式指示最終通過潛在屏蔽的數據破碎的中介,因此不會造成麻煩。由於屏蔽鍵在框架中,可以編寫中介以理解和揭露數據,以便如果他們想要執行某種形式的聰明檢查。

這也解釋了從服務器到客戶端屏蔽的缺失......我在我的博客here上寫了更多關於此的內容。

+0

我讀過你的博客並閱讀相關鏈接,我仍然無法真正理解掩蓋點,我不能完全理解他們在談論的內容,如透明代理,路由,它就像是軟件開發中的另一個領域,但我有一種感覺,在協議中有一些偉大的設計思想(或者不是很好,但你可以從中學到一些教訓),有一天我可以在我的工作中使用它們。如果有人能夠用一種流行的方式來解釋它,那麼大羣體可以受益從它。無論如何,謝謝你發佈:) – user2003548

+0

我認爲掩蔽的重點是沒有掩碼;)恕我直言。 –