Re: [tor-dev] Proposal xxx: Further SOCKS5 extensions (Was Pluggable transport SOCKS5 extensions)
28.02.2014 09:53, Yawning Angel: 2.2. Tor Extended SOCKS5 Reply Codes We introduce the following additional SOCKS5 reply codes to be sent in the REP field of a SOCKS5 message. Implementations MUST NOT send any of the extended codes unless the initiator has indicated that it understands the Tor Extended SOCKS5 Authentication as part of the version identifier/method selection SOCKS5 message. Where: * X'E0' Hidden Service Not Found The requested Tor Hidden Service was not reachable. * X'E1' Hidden Service Not Reachable The requested Tor Hidden Service was not found. To me it is clear that the two are messed up, but I'm not sure what's the correct order. X'E0' means either it couldn't be found or it is not reachable, but is the description wrong or the error message? Regards, Sebastian (bastik) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request to expunge project 'torsocks' on Google Code
On 28 Feb (22:19:39), Roger Dingledine wrote: On Wed, Feb 26, 2014 at 02:06:25PM +0100, Jeroen Massar wrote: On 2014-02-26 13:46, Jacob Appelbaum wrote: I think this is a fine idea - if no one objects, I'll purge it. No objection per-se, but a recommendation/check-up: Sounds great to me -- disabling it seems like the best option, along with (if doable) marking it as moved to the new url. As Jeroen says, we don't want somebody showing up and starting a google code project called torsocks. (I just found myself trying to help somebody on #tor with torsocks, and it was totally not clear to me where torsocks actually lives today.) Just to follow up this. The current code (1.3) is at git.tpo.org/torsocks.git. The 2.x version is at https://github.com/dgoulet/torsocks. Hopefully, we get the new one soon upstream and that would mean one central point for the code. I'll join #tor so I can help with torsocks questions. Thanks! David Thanks! --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: 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 to remove goto from sandbox.c
Hartmut Prochaska: I changed a function in sandbox.c to not use a goto statement. I didn't understood what use it had. Attached the patch file. See https://www.kernel.org/doc/Documentation/CodingStyle, Chapter 7, “Centralized exiting of functions” for a rationale. -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] [weather-rewrite] Update on hourly-script
Hi, I second Abhiram's opinion, let's see if this comes in handy. Thanks for the tip, anyway! Lukas, if you're interested, we generally meet in #tor-dev Wednesdays, 18:00 UTC. Come join in if you want to, we generally talk about what we worked on and what the next steps are. Feel free to contribute! Cheers, Oliver On 03/01/14, Abhiram Chintangal wrote: Lukas, Thanks for the suggestion. Celery sounds like good option, I will try to look into it once I find time. About the coding part, in the coming days we are planning on integrating these hourly and daily scripts with the existing web-application. If you are interested you can take a look at the projects wiki page[1]. Cheers! Abhiram [1]: https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 On Sat, Mar 1, 2014 at 8:16 AM, Lukas Erlacher t...@lerlacher.de wrote: Hello, I've been following the tor rewrite for a while. While I don't currently see where I could directly help out with code, I have the following hint: Celery[1] is a task/queue management system that has excellent django integration and can be used to solve the how to perform the hourly query question mentioned on the github page. Best regards, Luke [1] http://celery.readthedocs.org/en/latest/django/first-steps-with-django.html On 02/27/2014 10:18 PM, Oliver Baumann wrote: Hi Team, please see [1] for the current status of the hourly bandwidth script and feel free to comment on any improvements! Currently it's just a script calling several functions and performing some work 'off hand'. Once we move into integrating with a webapp, refactoring should make this nice and object-oriented :) Have a nice weekend and happy hacking, Oliver [1] https://trac.torproject.org/projects/tor/ticket/10697 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev -- Abhiram Chintangal ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev pgpxgCqmMWzEe.pgp Description: PGP signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] HOWTO use Lantern as a pluggable transport
I met today with some developers of Lantern (https://getlantern.org/,
https://github.com/getlantern/lantern). Lantern acts as an HTTP proxy
and proxies your traffic through trusted friends. We found that we had
the pieces necessary to make Lantern a pluggable transport of Tor; that
is, use Lantern as a transport for Tor traffic where Tor is blocked but
Lantern is not. Here's what we did to make it work.
Lantern is an HTTP proxy. As luck would have it, I have lately been
working on a transport that encodes data in HTTP requests
(https://lists.torproject.org/pipermail/tor-dev/2014-January/006159.html).
meek was designed for a completely different purpose--tunneling traffic
through App Engine--but it turned out to be almost perfect for the
Lantern case, too. The only thing it was missing was support for an
upstream HTTP proxy. We used the attached patch to add proxy support and
hardcode Lantern's proxy port of 8787.
meek normally connects to App Engine, and uses a TLS trick to make it
look like it is going to www.google.com. The meek-client program
connects App Engine, and then App Engine forwards traffic to the bridge.
The configuration looks like this:
ClientTransportPlugin meek exec meek-client
--url=https://meek-reflect.appspot.com/ --front=www.google.com
With Lantern it's a bit different. We don't need to do the TLS fronting
trick because we use Lantern as an opaque HTTP-carrying transport.
Instead of going through App Engine, we tell meek-client to make
requests directly to the Tor bridge (where directly means directly
through the Lantern proxy).
ClientTransportPlugin meek exec meek-client
--url=http://tor1.bamsoftware.com:7002/
And that's all. We downloaded one of the experimental meek bundles from
https://people.torproject.org/~dcf/pt-bundle/3.5.2.1-meek-1/, copied in
the patched meek-client binary, and made the above change to the
ClientTransportPlugin line in torrc-defaults. With Lantern already
running and configured on the same machine, we started tor and it
bootstrapped.
I'll take the proxy patch and modify it so that the proxy address is not
hardcoded, so that you can configure it from the command line. It could
also be useful for users who need pluggable transports but are stuck
behind an HTTP proxy.
Special thanks to Ox from Lantern who pair-programmed this with me.
David Fifield
commit bd54bdd4b8d0ac66834fa4897cbea97eac0df120
Author: David Fifield da...@bamsoftware.com
Date: Sat Mar 1 15:29:46 2014 -0800
Use fixed HTTP proxy http://127.0.0.1:8787/.
diff --git a/meek-client/meek-client.go b/meek-client/meek-client.go
index 6ed9289..872e23f 100644
--- a/meek-client/meek-client.go
+++ b/meek-client/meek-client.go
@@ -36,6 +36,14 @@ var globalURL string
var handlerChan = make(chan int)
func roundTrip(buf []byte, u, host, sessionId string) (*http.Response, error) {
+ proxyURL, err := url.Parse(http://127.0.0.1:8787;)
+ if err != nil {
+ return nil, err
+ }
+ proxyFunc := http.ProxyURL(proxyURL)
+ tr := http.Transport{
+ Proxy: proxyFunc,
+ }
req, err := http.NewRequest(POST, u, bytes.NewReader(buf))
if err != nil {
return nil, err
@@ -45,7 +53,7 @@ func roundTrip(buf []byte, u, host, sessionId string) (*http.Response, error) {
}
req.Header.Set(Content-Type, application/octet-stream)
req.Header.Set(X-Session-Id, sessionId)
- return http.DefaultTransport.RoundTrip(req)
+ return tr.RoundTrip(req)
}
func sendRecv(buf []byte, conn net.Conn, u, host, sessionId string) (int64, error) {
___
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.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
[tor-dev] Damian's Status Report - February 2014
It was great meeting everyone in Reykjavík! February largely went toward GSoC prep. Thanks to everybody that sent me project ideas! https://blog.torproject.org/blog/tor-google-summer-code-2014 This left a lot less time than I'd like for coding. The only noteworthy changes this month were... * Added a new 'stem.util.test_tools' module for easily running Pyflakes and PEP8 checks... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/util/test_tools.py Stem, ExitMap, and arm all do these checks as part of their tests so this let them shed quite a bit of boilerplate. Want these checks for your own project? It's easy, so give it a try! https://gitweb.torproject.org/user/atagar/exitmap.git/blob/HEAD:/run_tests.py * Stem tutorial example for checking the Tor exits you're using for your connections... https://stem.torproject.org/tutorials/to_russia_with_love.html#determine-the-exit-you-re-using * Couple new Controller methods for checking where Tor is listening for connections of a given type... https://stem.torproject.org/api/control.html#stem.control.Listener https://stem.torproject.org/api/control.html#stem.control.Controller.get_ports https://stem.torproject.org/api/control.html#stem.control.Controller.get_listeners for listener_type in stem.control.Listener: ... ports = map(str, controller.get_ports(listener_type)) ... print %s ports: %s % (listener_type, ', '.join(ports)) ... OR ports: DIR ports: SOCKS ports: 9050 TRANS ports: NATD ports: DNS ports: CONTROL ports: 2779 * Gave Sphinx's aafig module a try to see if it could improve our API overviews... https://www.atagar.com/transfer/stem/overview_before.png https://www.atagar.com/transfer/stem/overview_after.png In the end I decided against it since this doesn't add much, and it causes us to render the overview as a svg (so users can't copy/paste function names). * Sent Philipp some improvements for ExitMap... https://lists.torproject.org/pipermail/tor-dev/2014-February/006162.html Cheers! -Damian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
