[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #29206 [Circumvention/Snowflake]: New design for client -- server protocol for Snowflake
#29206: New design for client -- server protocol for Snowflake
-----------------------------------------------+---------------------------
Reporter: cohosh | Owner: cohosh
Type: task | Status:
| needs_review
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: anti-censorship-roadmap-september | Actual Points:
Parent ID: | Points: 6
Reviewer: dcf | Sponsor:
| Sponsor28-must
-----------------------------------------------+---------------------------
Changes (by cohosh):
* status: needs_revision => needs_review
Comment:
This is finally ready for another review. Here's a rebased branch:
https://github.com/cohosh/snowflake/compare/sequencing The main
improvements from the last version are:
- Each end of a SnowflakeConn will send empty acknowledgement packets
(consisting of just the Snowflake header) upon the receipt of new data
- Each write method spins up a goroutine that will wait for some specified
time until checking to see if the acknowledgement packet for that data has
been received. If not, it closes the underlying connection causing future
reads and writes to fail.
- On each call to SnowflakeConn's write method, data is saved in an
internal buffer until it has been acknowledged
- SnowflakeConn now has a new method to set and reset the underlying
connection. If there is buffered data, SnowflakeConn will resend that data
under the same session ID whenever a new underlying connection has been
specified
My reasoning for implementing it this way is that the client and server
shouldn't have to worry about buffering data after a call to Write(). This
makes
[https://github.com/cohosh/snowflake/blob/sequencing/client/lib/webrtc.go#L34
the buffer in `client/webrtc.go`] redundant, but I'll remove it later when
finishing up tying together the client and server interactions.
The next step of course is to allow for resetting the underlying
connection in SnowflakeConn and using the sessionID to correlate new
connections with old ones. There's going to have to be some tricky
refactoring here. Right now when the webrtc connection times out (due to
staleness), both the webrtc connection and the socks connection are closed
and the client waits for a new socks connection to open. The SnowflakeConn
should be persistent across snowflakes (and the way it is currently set up
perhaps also across SOCKS connections (??)), so the question is where
SnowflakeConn should "live".
I'm thinking of adding a new method to SnowflakeCollector that will set
(and reset) the underlying connection, and then modifying the
[https://github.com/cohosh/snowflake/blob/sequencing/client/lib/snowflake.go#L24
Handler function] to redefine the snowflake rather than closing the SOCKS
connection and waiting for a new one. This doesn't fit perfectly with what
I'd assume a SnowflakeCollector does by name, but then again maybe it
does. This would make the SnowflakeCollector responsible for both getting
new snowflakes and also deciding which snowflake(s) to send traffic
through.
Any feedback on decisions up to this point and on future plans is welcome
:)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29206#comment:23>
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