- tor-commits - lists.torproject.org

[torbutton/master] Bug #1968: Reset window.name in the content window on toggle
by mikeperry＠torproject.org 28 Feb '11

28 Feb '11

commit fef8cb176662120197bf10d955c1175c1dad82a2 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sun Feb 27 20:38:03 2011 -0800 Bug #1968: Reset window.name in the content window on toggle --- src/chrome/content/torbutton.js | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/src/chrome/content/torbutton.js b/src/chrome/content/torbutton.js index c45a8df..3fe8145 100644 --- a/src/chrome/content/torbutton.js +++ b/src/chrome/content/torbutton.js @@ -2260,6 +2260,16 @@ function torbutton_check_js_tag(browser, tor_enabled, js_enabled) { torbutton_log(4, "Failed to disable JS events: "+e) } + try { + // My estimation is that this does not get the inner iframe windows, + // but that does not matter, because iframes should be destroyed + // on the next load. + browser.contentWindow.name = null; + browser.contentWindow.window.name = null; + } catch(e) { + torbutton_log(4, "Failed to reset window.name: "+e) + } + if(browser.__tb_tor_fetched == tor_enabled) { // States match, js ok browser.docShell.allowJavascript = js_enabled; if (eventSuppressor)

1 0

[torbutton/master] Add plumbing that might've helped #1968, except it didn't.
by mikeperry＠torproject.org 28 Feb '11

28 Feb '11

commit ed1458b58cf9c30dfdc8cf81cc8262bd090403c4 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sun Feb 27 17:37:44 2011 -0800 Add plumbing that might've helped #1968, except it didn't. Might end up useful in the future though. --- src/chrome/content/jshooks.js | 1 - src/chrome/content/torbutton.js | 17 ++++++++++++----- 2 files changed, 12 insertions(+), 6 deletions(-) diff --git a/src/chrome/content/jshooks.js b/src/chrome/content/jshooks.js index 32c446d..aff355b 100644 --- a/src/chrome/content/jshooks.js +++ b/src/chrome/content/jshooks.js @@ -314,7 +314,6 @@ window.__HookObjects = function() { } } // window.__tb_hook_date == true - with(window) { XPCNativeWrapper = function(a) { return a; }; diff --git a/src/chrome/content/torbutton.js b/src/chrome/content/torbutton.js index 54e15f4..c45a8df 100644 --- a/src/chrome/content/torbutton.js +++ b/src/chrome/content/torbutton.js @@ -2393,7 +2393,9 @@ function torbutton_apply_tab_tag(browser, tag) { else torbutton_log(5, "No tab found for session store tag."); } + var oldtag = browser.__tb_tor_fetched; browser.__tb_tor_fetched = tag; + return oldtag != tag; } function torbutton_tag_new_browser(browser, tor_tag, no_plugins) { @@ -3692,6 +3694,7 @@ function torbutton_is_same_origin(win, source, target) { // unused. function torbutton_update_tags(win, new_loc) { + var tag_change = false; torbutton_eclog(2, "Updating tags."); if(typeof(win.wrappedJSObject) == 'undefined') { torbutton_eclog(3, "No JSObject: "+win.location); @@ -3743,6 +3746,7 @@ function torbutton_update_tags(win, new_loc) { torbutton_apply_tab_tag(browser, tor_tag); } if(browser.__tb_tor_fetched != !tor_tag) { + tag_change = true; // Purge session history every time we fetch a new doc // in a new tor state torbutton_log(2, "Purging session history"); @@ -3807,6 +3811,7 @@ function torbutton_update_tags(win, new_loc) { } torbutton_log(2, "Tags updated."); + return tag_change; } // Same-origin policy may prevent our hooks from applying @@ -3825,7 +3830,7 @@ function torbutton_update_tags(win, new_loc) { // - http://swik.net/User:Staple/JavaScript+Popup+Windows+Generation+and+Testing… // - pure javascript pages/non-text/html pages // - Messing with variables/existing hooks -function torbutton_hookdoc(win, doc) { +function torbutton_hookdoc(win, doc, state_change) { if(typeof(win.wrappedJSObject) == 'undefined') { torbutton_eclog(3, "No JSObject: "+win.location); return; @@ -3857,7 +3862,7 @@ function torbutton_hookdoc(win, doc) { // the insertion function returning before the injected code is evaluated. // This code seems to do what we want. - var str2 = ""; + var str2 = "window.__tb_state_changed="+state_change+";\r\n"; if(m_tb_ff3) { str2 += "window.__tb_set_uagent=false;\r\n"; str2 += "window.__tb_hook_date=false;\r\n"; @@ -3899,13 +3904,15 @@ function torbutton_hookdoc(win, doc) { } else { s = new Components.utils.Sandbox(win.wrappedJSObject); } + torbutton_log(2, "Type of sandbox: " + typeof(s)); // FIXME: FF3 issues // http://developer.mozilla.org/en/docs/XPConnect_wrappers#XPCSafeJSObjectWrap… // http://developer.mozilla.org/en/docs/Code_snippets:Interaction_between_priv… s.window = win.wrappedJSObject; -//s.__proto__ = win.wrappedJSObject; + //s.__proto__ = win.wrappedJSObject; var result = Components.utils.evalInSandbox(str2, s); + torbutton_log(2, "Type of result: " + typeof(result)); if(result === 23) { // secret confirmation result code. torbutton_log(3, "Javascript hooks applied successfully at: " + win.location); } else if(result === 13) { @@ -4079,9 +4086,9 @@ function torbutton_check_progress(aProgress, aRequest, aFlags, new_loc) { var doc = DOMWindow.document; try { if(doc) { - torbutton_update_tags(DOMWindow.window, new_loc); + var tag_change = torbutton_update_tags(DOMWindow.window, new_loc); if(doc.domain) { - torbutton_hookdoc(DOMWindow.window, doc); + torbutton_hookdoc(DOMWindow.window, doc, tag_change); } } } catch(e) {

1 0

[torbutton/master] Bug #2148: Make the ref spoofing more uniform in behavior
by mikeperry＠torproject.org 28 Feb '11

28 Feb '11

commit 2589477ba1034c394d9ef74c33bd1123316da214 Author: Mike Perry <mikeperry-git(a)fscked.org> Date: Sun Feb 27 16:53:29 2011 -0800 Bug #2148: Make the ref spoofing more uniform in behavior This may not be the final form we want for it to take, see FIXME in the comments. Also fix a potential issue with unescaped .'s in regex match strings. I'm really not sure we can call this ref spoofing protection a real security feature, though, so it's not like this matters a whole bunch. But might as well fix it, too. --- src/components/torRefSpoofer.js | 35 +++++++++++++++++++++-------------- 1 files changed, 21 insertions(+), 14 deletions(-) diff --git a/src/components/torRefSpoofer.js b/src/components/torRefSpoofer.js index 2a2325d..e3504b8 100644 --- a/src/components/torRefSpoofer.js +++ b/src/components/torRefSpoofer.js @@ -4,6 +4,7 @@ const kMODULE_CONTRACTID = "@torproject.org/torRefSpoofer;1"; function RefSpoofer() { this.logger = Components.classes["@torproject.org/torbutton-logger;1"].getService(Components.interfaces.nsISupports).wrappedJSObject; this.logger.log(3, "RefSpoof component created"); + this.specials = /[-[\]{}()*+?.,\\^$|#\s]/g; } @@ -49,25 +50,31 @@ RefSpoofer.prototype = { return;//no referer available or invalid uri } var requestURI = oHttpChannel.URI; //request nsIURI object - var refererHost = referer.host; //referer host w/o scheme - var requestHost = oHttpChannel.URI.host;//request host without scheme - - //get rid of www. to compare root domain - if (refererHost.match("^www.")) - refererHost = refererHost.substring(4); - - if (requestHost.match("^www.")) - requestHost = requestHost.substring(4); - - //if they're in the same domain(if we can tell) or have the same host, keep the referer - if (requestHost.split(".").length >= refererHost.split(".").length && requestHost.match(refererHost)) + var destHost = referer.host; //referer host w/o scheme + var srcHost = oHttpChannel.URI.host;//request host without scheme + + // match is not what we want, unless we escape dots: + var destHostMatch = destHost.replace(this.specials, "\\$&"); + var srcHostMatch = srcHost.replace(this.specials, "\\$&"); + + // FIXME: This isn't exactly bulletproof security here, but it still + // may need to be more lenient not to break sites... + // + // If we suspect issues, we can try doing the following first: + // 1. Strip off all TLD suffixes, up to but not including '.' + // 2. If more than one domain part is till left, strip off prefix + + //if they're in the same domain(if we can tell) or have the same host, keep the referer + if (srcHost.split(".").length >= destHost.split(".").length + && srcHost.match(destHostMatch)) // dest is a substring of src return; - else if (refererHost.split(".").length >= requestHost.split(".").length && refererHost.match(requestHost)) + else if (destHost.split(".").length >= srcHost.split(".").length + && destHost.match(srcHostMatch)) // src is a substring of dest return; //if they do not have the same host this.adjustRef(oHttpChannel, requestURI.scheme + "://" + requestURI.host); this.logger.safe_log(3, "Adjusting Referer, ", - "from " + refererHost + " to " + requestURI.host); + "from " + destHost + " to " + requestURI.host); } catch (ex) { this.logger.log(5, "RefSpoof onModifyRequest: " +ex);

1 0

