Combining obfsproxy+scramblesuit with OpenVPN
Hello people, I'm investigating how may we combine the traffic obfuscation provided by obfsproxy+scramblesuit with OpenVPN instead of Tor. I completely understand how this combination does not provide anonymity, but nevertheless I think it will be of some use. In the recent past there have been some interest in this combination [1], [2], [3], mainly cause of VPN traffic blocking in various countries or networks. OpenVPN supports only Socks5 proxy but current obsfproxy's version doesn't have a Socks5 listener, see ticket #9221 [4]. Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one. Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers. So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase. Do the credentials depend on the pluggable transport in use by the obfsproxy? If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit? Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication? Thanks in advance for any answers. Alex [1] http://community.openvpn.net/openvpn/wiki/TrafficObfuscation [2] http://www.dlshad.net/?p=135 [3] https://www.void.gr/kargig/blog/2012/10/05/bypassing-censorship-devices-by-o... [4] https://trac.torproject.org/projects/tor/ticket/9221 [5] https://trac.torproject.org/projects/tor/attachment/ticket/9221/0001-Use-SOC...
Heya, The company I work for is building an OpenVPN client which has obfsproxy support, there is a branch, but it's not finished: https://github.com/greenhost/viper/tree/obfsproxy-support And then.. the serverside isn't pushed but it was working, it would generate scramblesuite passwords using some funky way. Anyway, you might want to look into this: https://github.com/kheops2713/telecomix-openvpn/tree/master/Linux Also see: https://lists.torproject.org/pipermail/tor-dev/2014-February/006192.html It's rather trivial. Jurre On 03/05/2014 02:08 PM, irregulator@riseup.net wrote:
Hello people,
I'm investigating how may we combine the traffic obfuscation provided by obfsproxy+scramblesuit with OpenVPN instead of Tor.
I completely understand how this combination does not provide anonymity, but nevertheless I think it will be of some use.
In the recent past there have been some interest in this combination [1], [2], [3], mainly cause of VPN traffic blocking in various countries or networks.
OpenVPN supports only Socks5 proxy but current obsfproxy's version doesn't have a Socks5 listener, see ticket #9221 [4].
Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one.
Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers.
So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase. Do the credentials depend on the pluggable transport in use by the obfsproxy? If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit? Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication?
Thanks in advance for any answers. Alex
-- Developer at https://www.useotrproject.org/
On Wed, 05 Mar 2014 15:08:06 +0200 irregulator@riseup.net wrote:
Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one.
Correct.
Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers.
I didn't consider other things when I wrote it, though I expect it to work, assuming the "other things" implement SOCKSv5 correctly. Also note that my github branch[0] will have a more up to date version of the code, there are a few changes that I have made based on feedback since then, and I'll probably change the code further. At this point the only change that would be user facing is that I may allow the DOMAINNAME address type (which is a bad thing to support for pluggable transports, but probably useful for everyone else.
So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase.
Yay.
Do the credentials depend on the pluggable transport in use by the obfsproxy?
Yes. It only should happen for obfs2 (if Shared Secret mode is used) and ScrambleSuit. All the other transports will ignore any credentials passed.
If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit?
As the *username*: * "password=<Base32 encoded k_B>" k_B is 32 characters encoded. As the *password*: * '\0' (A single byte of value 0x00).
Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication?
Just k_B. Session Tickets are separate and not something the user should ever mess with. It is also possible to skip using RFC 1929 auth entirely by passing "--password <Base32 encoded k_B>" as a command line option. Regards, -- Yawning Angel [0]: https://github.com/Yawning/obfsproxy/tree/socks5-listener
On 03/05/2014 07:58 PM, Yawning Angel wrote:
>
>> So, while testing OpenVPN with obfsproxy and the latest patch, the vpn
>> client enters the authentication phase.
> Yay.
>
>> Do the credentials depend on the pluggable transport in use by the
>> obfsproxy?
> Yes. It only should happen for obfs2 (if Shared Secret mode is used)
> and ScrambleSuit. All the other transports will ignore any credentials
> passed.
>
>> If so, what credentials should the vpn or the ssh socks client
>> provide when talking with scramblesuit?
> As the *username*:
> * "password=<Base32 encoded k_B>" k_B is 32 characters encoded.
>
> As the *password*:
> * '\0' (A single byte of value 0x00).
>
>> Will vpn client have to provide the session ticket or other
>> pre-shared secret through socks authentication?
> Just k_B. Session Tickets are separate and not something the user
> should ever mess with.
>
> It is also possible to skip using RFC 1929 auth entirely by passing
> "--password <Base32 encoded k_B>" as a command line option.
>
> Regards,
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.
So I made a rearrangement like this :
--- a/obfsproxy/network/socks5.py
+++ b/obfsproxy/network/socks5.py
@@ -98,8 +98,8 @@ class SOCKSv5Protocol(protocol.Protocol):
# Authentication methods
ACCEPTABLE_AUTH_METHODS = [
- _SOCKS_AUTH_USERNAME_PASSWORD,
- _SOCKS_AUTH_NO_AUTHENTICATION_REQUIRED
+ _SOCKS_AUTH_NO_AUTHENTICATION_REQUIRED,
+ _SOCKS_AUTH_USERNAME_PASSWORD
]
AUTH_METHOD_VTABLE = {
_SOCKS_AUTH_USERNAME_PASSWORD:
methodcaller('processRfc1929Request'),
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'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.
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.
Alex
On Thu, 06 Mar 2014 19:22:16 +0200 irregulator <irregulator@riseup.net> 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
On 03/07/2014 12:10 AM, Yawning Angel wrote:
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.
Are we sure it's an OpenVPN bug? Cause I'm getting a : "socks_handshake: server asked for username/login auth but we were not provided any credentials" which kind of makes sense regarding the methods' priority in socks5.py And that occurs even when using obfs3 which shouldn't expect any credentials. Am I missing something?
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).
Option 3 does work for scramblesuit, cool! :) So, socks authentication could be used by the OpenVPN client to pass scramblesuit credentials to obfsproxy. Could I somehow run obfsproxy without explicitly setting a scramblesuit secret, as it's needed when running unmanaged? Greetings, Alex
On Mon, 10 Mar 2014 03:27:12 +0200 irregulator@riseup.net wrote:
Are we sure it's an OpenVPN bug? Cause I'm getting a :
"socks_handshake: server asked for username/login auth but we were not provided any credentials"
which kind of makes sense regarding the methods' priority in socks5.py
And that occurs even when using obfs3 which shouldn't expect any credentials.
Am I missing something?
Right, this is illustrating that it is a OpenVPN bug. So, what SOCKSv5 does is, when the client (OpenVPN) connects, it sends the version of the SOCKS protocol (5) and a list of methods it is willing to use. Out of the list that is sent, the server (obfsproxy) picks the one. I posted the snippet of code from OpenVPN that does this in my last e-mail, but in more detail:
const ssize_t size = send (sd, "\x05\x02\x00\x02", 4, MSG_NOSIGNAL);
0x05 -> I am speaking SOCKSv5 0x02 -> I have 2 authentication methods I can use 0x00 -> I can use NO AUTHENTICATION REQUIRED 0x02 -> I can use USERNAME/PASSWORD This happens regardless of if the user specifies a username/password in the config or not. What should happen is: * If there is no username/password specified in the OpenVPN config, it sends 0x05 0x01 0x00 (I only support NO AUTHENTICATION REQUIRED) * If there is a username/password specified in the OpenVPN config, it sends 0x05 0x01 0x02 (I only support USERNAME/PASSWORD). The SOCKS server I wrote will always pick USERNAME/PASSWORD over no authentication if it is offered by the client (In this context OpenVPN). What your patch does is reverse this to always pick NO AUTHENTICATION REQUIRED over USERNAME/PASSWORD, which will break things for OpenVPN users that want to specify the ScrambleSuit shared secret in the OpenVPN config file. For what it's worth, the obfsproxy behavior currently present also detects mis-configured clients (users inputting credentials when the SOCKS server doesn't require any), so I think it is a saner default. The relevant portions of RFC 1928 is: The NMETHODS field contains the number of method identifier octets that appear in the METHODS field. The server selects from one of the methods given in METHODS, and sends a METHOD selection message.
Option 3 does work for scramblesuit, cool! :)
So, socks authentication could be used by the OpenVPN client to pass scramblesuit credentials to obfsproxy. Could I somehow run obfsproxy without explicitly setting a scramblesuit secret, as it's needed when running unmanaged?
The moment the OpenVPN people fix their broken SOCKS client to not offer to negotiate an authentication method that they can't actually use due to missing parameters, this will work as expected. -- Yawning Angel
On Mon, 10 Mar 2014 01:57:11 +0000 Yawning Angel <yawning@schwanenlied.me> wrote:
The moment the OpenVPN people fix their broken SOCKS client to not offer to negotiate an authentication method that they can't actually use due to missing parameters, this will work as expected.
https://github.com/Yawning/openvpn/commit/7474f1acfc5d296289f3f65566184ea699... That should work, I'll open a pull request, but I'm not going to spend more time on it, and there's no guarantee that they will accept it. Regards, -- Yawning Angel
On 03/10/2014 05:56 AM, Yawning Angel wrote:
https://github.com/Yawning/openvpn/commit/7474f1acfc5d296289f3f65566184ea699...
That should work, I'll open a pull request, but I'm not going to spend more time on it, and there's no guarantee that they will accept it.
Regards,
Yawning's patch was commited and pushed, and will be part of OpenVPN as of version 2.3.4 http://community.openvpn.net/openvpn/ticket/377 Cheers, Alex
irregulator@riseup.net writes:
Hello people,
I'm investigating how may we combine the traffic obfuscation provided by obfsproxy+scramblesuit with OpenVPN instead of Tor.
I completely understand how this combination does not provide anonymity, but nevertheless I think it will be of some use.
In the recent past there have been some interest in this combination [1], [2], [3], mainly cause of VPN traffic blocking in various countries or networks.
OpenVPN supports only Socks5 proxy but current obsfproxy's version doesn't have a Socks5 listener, see ticket #9221 [4].
FWIW, #9221 got merged to obfsproxy master! This means that obfsproxy should be advertising a SOCKS5 listener by default now. I'm planning on doing an obfsproxy release soon (this or the next week), so please test the SOCKS5 feature and report any bugs you find! Enjoy!
Hi, my name is Benjamin Keeser. I am a student of computer science (master of software engineering) from Munich, Germany. I support and work in different social movements against suppression and control since many years. Consequently I am interested in the Tor project. Actually I am working with some others from different political media collectives on an book how to protect oneself from total digital surveillance. We already discussed the idea of a router which tunnels all the traffic over Tor. My guidelines in this case were the onion pi project and the freedombox. By chance I realized that there is already a similar project under your maintaince (and I hope this mail is not to late). But there wasn´t any activity since 16 months. What is the reason? Are you planning to continue the project? In our work of making computers of people a little bit safer it would make really sense to have a router which protects users via Tor and also filters recognizable parameters via privoxy. I discussed this point also, because I don´t see a similar project in the near future (the freedombox project also appears not to make this pogress in the next time - which is although a reason for the router project). In my case I would also combine the router project (GSoC) with my master´s thesis. And my plan is to do a PhD afterwards. So would there be a possibility to give the project a new chance. What do think about this idea? These are some thoughts about the implementation / further development - stable core features - dont´t reinvent the wheel: there are already some reusable features in tails/freedombox (e.g. dns handling, network filter) - debian hardening / openwrt - implementation of privoxy to obtain a not recognizable fingerprint. - future: modular system (email-server, file space, webspace, ***relay***), web interface Best regards, Benjamin Keeser -------------- public-key gpg --recv-keys 3B874A206875DC1A (hkp://keys.gnupg.net) http://http-keys.gnupg.net/pks/lookup?op=get&search=0x3B874A206875DC1A
Hi again, what do you think about the idea to restart the torouter project? Is there anybody on the list who is interested in it? Some feedback would be nice … Regards, Benjamin Keeser Am 12.03.2014 um 14:23 schrieb keeser@hm.edu:
Hi, my name is Benjamin Keeser. I am a student of computer science (master of software engineering) from Munich, Germany. I support and work in different social movements against suppression and control since many years. Consequently I am interested in the Tor project. Actually I am working with some others from different political media collectives on an book how to protect oneself from total digital surveillance. We already discussed the idea of a router which tunnels all the traffic over Tor. My guidelines in this case were the onion pi project and the freedombox. By chance I realized that there is already a similar project under your maintaince (and I hope this mail is not to late). But there wasn´t any activity since 16 months. What is the reason? Are you planning to continue the project? In our work of making computers of people a little bit safer it would make really sense to have a router which protects users via Tor and also filters recognizable parameters via privoxy. I discussed this point also, because I don´t see a similar project in the near future (the freedombox project also appears not to make this pogress in the next time - which is although a reason for the router project).
In my case I would also combine the router project (GSoC) with my master´s thesis. And my plan is to do a PhD afterwards. So would there be a possibility to give the project a new chance. What do think about this idea?
These are some thoughts about the implementation / further development
- stable core features - dont´t reinvent the wheel: there are already some reusable features in tails/freedombox (e.g. dns handling, network filter) - debian hardening / openwrt - implementation of privoxy to obtain a not recognizable fingerprint. >
- future: modular system (email-server, file space, webspace, ***relay***), web interface
Best regards, Benjamin Keeser
-------------- public-key gpg --recv-keys 3B874A206875DC1A (hkp://keys.gnupg.net) http://http-keys.gnupg.net/pks/lookup?op=get&search=0x3B874A206875DC1A
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Hi again, what do you think about the idea to restart the torouter project? Is there anybody on the list who is interested in it? Some feedback would be nice … https://trac.torproject.org/projects/tor/wiki/doc/Torouter Regards, Benjamin Keeser Am 12.03.2014 um 14:23 schrieb keeser@hm.edu:
Hi, my name is Benjamin Keeser. I am a student of computer science (master of software engineering) from Munich, Germany. I support and work in different social movements against suppression and control since many years. Consequently I am interested in the Tor project. Actually I am working with some others from different political media collectives on an book how to protect oneself from total digital surveillance. We already discussed the idea of a router which tunnels all the traffic over Tor. My guidelines in this case were the onion pi project and the freedombox. By chance I realized that there is already a similar project under your maintaince (and I hope this mail is not to late). But there wasn´t any activity since 16 months. What is the reason? Are you planning to continue the project? In our work of making computers of people a little bit safer it would make really sense to have a router which protects users via Tor and also filters recognizable parameters via privoxy. I discussed this point also, because I don´t see a similar project in the near future (the freedombox project also appears not to make this pogress in the next time - which is although a reason for the router project).
In my case I would also combine the router project (GSoC) with my master´s thesis. And my plan is to do a PhD afterwards. So would there be a possibility to give the project a new chance. What do think about this idea?
These are some thoughts about the implementation / further development
- stable core features - dont´t reinvent the wheel: there are already some reusable features in tails/freedombox (e.g. dns handling, network filter) - debian hardening / openwrt - implementation of privoxy to obtain a not recognizable fingerprint. >
- future: modular system (email-server, file space, webspace, ***relay***), web interface
Best regards, Benjamin Keeser
-------------- public-key gpg --recv-keys 3B874A206875DC1A (hkp://keys.gnupg.net) http://http-keys.gnupg.net/pks/lookup?op=get&search=0x3B874A206875DC1A
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (7)
-
George Kadianakis -
info＠tatura.net -
irregulator -
irregulator＠riseup.net
-
Jurre van Bergen -
keeser＠hm.edu -
Yawning Angel