Dlaczego maski WebSockets są maskowane?

Question

byłem po przewodnika dostarczonego przez MDN na Writing a WebSocket server, przewodnik jest bardzo proste i łatwe do zrozumienia ...

Jednak na następujące samouczek natknąłem ramce websocket wiadomości od klienta są przesyłane w:

 

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 ...    | 
+---------------------------------------------------------------+ 
 

Po wykonaniu niektórych funkcji w celu prawidłowego zdemaskowania danych i ramki wysyłanej przez klienta, zastanawiałem się, dlaczego dane są maskowane na początku. Nie musisz maskować danych, które wysyłasz z serwera ...

Jeśli ktoś otrzymywał dane z niewłaściwych powodów, względnie łatwo było go zdekasować, ponieważ klucz jest dołączony do cała wiadomość. Lub nawet jeśli nie mają klucza, klucz maskujący w ramce ma tylko 2 bajty. Ktoś może łatwo zdemaskować dane, ponieważ klucz jest bardzo mały.

Innym powodem, dla którego zastanawiam się, dlaczego dane są maskowane, jest to, że można po prostu lepiej chronić dane WebSocket niż maskowanie przy użyciu WSS (WebSockets Secure) na TLS/SSL i przez HTTPS.

Czy brakuje mi sensu, dlaczego WebSockets są zamaskowane? Wydaje się, że po prostu dodaje bezsensownej walki, aby zdemaskować dane wysyłane przez klienta, gdy nie dodaje żadnych zabezpieczeń na początek. Komentarz

Answer 1

jfriend00 zawiera świetne linki do dobrych informacji ...

chcę zwrócić uwagę na dość oczywiste, tak aby pokazać, że maskowanie nieszyfrowanych połączeń websocket jest niezbędnym wymogiem, a nie tylko korzystne :

Serwery proxy, routery i inni pośrednicy (zwłaszcza dostawcy usług internetowych) często odczytują żądania wysłane przez klienta i "poprawiają" wszelkie problemy, dodają nagłówki i w inny sposób "optymalizują" (np. Reagowanie z pamięci podręcznej) zużycie zasobów sieciowych.

Niektóre nagłówki i typy żądań (takie jak Connect) są często kierowane do tych pośredników, a nie do serwera punktu końcowego.

Ponieważ wiele z tych urządzeń jest starszymi i nieświadomymi protokołu Websockets, czysty tekst, który wygląda jak żądanie HTTP, może być edytowany lub obsługiwany.

Dlatego konieczne było, aby czysty tekst został "przesunięty" do nierozpoznanych bajtów, aby zainicjować "przekazanie" zamiast "przetwarzanie".

Po tym etapie chodziło tylko o wykorzystanie maskowania, aby upewnić się, że hakerzy nie "odwrócą" tego maskowania, aby wysłać złośliwe ramki.

Jeśli chodzi o wymaganie wss zamiast maskowania - wiem, że było to brane pod uwagę podczas pisania standardu ... ale dopóki certyfikaty nie będą dostępne, spowoduje to, że każdy standard sieciowy wymagający protokołu SSL/TLS będzie standardem "bogatego mężczyzny", a nie rozwiązanie internetowe.

Co do "dlaczego maska ​​wss danych?" - Nie jestem pewien co do tego, ale podejrzewam, że ma to na celu umożliwienie parsera, aby był agnostyczny i łatwiejszy do napisania. W czystym tekście, niezamaskowane ramki są błędem protokołu i powodują rozłączenie zainicjowane przez serwer. Posiadanie parsera zachowuje się tak samo, niezależnie od połączenia, pozwala nam oddzielić parser od surowej warstwy IO, czyniąc z niej agnostyczne połączenie i oferując wsparcie dla programowania opartego na zdarzeniach.