[tor-bugs] #11487 [FTE]: FTEproxy should (maybe) select the regex on each Bridge line

[Tor Bug Tracker & Wiki]

#11487: FTEproxy should (maybe) select the regex on each Bridge line
---------------------------+--------------------
     Reporter:  infinity0  |      Owner:  kpdyer
         Type:  defect     |     Status:  new
     Priority:  major      |  Milestone:
    Component:  FTE        |    Version:
   Resolution:             |   Keywords:
Actual Points:             |  Parent ID:
       Points:             |
---------------------------+--------------------

Comment (by kpdyer):

 Replying to [ticket:11487 infinity0]:
 > Kevin thinks it would be nice to have the FTE regex specified on the
 Bridge line. However, I am confused by the subsequent discussion we had.
 >
 > I originally suggested this, because I thought each server has their own
 regex-pair (one for reading, writing), sort of like a scramblesuit shared-
 secret. Then, each client needs a separate regex-pair, per Bridge line.
 >
 > However, there is apparently a negotiation step to determine the actual
 regex-pair used:
 >
 > 18:50:01 <kpdyer_> the first upstream message is always a message
 encoded with some regex and contains a negotiation message
 > 18:50:16 <kpdyer_> that message contains the exact upstream/downstream
 regexs that will be used for the session
 >
 > In this case, if the negotiation happens *independently* of what the
 Bridge is, then
 >
 > a) what does the command-line regex mean? the regex for the initial
 negotiation message?

 One can think of this as follows. A server supports a set of regexes R_1,
 R_2, ..., R_N. When the fteproxy-server boots up, no regex needs to be
 specified. When an fteproxy-client starts up, a regex must be specified.

 The first client-to-server packet is encoded with the regex pair of the
 client's choice. Upon receipt of this packet, the server iterates though
 all known regexs in an attempt to decode/decrypt, upon successful decrypt
 (incl. MAC validation) the packet is recovered and specifies the regex the
 server should use for server-to-client messages.

 At the moment we do not allow clients to specify arbitrary regexes. We
 allow the client to select from a list of hard-coded regexes that specify
 upstream/downstream format pairs.

 > b) it would be *inappropriate* to set this on the Bridge line, in which
 case please close this ticket as invalid.

 It definitely shouldn't be specified per-bridge. However, we may want to
 broadcast the types of regexes that a bridge knows about?

 > It would be more appropriate to tell the user to edit their
 ClientTransportPlugin line (the current behaviour), since the regex that
 avoids blocking would be *dependent* on their own network, and *not* the
 Bridges that they want to connect to. Or even better, try multiple initial
 regexes and use the one that works.

 If a user does want to change their formats, then it is best for them to
 do so on the ClientTransportPlugin. (Or maybe the UI, in future?)

 -Kevin

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