On Thu, 06 Mar 2014 19:22:16 +0200 irregulator <irregulator@xxxxxxxxxx> wrote: > On 03/05/2014 07:58 PM, Yawning Angel wrote: > Hey people thanks for your input, > > I'm actually passing password inline while starting obfsproxy > (client-side) like that : > > python pyobfsproxy.py --log-min-severity=info scramblesuit --password > LLDNOWV7I4P6RKFJMDEMIY2GNU2IQISA socks 127.0.0.1:9999 > > Still when openvpn client connects to localhost:9999 enters the > authentication phase. I think this is undesirable and needless since > obfsproxy client has already been started with the password. Looking at the OpenVPN source (src/openvpn/socks.c): > const ssize_t size = send (sd, "\x05\x02\x00\x02", 4, MSG_NOSIGNAL); The method selection request is hardcoded to always claim support for No Auth, and Username/Password Auth in that order. This as a OpenVPN bug. It should not be offering to negotiate Username/Password Auth if the user has not provided credentials. And, if the user did happen to provide credentials, then it should not claim that No Auth is acceptable. > So I made a rearrangement like this : [snip] > After the change openVPN client is no more requested to enter > credentials, and it works like a charm. OpenVPN client talks to > OpenVPN server over scramblesuit :) > > So I am wondering, is the change above acceptable for all cases? I > mean, changing the priority between authentication and no > authentication mode, will it affect some PTs ? I explicitly wrote the code to prefer using auth when the client claims to support it to guard against brain damaged clients that offer up No Auth Required when the user provides a username/password (with your code, the PT arguments get dropped, and this breaks for people that wish to have OpenVPN pass k_B to obfsproxy), so I don't see this as a workable fix since it just breaks the other way of doing it. For Tor, this does not matter since it only claim authentication support if authentication if PT args are given. > I'm not sure what is better here : should the OpenVPN client pass the > scramblesuit password to the obfsproxy client listening to localhost, > or the should the obfsproxy client already know the password so as the > OpenVPN client doesn't need to authenticate at all. Not sure which is better. > If the first is preferable, any idea how the '\0' value could fit in > there? OpenVPN socks authentication is implemented, afaik, either via > standard input or via a two line file containing user-password. Options: * Ignore the PASSWD field if the UNAME field is less than 255 characters. This feels somewhat ugly, and has Nasty Surprise potential in the future. * Only treat the SOCKS auth as a username/password when obfsproxy is in managed mode. This forces everyone to pass in args via the command line, and would break the "I want to use obfsproxy to connect to multiple servers via ScrambleSuit use case", so is probably unacceptable. * Leave things as is. Since the UNAME/PASSWD fields are just concatenated (except for the case where the passwd is 1 NUL character, people can set the credentials to something like: Username: "password=" Password: "<Base32 Encoded k_B here>" Sorry I should have been more clear about this. Presently I am leaning toward option 3, but I don't feel too strongly about this as long as Tor continues to work (Which it will regardless of how this is resolved since it will always only request SOCKS auth mechanisms that make sense based on the config file). -- Yawning Angel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev