WebSocketsがマスクされているのはなぜですか？

Question

私は Writing a WebSocket serverにMDNが提供するガイドを次れた

は、ガイドが...非常に簡単で理解しやすいです

しかし、私は、クライアントからのメッセージをWebSocketの枠を越え走っこのチュートリアルを以下の時に送信されます。

 

0     1     2     3 
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-------+-+-------------+-------------------------------+ 
|F|R|R|R| opcode|M| Payload len | Extended payload length | 
|I|S|S|S| (4) |A|  (7)  |    (16/64)   | 
|N|V|V|V|  |S|    | (if payload len==126/127) | 
| |1|2|3|  |K|    |        | 
+-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + 
|  Extended payload length continued, if payload len == 127 | 
+ - - - - - - - - - - - - - - - +-------------------------------+ 
|        |Masking-key, if MASK set to 1 | 
+-------------------------------+-------------------------------+ 
| Masking-key (continued)  |   Payload Data   | 
+-------------------------------- - - - - - - - - - - - - - - - + 
:      Payload Data continued ...    : 
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + 
|      Payload Data continued ...    | 
+---------------------------------------------------------------+ 
 

正しくデータとクライアントから送信されたフレームのマスクを解除するためにいくつかの機能を行った後、それはデータがさえで始まるようにマスクされている理由を私は不思議ました。つまり、サーバーから送信しているデータをマスクする必要はありません。

悪意のある理由で誰かがデータを取得していた場合、マスキングキーが含まれているため、マスクを解除するのは比較的簡単ですメッセージ全体あるいは、キーを持っていなかったとしても、フレームのマスキングキーは2バイトしかありません。キーが非常に小さいので誰かが簡単にデータのマスクを解除することができます。

なぜデータがマスクされているのか疑問に思うもう一つの理由は、TLS/SSL上でWSS（WebSockets Secure）を使用し、HTTPSを使用して、WebSocketデータをマスキングよりも簡単に保護できるからです。

なぜWebSocketsがマスクされているのか分かりませんか？最初にセキュリティを追加しないときに、クライアントから送信されたデータをアンマスクする無意味な闘争が追加されたようです。暗号化されていないのWebSocket接続をマスキングする必要が要件だけではなく、有益であることを示しているように

Answer 1

jfriend00さんのコメントが...

を良い情報への優れたリンクを持っている私は、やや明らかに指摘したいです：

プロキシ、ルーターおよびその他の仲介業者（特にISP）は、クライアントから送信された要求を読み取り、問題を「修正」し、ヘッダーを追加したり、ネットワークリソースの消費（キャッシュからの応答など）を最適化します。

一部のヘッダーと要求の種類（Connectなど）は、多くの場合、エンドポイントサーバーではなくこれらの仲介者に送られます。

これらのデバイスの多くは古いもので、Webソケットプロトコルを認識しないため、HTTP要求のようなクリアテキストが編集または処理される可能性があります。

したがって、「処理」ではなく「通過」を開始するには、クリアテキストを認識されないバイトに「シフト」する必要がありました。

これ以降、ハッカーが悪意のあるフレームを送信するためにこのマスキングを「リバース」しないようにするために、マスキングを利用していました。

マスキングの代わりにwssが必要ですが、これは標準の作成中に考えられたことですが、証明書が無料になるまでSSL/TLSを要求するウェブ標準は「リッチ・マン」インターネット全体のソリューションです。

"なぜマスクのwssデータですか？" - 私はこのことについてはわかりませんが、パーサーが接続に不可知論であり、書くのが簡単であると考えています。クリアテキストでは、マスクされていないフレームはプロトコルエラーであり、その結果、サーバーによって切断が開始されます。パーサーは接続に関係なく同じ動作をするので、パーサーをraw IOレイヤーから分離して、コネクションに依存しないようにし、イベントベースのプログラミングをサポートすることができます。