[tor-dev] #if 0 unused functions?
Hi there, we have some functions which we never call anywhere. In many cases, it appears we shouldn't delete them from the source because they "belong" there - the thing I initially stumbled across was ed25519_seckey_write_to_file(), for example. But I also don't see why compiling it and potentially including it in our binary makes any sense. Thoughts? Cheers Sebastian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Update: Proposal 237 - All relays are directory servers
Hi All, Here's an updated version of prop 237. I rewrote some parts for clarity and brought it inline with the current implementation for #12538. Updated branch on prop237_update in my torspec repo. Thanks! Matt Filename: 237-directory-servers-for-all.txt Title: All relays are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Open Target: 0.2.7.x Overview: This proposal aims at simplying how users interact directly with the Tor network by turning all relays into directory servers (also known as directory caches), too. Currently an operator has the options of running a relay, a directory server, or both. With the acceptance (and implementation) of this proposal the options will be simplified by having (nearly) all relays cache and serve directory documents, without additional configuration. Motivation: Fetching directory documents and descriptors is not always a simple operation for a client. This is especially true and potentially dangerous when the client would prefer querying its guard but its guard is not a directory server. When this is the case, the client must choose and query a distinct directory server. At best this should not be necessary and at worst, it seems, this adds another position within the network for profiling and partitioning users. With the orthogonally proposed move to clients using a single guard, the resulting benefits could be reduced by clients using distinct directory servers. In addition, in the case where the client does not use guards, it is important to have the largest possible amount of diversity in the set of directory servers. In a network where (almost) every relay is a directory server, the profiling and partitioning attack vector is reduced to the guard (for clients who use them), which is already in a privileged position for this. In addition, with the increased set size, relay descriptors and documents are more readily available and it diversifies the providers. Design: The changes needed to achieve this should be simple. Currently all relays download and cache the majority of relay documents in any case, so the slight increased memory usage from downloading all of them should have minimal consequences. There will be necessary logical changes in the client, router, and directory code. Currently directory servers are defined as such if they advertise having an open directory port. We can no longer assume this is true. To this end, we will introduce a new server descriptor line. "tunnelled-dir-server" NL The presence of this line indicates that the relay accepts tunnelled directory requests. For a relay that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and the line MAY be added if it also advertises an open directory port. In addition to this, relays will now download and cache all descriptors and documents listed in the consensus, regardless of whether they are deemed useful or usable, exactly like the current directory server behavior. All relays will also accept directory requests when they are tunnelled over a connection established with a BEGIN_DIR cell, the same way these connections are already accepted by bridges and directory servers with an open DirPort. Directory Authorities will now assign the V2Dir flag to a server if it supports a version of the directory protocol which is useful to clients and it has at least an open directory port or it has an open and reachable OR port and advertises "tunnelled-dir-server" in its server descriptor. Clients choose a directory by using the current criteria with the additional criterion that a server only needs the V2Dir status flag instead of requiring an open DirPort. Security Considerations and Implications: Currently all directory servers are explicitly configured. This is necessary because they must have a configured and reachable external port. However, within Tor, this requires additional configuration and results in a reduced number of directory servers in the network. As a consequence, this could allow an adversary to control a non-negligable fraction of the servers. By increasing the number of directory servers in the network the likelihood of selecting one that is malicious is reduced. Also, with this proposal, it will be more likely that a client's entry guard is also a directory server (as alluded to in Proposal 207). However, the reduced anonymity set created when the guard does not have, or is unwilling to distribute, a specific document still exists. With the increased diversity in the available servers, the impact of this should be reduced. Another question that may need further consideration is whether we trust bad directories to be good guards and exits. Specification: The version 3 directory protocol specificatio
[tor-dev] Directory Server Consensus Status Flag
Hi all, I'd like some opinions. Currently authorities give relays the V2Dir if they are useful directory servers. Clients don't actually care about this flag in any way, but it's a useful visual indicator. With proposal 237 (All relays are directory servers) and #12538 as its implementation, the current plan is to continue using the V2Dir flag, but now clients will actually care if a relay has the V2Dir flag and choose directory servers based on it. Tickets #11103 and #1338 actually wanted to get rid of the V2Dir flag, for good reasons. If we're going to rename the flag, we should do it before #12538 is merged, and probably make the change in the same branch. The V2Dir flag needlessly specifies an unuseful protocol version. #1338 suggested switching to a V3Dir flag, but it was decided this was not such a good idea. Proposal 185 chose a "DirCache" Consensus flag. I think either "DirServer" or "DirCache" are good choices for this, but DirServer is more in line with the wording used in Prop 237. Are there any objections to changing the name of the flag? (There will be another email in a few minutes with an updated version of prop 237.) Thanks! Matt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Call for a big fast bridge (to be the meek backend)
On Thu, Sep 18, 2014 at 08:41:20AM -0700, David Fifield wrote: > On Thu, Sep 18, 2014 at 02:02:42PM +0100, Ximin Luo wrote: > > On 18/09/14 03:31, David Fifield wrote: > > > Currently in the bundles we're not setting a bridge fingerprint, so > > > relays wouldn't have to share a key. > > > > > > > This is something to be *fixed*, not to build future components on top of. > > > > Previously you mentioned that "the user could set their circuits to 4 > > hops" but I think this is a hack of a solution and we can do better, > > by authenticating the Bridge. > > I really disagree with you here :( I don't understand your point of > view. Let's try and assume good faith. > > Do you remember a couple of days ago, when I had to separate the tor > processes for flash proxy and meek because the metrics were getting > mixed up? That would have been *impossible* to do if there were > hardcoded fingerprints out there in bundles. And how I recently put out > a call for someone else to run the meek bridge? How is that transition > supposed to work if changing the fingerprint means we suddenly and > inexplicably break every existing client installation? > > The answer surely isn't "make sure the bridge's private key never > changes" and it isn't "anticipate every possible eventuality > indefinitely into the future." > > Can you explain what you don't like about four hops? To me it feels like > the right thing. It wouldn't just be for meek, you know, but for all > bridge circuits (including ordinary plain-vanilla bridges). When you're > using a bridge you treat the first hop as unauthenticated and > unencrypted, as if it were a SOCKS proxy or third-party VPN or any other > circumvention proxy. You treat the first hop as not chosen by you, > because it's not: even with BridgeDB you're just pasting in some bytes > the web site chose for you. After your first circumvention hop, then you > add your own three hops, notably including your own chosen guard. > bridge → guard → middle → exit Mike talked to me about this and made me understand that adding a fourth hop is not sufficient to prevent certain attacks. In other words, you need to TLS to be good, because Tor's current crypto doesn't have a per-hop MAC. Namely, https://trac.torproject.org/projects/tor/ticket/14937#comment:17 . So we'll add fingerprint for the meek bridges after all. Upgrading or migrating bridges will require more care, basically the same as what exists for obfs3 etc. now (when you want to change a bridge, you need to keep the old one running for a while in order to give people time to upgrade, and in case of a major error like private key disclosure, just accept that many users will be cut off when you change the fingerprint). David ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
