summaryrefslogtreecommitdiff
path: root/src/or/rendclient.c
AgeCommit message (Collapse)Author
2011-11-07Remove an extraneous "if" in the 4424 fixNick Mathewson
2011-11-07Don't leak an extend_info_t in rend_client_any_intro_points_usableRobert Ransom
2011-10-10Update documentation comment for rend_client_reextend_intro_circuitRobert Ransom
One of its callers assumes a non-zero result indicates a permanent failure (i.e. the current attempt to connect to this HS either has failed or is doomed). The other caller only requires that this function's result never equal -2. Bug reported by Sebastian Hahn.
2011-10-10Don't launch a useless circuit in rend_client_reextend_intro_circuitRobert Ransom
Fixes bug 4212. Bug reported by katmagic and found by Sebastian.
2011-06-02Add info-level log messages during HS-client-state purgeRobert Ransom
I hope these will never be useful, but having them and not needing them is better than needing them and not having them.
2011-06-02Refactor HS client state-clearing code into a separate functionRobert Ransom
2011-06-02Clear last_hid_serv_requests on SIGNAL NEWNYMRobert Ransom
Fixes bug #3309.
2011-06-02Make last_hid_serv_requests functions less fragileRobert Ransom
Previously, Tor would dereference a NULL pointer and crash if lookup_last_hid_serv_request were called before the first call to directory_clean_last_hid_serv_requests. As far as I can tell, that's currently impossible, but I want that undocumented invariant to go away in case I^Wwe break it someday.
2011-05-30Merge branch 'bug3045' into maint-0.2.2Nick Mathewson
Conflicts: src/or/circuitbuild.c
2011-05-30Set timestamp_dirty on HS circuits as circuit_expire_building requiresRobert Ransom
Fixes part of #1297; bugfix on 48e0228f1e031a709c1deb149c7dfd187c3609cf, when circuit_expire_building was changed to assume that timestamp_dirty was set when a circuit changed purpose to _C_REND_READY. (It wasn't.)
2011-05-15Log descriptions of nodes, not just nicknames.Nick Mathewson
This patch introduces a few new functions in router.c to produce a more helpful description of a node than its nickame, and then tweaks nearly all log messages taking a nickname as an argument to call these functions instead. There are a few cases where I left the old log messages alone: in these cases, the nickname was that of an authority (whose nicknames are useful and unique), or the message already included an identity and/or an address. I might have missed a couple more too. This is a fix for bug 3045.
2011-05-11Merge remote-tracking branch 'public/3122_memcmp_squashed' into ↵Nick Mathewson
bug3122_memcmp_022 Conflicts throughout. All resolved in favor of taking HEAD and adding tor_mem* or fast_mem* ops as appropriate. src/common/Makefile.am src/or/circuitbuild.c src/or/directory.c src/or/dirserv.c src/or/dirvote.c src/or/networkstatus.c src/or/rendclient.c src/or/rendservice.c src/or/router.c src/or/routerlist.c src/or/routerparse.c src/or/test.c
2011-05-11Hand-conversion and audit phase of memcmp transitionNick Mathewson
Here I looked at the results of the automated conversion and cleaned them up as follows: If there was a tor_memcmp or tor_memeq that was in fact "safe"[*] I changed it to a fast_memcmp or fast_memeq. Otherwise if there was a tor_memcmp that could turn into a tor_memneq or tor_memeq, I converted it. This wants close attention. [*] I'm erring on the side of caution here, and leaving some things as tor_memcmp that could in my opinion use the data-dependent fast_memcmp variant.
2011-05-11Automated conversion of memcmp to tor_memcmp/tor_mem[n]eqNick Mathewson
This commit is _exactly_ the result of perl -i -pe 's/\bmemcmp\(/tor_memcmp\(/g' src/*/*.[ch] perl -i -pe 's/\!\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch] perl -i -pe 's/0\s*==\s*tor_memcmp\(/tor_memeq\(/g' src/*/*.[ch] perl -i -pe 's/0\s*!=\s*tor_memcmp\(/tor_memneq\(/g' src/*/*.[ch] git checkout src/common/di_ops.[ch] git checkout src/or/test.c git checkout src/common/test.h
2011-05-05Fix up some check-spaces issuesNick Mathewson
2011-04-28Fix bug 1930Robert Ransom
2011-04-28Clean up merge of bug3k_021Robert Ransom
2011-04-28Merge branch 'bug3k_021' into bug3k_022Sebastian Hahn
Conflicts: src/or/or.h src/or/rendclient.c
2011-04-28Fix a bug introduced by purging rend_cache on NEWNYMRobert Ransom
If the user sent a SIGNAL NEWNYM command after we fetched a rendezvous descriptor, while we were building the introduction-point circuit, we would give up entirely on trying to connect to the hidden service. Original patch by rransom slightly edited to go into 0.2.1
2011-04-28Allow rend_client_send_introduction to fail transientlyRobert Ransom
i.e. without closing the AP connection.
2011-04-28Forget all rendezvous client state on SIGNAL NEWNYMRobert Ransom
2011-04-27explain an argument in a function commentRoger Dingledine
2011-04-27Instead of checking whether we have unremoved intro points, check for usable ↵Nick Mathewson
ones
2011-04-26refuse excluded hidserv nodes if strictnodesRoger Dingledine
Make hidden services more flaky for people who set both ExcludeNodes and StrictNodes. Not recommended, especially for hidden service operators.
2011-03-25Triage the XXX022 and XXX021 comments remaining in the codeNick Mathewson
Remove some, postpone others, leave some alone. Now the only remaining XXX022s are ones that seem important to fix or investigate.
2011-03-15Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson
2011-03-15Fix a compile warning when using clangSebastian Hahn
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.
2011-02-22Merge remote branch 'public/bug1859_021' into maint-0.2.1Nick Mathewson
2011-02-10Make the DH parameter we use for TLS match the one from Apache's mod_sslNick Mathewson
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)
2011-01-24Make the DH parameter we use for TLS match the one from Apache's mod_sslNick Mathewson
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.
2011-01-15Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson
2011-01-15Fix a couple of non-cleared key issues in hidden servicesNick Mathewson
we need to do more hunting, but this fixes the ones mentioned in 2385.
2011-01-15Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson
Conflicts: src/or/config.c src/or/networkstatus.c src/or/rendcommon.c src/or/routerparse.c src/or/test.c
2011-01-15Fix a heap overflow found by debuger, and make it harder to make that ↵Nick Mathewson
mistake again 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)
2011-01-03Merge remote branch 'origin/maint-0.2.1' into maint-0.2.2Nick Mathewson
Conflicts: src/common/test.h src/or/test.c
2011-01-03Bump copyright statements to 2011Nick Mathewson
2010-12-15Merge remote branch fix_security_bug_021 into fix_security_bug_022Nick Mathewson
Conflicts: src/common/memarea.c src/or/or.h src/or/rendclient.c
2010-12-15Make payloads into uint8_t.Nick Mathewson
This will avoid some signed/unsigned assignment-related bugs.
2010-11-12Fix a remaining bug in Robert's bug1859 fix.Nick Mathewson
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.
2010-11-12Issues with router_get_by_nickname()Robert Hogan
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.
2010-11-12Issues with router_get_by_nickname()Robert Hogan
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.
2010-10-21Fix a remaining bug in Robert's bug1859 fix.Nick Mathewson
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.
2010-10-17Issues with router_get_by_nickname()Robert Hogan
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.
2010-10-13Issues with router_get_by_nickname()Robert Hogan
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.
2010-08-16Fix misplaced labelsSebastian Hahn
2010-07-27Create rephist.hSebastian Hahn
2010-07-27Create relay.hSebastian Hahn
2010-07-27Create main.hSebastian Hahn
2010-07-27Create directory.hSebastian Hahn
2010-07-27Create connection_edge.hSebastian Hahn