[tor-bugs] #12125 [Pluggable transport]: Proposal 232 (TOR_PT_PROXY) support for goptlib

[Tor Bug Tracker & Wiki]

#12125: Proposal 232 (TOR_PT_PROXY) support for goptlib
-------------------------------------+--------------------------
     Reporter:  dcf                  |      Owner:  dcf
         Type:  project              |     Status:  needs_review
     Priority:  normal               |  Milestone:
    Component:  Pluggable transport  |    Version:
   Resolution:                       |   Keywords:  goptlib
Actual Points:                       |  Parent ID:
       Points:                       |
-------------------------------------+--------------------------
Changes (by dcf):

 * status:  new => needs_review


Comment:

 Replying to [comment:2 yawning]:
 > Welp, I likewise spent the evening working on this for obfs4proxy
 (SOCKSv5 works through the magic of library code, I'll write SOCKSv4/HTTP
 support next).
 >
 > My `ProxyError`/`ProxyDone` routines are basically identical.  I went
 with having a `ptGetProxy()` routine and I currently do more validation
 (check vs known scheme types, validate that the rest of the URI is sane)
 since I stole the code I wrote for pyptlib, and need to have those checks
 anyway.
 >
 > https://github.com/Yawning/obfs4/blob/master/obfs4proxy/pt_extras.go#L83
 >
 > Changing my code to use your interface at a later date is no problem for
 me.

 It's good that you did this. now we have two clean-room implementations
 that we can compare against each other for bugs. They can both just mellow
 in their respective programs until we merge them to goptlib.

 It looks like ProxyDone and ProxyError are easy and uncontroversial.

 I'm thinking of doing even less validation of the URL, on the assumption
 that application authors know what they're doing and they're going to have
 to crawl the URL structure anyway to do anything useful. But the checks
 for credentials that won't work (like a password with socks4a, or too-long
 credentials with socks5) may be a good idea. On the other hand, I might
 like to let it fail at connect time, because the application has to check
 for errors at that time anyway.

 [https://github.com/Yawning/obfs4/blob/c05a7a2e34dc832f192beaeee43931d13778dbe2/obfs4proxy/pt_extras.go#L144
 validateAddrStr] appears to allow only IP addresses, not host names. I
 guess prop 232 isn't clear whether host names need to be supported. I
 assumed they should be, without thinking about it. (The use case I'm
 thinking of is like a corporate proxy-only network, where you set your
 proxy to "!http://proxy.megacorp.example.com:8000/". I was also doing
 tests locally with "localhost".) I suppose this should be clarified in the
 proposal.

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