subject:"\[tor\-bugs\] #18628 \[Obfuscation\/Snowflake\]\: Devise some way for the browser proxy to forward metadata to the bridge before the OR data"

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-10-22 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  closed
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * status:  assigned => closed
 * resolution:   => fixed


Comment:

 I added some logging code that reports, every 24 hours, how many incoming
 connections had `client_ip` set and how many did not. Here are the first
 two reports (they are not 24 hours apart because I had to restart the
 server in between). The fractions are 81% and 82%.
 {{{
 2017/10/20 07:03:00 in the past 9e+04 s, 782/968 connections had client_ip
 2017/10/22 15:19:03 in the past 86400 s, 507/618 connections had client_ip
 }}}

 We have 3 standalone proxy-go instances running around the clock,
 reporting `client_ip`. I would guess that the connections without
 `client_ip` come from the JavaScript code, the live copy of which does not
 yet have the `client_ip` change. (See #23947.) If my guess is right, and
 we assume that a client has an equal probability of getting any available
 proxy, that means that there are on average 0.75 JavaScript proxies
 running at any time (3 / 3.75 = 80%).

 I'm going to close this ticket now. Upgrading the JavaScript proxy code
 will happen as a side effect of #23947.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-10-17 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Here's the last `bridge-extra-info` descriptor before we pushed the code
 to the bridge (excerpted):
 {{{#!html
 
 @type bridge-extra-info 1.3
 extra-info flakey 5481936581E23D2D178105D44DB6915AB06BFB7F
 dirreq-stats-end 2017-10-13 17:04:29 (86400 s)
 dirreq-v3-ips ??=8
 dirreq-v3-reqs ??=16
 dirreq-v3-resp ok=16,not-enough-sigs=0,unavailable=0,not-found=0,not-
 modified=24,busy=0
 637461,q3=644613,d8=722983,d9=919679,max=1219266
 transport snowflake
 bridge-stats-end 2017-10-13 17:04:40 (86400 s)
 bridge-ips ??=8
 bridge-ip-versions v4=8,v6=0
 bridge-ip-transports snowflake=8
 
 }}}

 Here are the first few after pushing the change. So far there are users
 from Canada (that was us testing), Morocco, Russia, Taiwan, the United
 States, and Turkey. The numbers are rounded to a multiple of 8, so `8` can
 be anything between 1 and 8. There are still some `??` entries—maybe those
 are from the JavaScript proxy, where we haven't pushed the updated code
 yet.

 {{{#!html
 
 @type bridge-extra-info 1.3
 extra-info flakey 5481936581E23D2D178105D44DB6915AB06BFB7F
 dirreq-stats-end 2017-10-15 19:33:55 (86400 s)
 dirreq-v3-ips ??=8,ca=8,cn=8,ma=8,ru=8,tw=8,us=8
 dirreq-v3-reqs ??=8,ca=8,cn=8,ma=8,ru=8,tw=8,us=8
 dirreq-v3-resp ok=32,not-enough-sigs=0,unavailable=0,not-found=0,not-
 modified=40,busy=0
 transport snowflake
 bridge-stats-end 2017-10-15 19:34:09 (86400 s)
 bridge-ips ??=8,ca=8,cn=8,ma=8,ru=8,tw=8,us=8
 bridge-ip-versions v4=16,v6=0
 bridge-ip-transports snowflake=16
 
 }}}

 {{{#!html
 
 @type bridge-extra-info 1.3
 extra-info flakey 5481936581E23D2D178105D44DB6915AB06BFB7F
 dirreq-stats-end 2017-10-16 19:33:55 (86400 s)
 dirreq-v3-ips ??=8,ma=8,ru=8,tr=8,us=8
 dirreq-v3-reqs ??=8,ma=8,ru=8,tr=8,us=8
 dirreq-v3-resp ok=24,not-enough-sigs=0,unavailable=0,not-found=0,not-
 modified=0,busy=0
 transport snowflake
 bridge-stats-end 2017-10-16 19:34:09 (86400 s)
 bridge-ips ??=8,cn=8,ma=8,ru=8,tr=8,us=8
 bridge-ip-versions v4=8,v6=0
 bridge-ip-transports snowflake=8
 
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-10-14 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:15 dcf]:
 > Now all that remains is to make `remoteIPFromSDP` pass its tests. I have
 an idea for doing that. Let me know if you want me to do it or if you want
 to do it yourself.

 Here's the change (uses regexp like the JS code does):
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=319119a6117e43a11297ce24cae498c29087f6d4

 Rebased and merged to master:
 https://gitweb.torproject.org/pluggable-
 
transports/snowflake.git/diff/?id=9e5eb7f5ee1c15122425ab4fe47fa6ad6ec75f92=82d7f16babcdacdd120465fdd80b3468ea03246c

 The new code is running live now, the server and six proxy instances at
 snowflake.bamsoftware.com. So we should start seeing the first uploaded
 descriptors with country-level information within a day or so.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-09-21 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:14 cmm323]:
 > >The other changes in the snowflake branch look good. Please also
 merge/rebase with my commits at
 https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628
 (which include the tests for SDP parsing).
 > {{{
 > git remote add dcf https://git.torproject.org/user/dcf/snowflake.git
 > git fetch dcf
 > git merge dcf bug18628 # or rebase, deal with conflicts
 > }}}
 >
 > Done in private repo. You can push to your repo.

 Perfect. Pushed in
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628=421bc5836875aa23bc1b20f600f160e2b34bded9
 421bc583687].

 Now all that remains is to make `remoteIPFromSDP` pass its tests. I have
 an idea for doing that. Let me know if you want me to do it or if you want
 to do it yourself.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-09-17 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cmm323):

 >The other changes in the snowflake branch look good. Please also
 merge/rebase with my commits at
 https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628
 (which include the tests for SDP parsing).
 {{{
 git remote add dcf https://git.torproject.org/user/dcf/snowflake.git
 git fetch dcf
 git merge dcf bug18628 # or rebase, deal with conflicts
 }}}

 Done in private repo. You can push to the your repo.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-09-13 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:12 cmm323]:
 > Replying to [comment:8 dcf]:
 > >
 > > In websocket:
 > >
 > > I'm thinking it would be better to make request a pointer; i.e.
 `request *http.Request`, `ws.request = req`, in order to avoid copying the
 struct. I'm not sure it's safe to shallow-copy a Request struct, which may
 contain other recursive structures.
 >
 > Done.

 Great, merged all the websocket changes to master here:
 https://gitweb.torproject.org/pluggable-
 transports/websocket.git/log/?id=e0bb5efd8d78d372711652ec061923debe7f5cb0

 

 > > In snowflake:
 > >
 > > I'm a little concerned about parsing the SDP in order to get the
 remote address. Ideally, of course, we'd find another way to do it, or use
 a proper library to parse the SDP. But in the meantime, I
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=485538bcf00bd4ddaeb5f81dd05e3caaa89ffd6d
 pushed some tests] to cover some additional syntax options that I took
 from RFC 4566. Can you pull those changes and update the code so that all
 the tests pass with `go test`?
 >
 > Let me know if you feel like this is still needed.

 Yes, I think it's important. My worry is that if browsers change their SDP
 so that it is still within the spec but doesn't match what our code
 expects, we'll suddenly lose a lot of statistics without realizing it. I
 think the code doesn't need much more tweaking to make `go test` pass.

 Here's JS code that passes the same tests:
 
