[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #28726 [Obfuscation/Snowflake]: Loosen restrictions on message sizes in WebSocket server
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs