[tor-dev] RFC: obfsproxyssh
security thing, but it opens the bridge to being blocked). * Does Tor tunneled over SSH look distinctive? No effort is made to change the traffic signature, though this can be added if needed. The tarball contains a more detailed README explaining how to set it up and how it works. obfsproxyssh_client.c has a more in-depth TODO list as a large comment near the top of the file. Comments and feedback will be appreciated. Regards, -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfsproxyssh
On 2013-07-29 00:05, Andreas Krey wrote: > On Sat, 27 Jul 2013 09:52:52 +, Tom Ritter wrote: > ... >> I've always thought with SSH-based obsproxies, that you could >> distribute the SSH private key to connect to the server with the >> bridge IP address:port. > > I couldn't quite avoid the reflexive cringe at 'distribute private key'. :-) > > ... >> So I think the value of requiring a login a the SSH-based obsproxy is >> not for authentication but for scanning resistance. > > Ah, that's a cool idea. I was already assuming that a specific key would > be used to select the tor service on the sshd, but making that key > variable is a nice twist. (I didn't know the bridgedb has space for > such info.) Yep, that's the idea. All of the arguments in the gigantic bridge line of doom are the equivalent of something like the shared secret component present in ScrambleSuit. The code's changed quite a bit since I've last posted (per discussion with asn a while ago, we decided that it would be better to use a "real" ssh client), so I have been working on a python script that wraps OpenSSH. Works fairly well under U*IX, but under Windows, there's a few issues that need to be addressed still. Regards, -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: Lightweight Obfuscated Datagram Protocol (LODP)
Hello all, Inspired by a conversation with arma, I have been working on designing a UDP based protocol to serve as the bulk data transport for something along the lines of "obfs3, but over UDP". The spec document is approaching the point where I would like to have increased public review before I go and implement it. People who sit in #tor-dev probably have seen various revisions of this draft already. Some notes: * This is heavily inspired by SSU from the i2p project, and Dust by Brandon Wiley. * Ensuring that data gets delivered reliably and in order is outside the scope of this document. Such things are a well researched problem so my reference implementation will likely draw upon an existing protocol instead of reinventing the wheel here. * As far as existing work in this area, the only other protocols that attempt to do similar things are i2p's SSU and Dust. * LODP assumes that there is a shared secret between peers to attempt to thwart active probing attacks. * As part of my evil plans, "secure fingerprinting resistant UDP" is something useful to have. * Open questions/things that are subject to change are tagged with XXX. Questions, comments, feedback appreciated. -- Yawning Angel Lightweight Obfuscated Datagram Protocol (LODP) Yawning Angel (XXX: Preliminary Draft. If anyone implements this, I will laugh at them, because there are probably problems, and parts (all?) of it may suck. In particular, open questions/to-be-encorporated feedback is appended to the end of the document.) 0. Introduction This is an encrypted wire transport protocol designed to be a fingerprinting resistant alternative to Datagram TLS. Its purpose is to keep a third party from being able to tell what protocol is in use based on message contents and to provide authentication and data integrity. 1. Motivation There is a large volume of work that allows for "reliable bulk data transfer over UDP", by developing a lightweight secure obfuscated datagram transport protocol, it would be possible to leverage existing research in these areas. Examples of candidates for LODP encapsulation, in no particular order, are SCTP-over-UDP, Reliable Data Protocol (RFC1151), enet, and UDT. (XXX: Add something covering I2P's SSU and Dust) 2. LODP Threat Model The threat model for LODP is identical to the threat model of obfs3 [OBFS3 THREAT MODEL], with added goals: LODP offers protection against active scanning machines that expect the LODP protocol. Such machines should not be able to verify the existence of the LODP protocol without compromising the authenticated encryption used in session initialization. LODP offers protection against active attackers that attempt to mount a man-in-the-middle attack. The cryptographic handshake will fail, and such attacks will be detected. LODP does not protect against adversaries that are capable of measuring protocol entropy, or those that employ a protocol whitelist. Attacks on the out-of-band shared secret distribution mechanism (Eg: Tor's BridgeDB) are likewise outside the scope of the protocol design, however the most that an attacker that obtains a endpoint's shared secret is able to do is to censor the protocol. 3. Notation and Constants The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. All packet fields are in network byte order. A byte is a 8 bit octet. Let a | b be the concatenation of a with b. All random numbers used in this protocol MUST come from a cryptographically strong random number generator. 4. Overview of LODP LODP attempts to make all traffic look like random noise. The session handshake uses MAC and bulk encryption keys derived from the server's public Curve25519 key to mask the packet payload, and negotiates a ephemeral session key to provide actual data authentication, integrity and perfect forward secrecy. In the event that the server's long term identity key is compromised, the most that an attacker can do is identify the LODP protocol. The LODP packet format provides for added arbitrary random padding, and undersized packets are silently ignored to allow the implementer flexibility when attempting to mask the packet size. To mitigate the potential of an attacker to mount a denial of service attack given the server's host key, LODP uses a 4 way handshake similar to SCTP or DTLS. (XXX: Does this section need more stuff???) 5. Maximum Transmission Unit and Path MTU Discovery The MTU including IP and UDP headers MUST be a minimum of 576 bytes f
Re: [tor-dev] Pluggable transport weekly meeting
On 2013-09-06 01:58, Vmon wrote: > I sent this email quite a while ago and I was surprised that nobody was > interested/replied. Today I found out that I had sent it to a wrong > address. But here we are, so I'm sending it again. So please reply so we > can kick this off soon. Assuming not today (2013/09/16) isn't "soon", the times specified works for me and I will make an effort to attend. Regards, -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Pluggable Transports and rate limiting
On 2013-09-10 05:34, George Kadianakis wrote: > BTW, posting here two more PT-rate-limiting ideas (instead of the > currently proposed RATE_LIMIT command) proposed by Andreas and Lunar > in IRC: > > * PTs calculate their overhead and send a "fudge factor" to Tor when > they start up (for example, if an HTTP transport has 30% overhead > over the underlying TLS connection, the fudge factor is 30%), which > Tor uses to calculate the actual number of bytes sent to the network > and do rate-limiting/accounting on its own. > > Unfortunately, I doubt that PTs have a constant fudge factor. Some of the PTs I can envision having a non-constant fudge factor are those that decide to insert cover traffic or randomize packet lengths in an attempt to evade detection or mimic other protocols. This feels like a lazier implementation of option #2. > * PTs periodically send to Tor (over the TransportControlPort or > something) how many bytes (or how many bytes overhead) they have > pushed to the network. These numbers are used by Tor to update its > traffic stats and enforce rate-limiting/accounting on its own. A more generic variant of option #1. I assume tor will enforce rate limiting by delaying writing to the PT connection(s) in question? PTs can/may end up breaking this if they need/want to insert constant cover traffic. It's entirely possible to say "Don't do that" in the spec, but that feels overly limiting. For what it's worth the main example that comes to mind when I try to remember how this sort of problem was solved before (besides, "use iptables and tc") is similar to the original proposal. See: http://monkey.org/~marius/pages/?page=trickle They cheat and use a shared library that wraps socket calls though. I assume that's not an option due to "this needs to work on windows". For the U*IX targets, trickle does most of what we would want. -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Lightweight Obfuscated Datagram Protocol (LODP)
Hello all, I didn't get much review on my first draft due to recent craziness and people being generally busy, but I've been slowly poking at LODP as time allows. I've went and made some modifications to the initial draft that I posted to tor-dev@, and made some tentative steps towards writing the accompanying PT (UDT over LODP). Major changes since last revision: * Replaced SHA-256 with BLAKE2s, and switched to using BLAKE2s' native keyed hash support instead of HMAC where appropriate. * Added support for rekeying. * Fixed typeos. Questions, comments, feedback all appreciated, -- Yawning Angel Lightweight Obfuscated Datagram Protocol (LODP) Yawning Angel 0. Introduction This is an encrypted wire transport protocol designed to be a fingerprinting resistant alternative to Datagram TLS. Its purpose is to keep a third party from being able to tell what protocol is in use based on message contents and to provide authentication and data integrity. 1. Motivation There is a large volume of work that allows for "reliable bulk data transfer over UDP", by developing a lightweight secure obfuscated datagram transport protocol, it would be possible to leverage existing research in these areas. Examples of candidates for LODP encapsulation, in no particular order, are SCTP-over-UDP, Reliable Data Protocol (RFC1151), enet, and UDT. (XXX: Add something covering I2P's SSU and Dust) 2. LODP Threat Model The threat model for LODP is identical to the threat model of obfs3 [OBFS3 THREAT MODEL], with added goals: LODP offers protection against active scanning machines that expect the LODP protocol. Such machines should not be able to verify the existence of the LODP protocol without compromising the authenticated encryption used in session initialization. LODP offers protection against active attackers that attempt to mount a man-in-the-middle attack. The cryptographic handshake will fail, and such attacks will be detected. LODP does not protect against adversaries that are capable of measuring protocol entropy, or those that employ a protocol whitelist. Attacks on the out-of-band shared secret distribution mechanism (Eg: Tor's BridgeDB) are likewise outside the scope of the protocol design, however the most that an attacker that obtains a endpoint's shared secret is able to do is to censor the protocol. 3. Notation and Constants The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [KEYWORDS]. All packet fields are in network byte order. A byte is a 8 bit octet. Let a | b be the concatenation of a with b. All random numbers used in this protocol MUST come from a cryptographically strong random number generator. 4. Overview of LODP LODP attempts to make all traffic look like random noise. The session handshake uses MAC and bulk encryption keys derived from the server's public Curve25519 key to mask the packet payload, and negotiates a ephemeral session key to provide actual data authentication, integrity and perfect forward secrecy. In the event that the server's long term identity key is compromised, the most that an attacker can do is identify the LODP protocol. The LODP packet format provides for added arbitrary random padding, and undersized packets are silently ignored to allow the implementer flexibility when attempting to mask the packet size. To mitigate the potential of an attacker to mount a denial of service attack given the server's host key, LODP uses a 4 way handshake similar to SCTP or DTLS. 5. Maximum Transmission Unit and Path MTU Discovery The MTU including IP and UDP headers MUST be a minimum of 576 bytes for IPv4 endpoints, and 1280 bytes for IPv6 endpoints. Implementations MAY implement PMTU discovery and MAY chose to send larger packets if the underlying data link layer is capable of doing so. Note: Implementations that chose to implement PMTU discover MUST ensure that the traffic profile is not trivially fingerprinted. Implementations SHOULD make attempts to avoid IP fragmentation. As LODP is designed as the transport for an encapsulated higher level transport, implementations MAY allow the higher level protocol to handle PMTU discovery. (XXX: The peer could advertise a MTU when handshaking but not sure how useful that is going to be.) (XXX: Technically the MTUs I chose will never be fragmented, but there's probably screwed up routers/hosts on the internet that aren't spec compliant, not sure "thou shalt not fragment" is bet
[tor-dev] Announcing liballium (A C Tor Pluggable Transports Utility Library)
Hello, For those aspiring Pluggable Transports authors out there, I've recently written a simple library that handles the Tor Pluggable Transport Configuration protocol. The idea is for this library to be the C/C++ equivalent to pyptlib (and maybe more, depending on how much time I have to work on it). The code is available at: https://github.com/Yawning/liballium It still needs more documentation, but all of the use cases are covered by a reasonably well commented example (examples/ptcfg_example.c). Questions, comments, feedback all appreciated. -- Yawning Angel ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] torsocks-v2.0.0-rc3 NetBSD improvements
On Tue, 5 Nov 2013 14:25:25 -0500 David Goulet wrote: > I encountered that on FreeBSD but I can't really make it go > away :S ... mmap() returns a void * but syscall() returns an int on > BSD but even with a cast it prints the warning... I have *no* idea > how *BSD systems handle syscall(SYS_MMAP, ...) for instance on an x64 > system when syscall() returns an int (8 bytes vs 4 bytes). They don't, because people should be using __syscall for mmap on those systems. Quoting the relevant parts from the documentation: off_t __syscall(quad_t number, ...); The __syscall() form should be used when one or more of the arguments is a 64-bit argument to ensure that argument alignment is correct. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Does TLS round-trip optimization apply do Tor?
On Tue, 24 Dec 2013 12:38:37 -0500 Tom Ritter wrote: > AFAIK Optimizations that reduce round trips, including that one, are > very desirable for websites accessed over Tor. The communication with > a website uses TCP, SSL, and HTTP as normal, TCP acks, etc are still > needed and transported over SOCKS. So optimizations there will reduce > time to first byte for the website accessed over Tor, and with Tor's > increased latency, it's even more pronounced. Win. Kind of. Tor terminates TCP at each hop, so you don't gain much at the TCP level (though reducing round trips that span from the client to the destination are Good Things(TM)). Looking at what is linked, it's all configurations that need to be done on the destination, so none of the information is really all that specific to Tor. > But for TLS used in Tor itself, it's not as analogous. The analogous > optimization would be looking at the cell protocol and see if cells > are small enough to fit in the initial congestion window. I don't > know, but what I would look for is something like Alice sending cells > to Bob, but Bob can't reply to Alice's cells because Bob needs more > data, but Alice needs to hear Bob's ACK before sending the rest of > the data. This is defined in RFC3390 (though certain people *cough Google* want to increase this). Per the spec: "min (4*MSS, max (2*MSS, 4380 bytes))" Linux uses 512 for the MSS (unless PMTUD is enabled in which case it will use the cached value (IIRC, been a while since I looked at the code). Technically it can be slightly larger (536 bytes, see RFC 879), and with IPv6 this is even less of an issue since compliant hosts must be able to receive 1280 byte packets (MSS = 1220). Note that cwnd gets reset to 1*MSS on a timeout, which isn't great for Tor if the path in question has something that keeps PMTUD from working correctly. Personally I don't think this is useful to worry about since you've lost at the point where your RTO timer triggers from a performance standpoint (network conditions are atrocious to the point where you entirely skipped Fast Recovery). If people are really concerned about the initial startup latency that accompanies doing a TCP handshake (despite pre-built circuits), then I suggest looking into TCP Fast Open (https://tools.ietf.org/html/draft-ietf-tcpm-fastopen-05), and piggybacking the ClientHello/ServerHello in the SYN/SYN-ACK, assuming Tor does not do this already. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for testing/review: obfsclient
Hello all, For a few reasons I thought it would be useful to have an obfs3 client implementation that did not depend on python (primarily systems where building python is non-trivial, think cellphones). The end result is https://github.com/yawning/obfsclient It passes what little basic functionality testing I've done (I can browse the web with it), but could use another set of eyes on the code. Caveats: * The build process kind of sucks, since it starts off with "Edit the CMakeLists.txt". * liballium doesn't have a install target since I didn't get around to it, adding a bit more pain to the build process. Thanks in advance, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
obfsclient (https://github.com/yawning/obfsclient) now also supports the latest and greatest in pluggable transport technology in the form of ScrambleSuit. All 3 transports pass the "Can I watch youtube over it" test. My current TODO for this project is roughly: * Finish implementing the optional parts of ScrambleSuit that I skipped * Clean up the code * Clean up the build system * Add debug logging for people that don't want to attach a debugger to it when it breaks. Comments, Questions, Feedback appreciated! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Thu, 13 Feb 2014 14:06:39 +0100 Fabian Keil wrote: > Trying to build it on FreeBSD 11.0-CURRENT I get (after a couple > of other issues): FreeBSD has Clang as the default compiler right? I've been using GCC for development, sorry, I should have tested both. > fk@r500 ~/git/obfsclient $make obfsclient > [ 91%] Built target obfsclient_lib > [100%] Building CXX object src/CMakeFiles/obfsclient.dir/main.cc.o > In file included from /home/fk/git/obfsclient/src/main.cc:49: > /home/fk/git/obfsclient/src/schwanenlied/pt/scramblesuit/client.h:145:60: > error: implicit instantiation of undefined template > 'std::__1::array' ::std::array kHeaderLength + kMaxPayloadLength> decode_buf_; > ^ /usr/include/c++/v1/__tuple:69:60: note: template is declared here > template struct _LIBCPP_TYPE_VIS array; ^ > In file included from /home/fk/git/obfsclient/src/main.cc:49: > /home/fk/git/obfsclient/src/schwanenlied/pt/scramblesuit/client.h:64:14: > error: cannot initialize return object of type 'Socks5Server::Session > *' with an rvalue of type 'schwanenlied::pt::scramblesuit::Client *' > return new Client(base, sock, addr, addr_len); > ^~ 2 errors generated. I've installed Clang, so I locally fixed all the other minor issues[0] you probably encountered but I didn't encounter the last error, I think I know why it's unhappy and believe it's fixed. commit 581bb2ac42be529b7bb5f8617a3c362ac38e47f9 commit 218c86b501f897a6c6b6e0bd14bde9ada5488b5d commit 594caa7f36ae9f5a465324eda983b70c6289fcfb <- master Please let me know if it's still broken/if I've missed anything. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Fri, 14 Feb 2014 12:00:40 +0100
Fabian Keil wrote:
> Patch attached. Maybe client.cc should get its own #include, though.
Merged, it's fine to include there since some of the pts also use the
endian conversion macros.
> > Please let me know if it's still broken/if I've missed anything.
> from /home/fk/git/obfsclient/src/main.cc:49:
> /home/fk/git/obfsclient/src/schwanenlied/pt/scramblesuit/client.h:146:60:
> error: implicit instantiation of undefined template
> 'std::__1::array' ::std::array kHeaderLength + kMaxPayloadLength> decode_buf_;
> ^ /usr/include/c++/v1/__tuple:69:60: note: template is declared here
> template struct _LIBCPP_TYPE_VIS array; ^
This should also be fixed, left out #include in
scramblesuit/client.h.
> In file included from /home/fk/git/obfsclient/src/main.cc:49:
> /home/fk/git/obfsclient/src/schwanenlied/pt/scramblesuit/client.h:64:14:
> error: static_cast from 'schwanenlied::pt::scramblesuit::Client *' to
> 'Socks5Server::Session *' is not allowed return
> static_cast(new Client(base, sock, addr,
> ^~~~ 2
> errors generated. *** Error code 1 [...]
Argh. Ok, I think I know what the issue is, although it builds fine
with:
somme :: Development/obfsclient/build ‹master*› % clang --version
clang version 3.4 (tags/RELEASE_34/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Please try the attached patch and let me know if it's *still* broken.
If it works, I'll merge the change.
On a side note, tip of tree requires updating liballium since I
switched both of liballium and obfsclient to auto[conf/make]/libtool.
Hopefully the build process is less rage inducing now.
Apologies in advance for the inconvenience, and thanks for the changes
and your patience.
--
Yawning Angel
diff --git a/src/schwanenlied/pt/obfs2/client.cc b/src/schwanenlied/pt/obfs2/client.cc
index 57daff4..0b567cc 100644
--- a/src/schwanenlied/pt/obfs2/client.cc
+++ b/src/schwanenlied/pt/obfs2/client.cc
@@ -46,6 +46,14 @@ namespace schwanenlied {
namespace pt {
namespace obfs2 {
+Socks5Server::Session* Client::SessionFactory::create_session(struct event_base* base,
+ const evutil_socket_t sock,
+ const struct sockaddr* addr,
+ const int addr_len) {
+ return static_cast(new Client(base, sock, addr,
+addr_len));
+}
+
void Client::on_outgoing_connected() {
static constexpr ::std::array init_mac_key = { {
'I', 'n', 'i', 't', 'i', 'a', 't', 'o', 'r', ' ',
diff --git a/src/schwanenlied/pt/obfs2/client.h b/src/schwanenlied/pt/obfs2/client.h
index 7528d94..0c76df6 100644
--- a/src/schwanenlied/pt/obfs2/client.h
+++ b/src/schwanenlied/pt/obfs2/client.h
@@ -60,10 +60,7 @@ class Client : public Socks5Server::Session {
Socks5Server::Session* create_session(struct event_base* base,
const evutil_socket_t sock,
const struct sockaddr *addr,
- const int addr_len) override {
- return static_cast(new Client(base, sock, addr,
-addr_len));
-}
+ const int addr_len) override;
};
Client(struct event_base* base,
diff --git a/src/schwanenlied/pt/obfs3/client.cc b/src/schwanenlied/pt/obfs3/client.cc
index d98f3ec..eefcb39 100644
--- a/src/schwanenlied/pt/obfs3/client.cc
+++ b/src/schwanenlied/pt/obfs3/client.cc
@@ -41,6 +41,14 @@ namespace schwanenlied {
namespace pt {
namespace obfs3 {
+Socks5Server::Session* Client::SessionFactory::create_session(struct event_base* base,
+ const evutil_socket_t sock,
+ const struct sockaddr* addr,
+ const int addr_len) {
+ return static_cast(new Client(base, sock, addr,
+addr_len));
+}
+
void Client::on_outgoing_connected() {
SL_ASSERT(state_ == State::kCONNECTING);
diff --git a/src/schwanenlied/pt/obfs3/client.h b/src/schwanenlied/pt/obfs3/client.h
index d7a230c..86d3390 100644
--- a/src/schwanenlied/pt/obfs3/client.h
+++ b/src/schwanenlied/pt/obfs3/client.h
@@ -62,10 +62,7 @@ class Client : public Socks5Server::Session {
Socks5Server::Session* create_session(struct event_base* base,
const evutil_socket_t
Re: [tor-dev] Call for testing/review: obfsclient
On Fri, 14 Feb 2014 16:43:00 +0100
Fabian Keil wrote:
> Yawning Angel wrote:
> It's already fixed in 1e25c55ba54 without the patch.
Yay.
> > On a side note, tip of tree requires updating liballium since I
> > switched both of liballium and obfsclient to
> > auto[conf/make]/libtool. Hopefully the build process is less rage
> > inducing now.
>
> It is for me. With the attached patches it builds on FreeBSD.
I'll merge them, thanks!
> The "#if 0" patch is just FYI, I'm sure a better solution is
> possible, but it wasn't immediately obvious to me what the
> pragmas are good for.
Hmm. It should have suppressed the warning that caused build failure,
but since my use of gtest never uses those, I'll just go with "#if 0"ing
it out.
> ./obfsclient_test dumps core:
> Core was generated by `obfsclient_test'.
> Program terminated with signal 10, Bus error.
> #0 0x004090c6 in
> schwanenlied::crypto::Ctr 16ul> >::process (this=0x7fffd4f8, buf=0x433c31
> 16ul>
> >
> 16ul> >"\301\276\342.@\237\226\351=~\021s\223\027*\207Ma\221\266
> 16ul>
> >\343&\033\357hd\231\r\266\316\256-\212W\036\003\254\234\236\267o\254E\257\216Q\230\006\366kyp\375\377\206\027\030{\271\377\375\377\060\310\034F\243\\\344\021\345\373\301\031\032\nR\357Z\344\337>\333\325\323^[O\t\002\r\260>\253\366\237$E\337O\233\027\255+A{\346l7\020\036\003\035\332/\276\003\321y!p\240\363",
> 16ul> >len=, out=)
> 16ul> >at ./src/schwanenlied/crypto/ctr.h:165 165 *out++
> 16ul> >= (*buf++)^ block_[offset_];
> (gdb) p offset_
> $1 = 11330806256049838041
What the. Ok. I'll look at that, though it is a "this should never
happen" sort of situation. I think I'll end up setting up a FreeBSD VM
since my FreeBSD box is on 9.1p10.
> I didn't look into this or test obfsclient yet, but intend
> to do so in the next couple of days.
If the test case is failing, it will probably dump core unfortunately.
I'll look into it as well.
Thanks for the assistance and patches!
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Fri, 14 Feb 2014 16:17:59 + Yawning Angel wrote: > What the. Ok. I'll look at that, though it is a "this should never > happen" sort of situation. I think I'll end up setting up a FreeBSD VM > since my FreeBSD box is on 9.1p10. Fixed in commit 600af0991cd3ec66d45399a9496186ae58ab7ace The unit tests passes on my 10.0-RELEASE VM. I'm going to install tor on the box shortly and give obfsclient a whirl. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Mon, 17 Feb 2014 15:39:07 +0100 Fabian Keil wrote: > Were you able to build it on your FreeBSD 9.1p10 system using > gcc? Not yet, I've been working on adding support for logging. I will address the GCC build issues when I'm done working on that. The system gcc on 9.1p10 is ancient (4.2.1), and does not support C++11, so I would have to install gcc from ports. I have somewhat mixed feelings about working around compiler bugs[0], but as of this date, gcc 4.7.x is probably still far too common to not support. Anything earlier than that start to run into more C++11 compliance problems. Looking at the rest of the log: * 'to_string' is not a member of 'std' -> the file needs #include * invalid operands of types 'int' and 'void' to binary 'operator!=' -> OpenSSL changed the function prototypes for the hmac routines. The code is correct for modern OpenSSL, but it looks like FreeBSD-9.2 ships with 0.9.x. I'll add a bunch of #ifdefs to do the right thing.) Looking at the patches: * Patch 1 tramples over my most recent change to main.cc, will fix when merging. * Instead of errno.h, cerrno is more appropriate, the constants should use the std namespace ones as well, will fix when merging. Thanks again for the patches, -- Yawning Angel [0]: [C++11] <:: is incorrectly treated as digraph <: followed by colon (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526) signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Mon, 17 Feb 2014 19:34:36 + Yawning Angel wrote: > I will address the GCC build issues when I'm done working on that. > The system gcc on 9.1p10 is ancient (4.2.1), and does not support > C++11, so I would have to install gcc from ports. I haven't installed gcc on my FreeBSD 9 box (or setup a 9.2 VM), but with gcc47 from ports, it builds on FreeBSD 10 with tip of tree. I'm fairly sure I put the correct ifdefs in to handle the older OpenSSL interface as well, so I don't anticipate further problems. Relevant changes: * Logging was broken -> 6de5dbdb283da9afb0ba0020c17254945821f88e * "<::" lexer bug -> 9b0dbf0197f0fa3e3ff991202bf0977452c3d000 * std::to_string missing -> 1fe7ad18d0bfac52418e2991511bb2aaa6abc9bf * added casts -> 2a84ce036121f959ba553076986b248c2a873e47 * OpenSSL interface -> 39e1dd27000b6aecb074c55afaafab58b86e933a Note: The logging library I'm using supposedly ICEs with gcc 4.6, and I'm not overly inclined to support anything pre-4.7.x. The OpenSSL interface change is current master. I'm not sure if I'm quite ready to tag this as 0.0.1 yet, I kind of want to add the optional ScrambleSuit features that I skipped, but since the pt isn't quite production yet (any day now), maybe it's ok. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient
On Wed, 19 Feb 2014 13:52:01 +0100 Fabian Keil wrote: > It also builds on 9.2 and 8.4 now: > https://redports.org/buildarchive/20140218142926-87456/ > (The failures on EXP1 and QATty are unrelated) Looks like the tests are SIGSEGVing on 9.2/8.4, I replicated the issue, and pushed a fix (7f123275d95ed8a95f15c0a75bd4e9ca241bee93). On my 9.2-RELEASE vm, the tests and obfsclient binary run now, and I made sure it still builds on the 10.0-RELEASE vm. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] [draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
Hello all, To address bug #10671: "Pluggable Transports: Improve method of transferring parameters to client-side transports", I submit the enclosed proposal for consideration. --- Begin proposal body --- Filename: xxx-pt-socks5-extensions.txt Title: Pluggable transport SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft 0. Abstract We propose extending the SOCKS5 protocol when communicating with pluggable transports to allow passing more per-bridge meta-data to the transport and returning more meaningful connection failure response codes back to Tor. 1. Introduction To allow for more sophisticated pluggable transports, it would be useful to support more than 510 bytes of per-connection data, while using the SOCKS5 pluggable transport interface. Additionally as pluggable transports increase in sophistication, it is useful for the pluggable transport to be able to return well defined errors back to Tor if the connection establishment fails. 2. Proposal 2.1. Tor Pluggable Transport Username/Password Authentication We introduce a new authentication method to the SOCKS5 protocol based on the existing RFC 1929 Username/Password Authentication that pluggable SHOULD support. The METHOD number to be returned to indicate support for or select this method is X'80', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. Tor will send a Username/Password/Extended Data request: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Username Len | +---+---+ \ Username\ / ... / \ (Username Len bytes) \ +---+---+ | Password Len | \ +---+ / \ Password\ / ... / \ (Password Len bytes) \ +---+---+ | Extended Data Len | +---+---+ \ Extended Data \ / ... / \ (Extended Data Len bytes) \ +---+---+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Username Len: 8 bits (unsigned integer) This field specifies the length of the Username field in bytes. It MAY be X'00', in which case the Username field is omitted. Username: variable length, optional The Username to use when authenticating. Password Len: 8 bits (unsigned integer) This field specifies the length of the Password field in bytes. It MAY be X'00', in which case the Password field is omitted. Password: variable length, optional The Password to use when authenticating. Extended Data Len: 16 bits (unsigned integer) This field specifies the length of the Extended Data field in bytes. It MAY be X'', in which case the Extended Data field is omitted. The Extended Data Len field MUST be transmitted in network byte order. The pluggable transport verifies the supplied Username, Password, and Extended Data and sends the following response: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version|Status | +---+---+ Version: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. Status: 8 bits (unsigned integer) This field specifies the status of the authentication request. A Status of X'00' indicates 'success'. If the pluggable transport returns a 'failure' (Status value other than X'00'), it MUST close the connection. 2.2. Tor Pluggable Transport SOCKS5 Reply Codes We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 reply message. Where: * X'F0' Temporary failure, retry immediately Pluggable transports SHOULD return this status code if the connection attempt failed, but the pluggable transport believes that subsequent connections with the same parameters are likely to succeed. Example: The ScrambleSuit Session Ticket handshake failed, but reconnecting is likely to succeed as it will use the UniformDH handshake. * X'F1' Pluggable transport protocol failure, invalid bridge Pluggable transports MUST return this status code
Re: [tor-dev] [draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
On Tue, 25 Feb 2014 19:42:51 + George Kadianakis wrote: > > Version: 8 bits (unsigned integer) > > > >This field specifies the version of the authentication > > method. It MUST be set to X'01'. > > > > How is the client-side version field supposed to be used? For example, > if the client doesn't support the version that the server proposed, is > it supposed to fail with a non-zero Status value, and set the Version > to the version it supports (doesn't sound like a great idea tbh)? > > Or is it always supposed to be the same version that the server > proposed? The latter. The client sends a version field as part of the request, the server either echos it in the response, or drops the connection (unsupported auth version). > > 2.2. Tor Pluggable Transport SOCKS5 Reply Codes > > > >We introduce the following additional SOCKS5 reply codes to be > > sent in the REP field of a SOCKS5 reply message. > > > > Hm, this looks like a useful feature but requires some engineering > effort. > > For example, with the current obfsproxy/Twisted codebase, obfsproxy > receives the SOCKS request, connect()s to the destination, and if the > connect succeeds it sends a positive SOCKS reply to the SOCKS > server. Then, only when obfsproxy has received the first > application-layer data from Tor, it performs the scramblesuit/obfs3 > handshake. > > So with the current codebase, obfsproxy wouldn't know whether to send > 'F0' back to the server at the time of the SOCKS handshake. Changing > this would be possible but it would require a few changes in the > Twisted and obfsproxy networking logic. *nods*. All of that code has to be touched when obfsproxy gets a SOCKS5 listener anyway, so I don't see that as being a huge blocker. For the record, obfsclient delays sending a SOCKS5 response till after the handshake succeeds. I personally view sending a successful SOCKS5 reply to indicate to the client (tor) that "If you send data, it will get relayed", which isn't necessarily the case in the current obfsproxy model as you described it. obfsproxy's behavior probably should be changed to sending the response post handshake regardless. > Also, the transport author would have to know whether an error is > retryable or not, and raise the appropriate exception (or something). > > I wonder if we have enough use cases for the 'F0' return value to make > this worth implementing. Perhaps not now, but moving forward, I think differentiating between "the connection failed because of transient reasons" vs "The bridge is invalid/your connection is getting MITMed/etc" is important. For ScrambleSuit, with a deferred SOCSK5 response it's also possible to hold the SOCKS5 connection open if the Session Ticket handshake fails, and reopen the outgoing connection and try UniformDH, but I believe that would require more code than "send back a different response code and let tor decide what to do". Thanks, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [draft]: Proposal xxx: Pluggable transport SOCKS5 extensions
On Tue, 25 Feb 2014 22:30:06 +0100 "Fabio Pietrosanti (naif)" wrote: > Il 2/25/14, 11:15 AM, Yawning Angel ha scritto: > > Hello all, > > > > To address bug #10671: "Pluggable Transports: Improve method of > > transferring parameters to client-side transports", I submit the > > enclosed proposal for consideration. > Please consider integrating within SOCKS protocol related extension > proposals also the ones needes by Tor2web described at > https://trac.torproject.org/projects/tor/ticket/6031 Skimming the ticket, it looks like the extensions discussed there are orthogonal to what this proposal is aimed at. To be specific, this proposal is aimed at the SOCKS server that is run in a pluggable transport binary (obfsproxy, obfsclient, and others), with tor acting as the SOCKS client. While there may be other possible uses for the extended authentication mechanism or response codes (In particular, it could be useful for the Tor Browser to pass out of band data on a per connection basis to Tor), use in such contexts should probably be discussed separately, as design considerations that apply when we do not control and define both the client and server side of the link start to apply. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for testing/review: obfsclient-0.0.1rc1
Hello all, Due to a moment of surprising productivity, I have a release candidate of obfsclient available now. For those of you that missed the last thread regarding this, it is a C++11 client implementation of obfs2, obfs3, and ScrambleSuit that works as a drop in replacement for obfsproxy. Notable changes since the last time I posted: * ScrambleSuit code is now up to spec. * Packet length and Inter-packet Arrival Times are randomized. * Session Ticket Handshake is supported. * obfsclient will give up on handshaking after 60 seconds. * Needed because obfsproxy servers do not close the connection for certain protocols. * SIGINT is hooked and handled per the pt spec. * Some dumb bugs were fixed. Places where obfsclient behaves differently from obfsproxy: * Current production obfsproxy releases disable Scramblesuit IAT obfuscation. obfsclient also uses slightly different logic for sending with it enabled. (May change for final release) * WELL512 is used instead of MT for the ScrambleSuit packet length obfuscation. * obfsclient gives up when the handshaking stalls. * The SOCKS5 response is sent post obfuscation protocol handshake instead of before. * obfsclient uses SOCKS5 instead of SOCKS4. * The ScrambleSuit Session Ticket store is a plain text file. Things that are not bugs: * ScrambleSuit requires the client side tor to be 0.2.5.x. * The code will not build if the compiler is from the stone age. To what I assume will be a sigh of relief from Fabian, I tested on FreeBSD as well this time. The systems used for testing are in the release notes. Where: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1-rc1 Thanks in advance, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
Hello all, Based on feedback from nickm/arma, I have extended the proposal to also cover Tor's SOCKS port, including response codes related to hidden service status. Additionally, instead of having a username/password field pre-defined, the extended authentication method has been generalized to contain key/value pairs for extra flexibility in the future. Questions, comments, feedback appreciated as always, -- Yawning Angel --- Begin proposal body --- Filename: xxx-further-socks5-extensions.txt Title: Further SOCKS5 extensions Author: Yawning Angel Created: 25-Feb-2014 Status: Draft 0. Abstract We propose extending the SOCKS5 protocol to allow passing more per-session metadata, and to allow returning more meaningful reponse failure codes back to the client. 1. Introduction The SOCKS5 protocol is used by Tor both as the primary interface for applications to transfer data, and as the interface by which Tor communicates with pluggable transport implementations. While the current specifications allow for passing a limited amount of per-session metadata via hijacking the Username/Password authentication method fields, this solution is limited in that the amount of payload that can be conveyed is restricted to 510 bytes, does not allow the SOCKS server to return a response, and precludes using authentication on the SOCKS port. The first part of this proposal defines a new authentication method to overcome both of these limitations. The second part of this proposal defines a range of SOCKS5 response codes that can be used to signal Tor specific error conditions when processing SOCKS requests. 2. Proposal 2.1. Tor Extended SOCKS5 Authentication We introduce a new authentication method to the SOCKS5 protocol. The METHOD number to be returned to indicate support for or select this method is X'97', which belongs to the "RESERVED FOR PRIVATE METHODS" range in RFC 1928. After the authentication method has been negotiated following the standard SOCKS5 protocol, the actual authentication phase begins. The initiator will send an Extended Authentication request: ++--+---+-+---+-+--- |VER | NR PAIRS | KLEN1 |KEY1 | VLEN1 | VALUE1| ... ++--+---+-+---+-+--- | 1 |2 | 2 | KLEN1 bytes | 2 | VLEN1 bytes | ... ++--+---+-+---+-+--- VER: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. NR PAIRS: 16 bits (unsigned integer) This field specifies the number of key/value pairs to follow. The NR PAIRS field MUST be transmitted in network byte order. KLEN: 16 bits (unsigned integer) This field specifies the length of the key in bytes. It MUST be transmitted in network byte order, and MUST be greater than 0. KEY: variable length This field contains the key associated with the subsequent VALUE field as an ASCII string, without a NULL terminator. VLEN: 16 bits (unsigned integer) This field specifies the length of the value in bytes. It MUST be tramsmitted in network byte order. It MAY be X'', in which case the corresponding VALUE field is omitted. VALUE: variable length, optional The value corresponding to the KEY. The responder will verify the contents of the Extended Authentication request and send the followint response: +++--+---+-+---+-+--- |VER | STATUS | NR PAIRS | KLEN1 |KEY1 | VLEN1 | VALUE1| ... +++--+---+-+---+-+--- | 1 | 1|2 | 2 | KLEN1 bytes | 2 | VLEN1 bytes | ... +++--+---+-+---+-+--- VER: 8 bits (unsigned integer) This field specifies the version of the authentication method. It MUST be set to X'01'. STATUS: 8 bits (unsigned integer) The status of the Extended Authentication request where: * X'00' SUCCESS * X'01' AUTHENTICATION FAILED * X'02' INVALID ARGUMENTS If a server sends a response indicating failure (STATUS value other than X'00') it MUST close the connection. NR PAIRS: 16 bits (unsigned integer) This field specifies the number of key/value pairs to follow. The NR PAIRS field MUST be transmitted in network byte order. KLEN: 16 bits (unsigned integer) This field specifies the length of the key in bytes. It MUST be transmitted in network byte order, and MUST be greater than 0. KEY: variable length This field contai
Re: [tor-dev] Call for testing/review: obfsclient-0.0.1rc2
Hello all, I have a new release candidate of obfsclient available now. Notable changes since 0.0.1rc1: * Use OpenSSL's CSPRNG instead of arc4random rng from libevent * Use a CTR_DRBG instead of WELL512 * ScrambleSuit session tickets saved to disk also include a timestamp * ScrambleSuit is better about discarding handshake data for sessions that authenticate * ScrambleSuit IAT obfuscation is disabled by default (--enable-scramblesuit-iat) * The SOCKS5 TTL Expired code is sent when the handshake takes too long instead of abruptly closing the session * The Base32 decoder now accepts lower case input, and also will attempt to correct commonly mistyped characters (0,1,8) * Fixed a bug which would cause rare assertion when using obfs2 Known issues: * ScrambleSuit session ticket handshakes vs some of the bridges out there will fail (not a obfsclient bug). I believe the bridge that phw posted to tor-talk is running updated code with this issue fixed. Assuming nothing is broken, this will most likely become v0.0.1, though I may end up disabling Session Ticket handshakes. Where: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1-rc2 Questions, comments, feedback appreciated! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Combining obfsproxy+scramblesuit with OpenVPN
On Wed, 05 Mar 2014 15:08:06 +0200 irregula...@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=" 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 " as a command line option. Regards, -- Yawning Angel [0]: https://github.com/Yawning/obfsproxy/tree/socks5-listener signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoC - Profile UDP transport protocols
On Thu, 6 Mar 2014 09:55:42 -0300 Danilo Carvalho wrote: > I am interested in profiling the UDP transport protocols, I think > using a different underlying protocol could significantly improve > Tor's performance and I would like to be part of that. https://research.torproject.org/techreports/libutp-2013-10-30.pdf It's sort of been done. The project ended before they could get meaningful performance numbers, but an educated guess on my part says that they wouldn't have been that great in the presence of competing traffic, but I have not busted out ns-3 or anything so I could very well be wrong here. I also don't really see how merely switching to UDP would be a net gain performance wise, since currently any suitable UDP based transport needs to implement a lot of TCP like features (reliable + in-order delivery, and congestion control). Don't let my skepticism dissuade you if you're determined to do something like this, because there is potential for a lot of interesting research, but the scope of the project may be bigger than a summer one (Although reviving the libutp code and actually getting performance numbers may be something that is doable). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Combining obfsproxy+scramblesuit with OpenVPN
On Thu, 06 Mar 2014 19:22:16 +0200 irregulator 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: > > Still when openvpn client connects to localhost: 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: "" 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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
Sorry this response took so long. I've been kind of busy. On Sat, 01 Mar 2014 13:57:34 +0100 "Sebastian G. " wrote: > To me it is clear that the two are messed up, but I'm not sure what's > the correct order. Indeed. Since there isn't a clear advantage to going one way or another for this, 0xE0 should be not found, 0xE1 should be not available. Looking at some of the stuff nickm added: * What should a client if it gets a value here it does not recognize? (wrt status code in the response from the server) All response codes that are not 0x00 are defined as a failure state, and the server is required to drop the connection after sending one. I'm not sure client behavior needs to be specified here. * What do these do? What is their behavior? Are they client-only? (wrt The USERNAME/PASSWD keys that are reserved) My intention was to reserve keys required to add support for doing RFC1929 style authentication if we desire in the future that is separate from whatever other keys we decide to use in the future. (As a "Yes, these actually for a username/password, don't abuse them for other things"). Client-only, unless reserving this isn't useful (It might not be, there was some grumbling about one day supporting authentication again). "PASSWD" should be "PASSWORD" instead here I guess (or "USERNAME" should be "UNAME" to be consistent with RFC1929). * What should a client if it gets a value here it does not recognize? (wrt Key/Value pairs from the server contained in the response) There's three options here, "ignore", "drop the connection" or, "client sends Version/Status after receiving the response". I believe that the 3rd option is the best. "Ignore" may cause problems if we send important things back in the response (nickm asked for this to be added so I did, but I'm not clear on what it will be used for). "Drop" is not forward compatible. * Should we recommend any namespace conventions for these? Yes, probably. I have no strong preference for what sort of convention is used. "tor.streamIsolation", "scramblesuit.password" etc? * Actually, should this perhaps be controlled by additional KEY? (re: Response codes). I don't think this is necessary. Explicitly specifying that after sending/receiving a status code that is not 0x00 (Defined as Success in RFC1928, the server/client MUST drop the connection should be sufficient? (I'm not sure either) Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
On Fri, 7 Mar 2014 10:45:14 -0500 David Goulet wrote: > Quoting rfc1928: > > "When a reply (REP value other than X'00') indicates a failure, the > SOCKS server MUST terminate the TCP connection shortly after sending > the reply. This must be no more than 10 seconds after detecting the > condition that caused a failure." > > So what about simply terminating the connection which I guess would > be a fourth option "Close" ? This is for the auth status, which is different from the RFC1928 REP. But as you point out, the behavior set down for the server is the same as when a non 0x00 REP value is sent. Client behavior is undefined, but since the server will close, it doesn't matter (We could be the better spec and state that clients MUST close). > > * What should a client if it gets a value here it does not > > recognize? (wrt Key/Value pairs from the server contained in the > > response) > > > >There's three options here, "ignore", "drop the connection" or, > >"client sends Version/Status after receiving the response". I > >believe that the 3rd option is the best. "Ignore" may cause > >problems if we send important things back in the response (nickm > >asked for this to be added so I did, but I'm not clear on what it > >will be used for). "Drop" is not forward compatible. > > Same as above. Hmm, ok. I thought it would be nice to allow older clients to interoperate with newer servers that potentially send back more information in the response, but I suppose that isn't required (when we add more key/value pairs that get sent in the response, we can define them to only be sent if the client requests them"). So Close/Drop sounds reasonable here. > > * Should we recommend any namespace conventions for these? > > > >Yes, probably. I have no strong preference for what sort of > >convention is used. "tor.streamIsolation", > > "scramblesuit.password" etc? > > Would this be *appended* to a client given key like for instance > "myapp1:tor.streamIsolation" or it would be a hardcoded string key > that the client needs to use in order to enable the "feature". I was thinking the latter "myProtocol.myConfigSetting". So for example, every TBB connection would send "tor.sessionIsolation"/"Some Session ID", every ScrambleSuit pt client would send "scramblesuit.password"/"Base32 encoded k_B" etc. This model makes arg handling with nested socks client/server pairs fairly easy as well (Think Tor->ScrambleSuit->Meek as a example), since each step can strip off the args it handled and forward the rest to the next SOCKS proxy in the chain. Not sure if the inability to nest multiple invocations of the same protocol is a problem (Tor->ScrambleSuit->obfs3->ScrambleSuit would not work because 2 "scramblesuit.password" keys need to be sent). Back to the forward compatibility thing, we could also define "tor.optional", for things that can safely be ignored if not understood. Not sure if such things exist (most of the things I can think of for key/value pairs are mandatory). > I can see one use for having custom keys along with a name space which > is to having a way to identify the SOCKS connection on the control > port for knowing in which country the exit is for instance (or > whatever info you need). The source port can be use for that but for > an external client not knowing it, it might be interesting to be able > to ask the control port "What's the exit node of SOCKS > connection". Is a custom key needed for this? The query you used as an example could just as easily be done without any SOCKS extensions as "What's the exit node of SOCKS connection" couldn't it? One final open question, are there any other status codes that people think should be defined beyond the HS ones and the PT ones? Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
On Sat, 8 Mar 2014 09:08:06 -0500 David Goulet wrote: [snippity] > > > I can see one use for having custom keys along with a name space > > > which is to having a way to identify the SOCKS connection on the > > > control port for knowing in which country the exit is for > > > instance (or whatever info you need). The source port can be use > > > for that but for an external client not knowing it, it might be > > > interesting to be able to ask the control port "What's the exit > > > node of SOCKS connection". > > > > Is a custom key needed for this? The query you used as an example > > could just as easily be done without any SOCKS extensions as "What's > > the exit node of SOCKS connection" > > couldn't it? > > That would work (and works) if you know the source port and for that > you basically need to be the client who made that request unless you > happily parse netstat :P. So here is an exemple, I have 5 differents > apps using the SOCKSPort, I might be interested in asking tor daemon > what's the exit point of my app number 3? That could be interesting to > ask the control port something like "Give me exit relay country for > SOCKS port myapp3.insert.namespace.here". > > Not sure that it's or could be possible but maybe just something to > think about. Ah I see. I'd feel better about the namespace and "how easy would this be to implement" if this sort of thing was done via a separate key/value pair. So in addition to the keys I specified we could reserve "appID" as a key for this (Eg: "appid"/"tbb", "timb", etc). With prefixing the keys, the arg processing code for everything needs to be appid aware (optional thing should be optional, and easy to ignore). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Combining obfsproxy+scramblesuit with OpenVPN
On Mon, 10 Mar 2014 03:27:12 +0200 irregula...@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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Combining obfsproxy+scramblesuit with OpenVPN
On Mon, 10 Mar 2014 01:57:11 + Yawning Angel 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/7474f1acfc5d296289f3f65566184ea699e1896c 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 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GoSC - Website Fingerprinting project
On Wed, 12 Mar 2014 16:25:20 -0400 Roger Dingledine wrote: > It seems like some of the approaches would best be done inside Tor (as > modifications to the Tor program), and some of them would best be done > in a separate pluggable transport? Or should they all be done in a PT? > Can the bandwidth shaping in Scramblesuit (obfsproxy) be used as a > building block here? This depends on what all wants to be tested. Basing it off ScrambleSuit would pull in a lot of code that's probably unnecessary. If it were me doing this, I would write a simple transport that has hooks for adjusting the packet size/inter packet timing. Assuming a basic familiarity with python (bonus points for Twisted), this would be about an afternoon worth of code (if that), and from there real development on different padding strategies could be researched. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for testing/review: obfsclient-0.0.1
Hello all, I just tagged the obfsclient v0.0.1 (Release) Download at: https://github.com/Yawning/obfsclient/releases/tag/v0.0.1 Major changes since 0.0.1-rc2: * Invalid padding lengths in obfs3/ScrambleSuit handshakes are now correctly handled. * Handshake timeout is now set to a random interval between 60 and 120 seconds. * The ScrambleSuit probability distributions are now closer to what obfsproxy generates. * "--version" will now cause obfsclient to print the version and exit. * Various code cleanups. Some notes about ScrambleSuit: * I reverted the "workaround" I had for bug #11100, so Session Ticket handshakes to bridges running obfsproxy 0.2.6 will fail if they have been running long enough to trigger the bug condition. * Actual protocol behavior is closer to obfsproxy than my previous releases, but still not identical to 0.2.7. the next obfsproxy release will close the difference further. Hopefully it is of some use to people. Special thanks to Fabian Keil for help testing and fixing the various release candidates. Questions, comments, feedback appreciated as always, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for testing/review: obfsclient-0.0.1
On Mon, 17 Mar 2014 13:26:25 +0100 Fabian Keil wrote: > My pleasure. Unfortunately I apparently missed one issue on FreeBSD > 8.4: > https://redports.org/~fk/20140317110212-48719-187908/obfsclient-0.0.1.log Ah, that's a easy fix. FreeBSD 8.x's sys/cdefs.h doesn't define __STDC_LIMIT_MACROS when the compiler is using C++11, so the limit macros aren't getting defined when I pull in cstdint. Fixed in: 5ab2988bdd390cdf557b4fd971dcd64380dd8ab5 > When I tested rc2 with Redports the 8.4 build systems had > network problems and thus this might not be a new problem: > https://redports.org/buildarchive/20140302115957-67062/ It's code I changed for rc2. No biggie. I don't think that the build fixes for Darwin/FreeBSD warrant tagging 0.0.2 on their own, but it should be easy to work around in the port package (it's a minor tweak to CXXFLAGS if the host is < FreeBSD 9.1). Thanks! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Call for testing/review: obfsclient-0.0.2
Hello all, I just tagged obfsclient v0.0.2 (Release) Download at: https://github.com/Yawning/obfsclient/archive/v0.0.2.tar.gz This is mostly a bug fix release that addresses issues found in testing/actual use. The code is quite stable now, and I have been using it for all of my tor for approximately 2 weeks. Changes since 0.0.1: * Change the command line arguments to match the obfsproxy counterparts. This fixes issue #31. * Apply pushback between each side of the proxied connection to limit the amount of data that can be buffered. This fixes issue #3. * Use bufferevent_write_buffer to save allocating/copying in obfs2/obfs3. This fixes issue #24. * Fix assertions primarily seen on abrupt connection close by disabling all reads on transition into the various SOCKS5 FLUSHING states. * Cleaned up the logging, and log SOCKS5 assertions to the log file. * Send a TTL EXPIRED SOCKS5 error on connection timeouts. * Fixed an assertion that occurred if the outgoing connection immediately failed (Eg: Network interface being down). * Darwin build fixes, pointed out by Jeroen Massar. * FreeBSD 8.x/9.0 build fix, pointed out by Fabian Keil. NB: Darwin builds require using liballium from git and not 0.0.1, due to a minor code change to a embedded dependency. It is also entirely possible that I broke this again via changes made since then, but I don't use Darwin at all. Assuming there are no major bugs, I am hoping that 0.0.3 will be a feature release so the pace should be less hectic. Questions, comments, feedback appreciated as always, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] ideas/xxx-pluggable-transports-through-proxy.txt
Hello, The topic of routing pluggable transports through other proxys (SOCKS and HTTP CONNECT) has come up a few times recent, both as bug reports from users and as something that probably should be done to round out the pluggable transport concept since they will be included in the browser bundle by default. Relevant bugs: * #8402 - Tor should help its transport proxy use a proxy, if needed. * #8956 - obfsproxy should use a SOCKS proxy if Tor wants it to * #11409 - Obfsproxy through HTTP proxy There is one change that also needs to be made to the idea document (diff attached) that changes one of the return codes to be slightly more in line with the rest of the PT protocol chatter. As far as code support goes: * tor done, not merged, needs review by nickm or similar (branch linked from #8402). It *may* have rotted since it got triaged as a 0.2.6 thing right before I started working on this, but if that's the case I will update it as needed. * pyptlib, done not merged. Waiting on #8402. * obfsproxy, SOCKS4/5 done, not merged. HTTP CONNECT is a work in progress, needs the pyptlib changes. Regards, -- Yawning Angel From 3ad31e8727b46ef46b73d11764ca5fec15c5b57c Mon Sep 17 00:00:00 2001 From: Yawning Angel Date: Fri, 11 Apr 2014 06:12:32 + Subject: [PATCH 1/1] Change "PROXY true" to "PROXY DONE" for consistency. --- proposals/ideas/xxx-pluggable-transports-through-proxy.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt index 3fc7754..e03a6b9 100644 --- a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt +++ b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt @@ -69,7 +69,7 @@ Specifications: Tor Pluggable Transport communication If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set, it attempts connecting to it. On - success it writes to stdout: "PROXY true". + success it writes to stdout: "PROXY DONE". On failure it writes: "PROXY-ERROR ". If Tor does not read a PROXY line or it reads a PROXY-ERROR line -- 1.9.2 signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfsproxy getting scramblesuit password from file in unmanaged mode
On Tue, 20 May 2014 18:25:46 +0300 irregula...@riseup.net wrote: > Hey all, > > when running obfsproxy with scramblesuit in unmanaged mode (e.g. to > obfuscate non-Tor traffic) the UniformDH password is passed in command > line like this: > > obfsproxy scramblesuit --password=W3ECD5GOYU5AAW4G35GSH5QXIHSRBU2X > > The problem with this is that the password is visible in the system's > process list. > > Do you think it would make sense to add an argument like > "--password-file", so as scramblesuit can fetch the password from a > file? Any caveats? > > Although this is not related to the Tor ecosystem, i think it would be > useful. Indeed, we have a bug open for this. https://trac.torproject.org/projects/tor/ticket/8040 I think using `setproctitle` to modify what appears on the system process list may be a better general solution (and it would let us do things like showing `obfsproxy: obfs3,scramblesuit` in the managed use case as well which I think is cute, if not massively useful. As an added bonus it is a general solution that's more futureproof. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: obfs4 (Name not final)
Hello, The people that have been following Pluggable Transport development may know that I have been working on something tentatively called "obfs4" recently. It's rapidly approaching the point where I would like to open it up for review and feedback, hence the e-mail. A quick and dirty description would be: obfs4 is ScrambleSuit with djb crypto. Instead of obfs3 style UniformDH and CTR-AES256/HMAC-SHA256, obfs4 uses a combination of Curve25519, Elligator2, HMAC-SHA256, XSalsa20/Poly1305 and SipHash-2-4. The feature set offered by obfs4 is comparable to ScrambleSuit with the following differences (implementation specific changes are noted as such): * The key exchange is based on the ntor handshake, and thus authenticates the server to the client. Both obfs3 and ScrambleSuit depend on the encapsulated protocol to handle this on it's own. * obfs4 always does a full handshake. ScrambleSuit style session ticket handshakes are not supported. Even with Elligator2 mapping taken into account, the obfs4 handshake is significantly faster, so there is less of a need for this. * (Impl) obfs4proxy currently does not offer Inter-Arrival Time obfuscation, but this could easily be added if it is something that a lot of people want. It is worth noting that while obfsproxy and obfsclient both support IAT obfuscation, support for it is currently disabled by default as a performance tradeoff. * (Impl) obfs4proxy is currently written in golang. Neither a clear plus or minus, it does allow people to run bridges on reserved ports significantly easier, is probably faster (native code, can use multiple cores for most things), but is more annoying to build and results in rather large binaries (the go runtime is statically linked). * (Impl) obfs4 supports a lot of the protocol improvements made to ScrambleSuit that are pending merge (See #11271, #11203). This difference is temporary. The code and a draft spec is at: https://github.com/Yawning/obfs4 Open questions: * Is the base design and my implementation sane? * Should obfs4proxy also have (disabled) IAT obfuscation? Adding it later will not require wire protocol changes. * The handshake length mimics ScrambleSuit in terms of maximum padding (< 1500 bytes). Should this be increased to be similar to obfs3 (~8k of maximum padding)? The server side cost for this shouldn't be that high. * Is this different enough from ScrambleSuit to be worth deploying? I would be ok with this ending up as "just a research project" and shelving it if the consensus is otherwise. * Should I have named it ScrambleSuit 2? It's a direct descendant of ScrambleSuit and is an obfs derivative only in name at this point. Future plans: * Implement suggestions/improve the code/fix bugs/write more unit tests. * Improve goptlib. * If this is deployed in meaningful amounts, support it in obfsclient. For the extremely brave, I am running a test bridge with the most recent snapshot of the code: UseBridges 1 ClientTransportPlugin obfs4 exec /path/to/obfs4proxy # Bridge line of doom, all one line. Bridge obfs4 178.209.52.110:52810 67E72FF33D7D41BF11C569646A0A7B4B188340DF node-id=Z+cv8z19Qb8RxWlkagp7SxiDQN8= public-key=vm+w9k57aMIX/o+A9ef5C7o9xKEkhr7kRBj3N4etDn8= As with any PT that requires per-bridge arguments, this also requires tor-0.2.5.x. The node-id in this case happens to be my bridge's fingerprint, the public key is the long term key used to validate my bridge's identity and generate M_[C,S]/MAC in the handshake (The bridge line is a bit of a UI/UX disaster unless people are copy/pasting it). Getting either of them wrong will result in handshake failures and tor not bootstrapping. A few warnings: * The spec assumes familiarity with ntor, ScrambleSuit and NaCl's crypto_secretbox. * The wire protocol is not final and I *will* push builds to the bridge as I break backward compatibility without notifying people (It's been 0 days since a wire protocol change.). The test bridge will randomly be broken/rebooted/etc as I also use it for other things. * Development was done with go1.2.x, older versions of the runtime are not supported. * It would be a terrible idea to use obfs4proxy as anything other than a client at this point. Questions, comments, feedback all appreciated. -- Yawning Angel PS: I also wrote https://github.com/yawning/or-applet recently. It's even less supported/tested than obfs4 is (it is written only for my laptop), but some people may find it cute. signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfs4 (Name not final)
On Wed, 21 May 2014 12:22:46 + David Stainton wrote: > > obfs4 is ScrambleSuit with djb crypto. Instead of obfs3 style > > UniformDH and CTR-AES256/HMAC-SHA256, obfs4 uses a combination of > > Curve25519, Elligator2, HMAC-SHA256, XSalsa20/Poly1305 and > > SipHash-2-4. > > Elligator... cool! > > > * Development was done with go1.2.x, older versions of the runtime > > are not supported. > > Did you get your builds to work with the deterministic build system? Not yet. While it's important I'm sort of working under the assumption that it's mostly a solved problem as the scary build process can handle flashproxy and meek. I've been a bit more focused on getting the protocol design and implementation to a point where I feel generally good about it. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: obfs4 (Name not final)
On Fri, 23 May 2014 14:16:49 +0200 Philipp Winter wrote: [snippity] > > * Should obfs4proxy also have (disabled) IAT obfuscation? Adding > > it later will not require wire protocol changes. > > I don't think that inter-arrival times are a significant practical > threat at this point. In addition, it has a major impact on > throughput which is the reason why obfsproxy's ScrambleSuit ships > with the option being disabled. As you write, it shouldn't be a > problem to add IAT obfuscation later on if it turns out to be > important for some reason. I went and added the code last night, so it's there if needed (as a command line option). > > * The handshake length mimics ScrambleSuit in terms of maximum > >padding (< 1500 bytes). Should this be increased to be similar > > to obfs3 (~8k of maximum padding)? The server side cost for this > >shouldn't be that high. > > I'm not sure if sound decisions can be made without comprehensive > data showing how real-world protocols behave. ScrambleSuit's (and > perhaps also obfs3's) padding length was determined by gut feeling, > so ~8k might be fine as well. On the gut feeling of "bigger handshakes = more random *waves hands*", I went and jacked it up last night. More real world data would be nice. > > * Is this different enough from ScrambleSuit to be worth > > deploying? I would be ok with this ending up as "just a research > > project" and shelving it if the consensus is otherwise. > > While you're at it, there are some other things which might be worth > improving: > > - ScrambleSuit's framing mechanism is vulnerable to this attack: > <http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf> > In a nutshell, the receiver needs to decrypt the ScrambleSuit > header before it is able to verify the HMAC which makes it possible > for an attacker to tamper with the length fields. While there are > probably simpler attacks, it would be nice to have a fix for this > problem. I believe obfs4 does not have the plaintext recovery issue as the length field is separate from the AEAD construct (Though at present an adversary tampering with the length field is only caught by MAC errors). However I will go and implement randomizing the length on a out of bounds length value (as suggested in section 6 of the paper) to reduce the timing differential. From reading the paper, I do not believe that ScrambleSuit's vulnerability leads to plaintext recovery either as it uses CTR-AES and recovery is based off CBC-AES, though as the authors note, there may be other side channel hazards. > - We didn't push the idea of polymorphism very far. There are more > flow characteristics such as "packet directions", "total bytes sent", > or "total bytes received" which could be disguised in a systematic > fashion. While reasonable protection against traffic analysis is > tricky, we could at least decrease a classifier's accuracy a bit > more. Some ideas could be taken from this paper: > <http://arxiv.org/pdf/1401.6022v1.pdf> This is the sort of thing that mjuarez is looking into as part of GSOC. As long as a padding frame type is defined, incorporating the results of his research at a later date should be possible without changes to the wire protocol. Thanks for the feedback! -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] wfpadtools: comments about primitives
On Fri, 30 May 2014 17:42:39 +0100 George Kadianakis wrote: > Marc Juarez writes: > > > Hi all, > > > > I am a GSoC student working in a new PT for the development of > > future Website Fingerprinting countermeasures in Tor. > > > > The PT is not targeting any specific defense, but to link padding > > defenses in general. The idea is to implement a set of primitives > > that any link padding-based defense would benefit of. > > > > In this email I provide a more detailed description of these > > primitives and give a short update about their state. I forked the > > obfsproxy repo and made it publicly available in bitbucket: > > > > https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools. Excellent. > > I would appreciate comments from the Tor development community. I'm > > specially looking for advices that help me generalizing the padding > > module (padutils) and comments about the primitives I describe > > below. > > > > The envisaged primitives are: > > > > 1. A general padding class that provides methods to pad the link > > > > This part is almost finished. For that I reused the Scramblesuit's > > probdist and fifobuffer modules to buffer and flush data according > > to a given probability distribution. > > > > Using this class I have implemented a simple version of BuFLO > > (which is also included in the padutils module). > > > > Sounds reasonable. > > (BTW, we recently found that scramblesuit's genDistribution() function > in probdist.py does not generate a uniform distribution. You can see > this, since the way the prob distr is generated, its first element has > a mean value of 1/2 instead of 1/n. Yawning fixed this in obfs4 I > think, but it remains unfixed in scramblesuit.) https://github.com/Yawning/obfs4/commit/9fe9959c76c96ec3284f43c692cbb099230dcb73 That's an example of how to make it uniform. I'm not sure which behavior is better, real world data on what the packet distribution of non-Tor network protocols look like on the wire would be useful here. > [snip] > > 4. Implement the protocol's handshake. > > > > I took a look to the Scramblesuit's handshake.The handshake of this > > protocol would boil down to the negotiation of the parameters (e.g., > > probability distributions) for the padding. > > > > In the end, I think this handshake will need to be confidential > (encrypted) somehow. Otherwise, the adversary could read the > probability distributions and unwrap your padding layer more > easily. Or is this not in your threat model? Likewise, however (correct me if I'm wrong), this is an orthogonal problem. The vision I have currently is, when when we do obfs6 or whatever, that we would come up with our own unique and clever way to handle authentication and confidentiality and use wfpadtools internally. > > 5. Implement a flow control protocol > > > > This would adjust the padding parameters while running. The > > fifobuffer we are currently using helps queuing the messages but we > > will need an extra logic to detect congestion. It's a shame that SIOCOUTQ isn't portable, because checking the send socket buffer's size is one of the better ways to do this. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] wfpadtools: comments about primitives
On Fri, 30 May 2014 20:40:07 +0200 Marc Juarez wrote: > >> 4. Implement the protocol's handshake. > >> > >> I took a look to the Scramblesuit's handshake.The handshake of this > >> protocol would boil down to the negotiation of the parameters > >> (e.g., probability distributions) for the padding. > >> > > > > In the end, I think this handshake will need to be confidential > > (encrypted) somehow. Otherwise, the adversary could read the > > probability distributions and unwrap your padding layer more > > easily. Or is this not in your threat model? > > Yes, you're right. However, I think we shouldn't overlap too much with > Scramblesuit. I was thinking that Scramblesuit or obfs3 could be used > together with this PT. Actually this is a question I wanted to ask > you: can multiple PTs be used together? Except for the overhead of the > protocol headers I don't see any technical limitation. Not as well as we would like. Further improving our designs for combining PTs and adding an implementation is one of our GSOC projects this year though. My 0.02 dogecoin here would be to say "the PT combiner will fix it, so eventually we could do wfpadtools + obfs3/obfs4/scramblesuit/meek/fte and get the added defenses without (many? any?) code changes. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 and ntor (question wrt node_id)
On Mon, 02 Jun 2014 16:12:03 +0100
George Kadianakis wrote:
> Yep, that's what I gathered too.
>
> Unfortunately, the server-side obfs4 might not have access to its
> address/port (it normally knows that it has to bind to 0.0.0.0:,
> not the actual external IP address).
>
> So we were considering whether generating a random nodeid would be OK
> for security.
> Or even omitting the nodeid completely, and just using the public key
> B in its place (since \hat{B} is just used as an one-to-one map to a
> B) Or does this complicate the security proof?
Unless I'm horrifically mistaken, a random nodeid is fine as it is just
as arbitrary as the current node ID. Since there isn't any tight
coupling between pluggable transports and the remote bridges they
connect to, the bridge fingerprint currently in use is also a "random
nodeid", at least as far as obfs4 is concerned (The fact that it
coincidentally happens to be the bridge fingerprint has no effect on
the obfs4 protocol itself).
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] GSoc update #2 - Stegotorus security enhancement
On Mon, 23 Jun 2014 21:04:25 -0500 Noah Rahman wrote: > - implemented the Elligator handshake on a circuit level. I need to > look into implementing it on a connection level to add greater > security, as well as adding OCB encryption (does anyone know for sure > whether this is in OpenSSL now? I can't seem to find out) As far as I know, "no, it is not". Even if it were, depending on it to be present would probably be a bad idea as there are systems in the wild that ship older versions of OpenSSL. Rogaway's page has a link to Krovetz's implementation that can use OpenSSL for certain internals, it would probably be easiest to look at that, and use it if suitable. Out of curiosity, from what I have seen of the code, there's already code that uses GCM, I'm sort of curious as to why you believe OCB would be better. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] What little-t-tor bridge features/issues we should address?
On Mon, 14 Jul 2014 12:30:06 -0700 Kevin P Dyer wrote: (This is orthogonal to the bridge code, but since you asked...) > I would like to be able to bind to privileged ports when running a > PT-enabled bridge in managed mode --- will any changes to > little-t-tor be required for this feature? (Assuming Lenooks for the sake of discussion.) At the dev meeting I was talking to dgoulet about having tor do the appropriate work to preserve the CAP_NET_BIND_SERVICE when dropping root so all PTs transparently get this capability. He mentioned difficulties with our python PTs, probably because the ServerTransportPlugin line was pointing directly at the script and it was getting invoked via the #! handler in the kernel. It may be possible that this "just works" if the ServerTransportPlugin line pointed at the python interpreter instead, but if it does not, this will probably require a kernel patch, that won't ever get accepted upstream. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] DEFAULT_ROUTE_LEN [was: Silly (or not so silly) question]
On Thu, 24 Jul 2014 16:48:21 -0400 grarpamp wrote: > On Wed, Jul 23, 2014 at 6:34 PM, Roger Dingledine > wrote: > > On Wed, Jul 23, 2014 at 11:24:47PM +0100, Noel David Torres Taño > > wrote: > >> What would happen if a Tor node changes behaviour and uses four or > >> five relay steps instead of three? > > At around DEFAULT_ROUTE_LEN 8 or above I get a lot of these, with > EXTEND being shown in various command locations, and no connectivity > to hidden services. Lower values or 4 or 5 probably work just fine > but I didn't bother testing more than a couple clearnet and onion > circuits since it's not yet a controller/config tunable and thus takes > edit/compile/run time. So even my test of 9 > 5 > 7 > 8 take with > salt. Don't know if this likely represent a bug to test more, or just > timeouts... the circuits that did work setup in times not feeling > much more than time/3*LEN. I'd suggest an undocumented tunable and > unit test if it's worth research/statistic/function_checking purpose. > > > relay_send_command_from_edge_(): Bug: Uh-oh. We're sending a > RELAY_COMMAND_EXTEND cell, but we have run out of RELAY_EARLY cells on > that circuit. Commands sent before: > (unrecognized),(unrecognized),(unrecognized),(unrecognized),EXTEND,EXTEND,(unrecognized) This is working exactly as specified, and despite the error message, is not a Bug. The number of hops each circuit can extend to is limited by the number of RELAY_EARLY cells allowed per circuit (8), as EXTENDs that are not contained in RELAY_EARLY are dropped. Roger linked prop 110, but this is also documented in the tor-spec (section 5.6). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 10:00:01 +0200 Lunar wrote: > isis: > > > We can't just make Tor Browser stop accepting obfs2 because some > > > people are using obfs2 bridges right now. But we shouldn't add > > > more people to the set of users of a broken protocol. > > > > Obfs3 is also "broken", it's just that we haven't yet seen a DPI > > box do it IRL. > > That's news to me. Any pointers? Well, the protocol is ok, but it is vulnerable to active probing (eg: See something they don't recognize, flag the destination IP/Port, call back later). Doing so on a mass scale is *quite* expensive since the obfs3 handshake isn't exactly cheap, but probably is in the reach of a nation-state adversary (China springs to mind). There also are a few interesting statistical attacks that are possible vs the obfs3 protocol if you make guesses about the inner payload, but such things are unnecessary for obfs3 (and ScrambleSuit/obfs4 both have some defenses against those, although not all are enabled as a performance tradeoff). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 13:25:31 +0200 Lunar wrote: > isis: > > > We can't just make Tor Browser stop accepting obfs2 because some > > > people are using obfs2 bridges right now. But we shouldn't add > > > more people to the set of users of a broken protocol. > > > > Obfs3 is also "broken", it's just that we haven't yet seen a DPI > > box do it IRL. If you want me to only hand out the holy grail, I'm > > never going to hand anything out. > > The holy grail will never exist, indeed. I fail too see why this would > be a reason to continue giving out solutions that are known to be bad > when they have suitable replacement. For what it's worth, the official plan is to kill off obfs2 once we figure out how we want to handle deprecating old transports. https://trac.torproject.org/projects/tor/ticket/10314 Personally I think when we deploy the next round of transports (meek, and either ScrambleSuit or obfs4) would be the right time to revisit this, and I can't think of a good reason to keep obfs2 around beyond "there are bridges that only support obfs2" which is a fairly terrible reason keep distributing the protocol to new users. My other objection to the idea a while back was that Orbot only supported obfs2, but that's been fixed for a while now. Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Email Bridge Distributor Interactive Commands
On Fri, 25 Jul 2014 22:19:40 + isis wrote: > > Personally I think when we deploy the next round of transports > > (meek, and either ScrambleSuit or obfs4) would be the right time to > > revisit this, and I can't think of a good reason to keep obfs2 > > around beyond "there are bridges that only support obfs2" which is > > a fairly terrible reason keep distributing the protocol to new > > users. > > Scramblesuit is "deployed", if you ask me... We've got roughly 2221 > scramblesuit supporting bridges. Kind of. TBB/Orbot and the FirefoxOS code all need to move to 0.2.5.x for those bridges to actually be useful which I belive is Real Soon Now. Just having bridges that only people that build stuff on their own can connect to is a bit silly. > > My other objection to the idea a while back was that Orbot only > > supported obfs2, but that's been fixed for a while now. > > So... I'm going to wait for an update from the Huggable Transport > folks, telling me to phase out obfsXYZ, whenever that happens. Until > then, obfs3 is still the default transport distributed. > > Does this sound okay to everyone? Otherwise you're shoving me back > into the hell where I get yelled at if I don't make a unilateral > decision, and also get yelled at if I do make a decision. It's kind > of annoying to get yelled at all the time. :( That's fine by me. I belive obfs3 should be ok for a while, and there are easier ways to identify bridges via active probing than doing on obfs3 handshake anyway (Fixing such things is also on my TODO list). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] (meek|flashproxy)+(obfs3|fte|scramblesuit|...)
On Sat, 26 Jul 2014 15:08:38 +0100 Kevin P Dyer wrote: > Are there any roadblocks that prevent us from doing the following? > > 1. Remove the hard-coded bridge_prefs.js in the TBB. Ok. > 2. Set meek as the default pluggable transport in the TBB. Sure that's also fairly easy. > 3. Use meek to acquire an up-to-date bridge_prefs.js from, say, > torproject.org. Whowa, what? I get (from other parts of the thread) that there are compelling reasons for this, but I can think of at least two reasons why I would be massively against this. a) Who is going to pay for this? The amount of data transferred will grow to be non-trivial rather quickly because each user that ends up doing this will do the full bootstrap. Granted, this will be a one time thing per bundle release (and a one time thing over the lifespan of the client in some magical world where TBB has an update mechanism), so the economic side in the future isn't quite as dire, but still. b) Giving anyone a list of a subset of our users (and a particularly vulnerable subset at that, since they need to use PTs), seems dangerous at best. Going from "all meek users need to trust $CDN" to "the default behavior is to give $CDN a list of anyone trying to use PTs" at first glance seems like something that will only end badly. > 4. Use the information from the acquired bridge_prefs.js to connect > to Tor as normal. No clue as to how hard this is. > Ostensibly, this doesn't do a better job of hiding bridge addresses. > However, it allows us to modify bridge addresses without releasing a > new TBB. I don't see that as being a sufficiently compelling reason to give a third party the ability to enumerate (a unknown fraction of) the PT user base (while making them rich at the same time). Regards, -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PKCS#1 ASN.1 Public Key Encoding
On Sun, 17 Aug 2014 16:19:56 +0100
Gareth Owen wrote:
> I'm trying to generate the fingerprint given just the pubilc key in
> Java and after almost a whole day I'm about to give up. Does anyone
> have a sample PKCS#1 encoded public key that is used immediately
> before SHA-1 to generate the fingerprint? e.g. a hex string is what
> I'm after.
Both descriptors and microdescriptors contain this in the appropriate
format (albeit Base64 encoded and with a PEM envelope). Check the data
directory of a running tor instance and look at
cached-microdescs(.new), which will have onion-key entries for all the
relays.
> It seems there are subtle ways that an PKCS#1 can vary while encoding
> the same information which affects the hash, Java seems to be doing
> it one way, OpenSSL another, an example on stack overflow adds an
> extra field, etc.
The way that you care about (that matches how tor does it) is specified
in RFC 2313.
7.1 Public-key syntax
An RSA public key shall have ASN.1 type RSAPublicKey:
RSAPublicKey ::= SEQUENCE {
modulus INTEGER, -- n
publicExponent INTEGER -- e }
(This type is specified in X.509 and is retained here for
compatibility.)
How to do this in Java depends on which crypto API you are using, look
at oracle.security.crypto.asn1 or org.bouncycastle.asn1. Additionally
this (http://lapo.it/asn1js/) will probably be useful.
Regards,
--
Yawning Angel
signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] obfs4 test bundles
Hello all, So after a brief pause in my productivity due to the dev meeting and some IRL things, I'm back in the swing of development and have been working on getting obfs4 ready for development. I've recently mostly finished a fairly large cleanup/refactor of the obfs4 codebase and dusted off the Tor Browser build integration patch. Test bundles signed with my PGP key are available at: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140820/ Some quick notes: * The bundles are alpha. DO NOT USE THEM IF YOU REQUIRE STRONG ANONYMITY OR SECURITY. * While it is possible to pull out the obfs4proxy binary from the bundle and use it to run a bridge, that will be a *terrible* idea because the bundles are missing some logging related fixes. * The Windows and OSX bundles are entirely untested, because I do not have access to either platform. The Linux bundle appears to work. * Using obfs2/obfs3 will also exercise new code (obfs4proxy instead of obfsproxy). * I'm not uploading a 32 bit linux bundle for now. * The one obfs4 test bridge is mine, and is the one I posted to tor-dev@ (port is different, bridge parameters are the same). If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 test bundles
Hello everyone, I just uploaded a new set of obfs4 test bundles to: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140829/ I forgot to change the file names (oops), but that shouldn't affect the bundles and regenerating them just to rename/reversion would take quite a while, so I'll pass on doing so. Changes since the last version: * obfs4proxy * obfs4proxy -v will print versioning information. * Bridge side logging will sanitize golang networking errors unless the log scrubber is disabled. * Bridge lines now use Base16 instead of Base64 to work around bugs in the pt bridge args processing. * A dumb bug that was causing TYPE_PRNG_SEED frames to be silently ignored was fixed. * Bridge lines now have "iat-mode" which controls Inter-Arrival Time obfuscation. This is done so the bridge administrator can specify client behavior (Default is to disable IAT obfuscation). * There is now an optional paranoid IAT obfuscation mode, which disables optimizations made around bulk data transfer for additional obfuscation. This has a major impact on bulk data throughput and is not recommended. * Bundling * The #12535 patch is integrated into the goptlib build process, and go based pluggable transports will use SOCKS5. Eventually the patch will be merged into goptlib proper. * The default test bridge was updated to the new bridge line format, and includes the "iat-mode" argument. * The obfs4proxy and Go licenses are now included in the bundle. I have verified that the linux64 and windows (thanks to a friend) bundles appear to be functional. If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 test bundles
Hello everyone, I just uploaded a new set of obfs4 test bundles to: https://people.torproject.org/~yawning/volatile/tor-browser-obfs4-20140926/ Changes since the last version: * obfs4proxy * Updated to 0.0.2 (Most of the changes are related to packaging and a minor bridge side quality of life feature, no real functional changes since the last version from a client perspective.) * Bundling * Rebased my integration branch on Tor Browser 4.0-alpha-3. * I backed out the goptlib SOCKS5 code since I changed the patch a bunch. IPv6 obfs2/3/4 bridges will probably not work because of this, but that is a know issue, and the patch is sitting in a branch awaiting review and a better opportunity for systematic testing. To be perfectly honest not much has changed to the point where it really warrants another release, but apparently people are still using my old snapshots, so here's a new set for those people that folds in all the changes that went into the Tor Browser side of things. As far as the roadmap for full fledged deployment goes, it's at the "get enough bridges" point, with the step after that being "getting the Tor Browser folks to merge my branch". I have verified that the linux64 and windows (thanks to a friend) bundles appear to be functional. If you wish to follow obfs4 deployment the bug associated with this task is #12130. Questions, comments, feedback welcome. -- Yawning Angel signature.asc Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor-fw-helper redux
Hello, "You are in a maze of twisty little firmwares, all terrible". I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress... Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338 Yes, it's another Go app. It should work both as a helper for tor (PortForwardingHelper in the torrc), and for flashproxy. I am currently only concerned about the latter use case since it will immediately make flashproxy more useful in various environments, and I'm not sure people that can't setup port forwarding should be running relays in the first place. How to test it: $ go build github.com/yawning/go-fw-helper One of: * Play with it by hand. "-h" dumps usage. * Edit the torrc-defaults file shipped with Tor Browser to have flashproxy use the helper. On the Linux bundle the file in question is located at tor-browser_en-US/Browser/TorBrowser/Data/Tor The flashproxy ClientTransportPlugin line should look something like: ClientTransportPlugin flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --port-forwarding-helper=/path/to/go-fw-helper --register :0 :9000 You *can* edit where it says "9000" to use a different port, but having it auto assigned will lead to it being harder to remove when done. * Try running a tor relay using PortForwardingHelper. I personally don't recommend this, and haven't tested it at all, but there's no reason why it won't work unless the tor side of the code rotted (unlikely?). Caveats: * Not sure which version of the Go compiler/runtime this requires. Development was done on 1.3.3. It probably requires 1.2.x but it may work on older versions (Not a bug/WONTFIX). * UPnP discovery requires being able to listen on a UDP traffic and accept incoming packets. Your local firewall may prevent this. (Not a bug/WONTFIX). * flashproxy does not know how to deal with mappings expiring, so things will stop working after 2 hours if NAT-PMP is used. * Neither flashproxy nor tor know how to use go-fw-helper to delete mappings, because tor-fw-helper did not have such a thing. WARNING: If UPnP is used as the protocol, mappings are indefinite. You will need to use the router's admin interface or "go-fw-helper -d" to remove it. Yes, there is a very good reason why this is like this, despite the protocol on paper having the length as a registration time parameter. Note: NAT-PMP mappings obtained by go-fw-helper last for 2 hours. * go-fw-helper's "-T" option doesn't do everything tor-fw-helper's does. (Meh?) * The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper. Useful extensions over tor-fw-helper: Dump all current mappings with: $ go-fw-helper -l Remove mappings with: $ go-fw-helper -d ([]:] Both of those options only work with UPnP because NAT-PMP does not have a method of querying mapping information, and because at least one NAT-PMP implementation deployed on a lot of routers does not handle removal correctly (Bug reported to maintainer, and fixed in master but people do not update router firmware enough. There is a way to force go-fw-helper to let you delete port forwarding entries, but it's intentionally undocumented, because I don't want to support it.) Force a certain protocol (Case sensitive): $ go-fw-helper --protocol=NAT-PMP ... $ go-fw-helper --protocol=UPnP ... Tested on: * 64 bit Linux * 64 bit FreeBSD 9.3 * 32 bit Windows 7 Need testing on: * Darwin (esp with NAT-PMP) * With more routers than the 2 I have immediate access to. If something breaks "-v" gets you debug output. Questions, Comments, Feedback appreciated, -- Yawning Angel pgpWsPVIzWZO3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-fw-helper redux
On Sun, 26 Oct 2014 02:07:26 -0700 David Fifield wrote: > On Sun, Oct 26, 2014 at 08:41:08AM +0000, Yawning Angel wrote: > > Hello, > > > > "You are in a maze of twisty little firmwares, all terrible". > > > > I'm at the point where the new and improved firewall helper could > > use some additional testing by various users, though there's some > > issues with the design that still need to be resolved. But not > > being one to keep issues inherited from the original from stopping > > progress... > > > > Code: https://github.com/yawning/go-fw-helper > > Bug: https://trac.torproject.org/projects/tor/ticket/13338 > > This is great. Is there any reason not to call it tor-fw-helper, and > replace/deprecate the existing src/tools/tor-fw-helper? No particular reason for the former. This could even be done at the packaging step since I kind of don't want to move the repo. I think, assuming people like my stab at this, that having it live in it's own space under git.tp.o somewhere would be best. > I'm thinking that as a conservative step, we should first deploy > using a static external port for flash proxy. An ephemeral port is > better for scanning resistance, but there is also the risk of poking > long-lasting holes in firewalls and overflowing port forwarding > tables in these shoddy routers. Indeed. It has no external dependencies so adding it to the build process should be trivial, just not something I've bothered with yet. > We need at least to add a loop to where flashproxy-client calls the > port forwarding helper. Ideally we would also try to remove the > mapping before exiting. We could do it in the first SIGINT > handler--though we know that SIGINT handling doesn't work on Windows > because tor immediately zaps you with TerminateProcess. We could do > something like we do with terminateprocess-buffer and > meek-client-torbrowser, and add an --exit-on-stdin-eof option to > flashproxy-client so that it can detect when it is supposed to shut > down gracefully. I'm not sure it's worth it though, especially if > unmapping ports is unreliable. I would think it's worth trying to do so, particularly if ephemeral ports are used. NAT-PMP mappings (the one that has routers that have trouble unmapping), have a sane lifespan (currently 2h, but changing this is trivial). As far as I know removing UPnP mappings should always work, and that's the protocol that needs infinite duration mappings due to firmware badness. There's no harm in trying to unregister mappings. Unless the undocumented flag is set, go-fw-helper will just fail to remove NAT-PMP mappings with an internal error. I changed the reporting for the deregistration process to mostly match the registration as well, so automating this is straight forward. I may reconsider disallowing NAT-PMP deregistration since the router side implementation where I found the bug supports both UPnP and NAT-PMP, and so in such environments UPnP should be used anyway due to how the code is setup. > We'll need a tor-browser-bundle branch that builds go-fw-helper and > adds it to the ClientTransportPlugin line. I'll look at adding the > flashproxy-client loop. > > > * The UPnP mapping description is hard coded to "Tor relay" to > > match tor-fw-helper. > > Is there any way to omit it or leave it blank? I thought there was a > ticket somewhere about "Tor relay" making Tor use more conspicuous, > but I can't find it now. It's a constant in the UPnP code. This is also trivial to omit/change, if people want it to be different, but having it well defined makes the admin side of things easier. NAT-PMP doesn't have a description field. As a side note, before I sent the e-mail, I was browsing the web for a bit with flashproxy configured to use the helper, so at least in my test environment things work as expected. -- Yawning Angel pgpVJ0UyNHcWA.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
On Sun, 26 Oct 2014 17:16:46 +0200 s7r wrote: > 3. Last thing, the page https://bridges.torproject.org/ does not > contain obfs4 in the drop-down list where the user needs to select the > pluggable transport. It only allows requests for obfs2, obfs3, > scramblesuit and fteproxy bridges. Don't know about fteproxy, but > shouldn't obfs2 be deprecated or is it still working/used? A note on this (I don't handle packaging, sorry). obfs4 propbably should be added to the dropdown once there is a critical mass of bridges in the database, and when obfs4 is in official Tor Browser builds. As far as I am aware, the official integration (as opposed to my obsolete not-really-working-anymore snapshots) is scheduled to happen in the next alpha series. Regarding obfs2, it still "works" in some environments if the DPI used by the censor is not particularly sophisticated (not targeted specifically at detecting obfs2). I personally think that it should be deprecated sooner rather than later, but others have disagreed with me on this. Hope that helps, -- Yawning Angel pgpRkxhRUfSjM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Understanding Tor and SOCKS
On Sun, 26 Oct 2014 14:34:59 +0100 Rob van der Hoeven wrote: > So, the SOCKS protocol supports redirection to another SOCKS server. > An all-zero address/port simply means: use the server/port that you > are currently connected to. That's a really interesting way of interpreting that part of the RFC. The reason why BND.ADDR and BND.PORT are supplied in a SOCKS5 response is to provide the client with the information equivalent to calling getsockname() on a non-proxied socket. In the context of tor, the reason why BND.ADDR and BND.PORT are all NUL bytes is because the RELAY_CONNECTED cell does not propagate BND.PORT backwards to the client from the exit. BND.ADDR could technically be filled in (since the tor client knows where it is exiting from), but I don't see much point (and this information is useless at best in the context of HSes). Regards, -- Yawning Angel pgpGA5tzki8YH.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Hidden Service authorization UI
On Sun, 9 Nov 2014 16:19:24 + Andrea Shepard wrote: > How would Tor Browser learn about this reason for not being able to > connect/ tell Tor the authentication info? This is starting to sound > like wanting SOCKS5 extensions to indicate different causes for > connection failures in #6031 did. Well prop 229 is on my todo list, though it's not very high up. The last time I spoke to people about this, it seemed like a nice to have but not massively important sort of thing, but I'd be more than happy to rearrange things in that department. Especially as my tenative plans for obfsng (aka obfs6 depending on how long it gets stuck in design and deployment) involves 1 KiB keys... Regards, -- Yawning Angel pgp1Omyydtsp8.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 19th of November 2014)
Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgp17oIBtS3qf.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 13:08:04 + Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Hi, > > In the obfs4 spec I couldn't find a description of how the secretbox > nonces for the frames are constructed. A 16-byte nonce prefix comes > from the KDF, but what about the remaining 8 (presumably > frame-specific) bytes? It's a simple 64 bit frame counter (Big endian, starts at 1). Guess I never bothered to copy the relevant information from the gigantic comment in framing.go into the spec, oops. The code cuts the connection if the counter would wrap though that's unlikely at any sort of realistic data rate given the use case. > If an attacker changes the order of the secretboxes so that the > recipient tries to open a secretbox with the wrong nonce, is that > guaranteed to fail, as it would if the secretbox had been modified? I > can make a hand-wavy argument for why I think it will fail, but I > don't know whether the secretbox construct is designed to ensure this. Yes, the poly1305 verification will fail. > Any particular reason for using two different MACs (HMAC-SHA256-128 > for the handshake, Poly1305 for the frames) and two different hashes > (SHA-256 for the handshake, SipHash-2-4 for obfuscation)? No particular reason beyond "historical". Ntor is specified to use HMAC-SHA256, ScrambleSuit used HMAC-SHA256-128. I briefly toyed with sending 2 secretboxes one with the length, one with the payload, but that was kind of heavyweight, so I went with something lighter (Thus SipHash). I may go back to the two box design if I do an obfs5, not sure about that yet. Regards, -- Yawning Angel pgpgvpPIf0y5d.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 14:47:29 + Michael Rogers wrote: > I believe so too, but is it stated anywhere that this is a guaranteed > property of crypto_secretbox? The Poly1305 authenticator is calculated based on the payload and the nonce. In the case of the NaCL secretbox construct, 32 bytes of zeroes encrypted based on a one time key/counter derived from the actual key and the nonce. If the frames are reordered, the derived authenticator would be different. So yes, it is a property of crypto_secretbox because that's how Poly1305 works. It wouldn't be a workable AEAD mode if nonces (which usually are transmitted in the clear) could be modified undetected by attackers either. For more details see the original poly1305 paper[0] (nb: specified in terms of using AES for the nonce->16 byte string mapping, but that is arbitrary). > >> Any particular reason for using two different MACs > >> (HMAC-SHA256-128 for the handshake, Poly1305 for the frames) and > >> two different hashes (SHA-256 for the handshake, SipHash-2-4 for > >> obfuscation)? > > > > No particular reason beyond "historical". Ntor is specified to > > use HMAC-SHA256, ScrambleSuit used HMAC-SHA256-128. I briefly > > toyed with sending 2 secretboxes one with the length, one with the > > payload, but that was kind of heavyweight, so I went with something > > lighter (Thus SipHash). I may go back to the two box design if I do > > an obfs5, not sure about that yet. > > Interesting, thanks. Would SHA-256 be too slow for obfuscation? It > just seems like a lot of dependencies for a simple protocol. Probably not, but at that point, 2 boxes is also likely fine since it wasn't unusably slow. > For what it's worth, we're using the two-box approach for the next > version of the Briar transport protocol. I'm concerned about the > possibility of an attack conceptually similar to [1] against an > unauthenticated length field, even though that specific attack > wouldn't apply. This was brought up by phw during the obfs4 design phase. The code randomizes the length if it is invalid as per one of the suggested countermeasures in section 6 of the paper (So an identical failure to a modified plaintext/tag is observed). Regards, -- Yawning Angel [0]: http://cr.yp.to/mac/poly1305-20050329.pdf pgpD4SkRCdRkT.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 15:37:06 + Yawning Angel wrote: > The Poly1305 authenticator is calculated based on the payload and the > nonce. In the case of the NaCL secretbox construct, 32 bytes of > zeroes encrypted based on a one time key/counter derived from the > actual key and the nonce. If the frames are reordered, the derived > authenticator would be different. Ugh, I did a terrible job of explaining that, sorry to reply to myself. A one time poly1305 key is calculated for each box, based on 32 bytes of zeroes encrypted with a one time Salsa20 key/counter derived from the nonce and the box key. You can view the use of Salsa20 there as an arbitrary keyed hash function (in the case of the original paper, AES was used). Hope that clarifies things somewhat, -- Yawning Angel pgpxgTHsGjhbQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4 questions
On Fri, 28 Nov 2014 17:57:26 +
Michael Rogers wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 28/11/14 15:50, Yawning Angel wrote:
> > A one time poly1305 key is calculated for each box, based on 32
> > bytes of zeroes encrypted with a one time Salsa20 key/counter
> > derived from the nonce and the box key. You can view the use of
> > Salsa20 there as an arbitrary keyed hash function (in the case of
> > the original paper, AES was used).
> >
> > Hope that clarifies things somewhat,
>
> Thanks - this is similar to the argument I came up with. I called my
> argument hand-wavy because it relies on HSalsa20 and Salsa20 being
> PRFs, and I don't know how big an assumption that is.
For what it's worth "7 Nonce and stream" both support using a counter
here as the nonce, and refers to 'The standard ("PRF") security
conjecture for Salsa20". IIRC the security proof for the extended
nonce variants also hinges on the underlying algorithms being PRFs as
well, so it's something I'm comfortable in assuming.
http://cr.yp.to/highspeed/naclcrypto-20090310.pdf
Regards,
--
Yawning Angel
pgpVJBifs9PS3.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 17:32:05 -0500 Jason Cooper wrote: > > It is unauthenticated and you probably shouldn't use it if at all > > possible. > > How does that matter? All of the tags are signed by Nick Mathewson. > This allows the server *and* the path to be untrusted. What about intermediary commits between tagged releases? Yes, signing each commit is possible, and probably even a good idea, but it's not currently done. Regards, -- Yawning Angel pgpBtpnfUsqCQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Git hosting changes, git:// support discontinued
On Sun, 30 Nov 2014 19:19:58 -0500
Jason Cooper wrote:
> On Sun, Nov 30, 2014 at 11:55:31PM +0000, Yawning Angel wrote:
> > On Sun, 30 Nov 2014 17:32:05 -0500
> > Jason Cooper wrote:
> > > > It is unauthenticated and you probably shouldn't use it if at
> > > > all possible.
> > >
> > > How does that matter? All of the tags are signed by Nick
> > > Mathewson. This allows the server *and* the path to be untrusted.
> >
> > What about intermediary commits between tagged releases? Yes,
> > signing each commit is possible, and probably even a good idea, but
> > it's not currently done.
>
> git uses chained hashes so that verifying the integrity of the tagged
> commit also verifies the integrity of the previous commits between the
> prior tag and the current one (Actually, across the entire history,
> but once I've cloned and validated, I'm primarily concerned with
> commits from subsequent pulls).
So, I didn't communicate that well, so I'll try again:
Assuming people use the unauthenticated git protocol, and want to
clone a copy of master, maint-0.2.4 or maint-0.2.5, how do they ensure
that the copy they received is correct?
So "intermediary commits" as in "stuff that happens between releases,
with the next release having not happened yet" ('interim' would have
been a better word to use in hindsight). Sure you can validate up to the
last tag, but for all the commits that follow, there's no magic PGP
signed tag that covers those.
I don't see any reason to allow a unauthenticated protocol when
authenticated alternatives exist and are well supported in the first
place, but that's just me.
Regards,
--
Yawning Angel
pgpsUCIBbLyRC.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 3rd of December 2014)
Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgpgttQ9aqVoM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] basket: More eggs in the Guard basket.
Hi all, For several reasons I've been working on a bit of code that I named "basket". It's almost at the point where the brave members of the general public should be aware that it exists as a potential option in the privacy toolbox, though using it in any capacity beyond testing on a loopback device IS CURRENTLY ACTIVELY DISCOURAGED unless users are comfortable debugging it (This means, DO NOT USE IT. I will likely break backward compatibility in the future, and you will be sad.). "basket" is my stab at designing something that significantly increases Tor's resistance to upcoming/future attacks, by providing a link layer cryptographic handshake that uses post-quantum cryptographic primitives and defenses against website fingerprinting (and possibly e2e correlation) attacks. For the ease of development it is in the form of a pluggable transport with the expected tradeoffs (you must absolutely trust your Bridge, since both features only run to the Bridge). It is worth noting that it is anything but subtle, and it is blatantly obvious that a given connection is speaking "basket" as no attempt was made to obfuscate the handshake. The link layer handshake works roughly like thus: Setup: * Bob generates a long term SPHINCS256 keypair s,S used to sign responses. The handshake: 1. Alice generates a Curve25519 keypair x,X and a NTRUEncrypt EES1171EP1 keypair n,N. 2. Alice sends X | N to Bob. 3. Bob generates a Curve25519 keypair y,Y, and calculates Curve25519(y,X) as the shared secret. 4. Bob sends NTRUEncrypt(N,Y) | S | SPHINCS256(s, ntru_ciphertext | S) to Alice. 5. Alice verifies the SPHINCS256 signature (Alice's copy of S is saved/trusted in a Trust-On-First-Use manner), and decrypts the NTRU ciphertext to obtain Y. 6. Alice calculates Curve25519(x,Y) as the shared secret. NB: Some details omitted for brevity. Passive attackers see Alice's Curve25519 public key, Alice's NTRUEncrypt public key, Bob's SPHINCS256 public key, a NTRUEncrypt ciphertext, and SPHINCS256 signature. Obtaining the link's ephemeral session key requires decrypting the NTRUEncrypt ciphertext (to obtain Bob's Curve25519 public key), and reversing the scalar base multiply on one of X and Y. Active man-in-the-middle attackers need to be able to forge SPHINCS256 signatures to substitute their own NTRUEncrypt-ed payload to mount an attack (Alice's request is also validated/protected but it's one of the details omitted, read the code). As NTRUEncrypt is patent encumbered, there also is a handshake mode that removes the experimental post-quantum cryptography and uses Ed25519/Curve25519. The fingerprinting defenses are in the form of the CS-BuFLO algorithm in CTST (Client total, Server total) mode, without the application level hinting based optimizations to reduce bandwidth consumption (See: http://www3.cs.stonybrook.edu/~rob/papers/csbuflo.pdf). As a minor implementation refinement, "basket" uses the kernel information as described in the KIST paper to be more responsive to changing network conditions. Most of the CS-BuFLO parameters were adjusted in an attempt to compensate for the lack of said application level hinting, but "basket"'s CS-BuFLO implementation is still a lot more expensive than the one presented in the paper. The code: http://github.com/yawning/basket Notes: * The PQ crypto primitives used are ports to Go by yours truly based on the reference implementations. It is both possible and likely that I messed something up, so users should decide between trusting my implementations and using a handshake based on classical algorithms. * The "basket" handshake consumes a non-trivial amount of CPU on the server side due to the SPHINCS256 implementation being relatively unoptimized. * CS-BuFLO is EXTREMELY BANDWIDTH INTENSIVE, and if adversaries can observe the Bridge's upstream, it likely can be broken, especially if the Bridge is only servicing a handful of users. Running the defense end-to-end (or even to the middle relay) is *extremely* non-trivial, though that would be required if something more comprehensive is desired. * The KIST code is platform specific, and I only wrote the Linux version. If this ends up being useful to people, support for other platforms is possible. * "basket" was never written to be a general use transport, though it sits somewhere between obfsproxy-wfpadtools (a pure research framework) and obfs4proxy (something that is intended to be used in production) in terms of completeness. Thanks to Marc Juarez (KU Leuven) and Mike Perry for inspiration to write the CS-BuFLO component of "basket". Questions, comments, feedback appreciated as always, -- Yawning Angel ps: Seriously, unless you are a developer or researcher, you REALLY SHOULD NOT use
[tor-dev] Pluggable transports meeting tomorrow (16:00UTC Wednesday 17th of December 2014)
Hello! Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel pgpmwTq6Jwj11.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] basket: More eggs in the Guard basket.
On Wed, 17 Dec 2014 13:51:02 -0500 Nick Mathewson wrote: [snipity] > Should the handshake also a signature by Bob of (X|N), and should > maybe the shared secret also include a digest of all the other parts > of the communication? Hmm, maybe I shouldn't have left bits out, and I really do need to document the handshake component of the protocol. The former is actually done, a BLAKE-256 digest of the entire client request is included in Bob's response and is covered by the signature. The client verifies that Bob received a unmodified request, after checking the signature. There's no reason why the signature can't just include the entire request here if that's better. Including a digest of everything sent as part of the shared secret seems like a good idea, so I shall revise the protocol to do that (digesting < 50 KiB of data isn't that big of a deal given how heavyweight the other crypto bits are). Regards, -- Yawning Angel pgpI20qKE8Gnl.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] N reasons why the spooks love Tribler (Number N' will surprise you)
% (2^128) This is fatally broken and insecure on several fronts. a) "StrongRandom" is Mersenne Twister seeded once via os.urandom(). What little "StrongRandom" actually resembles something that is "Strong" and "Random" is due to the Python developers, though in practice it is neither. b) The GMP LCG is seeded with 32/64 bits of "entropy", where "entropy" is Mersenne Twister output. c) GMP's LCG is used for key generation. * How not to do Diffie-Hellman: key = pow(dh_received, dh_secret, DIFFIE_HELLMAN_MODULUS) This is relatively minor since recovering the secret key is trivial via PRNG attacks, so the fact that the modular exponentiation is not constant time matters less. * How not to do RSA: def rsa_encrypt(key, element): assert isinstance(element, (long, int)), type(element) _element = mpz(element) return long(pow(_element, key.e, key.n)) def rsa_decrypt(key, cipher): assert isinstance(cipher, long), type(cipher) _cipher = mpz(cipher) return long(pow(_cipher, key.d, key.n)) RSA being implemented without blinding, using GMP's modular exponentiation, and without OAEP is something I pray that I never see again. Things not covered: * How the intro point/rendezvous system works, including peer discovery and etc (Assuming it is trivial to obtain lots of ECElgamal keys/IP address:Port combinations of endpoints, it appears that it is possible to use the CREATE/CREATED response to mount an UDP amplification attack. But I did not check how easy this would be to mount in practice.) * The bittorrent bits. * The "dispersy" component beyond "ok, at least the ECElgamal key generation uses M2Crypto, assuming the horribly broken keygen code (community.privatesemantic.crypto.ecelgamal.ecelgamal_init()) is dead like I think it is". Recommendations: * For users, "don't". Cursory analysis found enough fundamental flaws, and secure protocol design/implementation errors that I would be reluctant to consider this secure, even if the known issues were fixed. It may be worth revisiting in several years when the designers obtain more experience, and a thorough third party audit of the improved code and design has been done. * For the developers: * Use a CSPRNG when doing key generation. Neither GMP's LCG nor Mersenne Twister are CSPRNGs, even if they are seeded from "StrongRandom" that actually is a "StrongRandom" (rather than a horrible misnomer). * Add a construct similar to RELAY_EARLY. * Add authenticated encryption to cell payload. This will break wire compatibility. * Use constant time modular exponentiation. As a matter of fact, don't include your own implementations of ECElGamal, RSA, and Diffie-Hellman. Use well tested/known secure library code instead. * Blind RSA operations, use padding as appropriate. * Fix the symmetric encryption somehow, after obtaining a in-depth understanding of what things break security of the mode you wish to use in various ways (Eg: IV/Nonce reuse). See: http://web.cs.ucdavis.edu/~rogaway/papers/modes.pdf * Instead of a DH + ElGamal handshake, consider Ntor. Even with GMPY, doing modular exponentiation is relatively CPU intensive, and there is the threat of CPU exhaustion attacks here. * Clean out all the dead code, after printing out copies to use to scare small children. Eg: Tribler/community/privatesemantic/crypto/elgamal.py Most of the fixes require major revisions to the wire protocol. As it appears that there is no versioning, how that will be done is left as an exercise for the student. Alternatively, rebase the system on I2P. Regards, -- Yawning Angel pgpGSqhEPfHVU.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Tor BSD underperformance (was [Tor-BSD] Recognizing Randomness Exhaustion)
On Thu, 1 Jan 2015 14:19:08 +1100 teor wrote: > On 1 Jan 2015, at 07:39 , Greg Troxel wrote: > > Tor 0.2.6.2-alpha (just in the process of being released) has some > changes to queuing behaviour using the KIST algorithm. > > The KIST algorithm keeps the queues inside tor, and makes > prioritisation decisions from there, rather than writing as much as > possible to the OS TCP queues. I'm not sure how functional it is on > *BSDs, but Nick Mathewson should be able to comment on that. (I've > cc'd tor-dev and Nick.) I don't think we merged that branch yet, since it's not ready for general use. Additionally, it's not currently functional on the *BSDs. The KIST code last I checked only is used under Linux. While the full portability story is in #12890 it looks roughly like: * Linux - Supported. * Windows - Possible, needs code in tor. * Darwin - Possible, uses interfaces marked as undocumented/internal. * FreeBSD - Requires a trivial kernel patch (interface is there, information exposed is incomplete). * Other BSDs - Requires a kernel patch, which is more involved than the FreeBSD one (implementing the required interface vs exposing more information). The patch is still trivial for anyone that's familiar with the TCP/IP code. I don't think we should be in the business of maintaining kernel patches either, so I'm not sure what the right thing to do would be for non-Darwin *BSD. Regards, -- Yawning Angel pgpus7JlLTwWJ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gettimeofday() Syscall Issues
On Thu, 01 Jan 2015 23:42:42 -0500 Libertas wrote: > The first two account for the bulk of the calls, as they are in the > core data relaying logic. > > Ultimately, the problem seems to be that the caching is very weak. At > most, only half of the calls to tor_gettimeofday_cached_monotonic() > use the cache. It appears in the vomiting print statements that > loading a single simple HTML page > (http://www.openbsd.org/faq/ports/guide.html to be exact) will cause > >30 gettimeofday() syscalls. You can imagine how that would > >accumulate for an exit carrying 800 KB/s if the caching > doesn't improve much with additional circuits. So while optimization is cool and all, I'm not seeing why this specifically is the underlying issue. Each cell can contain 498 bytes of user payload. Looking at things simplistically this is 800 KiB/s -> 1644 cells/sec, leaving you with approximately 608 microseconds of processing time per cell. On my i5-4250U box, gettimeofday() takes 22 ns on Linux, and 2441 ns on FreeBSD. I'm not sure how accurate the FreeBSD results are as it was in a VirtualBox VM (getpid() on the same VM takes 124 ns). If someone has a OpenBSD box they should benchmark gettimeofday() and see how long the call takes. Taking the FreeBSD case (since we know that tor works fine on Linux), a single gettimeofday() call takes approximately, 0.39% of the per-cell processing budget. For reference (assuming gettimeofday() in *BSD really is this shit performance wise), 7000 calls to gettimeofday() is 17.09 ms worth of calls. The clock code in tor does need love, so I wouldn't object to cleanup, but I'm not sure it's in the state where it's causing the massive performance degradation that you are seeing. Regards, -- Yawning Angel pgpN7QOVVGLMt.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] gettimeofday() Syscall Issues
On Fri, 2 Jan 2015 23:18:16 +1100 teor wrote: > IPredator has complained that tor on Linux spends too much time > calling time() when pushing 500Mbit/s, which is an issue for them > under 3.x series kernels, but not kernel 2.6. > > https://ipredator.se/guide/torserver#performance I really don't understand this, unless my benchmark methodology is overly naive. time() in a trivial benchmark takes roughly 3 ns per call. Linux doesn't even do a real syscall for gettimeofday() due to vDSO... > I just reviewed my profiling of an exit relay running chutney verify > with 200MB of random data. This is on OS X 10.9.5 with tor > 0.2.6.2-alpha-dev running the chutney basic-min network. > > The three leaf functions that take the most time in the call graph > are: > * channel_timestamp_recv > * channel_timestamp_active > * time > > Each of these functions takes around 16% of the execution time, the > next nearest function is sha1_block_data_order_avx on 4%. > > While I understand that OS X, BSD, and Linux syscalls aren't > necessarily identical, we now have results for the following > platforms suggesting that calling time() too often has a performance > impact: > * Linux kernel 3.x > * OpenBSD > * OS X 10.9 > > My results suggest a maximum performance improvement of 15% on OS X > if we reduced the calls to time() to a reasonable number per second. I'm still skeptical, but hey, the code needs love in general. Maybe nickm/dgoulet have more insight into this than I do, and this would also be a good opportunity to switch more things over to monotonic time. Regards, -- Yawning Angel pgpyHZsfFsxzw.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: gettimeofday() Syscall Issues
On Fri, 2 Jan 2015 18:15:06 -0500 grarpamp wrote: > On Fri, Jan 2, 2015 at 12:24 PM, Konstantin Belousov > wrote: > > On Fri, Jan 02, 2015 at 09:09:34AM -0500, grarpamp wrote: > >> Some recent FreeBSD related questions in this app area. > >> > > What is the question ? > > > > As a background, I can repeat that FreeBSD implements syscall-less > > gettimeofday() and clock_gettime() for x86 machines which have > > usable RDTSC. The selection of the timecounter can be verified > > by sysctl kern.timecounter.hardware, and enabled by default fast > > gettimeofday(2) can be checked by sysctl > > kern.timecounter.fast_gettime. > > > > On some Nehalem machine, I see it doing ~30M calls/sec with enabled > > fast_gettime, and ~6.25M calls/sec with disabled fast_gettime. This > > is measured on 2.8GHz Core i7 930 with > > src/tools/tools/syscall_timing. > > > > Check your timecounter hardware. Since it was noted that the tests > > were done in VM, check the quality of RDTSC emulation in your > > hypervisor. This all is kind of a moot point because even if the relevant time calls did take ~2 usec it still doesn't explain the performance issues, and my curiosity is close to being exhausted. But, for what it's worth. Forcing the timecounter hardware source to "TSC" in my VM results in a saner value (~45 ns). That said, I'm not sure if the clock source is actually sane. A quick skim through the code suggests that there's a decent number of things that would keep the TSC from being used, though VirtualBox supports the P-state invariant TSC cpuid bit (Linux picks it up), so why I'm seeing this behavior eludes me. Curiosity exhausted at this point, -- Yawning Angel pgp7pv29CGVwL.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] high latency hidden services
On Thu, 8 Jan 2015 03:25:52 -0800 Mike Perry wrote: > I am unfortunately not optimistic about simple low-overhead padding > being successful here. At the very least, this problem will require > something more like a congestion-sensitive "always pad if there is > spare capacity available to grow the CWIND, but no data". We have an > approximation of this defense, too, in the form of the "Basket" > pluggable transport: > https://lists.torproject.org/pipermail/tor-dev/2014-December/007977.html I believe most of BuFLO's shortcomings documented in Cai, X., Nithyanand, R., Johnson R., "New Approaches to Website Fingerprinting Defenses" 5.A. apply to the currently proposed defense, though some of the problems have been solved via CS-BuFLO/Basket. CS-BuFLO as implemented in Basket without application assistance (to terminate padding early) has an absolutely gargantuan amount of bandwidth overhead, and the smarter Basket variant that doesn't have stupid amounts of sender side buffering isn't portable (for the same reasons that the new KIST code isn't). > If the adversary is *also* capable of Guard node coercion/compromise, > then we also want something like "Basket" to pad all the way to the > middle node, but to accomplish that, we actually need fair end-to-end > flow control for clients (and by extension, a datagram/UDP transport). Indeed. This is something I'd consider fun, but is really hard to do correctly, since the CS part ideally should be global across all connections (Basket gets that for free since there's only one TCP connection per guard, and only one guard). > (Though also note: We should not need such end-to-end flow control to > use Adaptive Padding all the way to the middle node, because we can > approximate fairness using statistics and consensus load balancing > information). None of the schemes I've seen proposed so far fit well into Tor as it is now, due to the fact that multiple circuits are multiplexed over a single channel (that enforces in-order-reliable delivery semantics). HOL blocking is a thing that needs to be considered. Solving this undoubtedly has really interesting anonymity impacts that I haven't given much thought to. Another issue with all of the padding schemes that I currently don't have a solid suggestion for is how to actually detect malicious peers that don't pad/pad incorrectly. I know Marc Juarez is going to be systematically evaluating defenses as part of his research work, so perhaps he can provide more insight into algorithm selection. Regards, -- Yawning Angel pgpdDB_Sg9Y0F.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Obfsproxy Address Translation
On Fri, 16 Jan 2015 12:05:41 +0100 Alfredo Palhares wrote: > Between the OpenVPN I an obfsproxy server outside the country and a > client inside the country. But what I've found out is that Obfsproxy > server needs to be running as the OpenVPN server and Obfsproxy client > needs to be on the same machine as the OpenVPN client. So what you're saying is, you want to do something like: * There is an obfsproxy client instance running on c.example.com. * There is an obfsproxy server instance running on s.example.com, that feeds into an OpenVPN server instance running on v.example.com. * Multiple clients use c.example.com as the SOCKS proxy for the OpenVPN client, connect to s.example.com to get to the OpenVPN server running on v.example.com. My thoughts on the matter are: 1. This should work. If it can be shown to be broken via a trivial application/test case (Eg: netcat), then it should be fixed (The trival test case requirement is because I don't want to debug OpenVPN again). 2. Oh god, c.example.com is going to be running a public SOCKS proxy. Granted people trying to use it to get to most destinations will have a connection that fails, but bad people can use it as a DDoS amplification host (The SOCKS dialog is much much shorter than any of the client requests that would be sent). 3. I don't know enough about the OpenVPN protocol/implementation to know if there are application specific quirks unique to OpenVPN that would prevent this configuration from working. That would be an OpenVPN problem, unless obfsproxy is altering the data it's relaying (Extremely unlikely). I'll hold off on closing the ticket for now, but unless the code is broken in the "1." sense, I'm inclined to do so. Regards, -- Yawning Angel pgp040JdSEWuS.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Obfsproxy Address Translation
On Fri, 16 Jan 2015 16:17:38 +0100 Alfredo Palhares wrote: > > My thoughts on the matter are: > > > > 1. This should work. If it can be shown to be broken via a trivial > > application/test case (Eg: netcat), then it should be fixed > > (The trival test case requirement is because I don't want to > > debug OpenVPN again). > OK, what would be the best way to present this data? The easiest quick and dirty one off test I can think of for something like this would be (Using the same hostnames as the example e-mail, fill in the ports to taste): c.example.com: $ obfsproxy --log-min-severity=debug \ > --log-file=/tmp/obfsproxy-client.log \ > obfs3 socks 0.0.0.0:CPORT s.example.com: $ obfsproxy --log-min-severity=debug \ > --log-file=/tmp/obfsproxy-server.log \ > obfs3 --dest vpn.example.com:NPORT \ > server 0.0.0.0:SPORT vpn.example.com: $ nc -l NPORT client: $ nc -x c.example.com:CPORT s.example.com SPORT Typing into either netcat session should send bytes to the other side, on each newline (the newline requirement is due to the TTY code), and has nothing to do with obfsproxy. Naturally c.example.com:CPORT, s.example.com:SPORT and vpn.example.com:NPORT must allow incoming TCP/IP connections. If this doesn't work, c.example.com:/tmp/obfsproxy-client.log and s.example.com:/tmp/obfsproxy-server.log should have enough information to investigate further. Make sure that there is no sensitive information in either logfile, and attach it to the ticket along with the exact commands used on each host. If this does work, you are on your own from that point, because obfsproxy is doing exactly what it is supposed to do (relaying data). > > 2. Oh god, c.example.com is going to be running a public SOCKS > > proxy. Granted people trying to use it to get to most destinations > > will have a connection that fails, but bad people can use it as a > > DDoS amplification host (The SOCKS dialog is much much shorter than > > any of the client requests that would be sent). > The SOCKS proxy will not be public far from that. > The advantage on that is that I setup SOCKS proxy on the best location > that for international traffic. On this specific country international > traffic is very hard from most locations, just because the whole > censorship infrastructure can't deal with all the traffic. Having the > possibility to set it remotely would save work on deploying obfsproxy > trough the OpenVPN clients and to set up yet another HTTP proxy in > between the proxies. This sounds "public" to me, but ok, I'll take your word for it. Regards, -- Yawning Angel pgpReR9Io3KYH.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] oppy - an Onion Proxy in Python
On Wed, 21 Jan 2015 10:20:36 -0800 Damian Johnson wrote: > > Now that I think about it, something that would be great to have in > > Stem would be path selection capabilities. So something like, say, > > given a list of RelayDescriptors and some constraints that must > > hold for a path, return some randomly chosen path that satisfies > > those constraints. > > I'd be up for that. This isn't a very commonly requested piece of > functionality, but it was part of TorCtl (which Stem deprecated in > 2012)... > > https://gitweb.torproject.org/pytorctl.git/tree/PathSupport.py There's a mostly complete implementation in torps, that uses stem. The code isn't very Python-like as afaik it's a straightforward conversion of the tor path selection code. The last time I tried this, downloading and processing all the documents took forever and consumed a hilarious amount of RAM, but I belive stem has seen performance improvements since I tried using it for this. https://github.com/torps/torps Regards, -- Yawning Angel pgpr2VyLy2bvp.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [PATCH] torify/torsocks and TCP Fast Open
On Wed, 21 Jan 2015 15:26:56 -0500 David Goulet wrote: > > +/* > > + * Using TCP Fast Open (TFO) uses sendto() instead of connect() > > with 'flags' > > + * set to MSG_FASTOPEN. Without this code, using TFO simply > > bypasses TOR > > + * without letting the user know. > > + * > > + * This solution simply ignores TFO and falls back to connect(). > > + * At the time the TOR server supports TFO, socks5.c (client code) > > could > > + * implement it in send_data() and connect_socks5(). > > Could you simply clarify this for me meaning what's needed in socks5 > code for TFO to be supported? (no need for an extra comments, just how > would I do that :) This doesn't really make sense when a proxy is in the picture. What would you include as the TFO payload? The "VER | NMETHODS | METHODS" SOCKS5 handshake? In the vast majority of the deployed configurations, the client code talks to tor over a loopback interface, so cutting out 1xRTT isn't worth the added code (There's a case to be made for using TFO for inter-relay traffic, but that's entirely orthogonal to this.). Regards, -- Yawning Angel pgpVhB7cqfu70.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [PATCH] Fix comparison is always true due to limited range of data type
Hello,
On Thu, 5 Feb 2015 04:02:15 -0800 (PST)
Christian Kujau wrote:
> Hi,
>
> I was unable to compile Tor for powerpc32 for a while but I was
> unable to bisect it because of other compilation errors (and "git
> bisect skip" did not help):
>
> [snip]
>
> The last good version to compile for me was
> 4ae729683 ("Try to fix test_checkdir windows compilation more").
> Below is my attempt to fix this issue by declaring "dir" as "signed
> char". It compiles now (4.6.3 and 4.9.1) for powerpc32 and Tor seems
> to work - but please have a look if this is the Right Thing To Do.
Thanks for reporting this. The bug was fixed in master, and should be
in the next 0.2.6.x-alpha release. The fix suggested was fine but was
tweaked somewhat when applied
See: https://trac.torproject.org/projects/tor/ticket/14764
Regards,
--
Yawning Angel
pgpy4jp7142Fy.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] RFC: Ephemeral Hidden Services via the Control Port
ate hidden services is a good idea (SketchORChat has no business in seeing what hidden services JankORFileSharing is using), and that this will automate cleanup in the event of an application crashing, or not removing it's hidden services before terminating. * Does this interface expose enough functionality, in a way that is intuitive and easy to use? (The initial version I was planning on proposing made key generation entirely the application's problem, but nickm convinced me otherwise). Questions, comments, feedback appreciated, -- Yawning Angel pgpeQtjfKpLIu.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Sat, 14 Feb 2015 13:46:04 -0800 Damian Johnson wrote: > One gotcha to think about is that ADD_EPH_HS is using a variable > number of positional arguments. This will limit your ability to expand > this command in the future with new arguments. Also, I'd suggest > renaming addrPort to addrTarget (to avoid making this sound restricted > to a simple port). Hmm ok. Judging by the feedback, I'm thinking the following: * Auth is still a low-ish priority, I want to get the basic ephemeral stuff done first, and I need to read up more on how it works, and how the code is structured, before I can promise things in this area. * People seem to be ok with the tying ephemeral HSes to the originating control port (and if the only major argument against is "it's a bit weird, relative to other things, well, eph. HSes are weird, and this solves a bunch of problems). So this will be implemented as planned. * ADD_EPH_HS syntax changed to something like: "ADD_EPH_HS" keytype:keyblob 1*(SP "Port=" virtPort "," addrTarget) CRLF So, basically, space separated instances of "Port=virtPort,addrTarget" entries, of which there must be at least one. This clearly indicates the argument type and should be future proof (and also has the side benefit of being easier for me to validate. Thoughts? -- Yawning Angel pgp7Nxg_N4dT5.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Mon, 16 Feb 2015 10:17:51 -0500 David Goulet wrote: [snip] > A hidden service is created using the key and list of > port/targets, that will persist till configuration reload or the > termination of the tor process. > > Now, an HS bound to a control connection might be a good idea, I'm not > 100% sure but I can see issues with this. Let's say > "ControlListenAddress" is used, this means a TCP socket and it can > timeout if no activity, so if that happens, I loose my HS? That's correct, though unless tor or the controller library has code to stomp on long dormant connections (which a casual look says there isn't), this shouldn't happen, because TCP/IP in itself has no idle timeout (See RFC 1122 4.2.3.6 regarding keep alives, which would also not cause HS loss, since the OS will respond to the probe). There may be certain broken middleboxes (loadbalancers etc) that stomp on long idle TCP connections, but anyone that is running a control port connection through such a thing, and sending RSA keying material in the clear, probably has bigger things to worry about. > This also put quite a requirement on the user side to add an HS on its > tor-ramdisk for instance but has to use a client that keeps the > control connection opens for its lifetime?... How does that work with > stem, it would have to keep the control connection open and the > script using it can't quit else the socket gets closed by the OS? Yup, I don't see "you need to leave stem running" as being all that bad, since this is mostly targeted at managed applications (chat, filesharing, global leaks, etc). If someone has a suggestion for an alternative interface that can handle applications crashing (possibly before they persist the list of HSes they need to clean up), applications that are just poorly written (and not cleaning up all the ephemeral HSes), and (optionally, though lacking this would be a reduction in features) limiting cross application HS enumeration, I'd be more inclined to change things. Regards, -- Yawning Angel pgpw3rUD3yJJF.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Mon, 16 Feb 2015 16:11:55 + Leif Ryge wrote: [snippity] > However, it seems like in the case of applications which are not > HS-specific this will necessitate keeping another process running > just to keep the HS alive. I'd rather see two modes: one as you > describe, and another in which the ephemeral HS stays running until a > new control port connection requests that it be stopped. To avoid > allowing enumeration of running services, the "stop" command could > require that the requestor already knows some details of the HS - > either a cookie generated at creation time, or perhaps just the > private key that was provided when it was started. dgoulet suggested "Detach=true" as an optional argument, which is what the add side interface would look like if I did this. > This of course wouldn't result in crashed applications' HSes being > cleaned up automatically, but having a few stale HSes sitting around > isn't the end of the world. One approach for cleaning them up could > be that tor could remove them automatically after it sees connection > refused a few times. I'm not quite sure how I feel about this yet. The code for doing all of this isn't that difficult, but I'd want to hear from a few more people about what the right thing to do here would be. Most importantly since the `ADD_EPH_HS` interface uses key/value pairs for the port/target now, this would be easy to add on at a later date even if it doesn't get included in the first iteration. Something to discuss at the dev-meeting if consensus hasn't been reached by then. Regards, -- Yawning Angel pgpfWLpkffCJ7.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Mon, 16 Feb 2015 19:35:58 + Michael Rogers wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > (CCing the hidden-services list.) (Wonder if my reply will bounce.) > On 16/02/15 16:11, Leif Ryge wrote: > >> If someone has a suggestion for an alternative interface that > >> can handle applications crashing (possibly before they persist > >> the list of HSes they need to clean up), applications that are > >> just poorly written (and not cleaning up all the ephemeral HSes), > >> and (optionally, though lacking this would be a reduction in > >> features) limiting cross application HS enumeration, I'd be more > >> inclined to change things. > > > > First, thanks for doing this! I think it's a great feature which > > will make it much easier to create new hidden service > > applications. > > Seconded! > > > I like the idea of tying HS lifetime to the control port connection > > for the reasons you state, namely that cleanup is automatic when > > applications crash. > > As an app developer this strikes me as the right approach. But having > said that, I wouldn't actually need this feature because Briar already > uses __OwningControllerProcess to shut down Tor if the control > connection is closed. I imagine the same would apply to any app that > manages its own Tor process - so this feature would only be useful for > apps that share a Tor process with other apps and communicate directly > with it via the control port, rather than indirectly via a controller > such as Orbot. Yep. I suspect that well behaved applications won't need this for the most part, but by defining things this way, it avoids unpleasant surprises for apps that aren't written well, or those that do try to share a tor instance. > Are there any such apps, and is it a good idea to support such apps > (has the rest of the control protocol been examined for > cross-controller data leaks, what happens if apps tread on each > other's configuration changes, etc)? I haven't looked at other concerns in depth, and AFAIK it's a huge problem area. My concerns in this area are more "does my branch make the current situation any worse", rather than "solve all the control port problems, and make sure this is totally a safe/fine/recommended thing to do" (It's none of those things). If most if not all apps will set _OwningControllerProcess, the current behavior doesn't hurt either since the tor instance will die anyway, and on the off chance that someone writes a not-so-great app (heaven forbid), the right thing happens. > > However, it seems like in the case of applications which are not > > HS-specific this will necessitate keeping another process running > > just to keep the HS alive. > > Dormant processes are essentially free, so does this matter? I have this mindset too. -- Yawning Angel pgpUVCOT7N8h3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Tue, 17 Feb 2015 02:22:54 +0400 meejah wrote: > From my perspective, the entire point of this feature is to allow > applications to use "the system Tor" (or, at least "some > already-running tor") to put their hidden services on. The design the way it is with more isolation than usual also allows for people that use the tails/whonix/or my control port tinfoil hat filter to potentially whitelist the commands as well, since there isn't any information disclosure (unless I screwed up the implementation). Modifying the filters is left up to the implementors (and I probably won't change or-ctl-filter to allow them since I don't use HSes[0]), but I view it as a step forward for including/using applications that use HSes into such environments. > (Or, looking at it another way, if you don't want to share a tor > instance with other applications, you can do that easily today -- you > start up a tor, and can use __OwningControllerProcess as you see fit). > > The *only* reason that txtorcon by default launches a new tor process > for the "onion:" endpoints is because nothing else will work reliably. > > I'd very much like the default to be that it adds a new onion using > Yawning's API. This will still fall back to "launch a new tor > process", but if you know what you're doing you can have a system (or > personal) Tor instance running (with cookie authentication) that can > have hidden services added and removed from it. > > Obviously, this will be a lot faster than launching a new Tor (and > less load or DirAuths). As a bonus, Yawning's API is nice and simple > (versus SETCONF, which makes it super easy to nuke all the *other* > hidden services you configured). > > What I would expect of people using this feature is that the process > that's "adding the hidden service" is the very same one that's > "providing the service"... > > (If you're doing something with a separate nginx or whatever process > running your hidden-service, than you should know enough to be able to > add a couple lines to your torrc and make a normal, "permanent" > hidden-service). Or write a trivial script that prompts for a password, decrypts a HS key, and loads it into a tor instance over the control port. I assume if/when my branch gets merged into mainline tor that the controler APIs will support it in a easy to use manner. > So, in that context, if your application code isn't perfect and might > sometimes crash, definitely the right thing is to nuke the hidden > service. If the app didn't even save its private keys before that > happened, well, too bad. > > I guess to put another way: I can't see a use-case to keep the hidden- > service around if the application that added it went away. It seems a lose consensus is reached here that this is ok, so I'm going to leave the design as is and write the control-spec.txt patch. -- Yawning Angel [0]: The first HS I ever set up was when I finished my first pass implementation, and got the code to a working state. pgpBl_7Y6_Y46.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.4
Hello all, I just tagged obfs4proxy-0.0.4, though the changes do not affect most people directly, I figured it's worth an announcement. Changes in version 0.0.4 - 2015-02-17 - Improve the runtime performance of the obfs4 handshake tests. - Changed the go.crypto import path to the new location (golang.org/x/crypto). - Added client only support for ScrambleSuit. This is more useful for the Tor Browser people than anyone else since it means that the next build can remove the old go.crypto cruft from the build process, and the ScrambleSuit client provider can be switched over to obfs4proxy like obfs2 and obfs3 have been. With Go PTs being phased into Orbot as well, this release should allow for a smooth transition from obfsclient to obfs4proxy. A note about the build time dependency change, for packagers: What: code.google.com/p/go.crypto -> golang.org/x/crypto Why: The Go developers decided to move the repository, and Go libraries are referred to in the code via import location. The source in the code.google.com repo was also updated to mirror the new repository, so internal dependencies all reference the new location. Workarounds: If changing the build time dependency is not an option, you have an existing go.crypto package that will not change, and you are building with Go < 1.4, revert: cdeda5724124ca393c87be6d01c84fe4f906d612 Old copies of go.crypto will not compile with newer versions of the Go compiler so packaging golang.org/x/crypto is advised in the medium to long term. Questions, comments, feedback appreciated, -- Yawning Angel pgpOlSZ55i9Uj.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Hello, Not sure about the renaming thing. I'm open to doing so, but a lot of the user facing stuff (the torrc configuration variables etc) use the HS terminology, so I'm not sure if being inconsistent is good. On Wed, 25 Feb 2015 13:51:59 +0100 carlo von lynX wrote: > On Wed, Feb 25, 2015 at 07:41:01AM +0100, Andreas Krey wrote: > > The AF_TOR listener would go away with closing the listener socket > > as well (and thus is bound to the lifetime of the process); so > > binding a hidden service to the control connection is the obvious > > analogy. > > Yes, but as it stands AF_TOR is not the #1 API deployed in network > applications. The majority of hidden services are $whatever configured > to listen on port localhost:something and zero awareness of any tor > router doing the rest of the work. Having to change hundreds of > existing apps so that they can work with tor without having to edit > torrc is a worse tradeoff than having to edit torrc. So, write a python script that pulls in txtorcon or stem, does the appropriate controller goo, and subprocess.call()s $whatever. Anyway now that master is 0.2.7.x, I'm looking to revisit this in the form of: * Renaming the commands if necessary. * Minor code cleanups (that occurred to me after I let it sit for a while). * Adding an argument to `ADD_EPH_HS` to suppress the private key being returned over the control port, when the caller requests that tor generate the keypair (for cases where the HS is truely oneshot and the user does not wish to preserve it). * Documentation. Regards, -- Yawning Angel pgpAaj3f82G9d.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Wed, 25 Feb 2015 16:14:47 + Yawning Angel wrote: > Anyway now that master is 0.2.7.x, I'm looking to revisit this in the > form of: [snip] I talked to a few people at Valencia about this, including discussing the outstanding issues and made the following changes since the last discussion: * ADD_EPH_HS/DEL_EPH_HS are now ADD_ONION/DEL_ONION. * An optional "DiscardPK" argument can now be provided to suppress including the newly generated private key in the response (for one-shot, never-want-to-recreate-ever HSes, there's no reason to pass the private key around). * Minor cleanups. The code: https://github.com/Yawning/tor/compare/feature6411 The spec: https://github.com/Yawning/torspec/compare/feature6411 The spec change can probably use proofreading, corrections, and clarification, but those aren't my strong point(s). Assuming that no unpleasant surprises pop up, I will rebase/squash down my feature branch and seek code review/merge into master (0.2.7.x). Questions, comments, feedback appreciated[0], -- Yawning Angel [0]: Onions added this way will remain tied to the control port connection that created them for now. That particular dead pony has been loaded onto the cart and shipped off to the glue factory, and is no longer available for beatings. pgpLBEYTU5tBd.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
On Wed, 11 Mar 2015 02:35:10 + Yawning Angel wrote: > The code: https://github.com/Yawning/tor/compare/feature6411 > The spec: https://github.com/Yawning/torspec/compare/feature6411 Minor updates to both over the course of yesterday, thanks to all that gave useful feedback and corrections. The notable changes are: * "DiscardPK" is now "Flags=DiscardPK", to allow for. > [0]: Onions added this way will remain tied to the control port > connection that created them for now. That particular dead pony has > been loaded onto the cart and shipped off to the glue factory, and is > no longer available for beatings. * I lied. People that want to shoot themselves in the foot can now specify the "Detach" flag which explicitly unlinks the newly created HS from any control port instance. "Detach"ed Onion Services will persist till tor termination, or explicitly removed by "DEL_ONION". * "DEL_ONION" now will allow the removal of Onion Services belonging to the current connection in addition to any Onion Service created with the "Detach" flag. * Added "GET_ONIONS" that returns a list of Onion Services belonging to the current connection in addition to all Onion Services created with the "Detach" flag. I strongly recommend ignoring the fact that the "Detach" flag and "GET_ONIONS" command exists, beyond reviewing my code and making sure they're implemented correctly. That said, I know multiple developers will probably write applications that implements "cleanup" as "DEL_ONION ALL THE THINGS", stomping over unrelated "Detach"-ed services[0]. Unless something comes up, I plan to rebase/squash my feature branch for review sometime by early next week, so if people have strong opinions on this feature, they should speak up now. Regards, -- Yawning Angel [0]: I have my "not a bug"/"wontfix" ready for such situations. pgpZA9563xnv3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Pluggable transports meeting tomorrow (16:00 UTC Wednesday 18th of March 2015)
(Trying to get these back onto a regular schedule now that dev-meeting madness is over.) Just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#PluggableTransportIRCmeetings -- Yawning Angel ps: UTC does not do daylight savings. Those of you that have had clocks change, please double check the time and let me know if we need to change the time. pgpDv6z9btUDC.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Wide block cipher experiment.
Hello, Nickm mentioned to me that he was curious as to how LIONESS performs these days (See #5460) with modern cryptographic primitives. I've conveyed the results to several people, but I'm also sending them here for posterity. Code used: https://github.com/yawning/lioness (May be incorrect, don't use for anything other than benchmarking. Numbers taken with a previous version of the code without the initial memcpy, that was added later so that the code in git could be used by the extremely brave for other things.) All measurements taked on an i5-4250U, so the usual caveats about turboboost and hyperthreading apply. Baseline (from tests/bench, AES-NI enabled): = cell_ops = Inbound cells: 231.33 ns per cell. (0.45 ns per byte of payload) Outbound cells: 224.39 ns per cell. (0.44 ns per byte of payload) (Note: Outbound with AES-NI disabled is ~3.0 ns per byte) LIONESS (BLAKE2b/ChaCha, 509 byte block size): * ChaCha20: * Ted Krovetz's AVX2-ed ChaCha20/Ref AVX BLAKE2b: ~6.6 ns/byte (~143 MiB/s) * AVX2ed-ed ChaCha20, Andrew Moon's AVX2-ed Blake2b: ~5.0 ns/byte (~190 MiB/s) * ChaCha12: * Ted Krovetz's AVX2-ed ChaCha12/Ref AVX BLAKE2b: ~6.1 ns/byte (~156 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.4 ns/byte (~213 MiB/s) * ChaCha8: (Yolo swag 420 blaze it) * Ted Krovetz's AVX2-ed ChaCha8/Ref AVX BLAKE2b: ~5.8 ns/byte (~164 MiB/s) * AVX2ed-ed ChaCha12, Andrew Moon's AVX2-ed Blake2b: ~4.1 ns/byte (~232 MiB/s) NB: Using Andrew Moon's Blake2b isn't in git, because the way I tested it was kind of kludgey. Profiler output: 64.04% lioness_test_av lioness_test_avx2 [.] blake2b_compress 22.43% lioness_test_av lioness_test_avx2 [.] chacha_stream_xor 6.60% lioness_test_av lioness_test_avx2 [.] blake2b_init_key 2.72% lioness_test_av lioness_test_avx2 [.] blake2b 2.41% lioness_test_av libc-2.21.so [.] __memcpy_avx_unaligned 1.07% lioness_test_av lioness_test_avx2 [.] lioness_encrypt_block Ted Krovetz's ChaCha implementation isn't quite the fastest out there, but it doesn't lag massively behind Andrew Moon's. Benchmarks on the same hardware from Andrew Moon's chacha-opt/blake2b-opt are: BLAKE2b: 576 byte(s): avx2, 1468.00 cycles per call, 2.5486 cycles/byte avx, 1674.00 cycles per call, 2.9062 cycles/byte x86, 2020.00 cycles per call, 3.5069 cycles/byte generic/64, 2638.00 cycles per call, 4.5799 cycles/byte ChaCha20: 576 byte(s): avx2, 694.00 cycles per call, 1.2049 cycles/byte avx, 1104.00 cycles per call, 1.9167 cycles/byte ssse3, 1112.00 cycles per call, 1.9306 cycles/byte sse2, 1376.00 cycles per call, 2.3889 cycles/byte x86, 2528.00 cycles per call, 4.3889 cycles/byte generic, 3200.00 cycles per call, 5.5556 cycles/byte I don't think using CTR-AES (with AES-NI) in a LIONESS construct is going to be that big of a win, at least on my hardware, and the sort of performance I'm seeing feels too much of a performance hit to me. Regards, -- Yawning Angel pgpDNb5K2d0Nd.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
Hello all, Just a quick heads up for where this is going: * 'GET_ONIONS' was changed to be 'GETINFO' subcommands for consistency. * Code is in 'needs_review', for the 2nd round. As a proof of concept I wrote: https://github.com/Yawning/onionwrap It's a dumb quick and dirty hack that works like this: $ TOR_CONTROL_PORT=9251 ./onionwrap -port="80,8080" godoc -http=%TADDR INFO: Created onion: 5rn73le64hri2zmp.onion:80 -> 127.0.0.1:8080 [onionwrap blocks till killed] The %TADDR notation is a convenience thing for automation, there's also %TPORT, and %VPORT that get rewritten as appropriate. The onionwrap code is still incomplete, so I wouldn't recommend using it quite yet, especially since it: * Only supports creating one shot Onion Services. * Should support talking to the real server over AF_UNIX. * Needs documentation. * Requires a really experimental branch based on tor's master. * Maybe should use stem/txtorcon instead of bulb[0]. But as a proof of concept and a demonstration of the feature, I think it gets the point across. Thanks to special for inspiring me to write this. Regards, -- Yawning Angel [0]: Which is another quick and dirty hack I wrote, so I could write things like this. pgpEG1HqWaqA8.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Are DAC_OVERRIDE & CHOWN capabilities required for ControlSocket?
On Sun, 12 Apr 2015 12:46:26 +
Nusenu wrote:
> tor will fail to startup with the current systemd service file [1]
> if your torrc makes use of the ControlSocket feature.
>
> To work around the issue one has to additionally allow the following
> capabilities:
> CAP_DAC_OVERRIDE
> CAP_CHOWN
> since the socket file is create as root and then changed to the tor
> user (chown).
>
> Is it possible to change this to not require
> CAP_DAC_OVERRIDE and CAP_CHOWN capabilities anymore?
I bet using the AF_UNIX SocksPort stuff will break as well, since the
code is common. All of the listeners are launched before switching
uid/gid and dropping privileges since it's common code.
The way to fix this would be to change retry_listener_ports and
retry_all_listeners code to additionally allow only launching service
ports (< 1024), and staging the listener launch process on config
(re)load to something that looks like:
1. Launch listeners that require elevated priviledges
(CAP_NET_BIND_SERVICE).
2. Drop priviledges and switch the uid/gid.
3. Launch the rest of the listeners, including all of the AF_UNIX
based ones (as the runtime tor user, so neither privilege is
required).
Patches accepted.
--
Yawning Angel
pgpCrZZmkj5AW.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Fwd: Orbot v15 RC3... now with x86/ATOM-power!
On Mon, 13 Apr 2015 10:14:43 -0400 Nathan Freitas wrote: > One interesting issue is that GoLang 1.4.1, which we are using to > cross-compile the Meek and Obfs4 pluggable transports to Android, only > supports targeting Android ARM for right now... I assume that will > change soon, but if not, we may have to add Obfsclient back into Orbot > for supporting x86 devices. Hmm, maybe I should add obfs4 support to obfsclient. I have code for all of the crypto I would need to add. Regards, -- Yawning Angel pgpROO5FvVuvJ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Release: obfs4proxy-0.0.5
Hello all, I just tagged obfs4proxy-0.0.5, this time with improvements for both clients and servers. All users are recommended to upgrade. Special thanks to mvdan for various code cleanups. Tarball/Signature: https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5.tar.xz https://people.torproject.org/~yawning/releases/obfs4proxy/obfs4proxy-0.0.5.tar.xz.asc Changes in version 0.0.5 - 2015-04-15: - Go vet/fmt fixes, and misc. code cleanups. Patches by mvdan. - Changed the go.net import path to the new location (golang.org/x/net). - Added limited support for detecting if the parent process crashes. - Support for tor feature #15335 (stdin based termination notification). - Moved the leveled logging wrappers into common/log so they are usable in transport implementations. - Added a DEBUG log level. - Use a bundled SOCKS 5 server instead of goptlib's SocksListener. The big features are: - obfs4proxy now tries really hard to detect if the parent process has crashed, using various system specific hacks (and the new and improved tor assisted mechanism in #15335). This should reduce defunct obfs4proxy processes when tor happens to crash without tearing down the obfs4proxy instance. - Instead of using goptlib's SOCKS4a server, obfs4proxy now includes a SOCKS5 implementation, bringing IPv6 support to clients. Note that running IPv6 bridges has always worked (though dual stack configs are currently somewhat broken due to a tor PT configuration protocol limitation). Notes for packagers: - Like in obfs4proxy-0.0.5, one of the upstream dependency locations has changed. (code.google.com/p/go.net -> golang.org/x/net). As far as I am aware, migrating to the new package immediately is not required though, should be done sooner rather than later due to the impending deprecation of code.google.com. To temporarily continue to build against the old go.net dependency, please revert: aed4b723891db1be34eb866a03c62806b58ac148 - It is *strongly* recommended that packages be built against goptlib-0.4 or newer to work around tor bug #15240. Without this workaround, certain bridges will fail to operate correctly when the ExtORPort is enabled (the Tor side fix is in tor-0.2.6.5-rc and newer). Questions, comments, feedback appreciated, -- Yawning Angel pgpyviXcC_LtQ.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Release: obfs4proxy-0.0.5
On Thu, 16 Apr 2015 14:03:58 -0400 (EDT) "Steve Snyder" wrote: > The v0.5 binary is substantially larger than the v0.4 binary (7204KB > vs.5408KB, both built with Go v1.4.2). > > Is this expected behavior with the newer version of obfs4proxy? Building on linux/amd64 with 1.4.2 I get: * 0.0.4 7441792 * 0.0.5 7424544 If I strip either binary I get something in the 5 MiB range, so that might be where the difference is coming from, though I would strongly discourage doing so as it is not something that is supported by the toolchain developers[0], and if a binary that has been stripped breaks, I'm not going to do anything about it beyond saying "don't do that". Regards, -- Yawning Angel [0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717172 pgp6H1n7luQdM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor's "make test" fails when run on tails
On Mon, 27 Apr 2015 05:49:37 + warms0x wrote: > I am trying to execute tor's tests from git (63a90f2) on tails but the > socketpair_ersatz test keeps failing > > util/socketpair: [forking] OK > util/socketpair_ersatz: [forking] > > FAIL src/test/test_util.c:4212: assert(0 OP_EQ > tor_socketpair_fn(family, SOCK_STREAM, 0, fds)): 0 vs -111 > [socketpair_ersatz FAILED] util/max_mem: OK > > > The failure seems to be in connect(): > https://gitweb.torproject.org/tor.git/tree/src/common/compat.c#n1492 Considering that the error returned is -ECONNREFUSED, this is a reasonable assumption, yes. > armadev said on IRC that he/she could make the tests pass, so I wonder > if there might be some specific behavior on tails that prevents the > test from passing successfully. On a normal system, the tests pass fine, and it would be a bug if they didn't. Did you look at the `tor_ersatz_socketpair()` code at all? It should be obvious why this is failing on Tails. > Is there a suggested workaround? Or perhaps is it possible to easily > ignore this one test? Suggested workaround(s): * Don't use Tails, the tests are written under the assumption that they are running on a normal system that doesn't have a facist firewall preventing connections to things listening on the loop back interface. * Patch the test code to disable that test. * Maybe use torsocks with "AllowOutboundLocalhost", if the version included in Tails supports the option (I'd hope so, I added support for that feature to torsocks specifically for them). Other tests may or may not fail if you chose to go down this path. Regards, -- Yawning Angel pgpf9q_ceZn_j.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
