Re: [tor-bugs] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-09-03 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201905R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+
Changes (by intrigeri):

 * cc: intrigeri (added)


--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-08 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  closed
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:  fixed
 Keywords:  TorBrowserTeam201905R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

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


Comment:

 Merged with commit 0ce8339e490bb99096ff69cac17d648af028c951 to `master`.
 (And thanks dcf for the digging, it's not nitpicky :) ).

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-08 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201905R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by mcs):

 At the same time dcf made comment:11, I opened #30442.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-08 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201905R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:9 mcs]:
 > That is a good question.  We think the code is correct but the spec is
 wrong.  SOCKS5 supports up to 255 bytes in each auth field.  The
 obfs4proxy code reads a byte to get the length and does not have any other
 limitations, so up to and including 255 is supported.  Kathy and I wanted
 to maximize the space available for args, so we used <=.  Do you think
 this is OK?  Should we file a bug against the PT spec?

 There's for sure a small ambiguity in the PT spec, when the length of the
 username field is exactly 255. I almost mentioned it before but thought I
 was being too nitpicky. Suppose the PT receives a connection with a
 255-byte username `k=aaa...aaa` and a 1-byte password `\x00`. There are
 two possible strings with that encoding, and no way to distinguish between
 them:
  * the 255-byte string `k=aaa...aaa`
  * the 256-byte string `k=aaa...aaa\x00`
 Obviously in the PT context `\x00` is an unlikely byte to appear, so in
 this case both goptlib and obfs4proxy disambiguate by taking the first
 interpretation.

 To eliminate the ambiguous case, whenever the length of
 `this.mMeekClientEscapedArgs` is exactly 255, you could put 254 bytes in
 the username field and 1 byte in the password field.

 Though now that I check, technically the spec doesn't even say how the
 username and password fields are supposed to be combined, or whether a
 decoder is even required to look at the password field if the username
 field is not full. But the existing implementations work by concatenation
 without regard to the length of the fields, except that a password field
 consisting of a single `\x00` is treated as an empty string. An
 [https://gitweb.torproject.org/torspec.git/tree/pt-
 spec.txt?id=4dcd7e94f17c072e771119ec90d7cbce4a4788a4#n162 older version]
 of the spec stated the the fields should be joined by concatenation, but
 didn't say what to do with an empty password field.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-08 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201905R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by gk):

 * keywords:  TorBrowserTeam201905 => TorBrowserTeam201905R
 * status:  needs_information => needs_review


Comment:

 Replying to [comment:9 mcs]:
 > Replying to [comment:8 gk]:
 > > Okay, I gave it another look. Just one final bit: You write
 > > {{{
 > > +//  If the encoded argument list is less than 255 bytes in
 > > }}}
 > > which seems correct to me, but then you do
 > > {{{
 > > +  if (this.mMeekClientEscapedArgs.length <= 255)
 > > }}}
 > > I guess you want `if (this.mMeekClientEscapedArgs.length < 255)`
 instead?
 >
 > That is a good question.  We think the code is correct but the spec is
 wrong.  SOCKS5 supports up to 255 bytes in each auth field.  The
 obfs4proxy code reads a byte to get the length and does not have any other
 limitations, so up to and including 255 is supported.  Kathy and I wanted
 to maximize the space available for args, so we used <=.  Do you think
 this is OK?  Should we file a bug against the PT spec?

 Yes, please file a spec bug.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-08 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+---
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_information
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201905   |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+---
Changes (by mcs):

 * status:  needs_revision => needs_information


Comment:

 Replying to [comment:8 gk]:
 > Okay, I gave it another look. Just one final bit: You write
 > {{{
 > +//  If the encoded argument list is less than 255 bytes in
 > }}}
 > which seems correct to me, but then you do
 > {{{
 > +  if (this.mMeekClientEscapedArgs.length <= 255)
 > }}}
 > I guess you want `if (this.mMeekClientEscapedArgs.length < 255)`
 instead?

 That is a good question.  We think the code is correct but the spec is
 wrong.  SOCKS5 supports up to 255 bytes in each auth field.  The
 obfs4proxy code reads a byte to get the length and does not have any other
 limitations, so up to and including 255 is supported.  Kathy and I wanted
 to maximize the space available for args, so we used <=.  Do you think
 this is OK?  Should we file a bug against the PT spec?

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-05-03 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_revision
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201905   |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+
Changes (by gk):

 * status:  needs_review => needs_revision
 * keywords:  TorBrowserTeam201905R => TorBrowserTeam201905


Comment:

 Okay, I gave it another look. Just one final bit: You write
 {{{
 +//  If the encoded argument list is less than 255 bytes in
 }}}
 which seems correct to me, but then you do
 {{{
 +  if (this.mMeekClientEscapedArgs.length <= 255)
 }}}
 I guess you want `if (this.mMeekClientEscapedArgs.length < 255)` instead?

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-03-05 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 Replying to [comment:4 mcs]:
 > Kathy and I think this is worth fixing. Here is a revised patch:
 > https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug29627-02=99035eb7b6069c60fe4f97291abbea5af4fee886

 I incidentally tested this revised patch (with an additional patch to send
 the `utls=` SOCKS) arg while testing for comment:12:ticket:29430. Moat
 worked fine, and had the same TLS fingerprints as meek.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-03-05 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by mcs):

 Replying to [comment:3 gk]:
 > We have `meekTransport`, `meekClientPath`, and `meekClientArgs` as
 parameters in `network-settings.js`. I wonder what happened to the `meek`
 part in `meekTransport` in `tl-bridgedb.jsm` as we only have
 `aTransport`/`mTransport` there. Maybe we don't need `meekTransport` but
 just `transport` in `network-seetings.js`?
 >
 > It's not that a big deal, I got just confused while reading over the
 code.

 Kathy and I think this is worth fixing. Here is a revised patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug29627-02=99035eb7b6069c60fe4f97291abbea5af4fee886

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-03-05 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by gk):

 We have `meekTransport`, `meekClientPath`, and `meekClientArgs` as
 parameters in `network-settings.js`. I wonder what happened to the `meek`
 part in `meekTransport` in `tl-bridgedb.jsm` as we only have
 `aTransport`/`mTransport` there. Maybe we don't need `meekTransport` but
 just `transport` in `network-seetings.js`?

 It's not that a big deal, I got just confused while reading over the code.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-03-04 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--

Comment (by dcf):

 I looked over the patch and it looks reasonable with respect to escaping
 and everything.

--
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] #29627 [Applications/Tor Launcher]: Moat: add support for obfsproxy's meek_lite

2019-03-01 Thread Tor Bug Tracker & Wiki
#29627: Moat: add support for obfsproxy's meek_lite
---+--
 Reporter:  mcs|  Owner:  brade
 Type:  defect | Status:  needs_review
 Priority:  Medium |  Milestone:
Component:  Applications/Tor Launcher  |Version:
 Severity:  Normal | Resolution:
 Keywords:  TorBrowserTeam201903R  |  Actual Points:
Parent ID:  #29430 | Points:
 Reviewer: |Sponsor:
---+--
Changes (by mcs):

 * keywords:  TorBrowserTeam201903 => TorBrowserTeam201903R
 * status:  new => needs_review


Comment:

 Here is a patch:
 https://gitweb.torproject.org/user/brade/tor-
 launcher.git/commit/?h=bug29627-01=9ddc818a394623bc21c900fa473a6d0802537733

 With these changes, Moat works with both `meek-client-torbrowser` and
 `obfs4proxy`.

--
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