wsproxy: add WithMaxReadMessageSize option to limit incoming WebSocket message size#45
Open
crawfordxx wants to merge 1 commit into
Open
wsproxy: add WithMaxReadMessageSize option to limit incoming WebSocket message size#45crawfordxx wants to merge 1 commit into
crawfordxx wants to merge 1 commit into
Conversation
…t message size Without a read-message limit, an unauthenticated client can send an arbitrarily large WebSocket message and force the proxy to buffer the entire payload in memory before forwarding it upstream. gorilla/websocket exposes conn.SetReadLimit(n) exactly for this purpose: when a message exceeds the limit it closes the connection with 1009 (message too big) instead of reading the oversized frame. Add a WithMaxReadMessageSize(int64) Option that, after upgrading the connection, calls conn.SetReadLimit if a positive limit is configured. The default behaviour (limit=0) is unchanged.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Without a read-message-size limit, an unauthenticated client can send a
single arbitrarily large WebSocket message and force the proxy to buffer
the entire payload in memory before forwarding it upstream. This is a
memory-exhaustion DoS vector: in etcd, a 256 MiB WebSocket message causes
~1.26 GiB RSS growth (~5× amplification).
gorilla/websocket exposes
conn.SetReadLimit(n)exactly for this purpose:when an incoming message exceeds the limit the connection is closed with
WebSocket status 1009 (message too big) instead of buffering the full frame.
Fix
Add a
WithMaxReadMessageSize(int64) Optionthat callsconn.SetReadLimitimmediately after the connection is upgraded:
When the limit is ≤ 0 the behaviour is unchanged (gorilla/websocket default
of 32 MiB applies).
Why this belongs in wsproxy
The limit must be applied at the WebSocket layer, after the protocol upgrade
but before the first
ReadMessagecall. HTTP-level middleware (e.g.http.MaxBytesReader) does not see WebSocket frame payloads becausegorilla/websocket reads directly from the raw TCP connection.