Сообщить об ошибке         Сообщить о новой версии         Дополнить описание

Описание программы Tor

Tor is a toolset for a wide range of organizations and people that want to be more safe and more secure on the Internet.
Using Tor can help you anonymize web browsing and publishing, instant messaging, IRC, SSH, and other applications that use the TCP protocol. Tor also provides a platform on which software developers can build new applications with built-in anonymity, safety, and privacy features.
Your traffic is safer when you use Tor, because communications are bounced around a distributed network of servers, called onion routers. Instead of taking a direct route from source to destination, data packets on the Tor network take a random pathway through several servers that cover your tracks so no observer at any single point can tell where the data came from or where it's going. This makes it hard for recipients, observers, and even the onion routers themselves to figure out who and where you are. Tor's technology aims to provide Internet users with protection against "traffic analysis," a form of network surveillance that threatens personal anonymity and privacy, confidential business activities and relationships, and state security.
Traffic analysis is used every day by companies, governments, and individuals that want to keep track of where people and organizations go and what they do on the Internet. Instead of looking at the content of your communications, traffic analysis tracks where your data goes and when, as well as how much is sent.
For example, online advertising companies like Fastclick and Doubleclick use traffic analysis to record what web pages you've visited, and can build a profile of your interests from that. A pharmaceutical company could use traffic analysis to monitor when the research wing of a competitor visits its website, and track what pages or products that interest the competitor. IBM hosts a searchable patent index, and it could keep a list of every query your company makes. A stalker could use traffic analysis to learn whether you're in a certain Internet cafe.
Tor aims to make traffic analysis more difficult by preventing eavesdroppers from finding out where your communications are going online, and by letting you decide whether to identify yourself when you communicate.
Tor's security is improved as its user base grows and as more people volunteer to run servers. Please consider installing it and then helping out.
Part of the goal of the Tor project is to deploy a public testbed for experimenting with design trade-offs, to teach us how best to provide privacy online. We welcome research into the security of Tor and related anonymity systems, and want to hear about any vulnerabilities you find.
Tor is an important piece of building more safety, privacy, and anonymity online, but it is not a complete solution. And remember that this is development code—it's not a good idea to rely on the current Tor network if you really need strong anonymity.

· Ключевые особенности и характеристики Tor 0.1.2.13

· Ограничения Tor 0.1.2.13

· Специальные требования Tor 0.1.2.13

· История версий и изменений Tor

· o Major bugfixes (crashes):
· - Stop crashing when the controller asks us to resetconf more than
· one config option at once. (Vidalia 0.0.11 does this.)
· - Fix a crash that happened on Win98 when we're given command-line
· arguments: don't try to load NT service functions from advapi32.dll
· except when we need them. (Bug introduced in 0.1.2.7-alpha;
· resolves bug 389.)
· - Fix a longstanding obscure crash bug that could occur when
· we run out of DNS worker processes. (Resolves bug 390.)
·
· o Major bugfixes (hidden services):
· - Correctly detect whether hidden service descriptor downloads are
· in-progress. (Suggested by Karsten Loesing; fixes bug 399.)
·
· o Major bugfixes (accounting):
· - When we start during an accounting interval before it's time to wake
· up, remember to wake up at the correct time. (May fix bug 342.)
·
· o Minor bugfixes (controller):
· - Give the controller END_STREAM_REASON_DESTROY events _before_ we
· clear the corresponding on_circuit variable, and remember later
· that we don't need to send a redundant CLOSED event. (Resolves part
· 3 of bug 367.)
· - Report events where a resolve succeeded or where we got a socks
· protocol error correctly, rather than calling both of them
· "INTERNAL".
· - Change reported stream target addresses to IP consistently when
· we finally get the IP from an exit node.
· - Send log messages to the controller even if they happen to be very
· long.
·
· o Minor bugfixes (other):
· - Display correct results when reporting which versions are
· recommended, and how recommended they are. (Resolves bug 383.)
· - Improve our estimates for directory bandwidth to be less random:
· guess that an unrecognized directory will have the average bandwidth
· from all known directories, not that it will have the average
· bandwidth from those directories earlier than it on the list.
· - If we start a server with ClientOnly 1, then set ClientOnly to 0
· and hup, stop triggering an assert based on an empty onion_key.
· - On platforms with no working mmap() equivalent, don't warn the
· user when cached-routers doesn't exist.
· - Warn the user when mmap() [or its equivalent] fails for some reason
· other than file-not-found.
· - Don't warn the user when cached-routers.new doesn't exist: that's
· perfectly fine when starting up for the first time.
· - When EntryNodes are configured, rebuild the guard list to contain,
· in order: the EntryNodes that were guards before; the rest of the
· EntryNodes; the nodes that were guards before.
· - Mask out all signals in sub-threads; only the libevent signal
· handler should be processing them. This should prevent some crashes
· on some machines using pthreads. (Patch from coderman.)
· - Fix switched arguments on memset in the implementation of
· tor_munmap() for systems with no mmap() call.
· - When Tor receives a router descriptor that it asked for, but
· no longer wants (because it has received fresh networkstatuses
· in the meantime), do not warn the user. Cache the descriptor if
· we're a cache; drop it if we aren't.
· - Make earlier entry guards _really_ get retried when the network
· comes back online.
· - On a malformed DNS reply, always give an error to the corresponding
· DNS request.
· - Build with recent libevents on platforms that do not define the
· nonstandard types "u_int8_t" and friends.
·
· o Minor features (controller):
· - Warn the user when an application uses the obsolete binary v0
· control protocol. We're planning to remove support for it during
· the next development series, so it's good to give people some
· advance warning.
· - Add STREAM_BW events to report per-entry-stream bandwidth
· use. (Patch from Robert Hogan.)
· - Rate-limit SIGNEWNYM signals in response to controllers that
· impolitely generate them for every single stream. (Patch from
· mwenge; closes bug 394.)
· - Make REMAP stream events have a SOURCE (cache or exit), and
· make them generated in every case where we get a successful
· connected or resolved cell.
·
· o Minor bugfixes (performance):
· - Call router_have_min_dir_info half as often. (This is showing up in
· some profiles, but not others.)
· - When using GCC, make log_debug never get called at all, and its
· arguments never get evaluated, when no debug logs are configured.
· (This is showing up in some profiles, but not others.)
·
· o Minor features:
· - Remove some never-implemented options. Mark PathlenCoinWeight as
· obsolete.
· - Implement proposal 106: Stop requiring clients to have well-formed
· certificates; stop checking nicknames in certificates. (Clients
· have certificates so that they can look like Tor servers, but in
· the future we might want to allow them to look like regular TLS
· clients instead. Nicknames in certificates serve no purpose other
· than making our protocol easier to recognize on the wire.)
· - Revise messages on handshake failure again to be even more clear about
· which are incoming connections and which are outgoing.
· - Discard any v1 directory info that's over 1 month old (for
· directories) or over 1 week old (for running-routers lists).
· - Do not warn when individual nodes in the configuration's EntryNodes,
· ExitNodes, etc are down: warn only when all possible nodes
· are down. (Fixes bug 348.)
· - Always remove expired routers and networkstatus docs before checking
· whether we have enough information to build circuits. (Fixes
· bug 373.)
· - Put a lower-bound on MaxAdvertisedBandwidth.

Смотреть всю историю изменений программы (3)

· Описание и дополнения от редакторов и пользователей сайта

Связанные статьи, обзоры и новости