[tor-dev] [DRAFT] Proposal: All Routers are Directory Servers
Hi All, Below is a draft proposal for making all relays also be directory servers (by default). It's almost ready for a number, but it can use some feedback beforehand (give or take a few days). Tonight I also found that Nick actually created a similar proposal a few moons ago (Proposal 185: Directory caches without DirPort). This new proposal may benefit from superseding that one, but I recommend they remain distinct proposals, for now. In general I'm not tied to any of the proposed names, so suggestions are welcome. Thanks! === Filename: directory-servers-for-all.txt Title: All routers are directory servers Author: Matthew Finkel Created: 29-Jul-2014 Status: Draft Target: 0.2.6.x Overview: (In practice we refer to the servers that mirror directory documents as directory servers, directory mirrors, and directory caches. Sometimes we also shorten directory to dir. This proposal attempts to consistently use directory server to refer to this functionality. We also typically use the term router and relay interchangably. This proposal uses (onion) router.) This proposal aims at removing part of the distinction between the router and the directory server. Currently operators have the options of being one of: an onion router, a directory server, or both. With the acceptance of this proposal the options will be simplified to being either only a directory server or a combined router and directory server. All routers will serve directory requests. Motivation: Fetching directory documents and descriptors is sometimes a non-trivial operation for clients. If they do not have a consensus then they must contact a directory authority (until directory sources are added or clients are able to use a fallback consensus). If they have a consensus and have at least one entry guard then the client can query that guard for documents. If the document isn't available then after a period of time the client will attempt to retry downloading it. If the entry guard isn't a directory server, as well, a directory server and/or directory guard must be chosen (based on the server having an open DirPort) and queried for the document. At a minimum, this has a potential performance impact, at worst it's an attack vector that allows for profiling clients and partitioning users. With the orthogonally proposed move to clients using a single guard, the potential performance bottleneck and ability to profile users could be increased. If the client selects an entry guard and it is not a directory server then the client may select a distinct directory guard which will leak client behavior to a second node. 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 every router 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 routers download and cache the majority of router 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 The presence of this line indicates that the router accepts tunnelled directory requests. For a router that implements this proposal, this line MUST be added to its descriptor if it does not advertise a directory port, and MAY be added if it also advertises an open directory port. In addition to this, routers 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 servers. All routers 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 OR port and advertises tunnelled-dir-server in its server descriptor. Clients choose a directory by using the current criteria with the additional qualification that a server only needs the V2Dir status flag instead of requiring an open DirPort. When the client chooses which
[tor-dev] GSoc Stegotorus status update
Sorry for the delay, I have been travelling for the past week and a half and was at HOPE. I have finished debugging the swf steg, and am hunting down the last bugs in the pdf steg. SRI advised me that they are still working on their JavaScript transcoding library they wish to plug into the SWF and JS stegs, so I will move the JS steg and JSON stegs over but at the unti tests for JSON first. By the time of the PT meeing on August 1st I intend: to have JS, SWF and PDF debugged with unit tests finish testing the handshake code and make it robust to packets arriving out of order (discussed ideas for this in person with vmon) be ready to start debugging the transparent proxy start sketching out how to incorporate the JSON steg and the SRI jel library (if they get it finished in the next two weeks) Best Noah ___ 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
isis: Lunar transcribed 2.9K bytes: Matthew Finkel: I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them. But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2? Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]? Sorry, but as a fail to see good reasons, I just don't get the logic. For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them? What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3? Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0] They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable. That's where obfs2 still works just fine. But obfs3 will work just as fine. Why continue giving out obfs2 bridges? -- 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] UX Idea - A controller inside TBB
On 7/29/14, 9:31 AM, Matthew Finkel wrote: Did you start working on this again? Having something like this is actually really important. It would be awesome to get this functionality in Tor Browser again. Nima's design looks really good. I think a lot of people would be happy to see something like that. Do you think this should be based on bulb or should it start from scratch? I looked at doing this about a month ago and considered adding it directly into TorButton. Maybe it is better to use Python/Stem for the backend. Thoughts? Just so others are aware: Arthur is actively working on this ticket: Create Browser UI indication for current circuit status and exit IP https://trac.torproject.org/projects/tor/ticket/8641 -- Mark Smith Pearl Crescent http://pearlcrescent.com/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX Idea - A controller inside TBB
On Tue, Jul 29, 2014 at 09:38:55AM -0400, Mark Smith wrote: On 7/29/14, 9:31 AM, Matthew Finkel wrote: Did you start working on this again? Having something like this is actually really important. It would be awesome to get this functionality in Tor Browser again. Nima's design looks really good. I think a lot of people would be happy to see something like that. Do you think this should be based on bulb or should it start from scratch? I looked at doing this about a month ago and considered adding it directly into TorButton. Maybe it is better to use Python/Stem for the backend. Thoughts? Just so others are aware: Arthur is actively working on this ticket: Create Browser UI indication for current circuit status and exit IP https://trac.torproject.org/projects/tor/ticket/8641 Thanks Mark! Arthur's mockup looks great. Combining his work with the ability to read the log in real-time would be awesome. I know these are distinct tickets, but if both functionality could land in TorButton at approximately the same time (very soon :)), it will help a lot. Maybe the easy way to do this will be to work on a simple log reader, that is integrated into TorButton, and then if another, fancier thing materializes, then all the better. (yes, I will start looking at this again because if I don't, how can I expect others will?). If anyone feels like hacking on this, then you're probably a better candidate than me :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] UX Idea - A controller inside TBB
Hi, Mark Smith wrote (29 Jul 2014 13:38:55 GMT) : Just so others are aware: Arthur is actively working on this ticket: Create Browser UI indication for current circuit status and exit IP https://trac.torproject.org/projects/tor/ticket/8641 Thanks for pointing to it. This might be enough for Tails to stop shipping Vidalia, finally :) However, ideally we would also need a UI that allows monitoring circuits created by non-web usage, which is apparently not covered by that ticket. Not sure if it's a real blocker. Damian, what's the status wrt. providing this feature in arm? Cheers, -- intrigeri ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] orbot: get its ports from another app
Hello, I'm currently developping orwall, a UI over iptables allowing to block all IP traffic and forcing selected apps through Orbot (while blocking the others), among other things. I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and TransPort configuration. I think NetCipher lib may do it, but I'm not that sure. Thanks in advance for your answer/help :). Cheers, C. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] orbot: get its ports from another app
On 07/29/2014 03:03 PM, CJ wrote: I'm currently developping orwall, a UI over iptables allowing to block all IP traffic and forcing selected apps through Orbot (while blocking the others), among other things. I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and TransPort configuration. I think NetCipher lib may do it, but I'm not that sure. This feature is underway. You can add a ticket on Github or via our dev tracker: https://dev.guardianproject.info/projects/onionkit For most users, it will be default (9040, 9050, etc), but its definitely possible that people can change them, especially if they have the dreaded Samsung Link conflict. As for the implementation, it will simply be an Intent you send to Orbot and it will respond with the values. +n ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] orbot: get its ports from another app
On 29/07/14 21:19, Nathan Freitas wrote: On 07/29/2014 03:03 PM, CJ wrote: I'm currently developping orwall, a UI over iptables allowing to block all IP traffic and forcing selected apps through Orbot (while blocking the others), among other things. I'm wondering if there's a way to ask Orbot, if installed, its SOCKS and TransPort configuration. I think NetCipher lib may do it, but I'm not that sure. This feature is underway. You can add a ticket on Github or via our dev tracker: https://dev.guardianproject.info/projects/onionkit For most users, it will be default (9040, 9050, etc), but its definitely possible that people can change them, especially if they have the dreaded Samsung Link conflict. As for the implementation, it will simply be an Intent you send to Orbot and it will respond with the values. +n Hello Nathan, Thanks for the tip, I'll open a feature request :). In the meanwhile, I suppose I'll get the current setting the user may edit. I'll use this lib in order to detect Orbot and propose the installation, as it seems to do it properly. Happy to be able to play a bit with that. Cheers, C. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Working on a Globe Fork
Hi all, I'm a freelance web designer and developer, and I'm working on a fork of Globe after seeing the recent blog post https://blog.torproject.org/blog/looking-front-end-web-developers-network-status-websites-atlas-and-globe on the Tor Project's website. Since none of the other forks have any changes or are actively maintained, I created a fork on GitHub here https://github.com/wpapper/globe . I'm going to start by improving the responsive aspects of the design, and also clean up some unclear design decisions (e.g. Changing to something more descriptive than keyword for the search box and removing some redundant UI elements). I'll be making GitHub issues for the changes that need to be made. Anyone else can add any issues they see there. If you'd like to help contribute, just take on an issue and submit a pull request. Of course, let me know if you have any comments or suggestions. Sincerely, Will Papper ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] DNS proposal for Tor hidden services
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello everyone, I have a proposal for Tor hidden services, which if it's a good idea and workable I may be writing my Master's thesis on. My description here is very early, and I would like to run it by you guys before I continue further. I have already run it past Tor developers, but have seen limited response, so I'm opening it up to a wider audience. Basically, I propose integrating Namecoin into supporting Tor relays, so as to provide a secure DNS service for .onion sites within Tor itself. The result is that a human-readable address can be translated into its .onion counterpart, analogous to a domain name resolving into an IP address on the regular Internet, a square of Zooko's Triangle conjecture. Namecoin has a nearly identical codebase to Bitcoin, but instead of currency its primary focus is holding information, with a focus in DNS. Domains in Namecoin have the .bit extension, and registrations are secured with hashes in a blockchain. Anyone with the Namecoin blockchain can look up information in it, and indeed there are already Namecoin-supporting DNS servers that use the Namecoin blockchain to look up registrations in it. These basic premises are at the heart of my idea. Now, 3g2upl4pq6kufc4m.onion is the address for the DuckDuckGo hidden service, but it's hard to remember: even worse than a traditional IP address. Under my idea, a user could type in duckduckgo.tor, would see a secure translation to 3g2upl4pq6kufc4m.onion transparently and with masking, increasing the usability and popularity of hidden services significantly. My plan is in the context of Tor, to use the .tor domain, so as to not conflict with existing Namecoin registrations. The .onion address is a hash of the hidden service's public key, so if I own the private keys to 3g2upl4pq6kufc4m.onion, I should be able to sign something (perhaps the Namecoin public DSA key) to prove my ownership and set duckduckgo.tor.bit to point to 3g2upl4pq6kufc4m.onion. I then upload this to the Namecoin network as usual, (this costs 0.01 Namecoin) so that it becomes integrated into the blockchain. So now duckduckgo.tor.bit points to 3g2upl4pq6kufc4m.onion, and everyone with the blockchain knows it. Global DNS propagation may take less than 15 minutes. Namecoin domain registrations expire after 36,000 blocks (about 200 days) so a registration would have to be renewed occasionally for it to still remain. This is free to do, but ensures that domains don't endure indefinitely. It's impractical for Tor users to download the Namecoin blockchain in order to use this system, (even with Merkle trees) so instead supporting Tor relays can hold a copy and the Tor client can send out queries to them. At startup, Tor clients build several circuits through the network in preparation for use. Now let's say the user wants to look up duckduckgo.tor. To avoid spoofing attacks from a malicious relay, Tor clients will query multiple relays and gain a consensus. To do this, the Tor client generates three nonces, N1, N2, and N3. It then picks three random relays, possible trusted relays like guards, R1, R2, and R3. These relays have public RSA keys K1, K2, and K3, respectively. For each of the three relays, the Tor client takes the request for duckduckgo.tor, nonce Nj, and encrypts the pair with the relay's public key Kj. Along with a special new Tor flag specifying the use of this protocol, it then sends the trio through the circuit to the middle relay. The middle relay then queries the three relays. Each relay decrypts the request using its private key, checks the blockchain for duckduckgo.tor.bit, finds 3g2upl4pq6kufc4m.onion, and encrypts this answer with the nonce, and sends it back, signing the result. The client receives the answers, checks the signatures, decrypts the responses from the three relays using the nonces, and compares the response. If all three match, it then looks up 3g2upl4pq6kufc4m.onion in the traditional way. If two or less match, it restarts with a different set of three relays. If all three relays return that duckduckgo.tor can't be found, it throws the standard DNS error message. So I am simply building on top of the existing Tor hidden service infrastructure, not modifying it. I can write up a proposal for torspec.git once I have more details. I've already taken Tor 0.2.5.6-alpha code, installed Tor from source, and used Chutney to set up a mini Tor network on localhost of 5 authorities, 10 relays, and 1 client. That seems a good platform for development on this. What do you guys think about my proposal? Is this a good idea, and feasible? Anything I should watch out for as I go forward? What security threats exist that I should specifically defend against? Thank you for your time. - -- Jesse V. /CS, Network Security/ /Utah State University/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using
Re: [tor-dev] Prototype Primitives for Website Traffic Fingerprinting defenses
I've inserted a couple of corrections and clarifications below. I'm leaving original text fully quoted for the archive. Mike Perry: Hello all, What follows is a summary of the primitives that Marc Juarez aims to implement for his Google Summer of Code project on prototyping defenses for Website Traffic Fingerprinting and follow-on research. After a review of Tamaraw[1], Adaptive Padding[2], CS-BuFLO[3], and the Supersequence[4] work, as well as some discussion at the Tor dev meeting, we came up with this list of padding message primitives. These functions are meant to be sent as command cells from one endpoint to the other. Some are bidirectional commands, others can only be sent in one direction (client to relay, or relay to client). For now, they will be implemented as ad-hoc messages between two modified obfsproxy (called wfpadtools) instances. The source code for this fork lives here for the moment: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools/ Long term, I am thinking that all of these should be specified as if they were their own RELAY_* cell type from tor-spec.txt: https://gitweb.torproject.org/torspec.git/blob/HEAD:/tor-spec.txt#l1215 This means that padding would be a circuit-level property, and it would be possible to send it to and from any hop in the circuit, due to leaky-pipe topology (using the recognized field). In a world of very cheap and excessive middle and Guard node bandwidth, we would run this padding to the middle node. For the wfpadtools prototype, it will obviously only cover the first hop. Here's the list of primitives, broken down by research paper: Generic Messages (common to all defenses): RELAY_IGNORE() Description: Simple fixed-length (CELL_SIZE) padding cell. Direction: Bidirectional (client to relay, relay to client) Parameters: None RELAY_SEND_PADDING(N,t) Description: Send the requested number of padding cells in response. Direction: Client to relay Parameters: N: Number of padding cells to send in response to this cell t: microseconds delay before sending RELAY_APP_HINT(session_id, status) Description: A hint from the application layer for session start/stop Direction: Client to relay Parameters: session_id: A string identifying the session (ie keyed hash of url bar domain) status: Start or Stop, indicating session start and end. Adaptive Padding Messages: RELAY_BURST_HISTOGRAM(histogram[], labels_ms[], remove_toks, fuzz, when) Description: Specifies a histogram that encodes a delay distribution representing the probability of sending a single padding packet after a given delay in response to either an upstream cell, or a client-originating cell. Direction: Client to relay Parameters: histogram[]: Contains delay distribution of sending an IGNORE packet after sending a real packet labels_ms[]: millisecond labels for the bins (with Infinity/Ignore bin to allow encoding the probability of not sending any padding packet in response to this packet). In both of the Adaptive Padding primitives, a considerably more compact form is possible for bin labeling. The original Adaptive Padding literature used a 2^K exponential spacing between these bins, but didn't rigorously analyze the choice. If experimentation finds this is indeed reasonable/optimal, we can send a single parameter W instead of a labels_ms. W would be bin width in milliseconds, and L is the length of the histogram[] array. The labels would then be computed as W*2^K with K ranging from 0 to L-2, with the addition of a zero-delay bin label. For the prototype though, I think we should allow the labeling to remain a free-form array, for maximum flexibility in research. We may decide we want some form of polynomial spacing instead of exponential here, for example. remove_toks: If true, follow Adaptive Padding token removal rules. If false, histograms are immutable. fuzz: If true, randomize the delay uniformly between bin labels. If false, use bin labels as exact delay values. fuzz here might be better called interpolate in both this and the below primitive, since linear interpolation is what I mean here. I suppose we could imagine smoother types of interpolation, like quadratic, cubic, etc, but I don't expect the actual interpolation mechanism to matter a whole lot. I expect it to be most useful for preventing the adversary from subtracting the padding due to its arrival at a fixed delay quantity after another packet. when: If set to receive, this histogram governs the probably of sending a padding packet after some delay in response to a packet originating from. If set to send, this histogram governs padding ^
Re: [tor-dev] Email Bridge Distributor Interactive Commands
Lunar transcribed 3.7K bytes: isis: Lunar transcribed 2.9K bytes: Matthew Finkel: I agree, and I think it's safe to assume that some nation-state adversaries do not have these capabilities yet. Users should choose obfs3 over obfs2, but if a user has a reason for requesting obfs2 then I don't think we should deny them. But aren't “we” the expert on the topic? Which reasons do you think a user might have to choose obfs2 over obfs3? Isn't it in an attacker interest to trick users into using obfs2? Should all HTTPS websites allow DES because users might have a reason to request it? Should OTR clients continue to support OTRv1 because users might a have a reason to request it [1]? Sorry, but as a fail to see good reasons, I just don't get the logic. For the Tor Browser, we stop even distributing the binaries as soon as a new version is out because we know the previous one to be insecure. Why should a broken protocol still be advertised? Why should addresses of insecure bridge still be distributed when we can just avoid them? What do users get out of retrieving obfs2 bridge addresses that they can't get when retrieving obfs3? Alice's university sysadmin / corporate IT department / highschool administration / overly-conservative techie parents block tor, by protocol identification after watching Alice's tor handshake with the first hop. They block relays from the public list. Their firewall runs Bro or similar, and they're able to detect and block bridges too. [0] They see an obfs2 handshake, and they try to connect to the obfs2 IP:port using vanilla tor (without any PTs). It doesn't work. Isn't not their job to spend all day trying to figure out what that weird protocol was, and they're not savvy enough to realise that the handshake is also fingerprintable. That's where obfs2 still works just fine. But obfs3 will work just as fine. Why continue giving out obfs2 bridges? Because we have only finite obfs3 bridges. If we had infinite, sure, everyone should use them. But in the meantime, I still see several uses for obfs2 bridges. Using obfs2, when the obfuscation provided is sufficent for your situation, allows for more obfs3 bridges to be distributed to people with a greater need for them. -- ♥Ⓐ isis agora lovecruft _ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
