[tor-bugs] #31278 [Circumvention/Snowflake]: Chrome proxies hang with open idle connection

Tor Bug Tracker & Wiki blackhole at torproject.org
Tue May 5 19:47:37 UTC 2020


#31278: Chrome proxies hang with open idle connection
-------------------------------------+------------------------
 Reporter:  cypherpunks              |          Owner:  (none)
     Type:  defect                   |         Status:  new
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  snowflake-webextension   |  Actual Points:
Parent ID:                           |         Points:  2
 Reviewer:                           |        Sponsor:
-------------------------------------+------------------------

Comment (by cohosh):

 Replying to [comment:1 dcf]:
 > There's a new ticket at https://github.com/keroserene/go-
 webrtc/issues/107 that has to do with Chrome.
 > > According https://bugs.chromium.org/p/webrtc/issues/detail?id=9484 new
 versions of Chrome are sending new offer format and answer cannot be
 generated.
 > >
 > > For example, for RemoteDescription with info
 > > {{{
 > > m=application 54111 UDP/DTLS/SCTP webrtc-datachannel a=sctp-port:5000
 > > }}}
 > > pc.CreateAnswer does not produce any result - no error, no answer
 > >
 > > Similiar issue for node implementation - [https://github.com/node-
 webrtc/node-webrtc/issues/483 node-webrtc/node-webrtc#483]

 This specific cause should no longer be an issue for us, since we added
 the datachannel timeout in #31100 (it also looks like it's been fixed
 upstream in wrtc at least). I'm still seeing that Chrome takes a very long
 time to realize the datachannel has been closed by the client. I started
 running a proxy in my local set up and killed the client once the
 datachannel opened. Two hours later, my chrome proxy still hasn't detected
 that the channel has been closed.

 My guess is this is a bug upstream that should be fixed, but in the short
 term, we could use something like the check for staleness at the client
 side to close the connection after 10-30 seconds of inactivity (especially
 since the client is supposed to be sending heartbeat messages every 10
 seconds anyway).

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


More information about the tor-bugs mailing list