Opened 7 years ago

Closed 7 years ago

#8023 closed defect (fixed)

Where's the pyobfsproxy code?

Reported by: arma Owned by: asn
Priority: Medium Milestone:
Component: pyobfsproxy Version:
Severity: Keywords:
Cc: asn, iang Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

There's no pyobfsproxy on gitweb.torproject.org -- there is a user/asn/pyobfsproxy, but it appears old and doesn't include the obfs3 module that we apparently shipped (https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles).

I tried some likely guesses for doing a git clone (maybe it's just missing from the gitweb list?), but I couldn't find it that way either.

Child Tickets

Change History (8)

comment:1 Changed 7 years ago by arma

Also, it looks like there's no public spec for the obfs3 protocol. Or rather, there are several, since we called it obfs3 before we settled on the design (oops -- maybe in the future we should use other names for things that we hope will become obfs4). So, where is the design for the thing that we're giving actual users? :/

comment:2 in reply to:  description ; Changed 7 years ago by asn

Replying to arma:

There's no pyobfsproxy on gitweb.torproject.org -- there is a user/asn/pyobfsproxy, but it appears old and doesn't include the obfs3 module that we apparently shipped (https://blog.torproject.org/blog/combined-flash-proxy-pyobfsproxy-browser-bundles).

I tried some likely guesses for doing a git clone (maybe it's just missing from the gitweb list?), but I couldn't find it that way either.

You are right that there is no official pyobfsproxy repository. pyobfsproxy was developed and deployed quickly and before I thought that an official repository would be needed. I created #8027 for this reason.

Also, it looks like there's no public spec for the obfs3 protocol. Or rather, there are several, since we called it obfs3 before we settled on the design (oops -- maybe in the future we should use other names for things that we hope will become obfs4). So, where is the design for the thing that we're giving actual users? :/

Yeah, I've been using user/asn/pyobfsproxy.git as a personal repository with experimental branches, which probably confuses people who are not me.

I agree it was a mistake to call all these variants "obfs3", in the future we should indeed use other names (maybe even "obfs3_test" could be an acceptable name for this situation).

In any case, to answer your question, the obfs3 that was deployed is the one that can be found under the branch "obfs3_take2":
https://lists.torproject.org/pipermail/tor-dev/2013-January/004334.html
I will call the deployed obfs3, "obfs3_take2" from now on.

"obfs3_take2" is *almost* ready. I still need to merge two patches: one from Philipp and another one that implements some suggestions of Ian. I'm also waiting for a mail reply from Ian, since he had some comments that I think I resolved but I want to make sure that he is happy with the results. After I receive the mail and merge the patches, I will merge the obfs3_take2 branch to master, and consider "obfs3" as done.

(For an extra fun factor, Ian suggested to change the key derivation function of obfs3 so that it uses an IV filled with zero bytes, while obfs2 and obfs3_take2 are using an IV derived from the shared-secret. As far as I understand, this is mostly an aesthetics matter which will make our CTR-mode use more conventional, but it will also break compatibility between obfs3_take2 and obfs3. I sent a mail to Ian to make *sure* that it's indeed an aesthetics matter, and if it is, I might consider skipping this change till the next obfs3-variant. I'm sure that my bridge is the only obfs3 bridge out there, and that such a change won't break lots of stuff, but I still want to be sure that backwards compatibility is maintained. Maybe I could also skip an integer and name the new transport "obfs4", but I don't think that that change is important enough to confuse people.)

(Looking at the obfs3_take2 deployment, I don't think I regret its super-quick and experimental deployment even though the code deployed might not be the final "obfs3" code: obfs3_take2 works correctly, it obfuscates stuff, it made me more confident that its implementation is correct, and it increased the number of deployed PTs by one. The lesson I learned, is that I should name experimentally deployed pluggable transports correctly, so that no confusion happens when they stabilize. Maybe I should even create a proper procedure for deploying experimental pluggable transports.)

Comments are welcome. Sorry for the wall of text.

comment:3 in reply to:  2 Changed 7 years ago by cypherpunks

Replying to asn:

Sorry for the wall of text.

its ok

comment:4 Changed 7 years ago by iang

Sorry; I didn't realize asn was waiting on me for a reply. We have touched base by email now.

comment:5 Changed 7 years ago by iang

Cc: iang added

comment:6 Changed 7 years ago by asn

FWIW, obfs3 is now merged in the master branch of user/asn/pyobfsproxy.git.

comment:7 Changed 7 years ago by asn

FWIW2, #8027 #8033 got implemented, and now
https://gitweb.torproject.org/pluggable-transports/pyobfsproxy.git
https://gitweb.torproject.org/pluggable-transports/pyptlib.git
are both populated and should be considered the official repositories for those projects.

I'll leave this ticket open in case anyone has any comments. Roger feel free to close it if you feel fulfilled.

comment:8 Changed 7 years ago by arma

Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.