r24274: {} Removing internal TODO document (it's being replaced by its (arm/trunk)
by Damian Johnson 27 Feb '11

27 Feb '11

Author: atagar Date: 2011-02-27 21:37:03 +0000 (Sun, 27 Feb 2011) New Revision: 24274 Removed: arm/trunk/TODO Log: Removing internal TODO document (it's being replaced by its wiki page: https://trac.torproject.org/projects/tor/wiki/projects/arm) Deleted: arm/trunk/TODO =================================================================== --- arm/trunk/TODO 2011-02-27 21:36:19 UTC (rev 24273) +++ arm/trunk/TODO 2011-02-27 21:37:03 UTC (rev 24274) @@ -1,360 +0,0 @@ -Contents: - 1. Easy Bugs / Improvements - 2. Known Bugs - 3. Features - 3a. Improvements - 3b. Projects - 4. Ideas (low priority or not yet really) - 4. Investigational - - - - - - - - - -- Roadmap and completed work for next release (1.4.2) - [ ] refactor panels - Currently the interface is a bit of a rat's nest (especially the - controller). The goal is to use better modularization to both simplify - the codebase and make it possible to use smarter caching to improve - performance (far too much is done in the ui logic). This work is in - progress - /init and /util are done and /interface is partly done. Known - bugs are being fixed while refactoring. - - * conn panel - - expand client connections and note location in circuit (entry-exit) - - for clients give an option to list all connections, to tell which are - going through tor and which might be leaking - - check family members to see if they're alive (VERSION cell - handshake?) - - fallback when pid or connection querying via pid is unavailable - List all connections listed both by netstat and the consensus - - note when connection times are estimates (color?), ie connection - was established before arm - - connection uptime to associate inbound/outbound connections? - - identify controller connections (if it's arm, vidalia, etc) with - special detail page for them - - provide bridge / client country / exiting port statistics - Include bridge related data via GETINFO option (feature request - by waltman and ioerror). - - note the common port usage along with the exit statistics - - show the port used in scrubbed exit connections - - pick apart applications like iftop and pktstat to see how they get - per-connection bandwidth usage. Forum thread discussing it: - https://bbs.archlinux.org/viewtopic.php?pid=715906 - - include an option to show both the internal and external ips for the - local connection, ie: - myInternal --> myExternal --> foreign - idea and initial patch by Fabian Keil - - give a warning if family relays don't name us - - use SAVECONF instead when overwriting the current torrc - * classify config options as useful (defaultly shown), standard, and - deprecated (configured to be hidden by default) - * check tor source for deprecated options like 'group' (are they - ignored? idea is thanks to NightMonkey) - * elaborate on the password prompt (suggestion by weasel) - -- Roadmap for version 1.4.3 - [ ] refactor panels - [ ] controller and popup panels - - allow arm to resume after restarting tor - This requires a full move to the torTools controller. - - improve on performance bottlenecks for startup time and cpu usage - - intermittent concurrency bugs during shutdown, one possible source: - https://trac.torproject.org/projects/tor/ticket/2144 - [ ] setup scripts for arm - [ ] updater (checks for a new tarball and installs it automatically) - - attempt to verify download signature, providing a warning if unable - to do so - [ ] look into CAPs to get around permission issues for connection - listing sudo wrapper for arm to help arm run as the same user as - tor? Irc suggestions: - - man capabilities - - http://www.linuxjournal.com/article/5737 - -- Bugs - * Config options with long names (ex. UpdateBridgesFromAuthority) are causing - the layout on the config panel to be shifted. - * The default resolver isn't configurable. - * Default config value checks don't work with older versions of tor. We need - a version check for the feature. From Sjon: - > Okay, I found the problem with all values being tagged as default, - > 'GETINFO config-text' has been introduced in 0.2.2.7, while I am - > running 0.2.1.28. Maybe a check in arm for the version-number for that - > feature to be enabled might be an idea? - also: https://trac.torproject.org/projects/tor/ticket/2501 - * When saving the config the Log entry should be filtered out if unnecessary. - * The config write dialog (ie, the one for saving the config) has its a - misaligned border when it's smaller than the top detail section. - * The cpu usage spikes for scrollable content when the key's held. Try - coalescing the events. - * The manpage layout is system dependent, so the scraper needs to be more - resilient against being confused by whitespace. Another improvement is - including fallback results if the man page can't be parsed (suggested by - rransom, issue caught by NightMonkey). - * Log deduplication is currently an n^2 operation. Hence it can't handle - large logs (for instance, when at the DEBUG runlevel). Currently we're - timing out the function if it takes too long, but a more efficient method - for deduplication would be preferable. - * when in client mode and tor stops the header panel doesn't say so - * util/torTools.py: effective bandwidth rate/burst measurements don't take - SETCONF into consideration, blocked on: - https://trac.torproject.org/projects/tor/ticket/1692 - * log prepopulation fails to limit entries to the current tor instance if - the file isn't logged to at the NOTICE level. A fix is to use the - timestamps to see if it belongs to this tor instance. This requires - tor's uptime - blocked on implementation of the following proposal: - https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/173-get… - * the STATUS_SERVER event may not be supported - 18:52 < mikeperry> atagar: I believe there is no event parsing for STATUS_SERVER - 18:53 < mikeperry> atagar: see TorCtl.EventSink and classes that inherit from it - 18:54 < mikeperry> specifically, TorCtl.EventHandler._decode1, _handle1, and _map1 - - * conn panel: - * *never* do reverse dns lookups for first hops (could be resolving via - tor and hence leaking to the exit) - * If there's duplicate family entries (and harder case: both nickname and - fingerprint entries for the same relay) then the duplicate should be - removed. This is also causing a bad scrolling bug where the cursor can't - get past the pair of duplicate entries. - * revise multikey sort of connections - Currently using a pretty ugly hack. Look at: - http://www.velocityreviews.com/forums/ - t356461-sorting-a-list-of-objects-by-multiple-attributes.html - and check for performance difference. - * replace checks against exit policy with Mike's torctl version - My version still isn't handling all inputs anyway (still need to handle - masks, private keyword, and prepended policy). Parse it from the rest - of the router if too heavy ("TorCtl.Router.will_exit_to instead"). - * avoid hostname lookups of private connections - Stripped most of them but suspect there might be others (have assertions - check for this in a debug mode?) - * connection uptimes shouldn't show fractions of a second - * connections aren't cleared when control port closes - -- Packaging - * OpenWrt - OpenWrt uses the opkg packaging format which could make use of - arm's current deb packages. Packaging for this platform would help with - the Torouter project: - https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter - * Mac - Couple of options include macport and dmg... - * macport (http://guide.macports.org/#development) - Build-from-source distribution method (like BSD portinstall). This has - been suggested by several people. - - * dmg (http://en.wikipedia.org/wiki/Apple_Disk_Image) - Most conventional method of software distribution on mac. This is just - a container (no updating/removal support), but could contain an icon - for the dock that starts a terminal with arm. This might include a pkg - installer. - - * mpkg (http://pypi.python.org/pypi/bdist_mpkg/) - Plugin for distutils. Like most mac packaging, this can only run on a - mac. It also requires setuptools: - http://www.errorhelp.com/search/details/74034/importerror-no-module-named-s… - -- Future Features - * Option for the graph to move right to left (easy - feature request by - ioerror and rdegraaf) - * client mode use cases - * not sure what sort of information would be useful in the header (to - replace the orport, fingerprint, flags, etc) - * one idea by velope: - "whether you configured a dnsport, transport, etc. and whether they - were successfully opened. might be nice to know this after the log - messages might be gone." - [notice] Opening Socks listener on 127.0.0.1:9050 - [notice] Opening Transparent pf/netfilter listener on 127.0.0.1:9040 - [notice] Opening DNS listener on 127.0.0.1:53 - * rdns and whois lookups (to find ISP, country, and jurisdiction, etc) - To avoid disclosing connection data to third parties this needs to be - an all-or-nothing operation (ie, needs to fetch information on all - relays or none of them). Plan is something like: - * add resolving/caching capabilities to fetch information on all relays - and distil whois entries to just what we care about (hosting provider - or ISP), by default updating the cache on a daily basis - * construct tarball and make this available for download rather than - fetching everything at each client - * possibly make these archives downloadable from peer relays (this is a - no-go for clients) via torrents or some dirport like scheme - * look at Vidalia and TorK for ideas - * need to solicit for ideas on what would be most helpful to clients - * dialog with bridge statuses (idea by mikeperry) - https://trac.vidalia-project.net/ticket/570 - https://trac.torproject.org/projects/tor/ticket/2068 - * menus - * http://gnosis.cx/publish/programming/charming_python_6.html ? - * additional options: - * make update rates configurable via the ui - * dialog with flag descriptions and other help - * menu with all torrc options (making them editable/toggleable) - * control port interpreter (interactive prompt) - Panel and startup option (-t maybe?) for providing raw control port - access along with usability improvements (piggybacking on the arm - connection): - * irc like help (ex "/help GETINFO" could provide a summary of - getinfo commands, partly using the results from - "GETINFO info/names") - * tab completion and up/down for previous commands - * warn and get confirmation if command would disrupt arm (for - instance 'SETEVENTS') - * 'safe' option that restricts to read-only access (start with this) - * issue sighup reset - * options for more deailed control of when bandwidth's contributed - https://trac.torproject.org/projects/tor/ticket/1730 - * make use of the new process/* GETINFO options - They'll be available in the next tor release, as per: - https://trac.torproject.org/projects/tor/ticket/2291 - * feature parity for arm's config values (armrc entries) - * editability - * parse descriptions from the man page? autogeneration of the man page from - something storing the descriptions - * handle mutiple tor instances - * screen style (dialog for switching between instances) - * extra window with whatever stats can be aggregated over all instances, - or a config option to aggregate stats for bw, resource usage, etc - * option to save the current settings to the config - * provide warning at startup if the armrc doesn't exist, with instructions - for generating it - * email alerts for changes to the relay's status, similar to tor-weather - * simple alert if tor shuts down - * accounting and alerts for if the bandwidth drops to zero - * daily/weekly/etc status reports - * log output, bandwidth history, etc - * graphic of the graphed bandwidth usage - * aggregated port usage for exits and country of origin for clients - * merge in and improve the consensus tracker - * tab completion for input fields that expect a filesystem path - * look through vidalia's tickets for more ideas - https://trac.vidalia-project.net/ - * look into additions to the used apis - * curses (python 2.6 extended?): http://docs.python.org/library/curses.html - * new control options (like "desc-annotations/id/<OR identity>")? - * look into better supporting hidden services (what could be useful here?) - * provide option for a consensus page - Shows full consensus with an interface similar to the connection panel. - For this Mike's ConsensusTracker would be helpful (though boost the - startup time by several seconds) - * splash screen when starting up to indicate that arm is loading, which - would be especially helpful when arm's taking a while to parse the man - page (idea by Sjon) - * show qos stats - Take a look at 'linux-tor-prio.sh' to see if any of the stats are - available and interesting. - * escaping function for uiTools' formatted strings - * provide an option for showing cpu usage on a per-core basis - This would be similar to top when you press 1, ie cpu0 X%, cpu1 Y%, etc. - This would help relay operators in checking system load (feature request - by Jordan) - * setup wizard for new relays - Setting the password and such for torrc generation. Maybe a netinstaller - that fetches the right package for the plagform, verifies signatures, etc? - Another alternative would be that when arm is started and tor isn't - running offer to start tor as a client, relay, or bridge. (idea by ioerror) - * audit what tor does - * Provide warnings if tor connections misbehaves, for instance: - * ensuring ExitPolicyRejectPrivate is being obeyed - * check that ExitPolicy violations don't occur (not possible yet since - not all relays aren't identified) - * check that all connections are properly related to a circuit, for - instance no outbound connections without a corresponding inbound (not - possible yet due to being unable to correlate connections to circuits) - * check file descriptors being accessed by tor to see if they're outside a - known pattern - * script that dumps relay stats to stdout - Derived from an idea by StrangeCharm. Django has a small terminal coloring - module that could be nice for formatting. Could possibly include: - * desc / ns information for our relay - * ps / netstat stats like load, uptime, and connection counts, etc - * implement control-spec proposals: - * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/172-cir… - * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/173-get… - * urwid improvements - Urwid (http://excess.org/urwid/) is an open source python library for - terminal applications. It provides a nicer interface, ideal for terminal - forms and some common UI elements. - - As I recall it isn't compatable with using curses directly, but checking - the library for interesting capabilities and code snippets could be very - helpful. For instance, the screenshots exemplify color support beyond the - 8 colors (RGB + CMYK) available with curses... *very* curious how they do - this and how widely higher color support is available! - * gui frontend (gtk?) - Look into if the arm utilities and codebase would fit nicely for a gui - controller like Vidalia and TorK. - * unit tests - Primarily for util, for instance 'addfstr' would be a good candidate. - * python 3 compatibility - Currently blocked on TorCtl support. - -- Release Checklist - 1. Run a sanity check over major changes: - - pylint --indent-string=" " --disable=C,R interface/foo.py | less - - double check __init__.py and README for added or removed files - 2. Revise the TODO (adding plans for the next release) - 3. Update release notes - - Spellcheck notes and copy them to the site (atagar.com/arm/log.php) - - Copy rendered release notes into the ChangeLog - 4. Check into release and upload the signed tarball - - svn co https://svn.torproject.org/svn/arm/ - - svn merge release trunk - - bump the version - - release/src/version.py - - resources/deb-prep.sh - - resources/build/debian/changelog - - svn commit -m "Arm release 1.4.1" - - note the commit number in the site log and ChangeLog - - svn export release arm - - copy the export and perform a final sanity check that it works - - tar cjf arm-1.4.1.0.tar.bz2 arm - - gpg --detach-sig --armor arm-1.4.1.0.tar.bz2 - - copy tarball and sig to the webserver (both to resources and static) - - update links and bump the release in download.php and index.php - - double check that there aren't any broken links - 5. Release notifications - - Log into https://blog.torproject.org/user/ - - Write a new blog post, example: - https://blog.torproject.org/blog/arm-release-141 - - Send an update to or-talk, example: - http://archives.seul.org/or/talk/Jan-2011/msg00096.html - 6. After a week bump package versions: - - Debian - Contact: weasel (Peter Palfrader) - Initial Release: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603056 - Update Instructions: - - update resources/build/debian/changelog - - ./resources/deb-prep.sh - - cd release_deb - - ./debian/make-deb - - copy the results to the webserver, example: - http://www.atagar.com/transfer/tmp/armBuild_12-7-10/ - - send the dsc link to weasel - - sign deb and copy that and sig for the download page - - - Red Hat - Contact: None - Update Instructions: - - update resources/build/redHat/MANIFEST - - ./resources/rpm-prep.sh - - cd release_rpm - - ./debian/make-rpm - - copy the results to the webserver - - sign rpm and copy that and sig for the download page - - - Gentoo - Contact: NightMonkey (Jesse Adelman) - Initial Release: https://bugs.gentoo.org/show_bug.cgi?id=341731 - Update Instructions: - - go to https://bugs.gentoo.org - - make a generic bug with "net-misc/arm-X.X.X version bump, please" - - - ArchLinux - Contact: Spider.007 - Initial Release: http://aur.archlinux.org/packages.php?ID=44172 - Update Instructions: - - go to aur.archlinux.org - - select "Out-of-date" for the package -

1 0

r24273: {arm} Last revisions made to the arm TODO (I'm about to nuke it, b (arm/trunk)
by Damian Johnson 27 Feb '11

27 Feb '11

Author: atagar Date: 2011-02-27 21:36:19 +0000 (Sun, 27 Feb 2011) New Revision: 24273 Modified: arm/trunk/TODO Log: Last revisions made to the arm TODO (I'm about to nuke it, but checking in this last version for the svn history's benefit). Modified: arm/trunk/TODO =================================================================== --- arm/trunk/TODO 2011-02-27 20:26:25 UTC (rev 24272) +++ arm/trunk/TODO 2011-02-27 21:36:19 UTC (rev 24273) @@ -1,5 +1,20 @@ -TODO +Contents: + 1. Easy Bugs / Improvements + 2. Known Bugs + 3. Features + 3a. Improvements + 3b. Projects + 4. Ideas (low priority or not yet really) + 4. Investigational + + + + + + + + - Roadmap and completed work for next release (1.4.2) [ ] refactor panels Currently the interface is a bit of a rat's nest (especially the @@ -61,6 +76,8 @@ - http://www.linuxjournal.com/article/5737 - Bugs + * Config options with long names (ex. UpdateBridgesFromAuthority) are causing + the layout on the config panel to be shifted. * The default resolver isn't configurable. * Default config value checks don't work with older versions of tor. We need a version check for the feature. From Sjon: @@ -140,6 +157,8 @@ http://www.errorhelp.com/search/details/74034/importerror-no-module-named-s… - Future Features + * Option for the graph to move right to left (easy - feature request by + ioerror and rdegraaf) * client mode use cases * not sure what sort of information would be useful in the header (to replace the orport, fingerprint, flags, etc) @@ -203,8 +222,11 @@ * email alerts for changes to the relay's status, similar to tor-weather * simple alert if tor shuts down * accounting and alerts for if the bandwidth drops to zero - * daily/weekly/etc alerts for basic status (log output, bandwidth history, - etc), borrowing from the consensus tracker for some of the formatting + * daily/weekly/etc status reports + * log output, bandwidth history, etc + * graphic of the graphed bandwidth usage + * aggregated port usage for exits and country of origin for clients + * merge in and improve the consensus tracker * tab completion for input fields that expect a filesystem path * look through vidalia's tickets for more ideas https://trac.vidalia-project.net/ @@ -250,6 +272,16 @@ * implement control-spec proposals: * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/172-cir… * https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/proposals/173-get… + * urwid improvements + Urwid (http://excess.org/urwid/) is an open source python library for + terminal applications. It provides a nicer interface, ideal for terminal + forms and some common UI elements. + + As I recall it isn't compatable with using curses directly, but checking + the library for interesting capabilities and code snippets could be very + helpful. For instance, the screenshots exemplify color support beyond the + 8 colors (RGB + CMYK) available with curses... *very* curious how they do + this and how widely higher color support is available! * gui frontend (gtk?) Look into if the arm utilities and codebase would fit nicely for a gui controller like Vidalia and TorK.

1 0

r24272: {website} Dropping packaging from the arm client use cases project ide (website/trunk/getinvolved/en)
by Damian Johnson 27 Feb '11

27 Feb '11

Author: atagar Date: 2011-02-27 20:26:25 +0000 (Sun, 27 Feb 2011) New Revision: 24272 Modified: website/trunk/getinvolved/en/volunteer.wml Log: Dropping packaging from the arm client use cases project idea and linking to further descriptions of the remaining projects. Modified: website/trunk/getinvolved/en/volunteer.wml =================================================================== --- website/trunk/getinvolved/en/volunteer.wml 2011-02-27 19:06:25 UTC (rev 24271) +++ website/trunk/getinvolved/en/volunteer.wml 2011-02-27 20:26:25 UTC (rev 24272) @@ -823,16 +823,11 @@ href="http://gnosis.cx/publish/programming/charming_python_6.html">example</a>).</li> <li>Look at Vidalia and TorK for ideas and solicit input from the Tor community.</li> - - <li>Make it easier for users to install arm by <a - href="https://secure.wikimedia.org/wikipedia/en/wiki/Opkg">packaging for - OpenWrt</a> (as a UI for the <a - href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/Torouter">Torouter - project</a>) and Macs.</li> </ul> - For more project ideas see arm's <a - href="https://svn.torproject.org/svn/arm/trunk/TODO">TODO</a>. + + More information is available in the following sections of arm's dev notes: <a href="https://trac.torproject.org/projects/tor/wiki/projects/arm#ConnectionListin…">Connection Listing Expansion</a>, <a href="https://trac.torproject.org/projects/tor/wiki/projects/arm#CircuitDetails">Circuit Details</a>, and <a href="https://trac.torproject.org/projects/tor/wiki/projects/arm#ClientModeUseCas…">Client Mode Use Cases</a> + </li> <a id="unitTesting"></a>

1 0

[weather/master] Fix get_highest_version(), so it really returns the highest version. Thanks, rransom.
by kaner＠torproject.org 27 Feb '11

27 Feb '11

commit 1cfd17ad5e86355162ae052dc73774b617efed32 Author: Christian Fromme <kaner(a)strace.org> Date: Sun Feb 27 11:42:51 2011 +0100 Fix get_highest_version(), so it really returns the highest version. Thanks, rransom. --- weather/weatherapp/ctlutil.py | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/weather/weatherapp/ctlutil.py b/weather/weatherapp/ctlutil.py index 88a098f..93c6318 100644 --- a/weather/weatherapp/ctlutil.py +++ b/weather/weatherapp/ctlutil.py @@ -238,8 +238,14 @@ class CtlUtil: """ if len(versionlist) is 0: return "" - versionlist.sort() - return versionlist[-1] + + highest = TorCtl.RouterVersion("0.0.0.0") + for v in versionlist: + cur = TorCtl.RouterVersion(v) + if cur > highest: + highest = cur + + return str(highest) def get_version_type(self, fingerprint): """Get the type of version the relay with fingerprint C{fingerprint}

1 0

r24271: {website} Stop directing users to obsolete and unsafe live CDs and bun (website/trunk/docs/en)
by Robert Ransom 27 Feb '11

27 Feb '11

Author: rransom Date: 2011-02-27 19:06:25 +0000 (Sun, 27 Feb 2011) New Revision: 24271 Modified: website/trunk/docs/en/faq.wml Log: Stop directing users to obsolete and unsafe live CDs and bundles Modified: website/trunk/docs/en/faq.wml =================================================================== --- website/trunk/docs/en/faq.wml 2011-02-27 07:16:31 UTC (rev 24270) +++ website/trunk/docs/en/faq.wml 2011-02-27 19:06:25 UTC (rev 24271) @@ -688,90 +688,11 @@ <h3><a class="anchor" href="#LiveCD">Is there a LiveCD or other bundle that includes Tor?</a></h3> - There isn't any official LiveCD at this point. We're still trying to find good - solutions and trying to understand the security and anonymity implications of - the various options. In the mean time, feel free to check out the list below - and use your best judgement: + Yes. Use <a href="https://amnesia.boum.org/">The (Amnesic) Incognito + Live System</a> or <a href="<page projects/torbrowser>">the Tor Browser + Bundle</a>. - - LiveCDs: - - - <ol> - <li><a href="https://amnesia.boum.org/">The (Amnesic) Incognito Live - System</a> is a Live System aimed at preserving your privacy and - anonymity: - <ul> - <li> All outgoing connections to the Internet are forced to go through - the Tor network.</li> - <li> No trace is left on local storage devices unless explicitely asked.</li> - <li> It includes Firefox, Tor, Torbutton, Vidalia graphical Tor - controller, Pidgin Instant Messaging client, and lots of other - software.</li> - <li> It's based upon Debian gnu/linux and comes with the GNOME desktop - environment.</li> - </ul> - <li><a href="http://tork.sourceforge.net/wiki/index.php/LiveCD">TorK LiveCD</a> - is Knoppix-based with an emphasis on user-friendliness. You can work - anonymously or non-anonymously while TorK tries to keep you informed of the - consequences of your activity. The TorK LiveCD is experimental, so the aim is - to provide regular releases through 2007 and beyond.</li> - <li><a href="http://mandalka.name/privatix/">Privatix LiveCD/USB</a> is a - debian based live-system including tor, firefox and torbutton which can save - bookmarks and other settings or data on an encrypted usb-key</li> - </li> - </ol> - - - Windows bundles: - - - <ol> - <li><a href="<page projects/torbrowser>">Tor Browser Bundle</a> - for Windows comes with a pre-configured web browser and is self contained - so you can run it from a USB stick.</li> - <li><a href="http://www.janusvm.com/tor_vm/">Tor VM</a> is a successor - to JanusVM. It needs testing from you!</li> - <li><a href="http://janusvm.com/">JanusVM</a> is a Linux kernel and software - running in VMWare that sits between your Windows computer and the Internet, - making sure that your Internet traffic is scrubbed and anonymized.</li> - <li><a href="http://www.xerobank.com/xB_browser.html">xB Browser</a>, - previously known as Torpark, is a Firefox+Tor package for Win32 that can - installed on a USB key. It needs a host Win32 operating system.</li> - </ol> - - - Not currently maintained as far as we know: - - - <ol> - <li>Polippix / Privatlivets Fred is a Danish Knoppix-based LiveCD with Tor - and utilities to encrypt IP-telephony. <a href="http://polippix.org/">Info and - download</a>.</li> - <li>ELE is a Linux LiveCD which is focused on privacy related - software. It includes Tor and you can download it at - <a - href="http://www.northernsecurity.net/download/ele/">http://www.northernsecurity.net/download/ele/</a>.</li> - <li>Virtual Privacy Machine is a Linux LiveCD that includes Firefox, Privoxy, - Tor, some IRC and IM applications, and a set of ipchains rules aimed to prevent - non-Tor traffic from accidentally leaving your computer. More information at - <a href="<wiki>VirtualPrivacyMachine"><wiki>VirtualPrivacyMachine</a>.</li> - <li>Anonym.OS is a LiveCD similar to the above but is based on OpenBSD rather - than Linux for maximum security. It was designed to be anonymous and secure - from the ground up, and thus has some features and limitations not found in - other LiveCDs (Tor related or otherwise). You can obtain more information and - download Anonym.OS from <a href="http://theory.kaos.to/projects.html">Kaos.Theory</a>.</li> - <li>Phantomix is a LiveCD for anonymous surfing and chatting based on the most - recent KNOPPIX release. It comes preconfigured with Privoxy, Tor and Polipo. You can - get it from the <a href="http://phantomix.ytternhagen.de/">Phantomix - Website</a>.</li> - </ol> - - - Please contact us if you know any others. - - <hr> <a id="torrc"></a>

1 0

[torsocks/master] Add missing doc/Makefile.am
by hoganrobert＠torproject.org 27 Feb '11

27 Feb '11

commit a02e49703440175c01dacade3e556227f996f246 Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Feb 27 17:41:05 2011 +0000 Add missing doc/Makefile.am --- doc/Makefile.am | 18 ++++++++++++++++++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/doc/Makefile.am b/doc/Makefile.am new file mode 100644 index 0000000..ed6cbf4 --- /dev/null +++ b/doc/Makefile.am @@ -0,0 +1,18 @@ +# Makefile used by configure to create real Makefile + +# Install configuration file +usewithtorconfdir = $(CONFDIR)/ +usewithtorconf_DATA = torsocks.conf + +# Install man pages +torsocksmanpagedir = $(mandir)/man1 +torsocksmanpage_DATA = torsocks.1 + +torsocks8manpagedir = $(mandir)/man8 +torsocks8manpage_DATA = torsocks.8 + +usewithtormanpagedir = $(mandir)/man1 +usewithtormanpage_DATA = usewithtor.1 + +torsocksconfmanpagedir = $(mandir)/man5 +torsocksconfmanpage_DATA = torsocks.conf.5

1 0

[torsocks/master] Move man pages and configuration files to docs folder
by hoganrobert＠torproject.org 27 Feb '11

27 Feb '11

commit ac681d8428a08d030ab3ab4608eddf9529159f6e Author: Robert Hogan <robert(a)roberthogan.net> Date: Sun Feb 27 12:39:21 2011 +0000 Move man pages and configuration files to docs folder --- Makefile.am | 2 +- configure.in | 4 +- doc/SOCKS4.protocol | 150 --------------------------- doc/SOCKS5 | 2 - doc/socks-extensions.txt | 79 -------------- doc/socks/SOCKS4.protocol | 150 +++++++++++++++++++++++++++ doc/socks/SOCKS5 | 2 + doc/socks/socks-extensions.txt | 79 ++++++++++++++ doc/torsocks.1.in | 63 ++++++++++++ doc/torsocks.8.in | 189 ++++++++++++++++++++++++++++++++++ doc/torsocks.conf | 56 ++++++++++ doc/torsocks.conf.5.in | 214 +++++++++++++++++++++++++++++++++++++++ doc/tsocks.conf.complex.example | 47 +++++++++ doc/tsocks.conf.simple.example | 16 +++ doc/usewithtor.1.in | 57 ++++++++++ src/Makefile.am | 17 --- src/torsocks.1.in | 63 ------------ src/torsocks.8.in | 189 ---------------------------------- src/torsocks.conf | 56 ---------- src/torsocks.conf.5.in | 214 --------------------------------------- src/tsocks.conf.complex.example | 47 --------- src/tsocks.conf.simple.example | 16 --- src/usewithtor.1.in | 57 ---------- 23 files changed, 876 insertions(+), 893 deletions(-) diff --git a/Makefile.am b/Makefile.am index 44a7fbd..0ef8147 100644 --- a/Makefile.am +++ b/Makefile.am @@ -2,4 +2,4 @@ # have all needed files, that a GNU package needs AUTOMAKE_OPTIONS = foreign 1.4 -SUBDIRS = src test +SUBDIRS = src doc test diff --git a/configure.in b/configure.in index f74a3fd..a89fa0e 100644 --- a/configure.in +++ b/configure.in @@ -634,10 +634,10 @@ AC_SUBST(LIBTOOL_DEPS) AC_ENABLE_SHARED AC_ENABLE_STATIC -AC_CONFIG_FILES([src/usewithtor src/torsocks src/torsocks.conf.5 src/torsocks.8 src/usewithtor.1 src/torsocks.1]) +AC_CONFIG_FILES([src/usewithtor src/torsocks doc/torsocks.conf.5 doc/torsocks.8 doc/usewithtor.1 doc/torsocks.1]) dnl Output the Makefile for libtorsocks -AC_OUTPUT(Makefile src/Makefile) +AC_OUTPUT(Makefile src/Makefile doc/Makefile) dnl Output the Makefile for test/test_torsocks. dnl Dump any LDFLAGS that were only required for linking libtorsocks, such as -dynamiclib on OSX. diff --git a/doc/SOCKS4.protocol b/doc/SOCKS4.protocol deleted file mode 100644 index 50fa5a7..0000000 --- a/doc/SOCKS4.protocol +++ /dev/null @@ -1,150 +0,0 @@ - SOCKS: A protocol for TCP proxy across firewalls - - Ying-Da Lee - yingda(a)best.com or yingda(a)esd.sgi.com - -SOCKS was originally developed by David Koblas and subsequently modified -and extended by me to its current running version -- version 4. It is a -protocol that relays TCP sessions at a firewall host to allow application -users transparent access across the firewall. Because the protocol is -independent of application protocols, it can be (and has been) used for -many different services, such as telnet, ftp, finger, whois, gopher, WWW, -etc. Access control can be applied at the beginning of each TCP session; -thereafter the server simply relays the data between the client and the -application server, incurring minimum processing overhead. Since SOCKS -never has to know anything about the application protocol, it should also -be easy for it to accommodate applications which use encryption to protect -their traffic from nosey snoopers. - -Two operations are defined: CONNECT and BIND. - -1) CONNECT - -The client connects to the SOCKS server and sends a CONNECT request when -it wants to establish a connection to an application server. The client -includes in the request packet the IP address and the port number of the -destination host, and userid, in the following format. - - +----+----+----+----+----+----+----+----+----+----+....+----+ - | VN | CD | DSTPORT | DSTIP | USERID |NULL| - +----+----+----+----+----+----+----+----+----+----+....+----+ - # of bytes: 1 1 2 4 variable 1 - -VN is the SOCKS protocol version number and should be 4. CD is the -SOCKS command code and should be 1 for CONNECT request. NULL is a byte -of all zero bits. - -The SOCKS server checks to see whether such a request should be granted -based on any combination of source IP address, destination IP address, -destination port number, the userid, and information it may obtain by -consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS -server makes a connection to the specified port of the destination host. -A reply packet is sent to the client when this connection is established, -or when the request is rejected or the operation fails. - - +----+----+----+----+----+----+----+----+ - | VN | CD | DSTPORT | DSTIP | - +----+----+----+----+----+----+----+----+ - # of bytes: 1 1 2 4 - -VN is the version of the reply code and should be 0. CD is the result -code with one of the following values: - - 90: request granted - 91: request rejected or failed - 92: request rejected becasue SOCKS server cannot connect to - identd on the client - 93: request rejected because the client program and identd - report different user-ids - -The remaining fields are ignored. - -The SOCKS server closes its connection immediately after notifying -the client of a failed or rejected request. For a successful request, -the SOCKS server gets ready to relay traffic on both directions. This -enables the client to do I/O on its connection as if it were directly -connected to the application server. - - -2) BIND - -The client connects to the SOCKS server and sends a BIND request when -it wants to prepare for an inbound connection from an application server. -This should only happen after a primary connection to the application -server has been established with a CONNECT. Typically, this is part of -the sequence of actions: - --bind(): obtain a socket --getsockname(): get the IP address and port number of the socket --listen(): ready to accept call from the application server --use the primary connection to inform the application server of - the IP address and the port number that it should connect to. --accept(): accept a connection from the application server - -The purpose of SOCKS BIND operation is to support such a sequence -but using a socket on the SOCKS server rather than on the client. - -The client includes in the request packet the IP address of the -application server, the destination port used in the primary connection, -and the userid. - - +----+----+----+----+----+----+----+----+----+----+....+----+ - | VN | CD | DSTPORT | DSTIP | USERID |NULL| - +----+----+----+----+----+----+----+----+----+----+....+----+ - # of bytes: 1 1 2 4 variable 1 - -VN is again 4 for the SOCKS protocol version number. CD must be 2 to -indicate BIND request. - -The SOCKS server uses the client information to decide whether the -request is to be granted. The reply it sends back to the client has -the same format as the reply for CONNECT request, i.e., - - +----+----+----+----+----+----+----+----+ - | VN | CD | DSTPORT | DSTIP | - +----+----+----+----+----+----+----+----+ - # of bytes: 1 1 2 4 - -VN is the version of the reply code and should be 0. CD is the result -code with one of the following values: - - 90: request granted - 91: request rejected or failed - 92: request rejected becasue SOCKS server cannot connect to - identd on the client - 93: request rejected because the client program and identd - report different user-ids. - -However, for a granted request (CD is 90), the DSTPORT and DSTIP fields -are meaningful. In that case, the SOCKS server obtains a socket to wait -for an incoming connection and sends the port number and the IP address -of that socket to the client in DSTPORT and DSTIP, respectively. If the -DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the -client should replace it with the IP address of the SOCKS server to which -the cleint is connected. (This happens if the SOCKS server is not a -multi-homed host.) In the typical scenario, these two numbers are -made available to the application client prgram via the result of the -subsequent getsockname() call. The application protocol must provide a -way for these two pieces of information to be sent from the client to -the application server so that it can initiate the connection, which -connects it to the SOCKS server rather than directly to the application -client as it normally would. - -The SOCKS server sends a second reply packet to the client when the -anticipated connection from the application server is established. -The SOCKS server checks the IP address of the originating host against -the value of DSTIP specified in the client's BIND request. If a mismatch -is found, the CD field in the second reply is set to 91 and the SOCKS -server closes both connections. If the two match, CD in the second -reply is set to 90 and the SOCKS server gets ready to relay the traffic -on its two connections. From then on the client does I/O on its connection -to the SOCKS server as if it were directly connected to the application -server. - - - -For both CONNECT and BIND operations, the server sets a time limit -(2 minutes in current CSTC implementation) for the establishment of its -connection with the application server. If the connection is still not -establiched when the time limit expires, the server closes its connection -to the client and gives up. diff --git a/doc/SOCKS5 b/doc/SOCKS5 deleted file mode 100644 index 40dfcbd..0000000 --- a/doc/SOCKS5 +++ /dev/null @@ -1,2 +0,0 @@ -http://www.ietf.org/rfc/rfc1928.txt - diff --git a/doc/socks-extensions.txt b/doc/socks-extensions.txt deleted file mode 100644 index 99e2b51..0000000 --- a/doc/socks-extensions.txt +++ /dev/null @@ -1,79 +0,0 @@ -$Id: socks-extensions.txt,v 1.1 2008-06-18 21:17:02 hoganrobert Exp $ -Tor's extensions to the SOCKS protocol - -1. Overview - - The SOCKS protocol provides a generic interface for TCP proxies. Client - software connects to a SOCKS server via TCP, and requests a TCP connection - to another address and port. The SOCKS server establishes the connection, - and reports success or failure to the client. After the connection has - been established, the client application uses the TCP stream as usual. - - Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and - SOCKS5 as defined in [3]. - - The stickiest issue for Tor in supporting clients, in practice, is forcing - DNS lookups to occur at the OR side: if clients do their own DNS lookup, - the DNS server can learn which addresses the client wants to reach. - SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of - SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and - hostnames. - -1.1. Extent of support - - Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows: - - BOTH: - - The BIND command is not supported. - - SOCKS4,4A: - - SOCKS4 usernames are ignored. - - SOCKS5: - - The (SOCKS5) "UDP ASSOCIATE" command is not supported. - - IPv6 is not supported in CONNECT commands. - - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is - supported. - -2. Name lookup - - As an extension to SOCKS4A and SOCKS5, Tor implements a new command value, - "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates - a remote lookup of the hostname provided as the target address in the SOCKS - request. The reply is either an error (if the address couldn't be - resolved) or a success response. In the case of success, the address is - stored in the portion of the SOCKS response reserved for remote IP address. - - (We support RESOLVE in SOCKS4 too, even though it is unnecessary.) - - For SOCKS5 only, we support reverse resolution with a new command value, - "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with - an IPv4 address as its target, Tor attempts to find the canonical - hostname for that IPv4 record, and returns it in the "server bound - address" portion of the reply. - (This command was not supported before Tor 0.1.2.2-alpha.) - -3. Other command extensions. - - Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2]. - In this case, Tor will open an encrypted direct TCP connection to the - directory port of the Tor server specified by address:port (the port - specified should be the ORPort of the server). It uses a one-hop tunnel - and a "BEGIN_DIR" relay cell to accomplish this secure connection. - - The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a - new use_begindir flag in edge_connection_t. - -4. HTTP-resistance - - Tor checks the first byte of each SOCKS request to see whether it looks - more like an HTTP request (that is, it starts with a "G", "H", or "P"). If - so, Tor returns a small webpage, telling the user that his/her browser is - misconfigured. This is helpful for the many users who mistakenly try to - use Tor as an HTTP proxy instead of a SOCKS proxy. - -References: - [1] http://archive.socks.permeo.com/protocol/socks4.protocol - [2] http://archive.socks.permeo.com/protocol/socks4a.protocol - [3] SOCKS5: RFC1928 - diff --git a/doc/socks/SOCKS4.protocol b/doc/socks/SOCKS4.protocol new file mode 100644 index 0000000..50fa5a7 --- /dev/null +++ b/doc/socks/SOCKS4.protocol @@ -0,0 +1,150 @@ + SOCKS: A protocol for TCP proxy across firewalls + + Ying-Da Lee + yingda(a)best.com or yingda(a)esd.sgi.com + +SOCKS was originally developed by David Koblas and subsequently modified +and extended by me to its current running version -- version 4. It is a +protocol that relays TCP sessions at a firewall host to allow application +users transparent access across the firewall. Because the protocol is +independent of application protocols, it can be (and has been) used for +many different services, such as telnet, ftp, finger, whois, gopher, WWW, +etc. Access control can be applied at the beginning of each TCP session; +thereafter the server simply relays the data between the client and the +application server, incurring minimum processing overhead. Since SOCKS +never has to know anything about the application protocol, it should also +be easy for it to accommodate applications which use encryption to protect +their traffic from nosey snoopers. + +Two operations are defined: CONNECT and BIND. + +1) CONNECT + +The client connects to the SOCKS server and sends a CONNECT request when +it wants to establish a connection to an application server. The client +includes in the request packet the IP address and the port number of the +destination host, and userid, in the following format. + + +----+----+----+----+----+----+----+----+----+----+....+----+ + | VN | CD | DSTPORT | DSTIP | USERID |NULL| + +----+----+----+----+----+----+----+----+----+----+....+----+ + # of bytes: 1 1 2 4 variable 1 + +VN is the SOCKS protocol version number and should be 4. CD is the +SOCKS command code and should be 1 for CONNECT request. NULL is a byte +of all zero bits. + +The SOCKS server checks to see whether such a request should be granted +based on any combination of source IP address, destination IP address, +destination port number, the userid, and information it may obtain by +consulting IDENT, cf. RFC 1413. If the request is granted, the SOCKS +server makes a connection to the specified port of the destination host. +A reply packet is sent to the client when this connection is established, +or when the request is rejected or the operation fails. + + +----+----+----+----+----+----+----+----+ + | VN | CD | DSTPORT | DSTIP | + +----+----+----+----+----+----+----+----+ + # of bytes: 1 1 2 4 + +VN is the version of the reply code and should be 0. CD is the result +code with one of the following values: + + 90: request granted + 91: request rejected or failed + 92: request rejected becasue SOCKS server cannot connect to + identd on the client + 93: request rejected because the client program and identd + report different user-ids + +The remaining fields are ignored. + +The SOCKS server closes its connection immediately after notifying +the client of a failed or rejected request. For a successful request, +the SOCKS server gets ready to relay traffic on both directions. This +enables the client to do I/O on its connection as if it were directly +connected to the application server. + + +2) BIND + +The client connects to the SOCKS server and sends a BIND request when +it wants to prepare for an inbound connection from an application server. +This should only happen after a primary connection to the application +server has been established with a CONNECT. Typically, this is part of +the sequence of actions: + +-bind(): obtain a socket +-getsockname(): get the IP address and port number of the socket +-listen(): ready to accept call from the application server +-use the primary connection to inform the application server of + the IP address and the port number that it should connect to. +-accept(): accept a connection from the application server + +The purpose of SOCKS BIND operation is to support such a sequence +but using a socket on the SOCKS server rather than on the client. + +The client includes in the request packet the IP address of the +application server, the destination port used in the primary connection, +and the userid. + + +----+----+----+----+----+----+----+----+----+----+....+----+ + | VN | CD | DSTPORT | DSTIP | USERID |NULL| + +----+----+----+----+----+----+----+----+----+----+....+----+ + # of bytes: 1 1 2 4 variable 1 + +VN is again 4 for the SOCKS protocol version number. CD must be 2 to +indicate BIND request. + +The SOCKS server uses the client information to decide whether the +request is to be granted. The reply it sends back to the client has +the same format as the reply for CONNECT request, i.e., + + +----+----+----+----+----+----+----+----+ + | VN | CD | DSTPORT | DSTIP | + +----+----+----+----+----+----+----+----+ + # of bytes: 1 1 2 4 + +VN is the version of the reply code and should be 0. CD is the result +code with one of the following values: + + 90: request granted + 91: request rejected or failed + 92: request rejected becasue SOCKS server cannot connect to + identd on the client + 93: request rejected because the client program and identd + report different user-ids. + +However, for a granted request (CD is 90), the DSTPORT and DSTIP fields +are meaningful. In that case, the SOCKS server obtains a socket to wait +for an incoming connection and sends the port number and the IP address +of that socket to the client in DSTPORT and DSTIP, respectively. If the +DSTIP in the reply is 0 (the value of constant INADDR_ANY), then the +client should replace it with the IP address of the SOCKS server to which +the cleint is connected. (This happens if the SOCKS server is not a +multi-homed host.) In the typical scenario, these two numbers are +made available to the application client prgram via the result of the +subsequent getsockname() call. The application protocol must provide a +way for these two pieces of information to be sent from the client to +the application server so that it can initiate the connection, which +connects it to the SOCKS server rather than directly to the application +client as it normally would. + +The SOCKS server sends a second reply packet to the client when the +anticipated connection from the application server is established. +The SOCKS server checks the IP address of the originating host against +the value of DSTIP specified in the client's BIND request. If a mismatch +is found, the CD field in the second reply is set to 91 and the SOCKS +server closes both connections. If the two match, CD in the second +reply is set to 90 and the SOCKS server gets ready to relay the traffic +on its two connections. From then on the client does I/O on its connection +to the SOCKS server as if it were directly connected to the application +server. + + + +For both CONNECT and BIND operations, the server sets a time limit +(2 minutes in current CSTC implementation) for the establishment of its +connection with the application server. If the connection is still not +establiched when the time limit expires, the server closes its connection +to the client and gives up. diff --git a/doc/socks/SOCKS5 b/doc/socks/SOCKS5 new file mode 100644 index 0000000..40dfcbd --- /dev/null +++ b/doc/socks/SOCKS5 @@ -0,0 +1,2 @@ +http://www.ietf.org/rfc/rfc1928.txt + diff --git a/doc/socks/socks-extensions.txt b/doc/socks/socks-extensions.txt new file mode 100644 index 0000000..99e2b51 --- /dev/null +++ b/doc/socks/socks-extensions.txt @@ -0,0 +1,79 @@ +$Id: socks-extensions.txt,v 1.1 2008-06-18 21:17:02 hoganrobert Exp $ +Tor's extensions to the SOCKS protocol + +1. Overview + + The SOCKS protocol provides a generic interface for TCP proxies. Client + software connects to a SOCKS server via TCP, and requests a TCP connection + to another address and port. The SOCKS server establishes the connection, + and reports success or failure to the client. After the connection has + been established, the client application uses the TCP stream as usual. + + Tor supports SOCKS4 as defined in [1], SOCKS4A as defined in [2], and + SOCKS5 as defined in [3]. + + The stickiest issue for Tor in supporting clients, in practice, is forcing + DNS lookups to occur at the OR side: if clients do their own DNS lookup, + the DNS server can learn which addresses the client wants to reach. + SOCKS4 supports addressing by IPv4 address; SOCKS4A is a kludge on top of + SOCKS4 to allow addressing by hostname; SOCKS5 supports IPv4, IPv6, and + hostnames. + +1.1. Extent of support + + Tor supports the SOCKS4, SOCKS4A, and SOCKS5 standards, except as follows: + + BOTH: + - The BIND command is not supported. + + SOCKS4,4A: + - SOCKS4 usernames are ignored. + + SOCKS5: + - The (SOCKS5) "UDP ASSOCIATE" command is not supported. + - IPv6 is not supported in CONNECT commands. + - Only the "NO AUTHENTICATION" (SOCKS5) authentication method [00] is + supported. + +2. Name lookup + + As an extension to SOCKS4A and SOCKS5, Tor implements a new command value, + "RESOLVE" [F0]. When Tor receives a "RESOLVE" SOCKS command, it initiates + a remote lookup of the hostname provided as the target address in the SOCKS + request. The reply is either an error (if the address couldn't be + resolved) or a success response. In the case of success, the address is + stored in the portion of the SOCKS response reserved for remote IP address. + + (We support RESOLVE in SOCKS4 too, even though it is unnecessary.) + + For SOCKS5 only, we support reverse resolution with a new command value, + "RESOLVE_PTR" [F1]. In response to a "RESOLVE_PTR" SOCKS5 command with + an IPv4 address as its target, Tor attempts to find the canonical + hostname for that IPv4 record, and returns it in the "server bound + address" portion of the reply. + (This command was not supported before Tor 0.1.2.2-alpha.) + +3. Other command extensions. + + Tor 0.1.2.4-alpha added a new command value: "CONNECT_DIR" [F2]. + In this case, Tor will open an encrypted direct TCP connection to the + directory port of the Tor server specified by address:port (the port + specified should be the ORPort of the server). It uses a one-hop tunnel + and a "BEGIN_DIR" relay cell to accomplish this secure connection. + + The F2 command value was removed in Tor 0.2.0.10-alpha in favor of a + new use_begindir flag in edge_connection_t. + +4. HTTP-resistance + + Tor checks the first byte of each SOCKS request to see whether it looks + more like an HTTP request (that is, it starts with a "G", "H", or "P"). If + so, Tor returns a small webpage, telling the user that his/her browser is + misconfigured. This is helpful for the many users who mistakenly try to + use Tor as an HTTP proxy instead of a SOCKS proxy. + +References: + [1] http://archive.socks.permeo.com/protocol/socks4.protocol + [2] http://archive.socks.permeo.com/protocol/socks4a.protocol + [3] SOCKS5: RFC1928 + diff --git a/doc/torsocks.1.in b/doc/torsocks.1.in new file mode 100644 index 0000000..b383859 --- /dev/null +++ b/doc/torsocks.1.in @@ -0,0 +1,63 @@ +.TH TORSOCKS 1 "" "TORSOCKS" + +.SH NAME +.BR torsocks +\- Shell wrapper to simplify the use of the torsocks(8) library to +transparently allow an application to use a SOCKS proxy. Basically a renamed, patched tsocks. +.SH SYNOPSIS +.B torsocks +.RB [application\ [application's\ arguments]] +.br +or +.B torsocks +.RB [on|off] +.br +or +.B torsocks +.SH DESCRIPTION +.B torsocks +is a wrapper between the torsocks library and the application what you +would like to run socksified. +.SH SUMMARY + +By default, torsocks will assume that it should connect to the SOCKS proxy +running at 127.0.0.1 on port 9050. This is the default address and port for +Tor's socks server on most installations. + +In order to use a configuration file, you must set the environment variable +TORSOCKS_CONF_FILE with the location of the file. + +If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration +file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will +use sensible defaults for most Tor installations, i.e. it will assume that +you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050. + +For further information on configuration, see +.B torsocks.conf(5). + +.SH OPTIONS +.IP \fB[application\ \fB[application's\ arguments]] +run the application as specified with the environment (LD_PRELOAD) set +such that torsocks(8) will transparently proxy SOCKS connections in +that program +.IP \fB[on|off] +this option adds or removes torsocks(8) from the LD_PRELOAD environment +variable. When torsocks(8) is in this variable all executed +applications are automatically socksified. If you want to +use this function, you HAVE to source the shell script from yours, +like this: "source /usr/bin/torsocks" or ". /usr/bin/torsocks" +.br +Example: +.br +". torsocks on" -- add the torsocks lib to LD_PRELOAD +.br +". torsocks off" -- remove the torsocks lib from LD_PRELOAD +.IP \fB[show|sh] +show the current value of the LD_PRELOAD variable +.IP \fB<without\ any\ argument> +create a new shell with LD_PRELOAD including torsocks(8). +.PP +.SH AUTHOR +This script was created by Tamas SZERB <toma(a)rulez.org> for the debian +package of tsocks. It (along with this manual page) have since been +adapted into the torsocks project and modified. diff --git a/doc/torsocks.8.in b/doc/torsocks.8.in new file mode 100644 index 0000000..0cda513 --- /dev/null +++ b/doc/torsocks.8.in @@ -0,0 +1,189 @@ +.TH TORSOCKS 8 "" "Shaun Clowes" \" -*- + \" nroff -* + +.SH NAME +.BR torsocks +\- Library for intercepting outgoing network connections and +redirecting them through a SOCKS server. + +.SH SYNOPSIS + +Set LD_PRELOAD to load the library then use applications as normal + +The syntax to force preload of the library for different shells is +specified below: + +Bash, Ksh and Bourne shell - + +export LD_PRELOAD=/lib/libtorsocks.so + +C Shell - + +setenv LD_PRELOAD=/lib/libtorsocks.so + +This process can be automated (for Bash, Bourne and Korn shell +users) for a single command or for all commands in a shell session +by using the torsocks(1) script + +You can also setup torsocks in such a way that all processes +automatically use it, a very useful configuration. For more +information on this configuration see the CAVEATS section of this +manual page. + +.SH DESCRIPTION + +.BR torsocks +is a library to allow transparent SOCKS proxying. It wraps the normal +connect() function. When a connection is attempted, it consults the +configuration file (which is defined at configure time but defaults to +/etc/torsocks.conf) and determines if the IP address specified is local. If +it is not, the library redirects the connection to a SOCKS server +specified in the configuration file. It then negotiates that connection +with the SOCKS server and passes the connection back to the calling +program. + +.BR torsocks +is designed for use in machines which are firewalled from then +internet. It avoids the need to recompile applications like lynx or +telnet so they can use SOCKS to reach the internet. It behaves much like +the SOCKSified TCP/IP stacks seen on other platforms. + +.SS ARGUMENTS +Most arguments to +.BR torsocks +are provided in the configuration file (the location of which is defined +at configure time by the \-\-with\-conf=<file> argument but defaults to +/etc/torsocks.conf). The structure of this file is documented in torsocks.conf(8) + +Some configuration options can be specified at run time using environment +variables as follows: + +.TP +.I TORSOCKS_CONFFILE +This environment variable overrides the default location of the torsocks +configuration file. This variable is not honored if the program torsocks +is embedded in is setuid. In addition this environment variable can +be compiled out of torsocks with the \-\-disable\-envconf argument to +configure at build time + +.TP +.I TORSOCKS_DEBUG +This environment variable sets the level of debug output that should be +generated by torsocks (debug output is generated in the form of output to +standard error). If this variable is not present by default the logging +level is set to 0 which indicates that only error messages should be output. +Setting it to higher values will cause torsocks to generate more messages +describing what it is doing. If set to \-1 torsocks will output absolutely no +error or debugging messages. This is only needed if torsocks output interferes +with a program it is embedded in. Message output can be permanently compiled +out of torsocks by specifying the \-\-disable\-debug option to configure at +build time + +.TP +.I TORSOCKS_DEBUG_FILE +This option can be used to redirect the torsocks output (which would normally +be sent to standard error) to a file. This variable is not honored if the +program torsocks is embedded in is setuid. For programs where torsocks output +interferes with normal operation this option is generally better than +disabling messages (with TORSOCKS_DEBUG = \-1) + +.TP +.I TORSOCKS_USERNAME +This environment variable can be used to specify the username to be used when +version 5 SOCKS servers request username/password authentication. This +overrides the default username that can be specified in the configuration +file using 'default_user', see torsocks.conf(8) for more information. This +variable is ignored for version 4 SOCKS servers. + +.TP +.I TORSOCKS_PASSWORD +This environment variable can be used to specify the password to be used when +version 5 SOCKS servers request username/password authentication. This +overrides the default password that can be specified in the configuration +file using 'default_pass', see torsocks.conf(8) for more information. This +variable is ignored for version 4 SOCKS servers. + +.SS DNS ISSUES +.BR torsocks +will normally not be able to send DNS queries through a SOCKS server since +SOCKS V4 works on TCP and DNS normally uses UDP. Version 1.5 and up do +however provide a method to force DNS lookups to use TCP, which then makes +them proxyable. This option can only enabled at compile time, please +consult the INSTALL file for more information. + +.SS ERRORS +.BR torsocks +will generate error messages and print them to stderr when there are +problems with the configuration file or the SOCKS negotiation with the +server if the TORSOCKS_DEBUG environment variable is not set to \-1 or and +\-\-disable\-debug was not specified at compile time. This output may cause +some problems with programs that redirect standard error. + +.SS CAVEATS +.BR torsocks +will not in the above configuration be able to provide SOCKS proxying to +setuid applications or applications that are not run from a shell. You can +force all applications to LD_PRELOAD the library by placing the path to +libtorsocks in /etc/ld.so.preload. Please make sure you correctly enter the +full path to the library in this file if you do this. If you get it wrong, +you will be UNABLE TO DO ANYTHING with the machine and will have to boot +it with a rescue disk and remove the file (or try the saveme program, see +the INSTALL file for more info). THIS IS A ***WARNING***, please be +careful. Also be sure the library is in the root filesystem as all hell +will break loose if the directory it is in is not available at boot time. + +.SH BUGS + +.BR torsocks +can only proxy outgoing TCP connections + +.BR torsocks +does NOT work correctly with asynchronous sockets (though it does work with +non blocking sockets). This bug would be very difficult to fix and there +appears to be no demand for it (I know of no major application that uses +asynchronous sockets) + +.BR torsocks +is NOT fully RFC compliant in its implementation of version 5 of SOCKS, it +only supports the 'username and password' or 'no authentication' +authentication methods. The RFC specifies GSSAPI must be supported by any +compliant implementation. I haven't done this, anyone want to help? + +.BR torsocks +can force the libc resolver to use TCP for name queries, if it does this +it does it regardless of whether or not the DNS to be queried is local or +not. This introduces overhead and should only be used when needed. + +.BR torsocks +uses ELF dynamic loader features to intercept dynamic function calls from +programs in which it is embedded. As a result, it cannot trace the +actions of statically linked executables, non-ELF executables, or +executables that make system calls directly with the system call trap or +through the syscall() routine. + +.SH FILES +@CONFDIR@/torsocks.conf - default torsocks configuration file + +.SH SEE ALSO +torsocks.conf(5) +torsocks(1) +usewithtor(1) + +.SH AUTHOR +Shaun Clowes (delius(a)progsoc.uts.edu.au) + +.SH COPYRIGHT +Copyright 2000 Shaun Clowes + +Renamed for use by torsocks to avoid conflict with tsocks by Robert Hogan. + +torsocks and its documentation may be freely copied under the terms and +conditions of version 2 of the GNU General Public License, as published +by the Free Software Foundation (Cambridge, Massachusetts, United +States of America). + +This documentation is based on the documentation for logwrites, another +shared library interceptor. One line of code from it was used in +torsocks and a lot of the documentation :) logwrites is by +adam(a)yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com +pub/dist/pkg diff --git a/doc/torsocks.conf b/doc/torsocks.conf new file mode 100644 index 0000000..8cc1b2c --- /dev/null +++ b/doc/torsocks.conf @@ -0,0 +1,56 @@ +# This is the configuration for libtorsocks (transparent socks) for use +# with tor, which is providing a socks server on port 9050 by default. +# +# Lines beginning with # and blank lines are ignored +# +# The basic idea is to specify: +# - Local subnets - Networks that can be accessed directly without +# assistance from a socks server +# - Paths - Paths are basically lists of networks and a socks server +# which can be used to reach these networks +# - Default server - A socks server which should be used to access +# networks for which no path is available +# Much more documentation than provided in these comments can be found in +# torsocks.conf(5) and usewithtor(1) manpages. + +# We specify local as 127.0.0.0 - 127.191.255.255 because the +# Tor MAPADDRESS virtual IP range is the rest of net 127. +# Torsocks also treats as local all the subnets that Tor does. +local = 127.0.0.0/255.128.0.0 +local = 127.128.0.0/255.192.0.0 +local = 169.254.0.0/255.255.0.0 +local = 172.16.0.0/255.240.0.0 +local = 192.168.0.0/255.255.0.0 + +# Default server +# For connections that aren't to the local subnets +# the server at 127.0.0.1 should be used (again, hostnames could be used +# too, see note above) +server = 127.0.0.1 + +# SOCKS server type defaults to 4 +#server_type = 5 + +# The port defaults to 1080 but I've stated it here for clarity +server_port = 9050 + +# Username and password (if required on a SOCKSv5 server) +#default_user = +#default_pass = + +# Paths +# For this example this machine needs to access 150.0.0.0/255.255.0.0 as +# well as port 80 on the network 150.1.0.0/255.255.0.0 through +# the socks 5 server at 10.1.7.25 (if this machines hostname was +# "socks.hello.com" we could also specify that, unless --disable-hostnames +# was specified to ./configure). + +#path { +# reaches = 150.0.0.0/255.255.0.0 +# reaches = 150.1.0.0:80/255.255.0.0 +# server = 10.1.7.25 +# server_type = 5 +# default_user = delius +# default_pass = hello +#} +# diff --git a/doc/torsocks.conf.5.in b/doc/torsocks.conf.5.in new file mode 100644 index 0000000..7cd22d8 --- /dev/null +++ b/doc/torsocks.conf.5.in @@ -0,0 +1,214 @@ +.TH TORSOCKS.CONF 5 "" "Robert Hogan" \" -*- + \" nroff -* + +.SH NAME +.BR torsocks.conf +\- configuration file for torsocks(8) + +.SH SUMMARY + +By default, torsocks will assume that it should connect to the SOCKS proxy +running at 127.0.0.1 on port 9050. This is the default address and port for +Tor's socks server on most installations. If you are running a normal Tor +installation and have no special requirements, then you should not need to +create, edit or invoke a configuration file when using torsocks. + +Your installation of torsocks includes a default configuration file +that contains values sensible for use with most Tor installations. The +installation location for your default configuration file is: + + @CONFDIR@/torsocks.conf + +In order to use a configuration file, you must set the environment variable +TORSOCKS_CONF_FILE with the location of the file. + +If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration +file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will +use sensible defaults for most Tor installations, i.e. it will assume that +you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050. + +An example of typical usage is provided under the 'example' heading at the +end of this manual page. The script 'usewithtor' provided with your torsocks +installation will set this environment variable for you, and load the +configuration file provided with your installation. + +If you want to use a custom file in a different location, you should set the +environment variable yourself and then use the torsocks command, rather than +usewithtor. + +.SH OVERVIEW + +The configuration for torsocks can be anything from two lines to hundreds of +lines based on the needs at any particular site. The basic idea is to define +any networks the machine can access directly (i.e without the use of a +SOCKS server) and define one or many SOCKS servers to be used to access +other networks (including a 'default' server). + +Local networks are declared using the 'local' keyword in the configuration +file. When applications attempt to connect to machines in networks marked +as local torsocks will not attempt to use a SOCKS server to negotiate the +connection. + +Obviously if a connection is not to a locally accessible network it will need +to be proxied over a SOCKS server. However, many installations have several +different SOCKS servers to be used to access different internal (and external) +networks. For this reason the configuration file allows the definition of +`paths' as well as a default SOCKS server. + +Paths are declared as blocks in the configuration file. That is, they begin +with a 'path {' line in the configuration file and end with a '}' line. Inside +this block directives should be used to declare a SOCKS server (as documented +later in this manual page) and 'reaches' directives should be used to declare +networks and even destination ports in those networks that this server should +be used to reach. N.B Each path MUST define a SOCKS server and contain one or +more 'reaches' directives. + +SOCKS server declaration directives that are not contained within a 'path' +block define the default SOCKS server. If torsocks needs to connect to a machine +via a SOCKS server (i.e it isn't a network declared as 'local') and no 'path' +has declared it can reach that network via a 'reaches' directive this server +is used to negotiate the connection. + +.SH CONFIGURATION SYNTAX + +The basic structure of all lines in the configuration file is: + +.RS +<directive> = <parameters> +.RE + +The exception to this is 'path' blocks which look like: + +.RS +path { +.RS +<directive> = <parameters> +.RE +} +.RE + +Empty lines are ignored and all input on a line after a '#' character is +ignored. + +.SS DIRECTIVES +The following directives are used in the torsocks configuration file: + +.TP +.I server +The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one +server may be specified per path block, or one outside a path +block (to define the default server). Unless \-\-disable-hostnames was +specified to configure at compile time the server can be specified as +a hostname (e.g "server = socks.nec.com") + +.TP +.I server_port +The port on which the SOCKS server receives requests. Only one server_port +may be specified per path block, or one outside a path (for the default +server). This directive is not required if the server is on the +standard port (1080). + +.TP +.I server_type +SOCKS version used by the server. Versions 4 and 5 are supported (but both +for only the connect operation). The default is 4. Only one server_type +may be specified per path block, or one outside a path (for the default +server). + +You can use the inspectorsocks utility to determine the type of server, see +the 'UTILITIES' section later in this manual page. + +.TP +.I default_user +This specifies the default username to be used for username and password +authentication in SOCKS version 5. In order to determine the username to +use (if the socks server requires username and password authentication) +torsocks first looks for the environment variable TSOCKS_USERNAME, then +looks for this configuration option, then tries to get the local username. +This option is not valid for SOCKS version 4 servers. Only one default_user +may be specified per path block, or one outside a path (for the default +server) + +.TP +.I default_pass +This specified the default password to be used for username and password +authentication in SOCKS version 5. In order to determine the password to +use (if the socks server requires username and password authentication) +torsocks first looks for the environment variable TSOCKS_PASSWORD, then +looks for this configuration option. This option is not valid for SOCKS +version 4 servers. Onle one default_pass may be specified per path block, +or one outside a path (for the default server) + +.TP +.I local +An IP/Subnet pair specifying a network which may be accessed directly without +proxying through a SOCKS server (e.g "local = 10.0.0.0/255.0.0.0"). +Obviously all SOCKS server IP addresses must be in networks specified as +local, otherwise torsocks would need a SOCKS server to reach SOCKS servers. + +.TP +.I reaches +This directive is only valid inside a path block. Its parameter is formed +as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range +of ports on that network) that can be accessed by the SOCKS server specified +in this path block. For example, in a path block "reaches = +150.0.0.0:80-1024/255.0.0.0" indicates to torsocks that the SOCKS server +specified in the current path block should be used to access any IPs in the +range 150.0.0.0 to 150.255.255.255 when the connection request is for ports +80-1024. + +.TP +.I tordns_enable +This enables the use of the 'tordns' feature in torsocks, which overrides the +standard C library name resolution calls to use SOCKS. The default value is +`true'. + +.TP +.I tordns_deadpool_range +Tor hidden sites do not have real IP addresses. This specifies what range of +IP addresses will be handed to the application as "cookies" for .onion names. +Of course, you should pick a block of addresses which you aren't going to ever +need to actually connect to. The default value is '127.0.69.0/255.255.255.0'. + +.TP +.I tordns_cache_size +This specifies the number of IP addresses looked up through SOCKS to cache. +The default value is 256. Each entry consumes 260 bytes of memory, so the +default adds 66,560 bytes of overhead to each 'torified' process. NOTE: if +the number of IP addresses in tordns_deadpool_range is less than the value +specified for tordns_cache_size, then the cache will be shrunk to fit the +deadpool range. This is to prevent duplicate deadpool addresses from ever +appearing in the cache. + +.SH UTILITIES +torsocks comes with two utilities that can be useful in creating and verifying +the torsocks configuration file. + +.SH EXAMPLE + + export TORSOCKS_CONF_FILE=$PWD/torsocks.conf + torsocks ssh account(a)sshserver.com + +.SH SEE ALSO +torsocks(8) + +.SH AUTHOR +Robert Hogan (robert(a)roberthogan.net) +Shaun Clowes (delius(a)progsoc.uts.edu.au) + +.SH COPYRIGHT +Copyright 2009 Robert Hogan +Copyright 2000 Shaun Clowes + +Renamed for use by torsocks to avoid conflict with torsocks by Robert Hogan. + +torsocks and its documentation may be freely copied under the terms and +conditions of version 2 of the GNU General Public License, as published +by the Free Software Foundation (Cambridge, Massachusetts, United +States of America). + +This documentation is based on the documentation for logwrites, another +shared library interceptor. One line of code from it was used in +torsocks and a lot of the documentation :) logwrites is by +adam(a)yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com +pub/dist/pkg diff --git a/doc/tsocks.conf.complex.example b/doc/tsocks.conf.complex.example new file mode 100644 index 0000000..bdeea24 --- /dev/null +++ b/doc/tsocks.conf.complex.example @@ -0,0 +1,47 @@ +# This is the configuration for libtsocks (transparent socks) +# Lines beginning with # and blank lines are ignored +# +# The basic idea is to specify: +# - Local subnets - Networks that can be accessed directly without +# assistance from a socks server +# - Paths - Paths are basically lists of networks and a socks server +# which can be used to reach these networks +# - Default server - A socks server which should be used to access +# networks for which no path is available +# Much more documentation than provided in these comments can be found in +# the man pages, tsocks(8) and tsocks.conf(8) + +# Local networks +# For this example this machine can directly access 192.168.0.0/255.255.255.0 +# (192.168.0.*) and 10.0.0.0/255.0.0.0 (10.*) + +local = 192.168.0.0/255.255.255.0 +local = 10.0.0.0/255.0.0.0 + +# Paths +# For this example this machine needs to access 150.0.0.0/255.255.0.0 as +# well as port 80 on the network 150.1.0.0/255.255.0.0 through +# the socks 5 server at 10.1.7.25 (if this machines hostname was +# "socks.hello.com" we could also specify that, unless --disable-hostnames +# was specified to ./configure). + +path { + reaches = 150.0.0.0/255.255.0.0 + reaches = 150.1.0.0:80/255.255.0.0 + server = 10.1.7.25 + server_type = 5 + default_user = delius + default_pass = hello +} + +# Default server +# For connections that aren't to the local subnets or to 150.0.0.0/255.255.0.0 +# the server at 192.168.0.1 should be used (again, hostnames could be used +# too, see note above) + +server = 192.168.0.1 +# Server type defaults to 4 so we need to specify it as 5 for this one +server_type = 5 +# The port defaults to 1080 but I've stated it here for clarity +server_port = 1080 + diff --git a/doc/tsocks.conf.simple.example b/doc/tsocks.conf.simple.example new file mode 100644 index 0000000..bf2a695 --- /dev/null +++ b/doc/tsocks.conf.simple.example @@ -0,0 +1,16 @@ +# This is the configuration for libtsocks (transparent socks) +# Lines beginning with # and blank lines are ignored +# +# This sample configuration shows the simplest (and most common) use of +# tsocks. This is a basic LAN, this machine can access anything on the +# local ethernet (192.168.0.*) but anything else has to use the SOCKS version +# 4 server on the firewall. Further details can be found in the man pages, +# tsocks(8) and tsocks.conf(5) and a more complex example is presented in +# tsocks.conf.complex.example + +# We can access 192.168.0.* directly +local = 192.168.0.0/255.255.255.0 + +# Otherwise we use the server +server = 192.168.0.1 + diff --git a/doc/usewithtor.1.in b/doc/usewithtor.1.in new file mode 100644 index 0000000..c7500cb --- /dev/null +++ b/doc/usewithtor.1.in @@ -0,0 +1,57 @@ +.TH USEWITHTOR 1 "" "USEWITHTOR" + +.SH NAME +.BR usewithtor +\- Shell wrapper to simplify the use of the torsocks(8) library to +transparently allow an application to use a SOCKS proxy. + +.SH SYNOPSIS +.B usewithtor +.RB [application\ [application's\ arguments]] +.br +.SH DESCRIPTION +.B usewithtor +is a wrapper between the torsocks library and the application what you +would like to run socksified. + +.SH OPTIONS +.IP \fB[application\ \fB[application's\ arguments]] +run the application as specified with the environment (LD_PRELOAD) set +such that torsocks(8) will transparently proxy SOCKS connections in +that program. + +.SH USEWITHTOR VERSUS TORSOCKS +.B usewithtor +runs +.B torsocks(1) +with the default configuration file, +located at +.B @CONFDIR@/torsocks.conf. +Running torsocks(1) directly means +that no configuration file will be used (unless you manually set the +TORSOCKS_CONF_FILE or TSOCKS_CONF_FILE environment variable), instead +.B torsocks(8) +will +use defaults that are sensible for most Tor installations. + +.SH USEWITHTOR VERSUS TORIFY +.B usewithtor(1) +and +.B torify(1) +intend to achieve the same ends for most +practical purposes. However +.B torify(1) +will use a default tsocks installation if one exists. +.B Usewithtor(1) +will only ever use a +.B torsocks(8) +installation. + +.SH SEE ALSO +torsocks.conf(5) +torsocks(1) +usewithtor(1) + +.SH AUTHOR +Robert Hogan (robert(a)roberthogan.net).This script is very similar to torify(1), +provided by the Tor project. \ No newline at end of file diff --git a/src/Makefile.am b/src/Makefile.am index cb69714..d6da8f3 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -2,27 +2,10 @@ libdir = @libdir@/torsocks -# Install configuration file -usewithtorconfdir = $(CONFDIR)/ -usewithtorconf_DATA = torsocks.conf - # Install invocation scripts bin_SCRIPTS = torsocks usewithtor INSTALL_SCRIPT = $(install_sh) -c -m 755 -# Install man pages -torsocksmanpagedir = $(mandir)/man1 -torsocksmanpage_DATA = torsocks.1 - -torsocks8manpagedir = $(mandir)/man8 -torsocks8manpage_DATA = torsocks.8 - -usewithtormanpagedir = $(mandir)/man1 -usewithtormanpage_DATA = usewithtor.1 - -torsocksconfmanpagedir = $(mandir)/man5 -torsocksconfmanpage_DATA = torsocks.conf.5 - # Install main library to $(prefix)/lib/tor (must match torsocks.in) lib_LTLIBRARIES = libtorsocks.la libtorsocks_la_SOURCES = torsocks.c common.c parser.c dead_pool.c darwin_warts.c socks.c diff --git a/src/torsocks.1.in b/src/torsocks.1.in deleted file mode 100644 index b383859..0000000 --- a/src/torsocks.1.in +++ /dev/null @@ -1,63 +0,0 @@ -.TH TORSOCKS 1 "" "TORSOCKS" - -.SH NAME -.BR torsocks -\- Shell wrapper to simplify the use of the torsocks(8) library to -transparently allow an application to use a SOCKS proxy. Basically a renamed, patched tsocks. -.SH SYNOPSIS -.B torsocks -.RB [application\ [application's\ arguments]] -.br -or -.B torsocks -.RB [on|off] -.br -or -.B torsocks -.SH DESCRIPTION -.B torsocks -is a wrapper between the torsocks library and the application what you -would like to run socksified. -.SH SUMMARY - -By default, torsocks will assume that it should connect to the SOCKS proxy -running at 127.0.0.1 on port 9050. This is the default address and port for -Tor's socks server on most installations. - -In order to use a configuration file, you must set the environment variable -TORSOCKS_CONF_FILE with the location of the file. - -If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration -file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will -use sensible defaults for most Tor installations, i.e. it will assume that -you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050. - -For further information on configuration, see -.B torsocks.conf(5). - -.SH OPTIONS -.IP \fB[application\ \fB[application's\ arguments]] -run the application as specified with the environment (LD_PRELOAD) set -such that torsocks(8) will transparently proxy SOCKS connections in -that program -.IP \fB[on|off] -this option adds or removes torsocks(8) from the LD_PRELOAD environment -variable. When torsocks(8) is in this variable all executed -applications are automatically socksified. If you want to -use this function, you HAVE to source the shell script from yours, -like this: "source /usr/bin/torsocks" or ". /usr/bin/torsocks" -.br -Example: -.br -". torsocks on" -- add the torsocks lib to LD_PRELOAD -.br -". torsocks off" -- remove the torsocks lib from LD_PRELOAD -.IP \fB[show|sh] -show the current value of the LD_PRELOAD variable -.IP \fB<without\ any\ argument> -create a new shell with LD_PRELOAD including torsocks(8). -.PP -.SH AUTHOR -This script was created by Tamas SZERB <toma(a)rulez.org> for the debian -package of tsocks. It (along with this manual page) have since been -adapted into the torsocks project and modified. diff --git a/src/torsocks.8.in b/src/torsocks.8.in deleted file mode 100644 index 0cda513..0000000 --- a/src/torsocks.8.in +++ /dev/null @@ -1,189 +0,0 @@ -.TH TORSOCKS 8 "" "Shaun Clowes" \" -*- - \" nroff -* - -.SH NAME -.BR torsocks -\- Library for intercepting outgoing network connections and -redirecting them through a SOCKS server. - -.SH SYNOPSIS - -Set LD_PRELOAD to load the library then use applications as normal - -The syntax to force preload of the library for different shells is -specified below: - -Bash, Ksh and Bourne shell - - -export LD_PRELOAD=/lib/libtorsocks.so - -C Shell - - -setenv LD_PRELOAD=/lib/libtorsocks.so - -This process can be automated (for Bash, Bourne and Korn shell -users) for a single command or for all commands in a shell session -by using the torsocks(1) script - -You can also setup torsocks in such a way that all processes -automatically use it, a very useful configuration. For more -information on this configuration see the CAVEATS section of this -manual page. - -.SH DESCRIPTION - -.BR torsocks -is a library to allow transparent SOCKS proxying. It wraps the normal -connect() function. When a connection is attempted, it consults the -configuration file (which is defined at configure time but defaults to -/etc/torsocks.conf) and determines if the IP address specified is local. If -it is not, the library redirects the connection to a SOCKS server -specified in the configuration file. It then negotiates that connection -with the SOCKS server and passes the connection back to the calling -program. - -.BR torsocks -is designed for use in machines which are firewalled from then -internet. It avoids the need to recompile applications like lynx or -telnet so they can use SOCKS to reach the internet. It behaves much like -the SOCKSified TCP/IP stacks seen on other platforms. - -.SS ARGUMENTS -Most arguments to -.BR torsocks -are provided in the configuration file (the location of which is defined -at configure time by the \-\-with\-conf=<file> argument but defaults to -/etc/torsocks.conf). The structure of this file is documented in torsocks.conf(8) - -Some configuration options can be specified at run time using environment -variables as follows: - -.TP -.I TORSOCKS_CONFFILE -This environment variable overrides the default location of the torsocks -configuration file. This variable is not honored if the program torsocks -is embedded in is setuid. In addition this environment variable can -be compiled out of torsocks with the \-\-disable\-envconf argument to -configure at build time - -.TP -.I TORSOCKS_DEBUG -This environment variable sets the level of debug output that should be -generated by torsocks (debug output is generated in the form of output to -standard error). If this variable is not present by default the logging -level is set to 0 which indicates that only error messages should be output. -Setting it to higher values will cause torsocks to generate more messages -describing what it is doing. If set to \-1 torsocks will output absolutely no -error or debugging messages. This is only needed if torsocks output interferes -with a program it is embedded in. Message output can be permanently compiled -out of torsocks by specifying the \-\-disable\-debug option to configure at -build time - -.TP -.I TORSOCKS_DEBUG_FILE -This option can be used to redirect the torsocks output (which would normally -be sent to standard error) to a file. This variable is not honored if the -program torsocks is embedded in is setuid. For programs where torsocks output -interferes with normal operation this option is generally better than -disabling messages (with TORSOCKS_DEBUG = \-1) - -.TP -.I TORSOCKS_USERNAME -This environment variable can be used to specify the username to be used when -version 5 SOCKS servers request username/password authentication. This -overrides the default username that can be specified in the configuration -file using 'default_user', see torsocks.conf(8) for more information. This -variable is ignored for version 4 SOCKS servers. - -.TP -.I TORSOCKS_PASSWORD -This environment variable can be used to specify the password to be used when -version 5 SOCKS servers request username/password authentication. This -overrides the default password that can be specified in the configuration -file using 'default_pass', see torsocks.conf(8) for more information. This -variable is ignored for version 4 SOCKS servers. - -.SS DNS ISSUES -.BR torsocks -will normally not be able to send DNS queries through a SOCKS server since -SOCKS V4 works on TCP and DNS normally uses UDP. Version 1.5 and up do -however provide a method to force DNS lookups to use TCP, which then makes -them proxyable. This option can only enabled at compile time, please -consult the INSTALL file for more information. - -.SS ERRORS -.BR torsocks -will generate error messages and print them to stderr when there are -problems with the configuration file or the SOCKS negotiation with the -server if the TORSOCKS_DEBUG environment variable is not set to \-1 or and -\-\-disable\-debug was not specified at compile time. This output may cause -some problems with programs that redirect standard error. - -.SS CAVEATS -.BR torsocks -will not in the above configuration be able to provide SOCKS proxying to -setuid applications or applications that are not run from a shell. You can -force all applications to LD_PRELOAD the library by placing the path to -libtorsocks in /etc/ld.so.preload. Please make sure you correctly enter the -full path to the library in this file if you do this. If you get it wrong, -you will be UNABLE TO DO ANYTHING with the machine and will have to boot -it with a rescue disk and remove the file (or try the saveme program, see -the INSTALL file for more info). THIS IS A ***WARNING***, please be -careful. Also be sure the library is in the root filesystem as all hell -will break loose if the directory it is in is not available at boot time. - -.SH BUGS - -.BR torsocks -can only proxy outgoing TCP connections - -.BR torsocks -does NOT work correctly with asynchronous sockets (though it does work with -non blocking sockets). This bug would be very difficult to fix and there -appears to be no demand for it (I know of no major application that uses -asynchronous sockets) - -.BR torsocks -is NOT fully RFC compliant in its implementation of version 5 of SOCKS, it -only supports the 'username and password' or 'no authentication' -authentication methods. The RFC specifies GSSAPI must be supported by any -compliant implementation. I haven't done this, anyone want to help? - -.BR torsocks -can force the libc resolver to use TCP for name queries, if it does this -it does it regardless of whether or not the DNS to be queried is local or -not. This introduces overhead and should only be used when needed. - -.BR torsocks -uses ELF dynamic loader features to intercept dynamic function calls from -programs in which it is embedded. As a result, it cannot trace the -actions of statically linked executables, non-ELF executables, or -executables that make system calls directly with the system call trap or -through the syscall() routine. - -.SH FILES -@CONFDIR@/torsocks.conf - default torsocks configuration file - -.SH SEE ALSO -torsocks.conf(5) -torsocks(1) -usewithtor(1) - -.SH AUTHOR -Shaun Clowes (delius(a)progsoc.uts.edu.au) - -.SH COPYRIGHT -Copyright 2000 Shaun Clowes - -Renamed for use by torsocks to avoid conflict with tsocks by Robert Hogan. - -torsocks and its documentation may be freely copied under the terms and -conditions of version 2 of the GNU General Public License, as published -by the Free Software Foundation (Cambridge, Massachusetts, United -States of America). - -This documentation is based on the documentation for logwrites, another -shared library interceptor. One line of code from it was used in -torsocks and a lot of the documentation :) logwrites is by -adam(a)yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com -pub/dist/pkg diff --git a/src/torsocks.conf b/src/torsocks.conf deleted file mode 100644 index 8cc1b2c..0000000 --- a/src/torsocks.conf +++ /dev/null @@ -1,56 +0,0 @@ -# This is the configuration for libtorsocks (transparent socks) for use -# with tor, which is providing a socks server on port 9050 by default. -# -# Lines beginning with # and blank lines are ignored -# -# The basic idea is to specify: -# - Local subnets - Networks that can be accessed directly without -# assistance from a socks server -# - Paths - Paths are basically lists of networks and a socks server -# which can be used to reach these networks -# - Default server - A socks server which should be used to access -# networks for which no path is available -# Much more documentation than provided in these comments can be found in -# torsocks.conf(5) and usewithtor(1) manpages. - -# We specify local as 127.0.0.0 - 127.191.255.255 because the -# Tor MAPADDRESS virtual IP range is the rest of net 127. -# Torsocks also treats as local all the subnets that Tor does. -local = 127.0.0.0/255.128.0.0 -local = 127.128.0.0/255.192.0.0 -local = 169.254.0.0/255.255.0.0 -local = 172.16.0.0/255.240.0.0 -local = 192.168.0.0/255.255.0.0 - -# Default server -# For connections that aren't to the local subnets -# the server at 127.0.0.1 should be used (again, hostnames could be used -# too, see note above) -server = 127.0.0.1 - -# SOCKS server type defaults to 4 -#server_type = 5 - -# The port defaults to 1080 but I've stated it here for clarity -server_port = 9050 - -# Username and password (if required on a SOCKSv5 server) -#default_user = -#default_pass = - -# Paths -# For this example this machine needs to access 150.0.0.0/255.255.0.0 as -# well as port 80 on the network 150.1.0.0/255.255.0.0 through -# the socks 5 server at 10.1.7.25 (if this machines hostname was -# "socks.hello.com" we could also specify that, unless --disable-hostnames -# was specified to ./configure). - -#path { -# reaches = 150.0.0.0/255.255.0.0 -# reaches = 150.1.0.0:80/255.255.0.0 -# server = 10.1.7.25 -# server_type = 5 -# default_user = delius -# default_pass = hello -#} -# diff --git a/src/torsocks.conf.5.in b/src/torsocks.conf.5.in deleted file mode 100644 index 7cd22d8..0000000 --- a/src/torsocks.conf.5.in +++ /dev/null @@ -1,214 +0,0 @@ -.TH TORSOCKS.CONF 5 "" "Robert Hogan" \" -*- - \" nroff -* - -.SH NAME -.BR torsocks.conf -\- configuration file for torsocks(8) - -.SH SUMMARY - -By default, torsocks will assume that it should connect to the SOCKS proxy -running at 127.0.0.1 on port 9050. This is the default address and port for -Tor's socks server on most installations. If you are running a normal Tor -installation and have no special requirements, then you should not need to -create, edit or invoke a configuration file when using torsocks. - -Your installation of torsocks includes a default configuration file -that contains values sensible for use with most Tor installations. The -installation location for your default configuration file is: - - @CONFDIR@/torsocks.conf - -In order to use a configuration file, you must set the environment variable -TORSOCKS_CONF_FILE with the location of the file. - -If TORSOCKS_CONF_FILE is not set, torsocks will attempt to read the configuration -file at @CONFDIR@/torsocks.conf. If that file cannot be read, torsocks will -use sensible defaults for most Tor installations, i.e. it will assume that -you want to use a SOCKS proxy running at 127.0.0.1 (localhost) on port 9050. - -An example of typical usage is provided under the 'example' heading at the -end of this manual page. The script 'usewithtor' provided with your torsocks -installation will set this environment variable for you, and load the -configuration file provided with your installation. - -If you want to use a custom file in a different location, you should set the -environment variable yourself and then use the torsocks command, rather than -usewithtor. - -.SH OVERVIEW - -The configuration for torsocks can be anything from two lines to hundreds of -lines based on the needs at any particular site. The basic idea is to define -any networks the machine can access directly (i.e without the use of a -SOCKS server) and define one or many SOCKS servers to be used to access -other networks (including a 'default' server). - -Local networks are declared using the 'local' keyword in the configuration -file. When applications attempt to connect to machines in networks marked -as local torsocks will not attempt to use a SOCKS server to negotiate the -connection. - -Obviously if a connection is not to a locally accessible network it will need -to be proxied over a SOCKS server. However, many installations have several -different SOCKS servers to be used to access different internal (and external) -networks. For this reason the configuration file allows the definition of -`paths' as well as a default SOCKS server. - -Paths are declared as blocks in the configuration file. That is, they begin -with a 'path {' line in the configuration file and end with a '}' line. Inside -this block directives should be used to declare a SOCKS server (as documented -later in this manual page) and 'reaches' directives should be used to declare -networks and even destination ports in those networks that this server should -be used to reach. N.B Each path MUST define a SOCKS server and contain one or -more 'reaches' directives. - -SOCKS server declaration directives that are not contained within a 'path' -block define the default SOCKS server. If torsocks needs to connect to a machine -via a SOCKS server (i.e it isn't a network declared as 'local') and no 'path' -has declared it can reach that network via a 'reaches' directive this server -is used to negotiate the connection. - -.SH CONFIGURATION SYNTAX - -The basic structure of all lines in the configuration file is: - -.RS -<directive> = <parameters> -.RE - -The exception to this is 'path' blocks which look like: - -.RS -path { -.RS -<directive> = <parameters> -.RE -} -.RE - -Empty lines are ignored and all input on a line after a '#' character is -ignored. - -.SS DIRECTIVES -The following directives are used in the torsocks configuration file: - -.TP -.I server -The IP address of the SOCKS server (e.g "server = 10.1.4.253"). Only one -server may be specified per path block, or one outside a path -block (to define the default server). Unless \-\-disable-hostnames was -specified to configure at compile time the server can be specified as -a hostname (e.g "server = socks.nec.com") - -.TP -.I server_port -The port on which the SOCKS server receives requests. Only one server_port -may be specified per path block, or one outside a path (for the default -server). This directive is not required if the server is on the -standard port (1080). - -.TP -.I server_type -SOCKS version used by the server. Versions 4 and 5 are supported (but both -for only the connect operation). The default is 4. Only one server_type -may be specified per path block, or one outside a path (for the default -server). - -You can use the inspectorsocks utility to determine the type of server, see -the 'UTILITIES' section later in this manual page. - -.TP -.I default_user -This specifies the default username to be used for username and password -authentication in SOCKS version 5. In order to determine the username to -use (if the socks server requires username and password authentication) -torsocks first looks for the environment variable TSOCKS_USERNAME, then -looks for this configuration option, then tries to get the local username. -This option is not valid for SOCKS version 4 servers. Only one default_user -may be specified per path block, or one outside a path (for the default -server) - -.TP -.I default_pass -This specified the default password to be used for username and password -authentication in SOCKS version 5. In order to determine the password to -use (if the socks server requires username and password authentication) -torsocks first looks for the environment variable TSOCKS_PASSWORD, then -looks for this configuration option. This option is not valid for SOCKS -version 4 servers. Onle one default_pass may be specified per path block, -or one outside a path (for the default server) - -.TP -.I local -An IP/Subnet pair specifying a network which may be accessed directly without -proxying through a SOCKS server (e.g "local = 10.0.0.0/255.0.0.0"). -Obviously all SOCKS server IP addresses must be in networks specified as -local, otherwise torsocks would need a SOCKS server to reach SOCKS servers. - -.TP -.I reaches -This directive is only valid inside a path block. Its parameter is formed -as IP[:startport[\-endport]]/Subnet and it specifies a network (and a range -of ports on that network) that can be accessed by the SOCKS server specified -in this path block. For example, in a path block "reaches = -150.0.0.0:80-1024/255.0.0.0" indicates to torsocks that the SOCKS server -specified in the current path block should be used to access any IPs in the -range 150.0.0.0 to 150.255.255.255 when the connection request is for ports -80-1024. - -.TP -.I tordns_enable -This enables the use of the 'tordns' feature in torsocks, which overrides the -standard C library name resolution calls to use SOCKS. The default value is -`true'. - -.TP -.I tordns_deadpool_range -Tor hidden sites do not have real IP addresses. This specifies what range of -IP addresses will be handed to the application as "cookies" for .onion names. -Of course, you should pick a block of addresses which you aren't going to ever -need to actually connect to. The default value is '127.0.69.0/255.255.255.0'. - -.TP -.I tordns_cache_size -This specifies the number of IP addresses looked up through SOCKS to cache. -The default value is 256. Each entry consumes 260 bytes of memory, so the -default adds 66,560 bytes of overhead to each 'torified' process. NOTE: if -the number of IP addresses in tordns_deadpool_range is less than the value -specified for tordns_cache_size, then the cache will be shrunk to fit the -deadpool range. This is to prevent duplicate deadpool addresses from ever -appearing in the cache. - -.SH UTILITIES -torsocks comes with two utilities that can be useful in creating and verifying -the torsocks configuration file. - -.SH EXAMPLE - - export TORSOCKS_CONF_FILE=$PWD/torsocks.conf - torsocks ssh account(a)sshserver.com - -.SH SEE ALSO -torsocks(8) - -.SH AUTHOR -Robert Hogan (robert(a)roberthogan.net) -Shaun Clowes (delius(a)progsoc.uts.edu.au) - -.SH COPYRIGHT -Copyright 2009 Robert Hogan -Copyright 2000 Shaun Clowes - -Renamed for use by torsocks to avoid conflict with torsocks by Robert Hogan. - -torsocks and its documentation may be freely copied under the terms and -conditions of version 2 of the GNU General Public License, as published -by the Free Software Foundation (Cambridge, Massachusetts, United -States of America). - -This documentation is based on the documentation for logwrites, another -shared library interceptor. One line of code from it was used in -torsocks and a lot of the documentation :) logwrites is by -adam(a)yggdrasil.com (Adam J. Richter) and can be had from ftp.yggdrasil.com -pub/dist/pkg diff --git a/src/tsocks.conf.complex.example b/src/tsocks.conf.complex.example deleted file mode 100644 index bdeea24..0000000 --- a/src/tsocks.conf.complex.example +++ /dev/null @@ -1,47 +0,0 @@ -# This is the configuration for libtsocks (transparent socks) -# Lines beginning with # and blank lines are ignored -# -# The basic idea is to specify: -# - Local subnets - Networks that can be accessed directly without -# assistance from a socks server -# - Paths - Paths are basically lists of networks and a socks server -# which can be used to reach these networks -# - Default server - A socks server which should be used to access -# networks for which no path is available -# Much more documentation than provided in these comments can be found in -# the man pages, tsocks(8) and tsocks.conf(8) - -# Local networks -# For this example this machine can directly access 192.168.0.0/255.255.255.0 -# (192.168.0.*) and 10.0.0.0/255.0.0.0 (10.*) - -local = 192.168.0.0/255.255.255.0 -local = 10.0.0.0/255.0.0.0 - -# Paths -# For this example this machine needs to access 150.0.0.0/255.255.0.0 as -# well as port 80 on the network 150.1.0.0/255.255.0.0 through -# the socks 5 server at 10.1.7.25 (if this machines hostname was -# "socks.hello.com" we could also specify that, unless --disable-hostnames -# was specified to ./configure). - -path { - reaches = 150.0.0.0/255.255.0.0 - reaches = 150.1.0.0:80/255.255.0.0 - server = 10.1.7.25 - server_type = 5 - default_user = delius - default_pass = hello -} - -# Default server -# For connections that aren't to the local subnets or to 150.0.0.0/255.255.0.0 -# the server at 192.168.0.1 should be used (again, hostnames could be used -# too, see note above) - -server = 192.168.0.1 -# Server type defaults to 4 so we need to specify it as 5 for this one -server_type = 5 -# The port defaults to 1080 but I've stated it here for clarity -server_port = 1080 - diff --git a/src/tsocks.conf.simple.example b/src/tsocks.conf.simple.example deleted file mode 100644 index bf2a695..0000000 --- a/src/tsocks.conf.simple.example +++ /dev/null @@ -1,16 +0,0 @@ -# This is the configuration for libtsocks (transparent socks) -# Lines beginning with # and blank lines are ignored -# -# This sample configuration shows the simplest (and most common) use of -# tsocks. This is a basic LAN, this machine can access anything on the -# local ethernet (192.168.0.*) but anything else has to use the SOCKS version -# 4 server on the firewall. Further details can be found in the man pages, -# tsocks(8) and tsocks.conf(5) and a more complex example is presented in -# tsocks.conf.complex.example - -# We can access 192.168.0.* directly -local = 192.168.0.0/255.255.255.0 - -# Otherwise we use the server -server = 192.168.0.1 - diff --git a/src/usewithtor.1.in b/src/usewithtor.1.in deleted file mode 100644 index c7500cb..0000000 --- a/src/usewithtor.1.in +++ /dev/null @@ -1,57 +0,0 @@ -.TH USEWITHTOR 1 "" "USEWITHTOR" - -.SH NAME -.BR usewithtor -\- Shell wrapper to simplify the use of the torsocks(8) library to -transparently allow an application to use a SOCKS proxy. - -.SH SYNOPSIS -.B usewithtor -.RB [application\ [application's\ arguments]] -.br -.SH DESCRIPTION -.B usewithtor -is a wrapper between the torsocks library and the application what you -would like to run socksified. - -.SH OPTIONS -.IP \fB[application\ \fB[application's\ arguments]] -run the application as specified with the environment (LD_PRELOAD) set -such that torsocks(8) will transparently proxy SOCKS connections in -that program. - -.SH USEWITHTOR VERSUS TORSOCKS -.B usewithtor -runs -.B torsocks(1) -with the default configuration file, -located at -.B @CONFDIR@/torsocks.conf. -Running torsocks(1) directly means -that no configuration file will be used (unless you manually set the -TORSOCKS_CONF_FILE or TSOCKS_CONF_FILE environment variable), instead -.B torsocks(8) -will -use defaults that are sensible for most Tor installations. - -.SH USEWITHTOR VERSUS TORIFY -.B usewithtor(1) -and -.B torify(1) -intend to achieve the same ends for most -practical purposes. However -.B torify(1) -will use a default tsocks installation if one exists. -.B Usewithtor(1) -will only ever use a -.B torsocks(8) -installation. - -.SH SEE ALSO -torsocks.conf(5) -torsocks(1) -usewithtor(1) - -.SH AUTHOR -Robert Hogan (robert(a)roberthogan.net).This script is very similar to torify(1), -provided by the Tor project. \ No newline at end of file

1 0