https://gitweb.torproject.org/user/dcf/snowflake.git/tree/proxy/util.coffee?h=bug18628#n115

 

 The other changes in the snowflake branch look good. Please also
 merge/rebase with my commits at
 https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=bug18628
 (which include the tests for SDP parsing).
 {{{
 git remote add dcf https://git.torproject.org/user/dcf/snowflake.git
 git fetch dcf
 git merge dcf bug18628 # or rebase, deal with conflicts
 }}}

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-09-12 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by cmm323):

 Replying to [comment:8 dcf]:
 >
 > In websocket:
 >
 > {{{
 > +   // Request
 > +   request http.Request
 > }}}
 > {{{
 > +   ws.request = *req
 > }}}
 > I'm thinking it would be better to make request a pointer; i.e. `request
 *http.Request`, `ws.request = req`, in order to avoid copying the struct.
 I'm not sure it's safe to shallow-copy a Request struct, which may contain
 other recursive structures.

 Done.

 >
 > 
 >
 > In snowflake:
 >
 > I'm a little concerned about parsing the SDP in order to get the remote
 address. Ideally, of course, we'd find another way to do it, or use a
 proper library to parse the SDP. But in the meantime, I
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=485538bcf00bd4ddaeb5f81dd05e3caaa89ffd6d
 pushed some tests] to cover some additional syntax options that I took
 from RFC 4566. Can you pull those changes and update the code so that all
 the tests pass with `go test`?

 Let me know if you feel like this is still needed.
 >
 > {{{
 > +   if conn.RemoteAddr() != nil && conn.RemoteAddr().String() != ""
 {
 > }}}
 > I don't think we need the `!= ""` comparison here. Unless there's a kind
 of Addr you're thinking of that can return an empty string?

 I removed it.


 >
 > {{{
 > +   if clientIP == nil {
 > +   // Set client addr to empty
 > +   log.Printf("failed to validate client_ip: %s", addr)
 > +   addr = ""
 > +
 > }}}
 > Let's not log an IP address here. We can add it (behind an "unsafe
 logging" option) if we need it later.

 Done.

 >
 > > Note client IP address is now added to `opt.relayURL` before dialing
 websocket.
 >
 > I think that doing it this way creates a race condition. You have a
 bunch of goroutines reading a writing global state. Better to make a copy
 of the global relay URL (e.g., via url.Parse) that you can mutate each
 time. In fact, opt.relayURL should probably be removed completely
 ([https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=dbe1ef4fa55569e5d17c405df5707f6eb05bb56c
 I just did that on the master branch]).

 Done.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-09-05 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:  cmm323
 Type:  defect | Status:  assigned
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cmm323):

 * owner:  (none) => cmm323
 * status:  needs_revision => assigned


--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-08-15 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+
 Reporter:  arlolra|  Owner:  (none)
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * status:  needs_review => needs_revision


Comment:

 I added support for `client_ip` to the JavaScript proxy in the bug18628
 branch:
 
https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=bug18628=b2be72724a1924bace6af18904a9e53f9094a5fd=1d6109a9eddd4e2d967efbde8aba89b4226aefc2
 Comment is welcome. It uses the same technique of parsing
 RTCPeerConnection.remoteDescription.sdp, because I couldn't find a better
 way.

 cmm32, reminder that we're looking for a few revisions from comment:8,
 particularly making the tests pass for remoteIPFromSDP.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-08-02 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:8 dcf]:
 > Replying to [comment:6 cmm32]:
 > I know that in comment:5 I made a fuss about moving the SDP parsing
 logic into webrtcConn.RemoteAddr. But for some reason, doing that makes it
 stop working for me to run proxy-go and snowflake-client on the same
 computer! The code hangs forever inside the call to
 c.pc.RemoteDescription(). I don't know why (it might be a bug in go-
 webrtc), but I bisected and
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=2c0cfdfb953d3b37254c0a4dff5b61ca2be795cf
 2c0cfdfb] is definitely the commit that causes a change. So as a
 workaround, we might need to put the SDP parsing back where it was, until
 we figure out the cause. I can do that, if it's okay with you, because I'm
 easily able to reproduce the problem.

 Okay, I applied
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=be4c2fdd5e0780d11386e7157cf92a9ea035b4c3
 a small workaround]: just calls conn.RemoteAddr() before entering the
 goroutine instead of inside. I wonder if there is some kind of locking
 around RemoteDescription that was making it hang when called from
 different threads.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-08-02 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:6 cmm32]:
 > * Most comments addressed.

 Great. Thanks. I think this is getting close. I'll ask arlolra and serene
 to take a look too.

  *
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/diff/?h=bug18628=2846bbec9adeb7b2e06aa5b204982496c1ece5ce=db2251345d16a530cf27fe951b235719515c2b88
 cumulative bug18628 diff for snowflake]
  * [https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/diff/?h=bug18628=02a8eb6d7a236f8b805dbd086f1c46f5dfb51149=6dc990ad6a898bc507605c51a5aa860fb9f74201
 cumulative diff for websocket]

 

 In websocket:

 {{{
 +   // Request
 +   request http.Request
 }}}
 {{{
 +   ws.request = *req
 }}}
 I'm thinking it would be better to make request a pointer; i.e. `request
 *http.Request`, `ws.request = req`, in order to avoid copying the struct.
 I'm not sure it's safe to shallow-copy a Request struct, which may contain
 other recursive structures.

 

 In snowflake:

 I'm a little concerned about parsing the SDP in order to get the remote
 address. Ideally, of course, we'd find another way to do it, or use a
 proper library to parse the SDP. But in the meantime, I
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=485538bcf00bd4ddaeb5f81dd05e3caaa89ffd6d
 pushed some tests] to cover some additional syntax options that I took
 from RFC 4566. Can you pull those changes and update the code so that all
 the tests pass with `go test`?

 {{{
 +   if conn.RemoteAddr() != nil && conn.RemoteAddr().String() != "" {
 }}}
 I don't think we need the `!= ""` comparison here. Unless there's a kind
 of Addr you're thinking of that can return an empty string?

 I know that in comment:5 I made a fuss about moving the SDP parsing logic
 into webrtcConn.RemoteAddr. But for some reason, doing that makes it stop
 working for me to run proxy-go and snowflake-client on the same computer!
 The code hangs forever inside the call to c.pc.RemoteDescription(). I
 don't know why (it might be a bug in go-webrtc), but I bisected and
 
[https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=2c0cfdfb953d3b37254c0a4dff5b61ca2be795cf
 2c0cfdfb] is definitely the commit that causes a change. So as a
 workaround, we might need to put the SDP parsing back where it was, until
 we figure out the cause. I can do that, if it's okay with you, because I'm
 easily able to reproduce the problem.

 {{{
 +   if clientIP == nil {
 +   // Set client addr to empty
 +   log.Printf("failed to validate client_ip: %s", addr)
 +   addr = ""
 +
 }}}
 Let's not log an IP address here. We can add it (behind an "unsafe
 logging" option) if we need it later.

 > Note client IP address is now added to `opt.relayURL` before dialing
 websocket.

 I think that doing it this way creates a race condition. You have a bunch
 of goroutines reading a writing global state. Better to make a copy of the
 global relay URL (e.g., via url.Parse) that you can mutate each time. In
 fact, opt.relayURL should probably be removed completely
 ([https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/commit/?id=dbe1ef4fa55569e5d17c405df5707f6eb05bb56c
 I just did that on the master branch]).

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-08-02 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:6 cmm32]:
 > * As for the ExtORPort USERADDR command, the
 [[https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-
 ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72|documentation]]
 should make the port optional. Internally, the code calls
 `tor_addr_port_split` which
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|checks
 if IPv6 address is passed]] and ignores the port if it is `AF_INET6`.
 Also, port is optional, see
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|here]]
 and
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1940|here]].

 I opened #23080 for the USERADDR documentation inconsistency. It looks
 like, regardless of what the spec says, it'll be fine to pass in an
 address with or without a port number, and with or without square brackets
 for IPv6.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-28 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by cmm32):

 * status:  needs_revision => needs_review


Comment:

 * Most comments addressed. Note client IP address is now added to
 `opt.relayURL` before dialing websocket.


 * As for the ExtORPort USERADDR command, the
 [[https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-
 ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72|documentation]]
 should make the port optional. Internally, the code calls
 `tor_addr_port_split` which
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|checks
 if IPv6 address is passed]] and ignores the port if it is `AF_INET6`.
 Also, port is optional, see
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1896|here]]
 and
 [[https://gitweb.torproject.org/tor.git/tree/src/common/address.c#n1940|here]].

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-25 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Review of the patch from comment:4:

 {{{
 @@ -50,6 +50,7 @@ type webRTCConn struct {
 dc *webrtc.DataChannel
 pc *webrtc.PeerConnection
 pr *io.PipeReader
 +   client_ip string
  }
 ...
 @@ -234,7 +235,22 @@ func makePeerConnectionFromOffer(sdp
 *webrtc.SessionDescription, config *webrtc.
 panic("short write")
 }
 }
 -   conn := {pc: pc, dc: dc, pr: pr}
 +   conn := {pc: pc, dc: dc, pr: pr, client_ip:
 clientIP}
 }}}

 Rather than adding a new member to the webRTCConn struct, it's better to
 put the IP address extraction logic in the
 [https://golang.org/pkg/net/#Conn RemoteAddr] function. Not only is that
 what RemoteAddr is for, it will make it easier to write unit test code
 when the logic is isolated in its own function.

 It's better if the remote IP address is represented as a
 [https://golang.org/pkg/net/#IPAddr net.IPAddr], rather than a string. You
 can get a net.IPAddr from a string using
 [https://golang.org/pkg/net/#ParseIP net.ParseIP]. You can turn it back
 into a string (so you can add it to the URL query string) by calling
 [https://golang.org/pkg/net/#IPAddr.String String()] on it.

 

 {{{
 -   wsConn, err := websocket.Dial(opt.relay, "", opt.relay)
 +   wsConn, err := websocket.Dial(opt.relay + "?client_ip=" +
 conn.client_ip, "", opt.relay)
 }}}

 It's better to build the URL using [https://golang.org/pkg/net/url/
 net/url] functions, rather than concatenating strings. That way, we know
 that escaping will be correct, and it's easier to extend if we want to set
 additional values in the query string. Something like this:

 {{{
 u, err := url.Parse(opt.relay)
 if err != nil {
 panic(err)
 }
 u.Query().Set("client_ip", conn.client_ip)
 wsConn, err := websocket.Dial(u.String(), "", opt.relay)
 }}}

 

 {{{
 +   //Parse Remote SDP to pass client IP to the server
 +   var clientIP string = ""
 +   remoteSDP := pc.RemoteDescription().Sdp
 +   splitSDP := strings.Split(remoteSDP, "\r\n")
 +   for i := range splitSDP {
 +   if strings.HasPrefix(splitSDP[i], "c=") {
 +   candidSplit := strings.Split(splitSDP[i],
 " ")
 +   if len(candidSplit) >= 3 {
 +   clientIP = candidSplit[2]
 +   break
 +   }
 +   }
 +   }
 }}}

 We need to think about what happens when this code fails to extract an IP
 address. Currently it will leave clientIP set to `""`, which will cause
 the websocket URL to be `wss://snowflake.bamsoftware.com/?client_ip=`.
 Maybe that's what we want, or maybe we want to omit the `client_ip`
 parameter completely in that case. What do you think?

 In any case, this code should be moved into webRTCConn.RemoteAddr, like I
 said in my first note. That function can return nil when there's no match
 found.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-25 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+

