Hello,
I'm new here, running a relay for the past year. I'm looking to implement obfsproxy running on port 80 and emulating HTTP traffic.
The official manual says I should add this line to torrc: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed
However, it runs on a random port (30000+) which kind of defeats the whole purpose of running an obfuscated bridge. I also haven't seen a way to force faking HTTP traffic. The manual page is very terse and doesn't explain how to do any of this.
How do I configure obfsproxy to look like a HTTP server?
I dont think running obfsproxy is beneficial on a relay, as the IP is associated with Tor.
Regards,
Matthew On 7 Oct 2013 16:26, "GDR!" gdr@gdr.name wrote:
Hello,
I'm new here, running a relay for the past year. I'm looking to implement obfsproxy running on port 80 and emulating HTTP traffic.
The official manual says I should add this line to torrc: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed
However, it runs on a random port (30000+) which kind of defeats the whole purpose of running an obfuscated bridge. I also haven't seen a way to force faking HTTP traffic. The manual page is very terse and doesn't explain how to do any of this.
How do I configure obfsproxy to look like a HTTP server?
-- Zapisz moj nowy prywatny adres email: gdr@gdr.name Teraz na wlasnym serwerze. Zawsze czysto - zawsze sucho - zawsze pewnie. Klucz PGP to nadal 4ED3D2B7
tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
GDR!:
Hello,
I'm new here, running a relay for the past year. I'm looking to implement obfsproxy running on port 80 and emulating HTTP traffic.
The official manual says I should add this line to torrc: ServerTransportPlugin obfs2,obfs3 exec /usr/bin/obfsproxy managed
However, it runs on a random port (30000+) which kind of defeats the whole purpose of running an obfuscated bridge. I also haven't seen a way to force faking HTTP traffic. The manual page is very terse and doesn't explain how to do any of this.
How do I configure obfsproxy to look like a HTTP server?
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
I recomend you to read these pages:
- - https://www.torproject.org/docs/bridges - - https://www.torproject.org/docs/faq.html.en#RelayOrBridge - - https://www.torproject.org/projects/obfsproxy.html.en
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
On 2013-10-07 16:13, GDR! wrote:
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
It does: StegoTorus.
Greets, Jeroen
On Mon, Oct 7, 2013 at 4:36 PM, Jeroen Massar jeroen@massar.ch wrote:
On 2013-10-07 16:13, GDR! wrote:
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
It does: StegoTorus.
Unless something has changed very recently, all publicly available copies of StegoTorus are missing critical pieces of functionality (such as the ability to use a session key that isn't HARDWIRED INTO THE SOURCE CODE), and also don't *really* implement HTTP, only something that looks like HTTP on cursory inspection but is trivial for an active attacker to detect (see Houmansadr et al., https://www.ieee-security.org/TC/SP2013/papers/4977a065.pdf ) Furthermore, last I looked at it, the "steg module" code (that is, the code that actually implements the HTTP-alike) was so riddled with security-critical bugs (of the "classic 1990s buffer overflow vulnerability" variety) that it was probably unsafe to run it on the public Internet *at all*. For these reasons, the copy of ST on my personal Github has been modified not to compile out of the box, and I am considering deleting it altogether.
Jeroen: I am aware that ISC and SRI are supposed to be working on fixes for these issues, but until the fixed code is available to the general public -- from the official Git repository on gitweb.torproject.org -- I request that you refrain from suggesting that StegoTorus solves this problem. In fact, I would prefer that you not even mention that it exists.
zw
Oh, and, the cryptographic choices made in the ST paper are, in retrospect, quite poor: for instance, I had no idea when I picked it that AES-GCM was so troublesome in software, and all of the elliptic curve stuff has since been obsoleted by Elligator.
Anyone interested in hacking on steganographic transports nowadays would be well-advised to begin from something else, such as Yawning Angel's LODP.
On 2013-10-07 22:48, Zack Weinberg wrote:
On Mon, Oct 7, 2013 at 4:36 PM, Jeroen Massar jeroen@massar.ch wrote:
On 2013-10-07 16:13, GDR! wrote:
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
It does: StegoTorus.
Unless something has changed very recently, all publicly available copies of StegoTorus are missing critical pieces of functionality (such as the ability to use a session key that isn't HARDWIRED INTO THE SOURCE CODE),
Indeed, the version you created had this and many other issues, these have been addressed, but indeed not made publicly available yet, though Tor Project members have had updates to it already.
As you are very aware unfortunately the people working on the system have restrictions on code releases, they are doing their best to get it out in the open though.
and also don't *really* implement HTTP, only something that looks like HTTP on cursory inspection but is trivial for an active attacker to detect (see Houmansadr et al., https://www.ieee-security.org/TC/SP2013/papers/4977a065.pdf )
A very well known paper, and a really good one too. The solution to this is a component called JumpBox, and the initial codename was MockingBird, I guess you can derive from that what the problem is that it solves: "How to kill a Mockingbird" :)
Furthermore, last I looked at it, the "steg module" code (that is, the code that actually implements the HTTP-alike) was so riddled with security-critical bugs (of the "classic 1990s buffer overflow vulnerability" variety) that it was probably unsafe to run it on the public Internet *at all*.
And it is good that several other people have been fixing up those problems before releasing it into the wild of people who depend on security and anonymity. More code audits are underway and also needed though before it gets there.
For these reasons, the copy of ST on my personal Github has been modified not to compile out of the box, and I am considering deleting it altogether.
That is a good idea, releasing/publishing code of that quality is IMHO quite irresponsible. It is good that one needs to specifically set it up on either side though before using it, as that gives an insight to the quality of the code.
Jeroen: I am aware that ISC and SRI are supposed to be working on fixes for these issues, but until the fixed code is available to the general public -- from the official Git repository on gitweb.torproject.org -- I request that you refrain from suggesting that StegoTorus solves this problem. In fact, I would prefer that you not even mention that it exists.
As you state yourself, if the code quality is that bad, why is it currently up there in that form?
The people who work on that code and are improving the many mistakes that where in there unfortunately have to go through code review before releasing things. That does not mean it does not exist or does not function properly. Code releases are coming, hopefully sooner than later though.
Getting the code out there under more eyes is something that will happen.
From another reply: Oh, and, the cryptographic choices made in the ST paper are, in retrospect, quite poor: for instance, I had no idea when I picked it that AES-GCM was so troublesome in software, and all of the elliptic curve stuff has since been obsoleted by Elligator.
Which just shows that new research improves things and that while implementing something that one can realize that certain design choices might not be perfect for the situation originally thought up. Hence, why one keeps on improving on things to avoid those shortcomings.
Anyone interested in hacking on steganographic transports nowadays would be well-advised to begin from something else, such as Yawning Angel's LODP.
While it is a project with a lot of merit, in a lot of locations UDP will simply not be going in or out of a country...
It is thus a project with quite different goals and resolving a very different problem, than what StegoTorus is trying to resolve.
And the more of these things the merrier, as it will just increase the chance of bypassing the filters that are in place.
Greets, Jeroen
On Tue, Oct 8, 2013 at 10:49 AM, Jeroen Massar jeroen@massar.ch wrote:
On 2013-10-07 22:48, Zack Weinberg wrote:
On Mon, Oct 7, 2013 at 4:36 PM, Jeroen Massar jeroen@massar.ch wrote:
On 2013-10-07 16:13, GDR! wrote:
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
It does: StegoTorus.
Unless something has changed very recently, all publicly available copies of StegoTorus are missing critical pieces of functionality (such as the ability to use a session key that isn't HARDWIRED INTO THE SOURCE CODE),
Indeed, the version you created had this and many other issues, these have been addressed, but indeed not made publicly available yet, though Tor Project members have had updates to it already.
I'm glad to hear that improvements have been made.
All I am asking is that you refrain from suggesting that StegoTorus solves anyone's problems -- and ideally that you refrain from bringing it up at all -- until the improved version is publicly available. I do not want anyone to get the idea that the current public version is safe to use.
As you are very aware unfortunately the people working on the system have restrictions on code releases, they are doing their best to get it out in the open though.
If development continues to be done behind closed doors, I rather think no one will be inclined to trust the end product.
That is a good idea, releasing/publishing code of that quality is IMHO quite irresponsible. It is good that one needs to specifically set it up on either side though before using it, as that gives an insight to the quality of the code.
It is still there mainly because I don't want to pull the rug out from under vmon, who I believe is also still working on it. vmon, can you comment on your current plans and the extent to which you need that code there?
Anyone interested in hacking on steganographic transports nowadays would be well-advised to begin from something else, such as Yawning Angel's LODP.
While it is a project with a lot of merit, in a lot of locations UDP will simply not be going in or out of a country...
It is thus a project with quite different goals and resolving a very different problem, than what StegoTorus is trying to resolve.
Based on my experience with StegoTorus, I think LODP will be a better *infrastructure* on which to build steganography. (Specifically, UDP as the transport between what ST calls the "chopper" and the "steg modules" should make a bunch of message-framing headaches just disappear.)
zw
You folks may find this link interesting
http://tor.stackexchange.com/questions/543/how-to-set-up-an-obfs3-bridge-on-...
You could also help improve the question and answers.
Just make sure you login/surf SE over Tor, as it records your IP.
Bests,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
GDR!:
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
There is a pluggable transport protocol that aims to mimic a cover protocol such HTTP. Its name is Stegotorus but I believe that still is not full developed. If you want more info you can read this:
- - http://www.owlfolio.org/media/2010/05/stegotorus.pdf - - https://gitweb.torproject.org/stegotorus.git
"GDR!" gdr@gdr.name writes:
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
Ha, you caught us! That website sentence is indeed an advertisement trick! Obfsproxy does *not* have an HTTP module yet, unfortunately.
The funny thing about HTTP transports is that it's easy to write a simple but trivially detectable HTTP transport, and quite hard to write an actually good HTTP transport. We have open tickets for both ideas and would appreciate coding help: https://trac.torproject.org/projects/tor/ticket/5625 https://trac.torproject.org/projects/tor/ticket/8676
Also see https://github.com/sjmurdoch/http-transport/blob/master/design.md for things to consider when writing your HTTP transport.
(I CC'ed dardok who recently appeared in tor-talk and wanted to contribute to pluggable transports development.)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
George Kadianakis:
"GDR!" gdr@gdr.name writes:
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
Ha, you caught us! That website sentence is indeed an advertisement trick! Obfsproxy does *not* have an HTTP module yet, unfortunately.
The funny thing about HTTP transports is that it's easy to write a simple but trivially detectable HTTP transport, and quite hard to write an actually good HTTP transport. We have open tickets for both ideas and would appreciate coding help: https://trac.torproject.org/projects/tor/ticket/5625 https://trac.torproject.org/projects/tor/ticket/8676
Also see https://github.com/sjmurdoch/http-transport/blob/master/design.md for things to consider when writing your HTTP transport.
(I CC'ed dardok who recently appeared in tor-talk and wanted to contribute to pluggable transports development.)
George Kadianakis, thanks for the links. I've been reading some papers and the conclusion that I drew is that it would be good to try to run a real service or program in both parts of communication, i.e. a browser binary in the client side and a server binary in the bridge side, to perfectly mimick the HTTP communication protocol and be able to hide inside these packets the TOR traffic. Is there some private list or chat about PTs? Is there some advanced work on this field, that's related to running real HTTP services and wrapping the TOR traffic into them?
dardok dardok@riseup.net writes:
George Kadianakis:
"GDR!" gdr@gdr.name writes:
On 07.10.2013 21:11, dardok wrote:
I guess that you misunderstood the concept of obfsproxy. It is useful to obfuscate the communication between a client within a censorship zone and a tor bridge. The obfsproxy doesn't emulate a HTTP protocol communication, instead it is designed to look random (and the packets are encypted). So if you try to run this service over the HTTP port 80 and the packets are random and not looking like a HTTP communication, it will be more suspicious than running this service over any other port.
Thank you. I understood the concept but not the implementation.
"For example, there MIGHT be a HTTP transport which transforms Tor traffic to look like regular HTTP traffic."
I missed the "MIGHT" part. Too bad this doesn't exist.
Ha, you caught us! That website sentence is indeed an advertisement trick! Obfsproxy does *not* have an HTTP module yet, unfortunately.
The funny thing about HTTP transports is that it's easy to write a simple but trivially detectable HTTP transport, and quite hard to write an actually good HTTP transport. We have open tickets for both ideas and would appreciate coding help: https://trac.torproject.org/projects/tor/ticket/5625 https://trac.torproject.org/projects/tor/ticket/8676
Also see https://github.com/sjmurdoch/http-transport/blob/master/design.md for things to consider when writing your HTTP transport.
(I CC'ed dardok who recently appeared in tor-talk and wanted to contribute to pluggable transports development.)
George Kadianakis, thanks for the links. I've been reading some papers and the conclusion that I drew is that it would be good to try to run a real service or program in both parts of communication, i.e. a browser binary in the client side and a server binary in the bridge side, to perfectly mimick the HTTP communication protocol and be able to hide inside these packets the TOR traffic. Is there some private list or chat about PTs? Is there some advanced work on this field, that's related to running real HTTP services and wrapping the TOR traffic into them?
Greetings dardok,
if you want to chat about PTs development, the tor-dev mailing list might be a good place (OTOH this mailing list is not a very good place). If you fancy synchronous communication, you can try dropping by the #tor-dev IRC channel in OFTC.
Furthermore, every 2 weeks we are having PT meetings where many PT developers come together and talk to each other. If I'm not mistaken, the next such meeting will be on the 25th of October.
As far as "advanced work" on the field of HTTP PTs is concerned, the links I posted on my previous mail are a good start.
( You might also want to check out the 'stegotorus' transport. It's a transport proxy capable of simulating multiple protocols (including HTTP) but it's main implementation is closed source (it also doesn't use an actual browser). There is an open source version of it, but it's codebase is huge and it needs tons of work to be deployable. If you want to make a new HTTP PT, I would suggest to start a new project. Please get in touch with us before you start hacking :) )
If you want to continue this development discussion, I would suggest to CC tor-dev instead of tor-relays :)
Cheers!
tor-relays@lists.torproject.org
-
dardok -
GDR! -
George Kadianakis -
Jeroen Massar -
Matthew Harrold -
Nima -
Zack Weinberg