Re: [tor-dev] Proposal idea: Stop assigning (and eventually supporting) the Named flag
On 10/04/14 09:45, Sebastian Hahn wrote: Filename: xxx-kill-named-flag.txt Title: Stop assigning (and eventually supporting) the Named flag Authors: Sebastian Hahnn Created: 10 April 2014 Target: 0.2.5 Status: Draft 1. Intro and motivation Currently, Tor supports the concept of linking a Tor relay's nickname to its identity key. This happens automatically as a new relay joins the network with a unique nickname, and keeps it for a while. To indicate that a nickname is linked to the presented identity, the directory authorities vote on a Named flag for all relays where they have such a link. Not all directory authorities are currently doing this - in fact, there are only two, gabelmoo and tor26. For a long time, we've been telling everyone to not rely on relay nicknames, even if the Named flag is assigned. This has two reasons: First off, it adds another trust requirement on the directory authorities, and secondly naming may change over time as relays go offline for substantial amounts of time. Now that a significant portion of the network is required to rotate their identity keys, few relays will keep their Named flag. We should use this chance to stop assigning Named flags. If I understand the proposal correctly, operators will still be able to name their relay or bridge, and people can still find it in Atlas or Globe by this nickname. If so, great! 2. Design None. Tor clients already support consensuses without Named flags, and testing in private Tor networks has never revealed any issues in this regard. 3. Implementation The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise. What's the process here? Ask on tor-dev@ if anybody sees a problem if the Named and Unnamed flags go away, wait for a week, and then just do it? All the best, Karsten Once this has been shown to not cause any issues, support for the Named flag can be removed from the Tor client implementation, and support for the NamingAuthoritativeDirectory can be removed from the Tor directory authority implementation. 4. Open questions None. ___ 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
[tor-dev] [Flashproxy] Some sites filtering users?
Hey all, Got a report from a friend* who noticed that twitch.tv stops letting him watch broadcasts while flashproxy is in an active state. He uses Cupcake, which shows flashproxy's status in the icon bar, and he only has an issue when the cupcake icon has a mustache. Has anyone noticed similar behavior when using flashproxy? ~Griffin * who is a hacker ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal idea: Stop assigning (and eventually supporting) the Named flag
On 18 Apr 2014, at 15:02, Karsten Loesing kars...@torproject.org wrote: If I understand the proposal correctly, operators will still be able to name their relay or bridge, and people can still find it in Atlas or Globe by this nickname. If so, great! Yes, this is in no way related to the nickname field. The gabelmoo and tor26 directory authorities can simply remove the NamingAuthoritativeDirectory configuration option to stop giving out Named flags. This will mean the consensus won't include Named and Unnamed flags any longer. The code collecting naming statistics is independent of Tor, so it can run a while longer to ensure Naming can be switched on if unforeseen issues arise. What's the process here? Ask on tor-dev@ if anybody sees a problem if the Named and Unnamed flags go away, wait for a week, and then just do it? I don't know, I want to move gabelmoo to a new machine and don't really want to set up the naming system. So I guess the above process as soon as possible :) Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Please try 3.5.4-meek-1 bundles (covert HTTPS pluggable transport)
A while back I wrote about a pluggable transport called meek that routes your traffic through a third-party web service in a way that should be difficult to block. There are now experimental bundles featuring this transport, ready for somewhat wider testing. Please try: https://people.torproject.org/~dcf/pt-bundle/3.5.4-meek-1/ The files are signed with my key 0xC11F6276 from: https://www.torproject.org/docs/signing-keys https://www.bamsoftware.com/david/david.asc You don't have to do anything in the configuration. Just click Connect. What you'll see, if you look at your network traffic, is a lot of HTTPS requests to www.google.com. (And no connections to any Tor bridge, nor anything speaking the Tor protocol.) Behind the scenes, Google is passing the requests on to our web app, which then forwards them to a Tor bridge. More on how the whole system works is at https://trac.torproject.org/projects/tor/wiki/doc/meek. Another thing to know is that starting the browser will run a second, headless instance of Firefox. The second browser is used as a tool for making HTTPS requests. It's the same Firefox binary used by Tor Browser (so it doesn't increase the size of the bundles), but it has a special configuration and an extension that allows it to access the network directly. When you're using meek, this browser extension is in fact the only thing that touches the network, but you never interact with it directly--it only takes orders from the client transport plugin. We do it this way so that the HTTPS requests look like they come from a browser, and are not fingerprintable as coming from some custom SSL program. The second browser should be completely invisible to you--except on OS X, where it creates a second dock icon (this is bug #11429). These bundles are experimental and you shouldn't use them to replace your main browser just yet. We're most interested in hearing about what didn't work for you or what was surprising. I'll write another post about code review and other things that need to happen before you'll see meek in a mainline bundle. David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Code review for meek
There are a lot of components that make up the meek transport. There is the client and server, and then there is the middle part that runs on App Engine, and the browser extension that ensures we are speaking HTTPS the right way. I'm working towards deploying the transport, and to that end I'd like to encourage code review. This is your chance to get in on the ground floor of a new transport! The purpose of review is to find bugs. Yawning found one already in the server component (the server didn't put a time limit on handling requests). Even comments such as it's not clear what this part of the code is doing are useful, because those parts of the code can hide bugs. The following are, in my opinion, the files most in need of review. Most of them are under 350 lines, so they shouldn't be too hard to get into. The languages used are JavaScript for the browser extensions and Go for everything else. The overall information flow is tor ↔ meek-client ↔ extension ↔ reflector ↔ meek-server ↔ tor Also look at https://trac.torproject.org/projects/tor/wiki/doc/meek#Overview to get a feel for precisely what packets get sent. Client plugin (meek-client) https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/meek-client/meek-client.go https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/meek-client/helper.go Server plugin (meek-server) https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/meek-server/meek-server.go Reflector (the part that runs on App Engine) https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/appengine/reflect.go Firefox extension (#11183) https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/firefox/components/main.js https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/blob/refs/heads/meek:/Bundle-Data/PTConfigs/meek-http-helper-user.js Chrome extension (#11393) (Not currently part of the bundle, but you can run it manually.) https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/chrome/app/background.js https://gitweb.torproject.org/pluggable-transports/meek.git/blob/HEAD:/chrome/extension/background.js Browser bundle packaging (#10935) https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/commitdiff/tbb-3.5.4-meek-1?hp=tbb-3.5.4-build3 David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] consensus-health.torproject.org
I think I can make some improvements to the consensus-health page (mostly removing redundant formatting code in the HTML), but I can't seem to find the git repo for the project listed at https://gitweb.torproject.org/ Could someone point me in the right direction? I another pertinent question would be: is anyone using any scripts that scrape this page, which might be broken if things are changed? An example of a change could be: since the flags in the Consensus column seem to always be blue, remove all the font color=blue tags, (and closing tags) in the consensus column, and replace them with one class per td in that column. I estimate that this change alone would save about 575KiB in the uncompressed HTML. That's about 10% of the document's uncompressed size, without even using any CSS3 trickery. -- Mike Wolf ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