Comment (by dcf):

 Hooman has also made a commit that makes proxy-go parse the remote address
 from the PeerConnection SDP string, and send it to the websocket server as
 a `client_ip` query item.
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=abc944ea876a7ba1de2f95d12a78a629805ecc85

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-22 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_revision
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+
Changes (by dcf):

 * status:  needs_review => needs_revision


Comment:

 Review of the patches from comment:2:

 It's better if the WebSocket struct exposes the entire client http.Request
 structure, not just Request.URL. That way, consumers can also inspect the
 headers etc. Compare with
 [https://godoc.org/golang.org/x/net/websocket#Conn.Request Conn.Request()]
 in the x/net websocket package. (You can make it a simple member access,
 doesn't have to be a function call.)

 Completely delete the path check in websocket, don't just comment it out.

 Run `go fmt`.

 About the client address:
  * There should be some validation of `client_ip`, such as parsing with
 [https://golang.org/pkg/net/#ParseIP net.ParseIP], before passing the
 string into tor.
  * The ExtORPort USERADDR command
 [https://gitweb.torproject.org/torspec.git/tree/proposals/196-transport-
 control-ports.txt?id=f59e8f5b2819842fe6cb5b162a9226a4f1891b4d#n72 is
 documented] to take an addr:port string, not just an IP address. So
 snowflake-server needs to add a dummy port number (using
 [https://golang.org/pkg/net/#JoinHostPort net.JoinHostPort]) before giving
 the string to tor. Alternately, rename `client_ip` to `client_addr` and
 have it contain the entire addr:port string.
* If tor is accepting a plain IP address for USERADDR, it's a bug in
 tor or in the documentation, and we need to file a separate bug.
  * How does client_ip handle IPv6 addresses? We need to decide whether
 IPv6 addresses will have square brackets (if the port is included, then
 yes; if the port is not included, then probably no) and document it at
 least in a comment.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-22 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+--
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  needs_review
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+--
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Hooman is working on patches to address this.

 websocket patch to retain the request URL and remove the restriction on
 paths:
   https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/commit/?h=bug18628=0446621630483a656f179963ca77451f04aeaf01
 snowflake patch to pass the `client_ip` from the websocket request URL
 query into pt.DialOr:
 
https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h=bug18628=0c958d8ffba0c117fb4768133afcbd4d56f61d1f

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

2017-07-14 Thread Tor Bug Tracker & Wiki

#18628: Devise some way for the browser proxy to forward metadata to the bridge
before the OR data
---+-
 Reporter:  arlolra|  Owner:
 Type:  defect | Status:  new
 Priority:  High   |  Milestone:
Component:  Obfuscation/Snowflake  |Version:
 Severity:  Normal | Resolution:
 Keywords: |  Actual Points:
Parent ID: | Points:
 Reviewer: |Sponsor:
---+-
Changes (by dcf):

 * cc: cmm32 (added)
 * priority:  Medium => High


Comment:

 Replying to [ticket:18628 arlolra]:
 > In order to report true client IP addresses, we will need to devise some
 way for the browser proxy to forward that metadata to the bridge before
 the OR data.

 I realized a good way to do this: put the client IP address in the
 WebSocket URL. Currently we have
 {{{
 new WebSocket("wss://snowflake.bamsoftware.com/")
 }}}
 We could just change that to (imagine proper escaping):
 {{{
 new WebSocket("wss://snowflake.bamsoftware.com/?client_ip=" + client_ip)
 }}}
 The WebSocket server can extract the IP address by inspecting the URL it
 gets in the request, and provide that IP address to the pt.DialOr
 function.

 The alternative of sending the client IP address in an HTTP header
 [[#13171|à la meek]] won't work, because the
 [https://developer.mozilla.org/en-US/docs/Web/API/WebSocket WebSocket API]
 doesn't provide a way to set headers. The only information you can provide
 to the constructor is a URL and an optional list of sub-protocol names.

 Unfortunately the WebSocket implementation used by snowflake-server (the
 one inherited from flash proxy) doesn't expose the URL of the client
 request (and in fact [https://gitweb.torproject.org/pluggable-
 
transports/websocket.git/tree/websocket/websocket.go?id=6dc990ad6a898bc507605c51a5aa860fb9f74201#n336
 requires the path to be `/`]). But that shouldn't be hard to change.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

Re: [tor-bugs] #18628 [Obfuscation/Snowflake]: Devise some way for the browser proxy to forward metadata to the bridge before the OR data

18 matches

Site Navigation

Mail list logo

Footer information