aboutsummaryrefslogtreecommitdiff
path: root/src/or/rendclient.c
Commit message (Expand)AuthorAge
...
| * | refuse excluded hidserv nodes if strictnodes•••Make hidden services more flaky for people who set both ExcludeNodes and StrictNodes. Not recommended, especially for hidden service operators. Roger Dingledine2011-04-26
* | | Merge remote-tracking branch 'origin/maint-0.2.2'•••Conflicts: src/common/address.c src/common/compat_libevent.c src/common/memarea.c src/common/util.h src/or/buffers.c src/or/circuitbuild.c src/or/circuituse.c src/or/connection.c src/or/directory.c src/or/networkstatus.c src/or/or.h src/or/routerlist.c Nick Mathewson2011-04-07
|\| |
| * | Triage the XXX022 and XXX021 comments remaining in the code•••Remove some, postpone others, leave some alone. Now the only remaining XXX022s are ones that seem important to fix or investigate. Nick Mathewson2011-03-25
* | | Merge remote branch 'origin/maint-0.2.2'Nick Mathewson2011-03-15
|\| |
| * | Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson2011-03-15
| |\|
| | * Fix a compile warning when using clang•••Issue noticed by Steven Murdoch; fixes bug 2689. The cast didn't do anything, and we don't need to look at the return value of the function here. Sebastian Hahn2011-03-15
| | * Merge remote branch 'public/bug1859_021' into maint-0.2.1Nick Mathewson2011-02-22
| | |\
| | | * Fix a remaining bug in Robert's bug1859 fix.•••When intro->extend_info is created for an introduction point, it only starts out with a nickname, not necessarily an identity digest. Thus, doing router_get_by_digest isn't necessarily safe. Nick Mathewson2010-11-12
| | | * Issues with router_get_by_nickname()•••https://trac.torproject.org/projects/tor/ticket/1859 Use router_get_by_digest() instead of router_get_by_hexdigest() in circuit_discard_optional_exit_enclaves() and rend_client_get_random_intro(), per Nick's comments. Using router_get_by_digest() in rend_client_get_random_intro() will break hidden services published by Tor versions pre 0.1.2.18 and 0.2.07-alpha as they only publish by nickname. This is acceptable however as these versions only publish to authority tor26 and don't work for versions in the 0.2.2.x series anyway. Robert Hogan2010-11-12
| | | * Issues with router_get_by_nickname()•••https://trac.torproject.org/projects/tor/ticket/1859 There are two problems in this bug: 1. When an OP makes a .exit request specifying itself as the exit, and the exit is not yet listed, Tor gets all the routerinfos needed for the circuit but discovers in circuit_is_acceptable() that its own routerinfo is not in the routerdigest list and cannot be used. Tor then gets locked in a cycle of repeating these two steps. When gathering the routerinfos for a circuit, specifically when the exit has been chosen by .exit notation, Tor needs to apply the same rules it uses later on when deciding if it can build a circuit with those routerinfos. 2. A different bug arises in the above situation when the Tor instance's routerinfo *is* listed in the routerlist, it shares its nickname with a number of other Tor nodes, and it does not have 'Named' rights to its nickname. So for example, if (i) there are five nodes named Bob in the network, (ii) I am running one of them but am flagged as 'Unnamed' because someone else claimed the 'Bob' nickname first, and (iii) I run my Tor as both client and exit the following can happen to me: - I go to www.evil.com - I click on a link www.evil.com.bob.exit - My request will exit through my own Tor node rather than the 'Named' node Bob or any of the others. - www.evil.com now knows I am actually browsing from the same computer that is running my 'Bob' node So to solve both issues we need to ensure: - When fulfilling a .exit request we only choose a routerinfo if it exists in the routerlist, even when that routerinfo is ours. - When getting a router by nickname we only return our own router information if it is not going to be used for building a circuit. We ensure this by removing the special treatment afforded our own router in router_get_by_nickname(). This means the function will only return the routerinfo of our own router if it is in the routerlist built from authority info and has a unique nickname or is bound to a non-unique nickname. There are some uses of router_get_by_nickname() where we are looking for the router by name because of a configuration directive, specifically local declaration of NodeFamilies and EntryNodes and other routers' declaration of MyFamily. In these cases it is not at first clear if we need to continue returning our own routerinfo even if our router is not listed and/or has a non-unique nickname with the Unnamed flag. The patch treats each of these cases as follows: Other Routers' Declaration of MyFamily This happens in routerlist_add_family(). If another router declares our router in its family and our router has the Unnamed flag or is not in the routerlist yet, should we take advantage of the fact that we know our own routerinfo to add us in anyway? This patch says 'no, treat our own router just like any other'. This is a safe choice because it ensures our client has the same view of the network as other clients. We also have no good way of knowing if our router is Named or not independently of the authorities, so we have to rely on them in this. Local declaration of NodeFamilies Again, we have no way of knowing if the declaration 'NodeFamilies Bob,Alice,Ringo' refers to our router Bob or the Named router Bob, so we have to defer to the authorities and treat our own router like any other. Local declaration of NodeFamilies Again, same as above. There's also no good reason we would want our client to choose it's own router as an entry guard if it does not meet the requirements expected of any other router on the network. In order to reduce the possibility of error, the patch also replaces two instances where we were using router_get_by_nickname() with calls to router_get_by_hexdigest() where the identity digest of the router is available. Robert Hogan2010-11-12
| | * | Make the DH parameter we use for TLS match the one from Apache's mod_ssl•••Our regular DH parameters that we use for circuit and rendezvous crypto are unchanged. This is yet another small step on the path of protocol fingerprinting resistance. (Backport from 0.2.2's 5ed73e3807d90dd0a3) Nick Mathewson2011-02-10
* | | | another api tweak to help task 1944Roger Dingledine2011-02-07
* | | | Merge remote branch 'origin/maint-0.2.2'Nick Mathewson2011-01-24
|\| | |
| * | | Make the DH parameter we use for TLS match the one from Apache's mod_ssl•••Our regular DH parameters that we use for circuit and rendezvous crypto are unchanged. This is yet another small step on the path of protocol fingerprinting resistance. Nick Mathewson2011-01-24
* | | | Merge remote branch 'origin/maint-0.2.2'Nick Mathewson2011-01-15
|\| | |
| * | | Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson2011-01-15
| |\| |
| | * | Fix a couple of non-cleared key issues in hidden services•••we need to do more hunting, but this fixes the ones mentioned in 2385. Nick Mathewson2011-01-15
* | | | Merge remote branch 'origin/maint-0.2.2'Nick Mathewson2011-01-15
|\| | |
| * | | Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2•••Conflicts: src/or/config.c src/or/networkstatus.c src/or/rendcommon.c src/or/routerparse.c src/or/test.c Nick Mathewson2011-01-15
| |\| |
| | * | Fix a heap overflow found by debuger, and make it harder to make that mistake...•••Our public key functions assumed that they were always writing into a large enough buffer. In one case, they weren't. (Incorporates fixes from sebastian) Nick Mathewson2011-01-15
* | | | Merge remote branch 'origin/maint-0.2.2'Nick Mathewson2011-01-03
|\| | |
| * | | Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2•••Conflicts: src/common/test.h src/or/test.c Nick Mathewson2011-01-03
| |\| |
| | * | Bump copyright statements to 2011Nick Mathewson2011-01-03
* | | | Merge branch 'maint-0.2.2'Roger Dingledine2010-12-19
|\| | |
| * | | Merge remote branch fix_security_bug_021 into fix_security_bug_022•••Conflicts: src/common/memarea.c src/or/or.h src/or/rendclient.c Nick Mathewson2010-12-15
| |\| |
| | * | Make payloads into uint8_t.•••This will avoid some signed/unsigned assignment-related bugs. Nick Mathewson2010-12-15
| | |/
* | | Merge remote branch 'origin/maint-0.2.2' for bug 1859 patches•••Some of this is already done in nodelist. Nick Mathewson2010-10-21
|\| |
| * | Fix a remaining bug in Robert's bug1859 fix.•••When intro->extend_info is created for an introduction point, it only starts out with a nickname, not necessarily an identity digest. Thus, doing router_get_by_digest isn't necessarily safe. Nick Mathewson2010-10-21
| * | Issues with router_get_by_nickname()•••https://trac.torproject.org/projects/tor/ticket/1859 Use router_get_by_digest() instead of router_get_by_hexdigest() in circuit_discard_optional_exit_enclaves() and rend_client_get_random_intro(), per Nick's comments. Using router_get_by_digest() in rend_client_get_random_intro() will break hidden services published by Tor versions pre 0.1.2.18 and 0.2.07-alpha as they only publish by nickname. This is acceptable however as these versions only publish to authority tor26 and don't work for versions in the 0.2.2.x series anyway. Robert Hogan2010-10-17
| * | Issues with router_get_by_nickname()•••https://trac.torproject.org/projects/tor/ticket/1859 There are two problems in this bug: 1. When an OP makes a .exit request specifying itself as the exit, and the exit is not yet listed, Tor gets all the routerinfos needed for the circuit but discovers in circuit_is_acceptable() that its own routerinfo is not in the routerdigest list and cannot be used. Tor then gets locked in a cycle of repeating these two steps. When gathering the routerinfos for a circuit, specifically when the exit has been chosen by .exit notation, Tor needs to apply the same rules it uses later on when deciding if it can build a circuit with those routerinfos. 2. A different bug arises in the above situation when the Tor instance's routerinfo *is* listed in the routerlist, it shares its nickname with a number of other Tor nodes, and it does not have 'Named' rights to its nickname. So for example, if (i) there are five nodes named Bob in the network, (ii) I am running one of them but am flagged as 'Unnamed' because someone else claimed the 'Bob' nickname first, and (iii) I run my Tor as both client and exit the following can happen to me: - I go to www.evil.com - I click on a link www.evil.com.bob.exit - My request will exit through my own Tor node rather than the 'Named' node Bob or any of the others. - www.evil.com now knows I am actually browsing from the same computer that is running my 'Bob' node So to solve both issues we need to ensure: - When fulfilling a .exit request we only choose a routerinfo if it exists in the routerlist, even when that routerinfo is ours. - When getting a router by nickname we only return our own router information if it is not going to be used for building a circuit. We ensure this by removing the special treatment afforded our own router in router_get_by_nickname(). This means the function will only return the routerinfo of our own router if it is in the routerlist built from authority info and has a unique nickname or is bound to a non-unique nickname. There are some uses of router_get_by_nickname() where we are looking for the router by name because of a configuration directive, specifically local declaration of NodeFamilies and EntryNodes and other routers' declaration of MyFamily. In these cases it is not at first clear if we need to continue returning our own routerinfo even if our router is not listed and/or has a non-unique nickname with the Unnamed flag. The patch treats each of these cases as follows: Other Routers' Declaration of MyFamily This happens in routerlist_add_family(). If another router declares our router in its family and our router has the Unnamed flag or is not in the routerlist yet, should we take advantage of the fact that we know our own routerinfo to add us in anyway? This patch says 'no, treat our own router just like any other'. This is a safe choice because it ensures our client has the same view of the network as other clients. We also have no good way of knowing if our router is Named or not independently of the authorities, so we have to rely on them in this. Local declaration of NodeFamilies Again, we have no way of knowing if the declaration 'NodeFamilies Bob,Alice,Ringo' refers to our router Bob or the Named router Bob, so we have to defer to the authorities and treat our own router like any other. Local declaration of NodeFamilies Again, same as above. There's also no good reason we would want our client to choose it's own router as an entry guard if it does not meet the requirements expected of any other router on the network. In order to reduce the possibility of error, the patch also replaces two instances where we were using router_get_by_nickname() with calls to router_get_by_hexdigest() where the identity digest of the router is available. Robert Hogan2010-10-13
* | | Rename router_get_by_digest()•••We now call the function router_get_by_id_digest() to make clear that we're talking about the identity digest here, not descriptor digest. Sebastian Hahn2010-10-14
* | | Initial conversion to use node_t throughout our codebase.•••A node_t is an abstraction over routerstatus_t, routerinfo_t, and microdesc_t. It should try to present a consistent interface to all of them. There should be a node_t for a server whenever there is * A routerinfo_t for it in the routerlist * A routerstatus_t in the current_consensus. (note that a microdesc_t alone isn't enough to make a node_t exist, since microdescriptors aren't usable on their own.) There are three ways to get a node_t right now: looking it up by ID, looking it up by nickname, and iterating over the whole list of microdescriptors. All (or nearly all) functions that are supposed to return "a router" -- especially those used in building connections and circuits -- should return a node_t, not a routerinfo_t or a routerstatus_t. A node_t should hold all the *mutable* flags about a node. This patch moves the is_foo flags from routerinfo_t into node_t. The flags in routerstatus_t remain, but they get set from the consensus and should not change. Some other highlights of this patch are: * Looking up routerinfo and routerstatus by nickname is now unified and based on the "look up a node by nickname" function. This tries to look only at the values from current consensus, and not get confused by the routerinfo_t->is_named flag, which could get set for other weird reasons. This changes the behavior of how authorities (when acting as clients) deal with nodes that have been listed by nickname. * I tried not to artificially increase the size of the diff here by moving functions around. As a result, some functions that now operate on nodes are now in the wrong file -- they should get moved to nodelist.c once this refactoring settles down. This moving should happen as part of a patch that moves functions AND NOTHING ELSE. * Some old code is now left around inside #if 0/1 blocks, and should get removed once I've verified that I don't want it sitting around to see how we used to do things. There are still some unimplemented functions: these are flagged with "UNIMPLEMENTED_NODELIST()." I'll work on filling in the implementation here, piece by piece. I wish this patch could have been smaller, but there did not seem to be any piece of it that was independent from the rest. Moving flags forces many functions that once returned routerinfo_t * to return node_t *, which forces their friends to change, and so on. Nick Mathewson2010-10-01
* | | Try to make most routerinfo_t interfaces constNick Mathewson2010-10-01
|/ /
* | Fix misplaced labelsSebastian Hahn2010-08-16
* | Create rephist.hSebastian Hahn2010-07-27
* | Create relay.hSebastian Hahn2010-07-27
* | Create main.hSebastian Hahn2010-07-27
* | Create directory.hSebastian Hahn2010-07-27
* | Create connection_edge.hSebastian Hahn2010-07-27
* | Create connection.hSebastian Hahn2010-07-27
* | Create config.hSebastian Hahn2010-07-27
* | Create circuituse.hSebastian Hahn2010-07-27
* | Create circuitlist.hSebastian Hahn2010-07-27
* | Create circuitbuild.hSebastian Hahn2010-07-27
* | Create rendclient.hSebastian Hahn2010-07-27
* | Create rendcommon.hSebastian Hahn2010-07-27
* | Create routerlist.hSebastian Hahn2010-07-27
* | Merge remote branch 'origin/maint-0.2.1'•••Conflicts: src/common/test.h src/or/test.c Nick Mathewson2010-02-27
|\|
| * Update Tor Project copyright yearsNick Mathewson2010-02-27
* | Merge commit 'origin/maint-0.2.1'Nick Mathewson2010-02-07
|\|