[tor-bugs] #28726 [Obfuscation/Snowflake]: Loosen restrictions on message sizes in WebSocket server

[Tor Bug Tracker & Wiki]

#28726: Loosen restrictions on message sizes in WebSocket server
---------------------------------------+--------------------
     Reporter:  dcf                    |      Owner:  (none)
         Type:  defect                 |     Status:  new
     Priority:  Medium                 |  Milestone:
    Component:  Obfuscation/Snowflake  |    Version:
     Severity:  Normal                 |   Keywords:
Actual Points:                         |  Parent ID:
       Points:                         |   Reviewer:
      Sponsor:                         |
---------------------------------------+--------------------
 ahf couldn't bootstrap beyond 25% when running his own client, broker, and
 WebSocket server (i.e., not using the public infrastructure). I asked him
 to try relaxing the message size limit in server.go:
 {{{
 -const maxMessageSize = 64 * 1024
 +const maxMessageSize = 10 * 1024 * 1024
 }}}
 This enabled him to bootstrap to 100% at least once, but "it still doesn't
 work most of the times i bootstrap from a clean tor instance."

 What I suspect is happening is that the browser proxy is sending WebSocket
 messages larger than 64 KB, which is causing the WebSocket server to error
 and tear down the connection. How much larger than 64 KB, I don't know.
 The underlying websocket package [https://gitweb.torproject.org/pluggable-
 transports/websocket.git/tree/websocket/websocket.go?id=e0bb5efd8d78d372711652ec061923debe7f5cb0#n143
 returns an error] like
 {{{
 "frame payload length of %d exceeds maximum of %d"
 }}}
 but we currently [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/server/server.go?id=596d28b57628dc57dd44080bb50b435c27c48861#n115
 throw away that error message] as a precaution until we've [ticket:21304
 audited error logs] to ensure that IP addresses don't appear.

 As an alternative to allowing larger messages at the server, we could try
 to ensure that proxies don't produce such over-large messages.
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/proxy/proxypair.coffee?id=596d28b57628dc57dd44080bb50b435c27c48861#n133
 Here], in `onClientToRelayMessage`, we could break `recv` into 64 KB
 chunks before pushing them onto `@c2rSchedule`. In proxy-go, I suspect we
 are succeeding by accident: the code [https://gitweb.torproject.org
 /pluggable-transports/snowflake.git/tree/proxy-
 go/snowflake.go?id=596d28b57628dc57dd44080bb50b435c27c48861#n211 uses]
 [https://golang.org/pkg/io/#Copy io.Copy], which must use an internal
 buffer smaller than 64 KB.

 Taking a longer view, there's no good reason for a message size limit to
 exist at all. It [https://gitweb.torproject.org/pluggable-
 transports/websocket.git/tree/doc/websocket-
 transport.txt?id=e0bb5efd8d78d372711652ec061923debe7f5cb0#n178 stems from
 a time] when I was naive in Go and didn't know how to provide an
 implementation that didn't buffer the entirety of each message in memory.
 The reason I wrote my own WebSocket implementation was that the other one
 that existed at the time, golang.org/x/net/websocket, had no limits on
 message size at all, and you could trivially DoS it (out of memory) by
 sending a 1 TB message. (Looks like
 [https://github.com/golang/net/commit/6dba816f1056709e29a1c442883cab1336d3c083
 #diff-bf56d570e62cdb573c86b18526296117 this got fixed] in 2016.) A good
 solution would be to rewrite our WebSocket library to provide a streaming
 interface without message buffering, so to investigate whether other
 WebSocket libraries like https://godoc.org/github.com/gorilla/websocket
 can do it.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/28726>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online