tor-dev March 2012

tor-dev@lists.torproject.org

35 participants
30 discussions

A modest proposal for a petname system in ideas/xxx-onion-nyms.txt
by Jacob Appelbaum 19 Mar '12

19 Mar '12

Hi, Arturo and I have discussed a possible petname system for tor2web that would make it simple to remember hidden service names; it's not perfect, it's not secure and it requires comment from the community. The basic idea is to make it easy to deploy and see if anyone cares to use it. Here's the proposal in url form: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-on… Here's the proposal as text: Filename: xxx-onion-nyms.txt Title: .onion nym system Author: Arturo FilastÃ², Jacob Appelbaum Created: 17 December 2011 Status: Draft 1. Intro and Motivation The main issue that prohibits the wide scale adoption of .onion addressing is the fact that they are not human memorable. While Zooko's triangle says that you can only have at most two of "memorable", "secure" and "global" it is possible to build a simple nym mechanism that relies on the current .onion addressing system. We define a basic registration system generally and also it's particual application to the tor2web network. This is a very simple kind of petname system for applications such as tor2web. 2. Definitions These are the definitions of the actors involved in the process. Beppe - The owner of the Tor Hidden Service User - A random user of Tor/tor2web v2cbb2l4lsnpio4q.onion - The .onion address that Beppe is interested in registering antani - The nym Beppe is interested in associating to v2cbb2l4lsnpio4q.onion t2w - A tor2web node 3. Registration This is the process through which Beppe is able to make a registration for his chosen nym. 3.1 General implementation Beppe wishes to register "antani" to point to v2cbb2l4lsnpio4q.onion so he creates a a TCP service listening on his .onion will respond with the string "reg antani" when interrogated. The requester will make a lookup in his database to see if "antani" is already registered. If it is not registered the "antani" <-> v2cbb2l4lsnpio4q.onion mapping is created. A timestamp is added to the database. 3.2 Tor2web implementation Beppe creates a file called "onion.txt" containing the string "reg antani" and uploads it to the root of his web server. When User visits v2cbb2l4lsnpio4q.tor2web.org the t2w checks if his database contains a mapping with v2cbb2l4lsnpio4q.onion, if it does not, it requests the http://v2cbb2l4lsnpio4q.onion/onion.txt file. If the file exists t2w reads it and extracts the "antani" string. A lookup is made in his database. If "antani" is not registered he creates a mapping between "antani" and v2cbb2l4lsnpio4q.onion. A timestamp is added to the database. 4. Expiration A nym will expire if either the HS goes offline for longer than a given time threshold or if he explicitly requests removal of the association to that particualr nym. This allows dynamic reallocation of nyms and avoids nym squatting. 4.1 Time delay We define the default tiem threshold to be 30 days since the last check. At the time of expiry or anytime before, another request is made to either the TCP service or for the "onion.txt" file. If the Hidden Service is offline or if the requested mapping has changed the mapping is removed or modified. If the onion.txt is unchanged, the nym remains valid and the database timestamp entry is updated. 4.2 Release The HS can specify the "release" string to delete the entry from the nym database. 5. Synchronization To keep the database of registered nyms up to date in for many t2w nodes, a synchronization mechanism is required but currently out of scope for this document. All the best, Jacob

5 5

TorHS related files re-organization ?
by Fabio Pietrosanti (naif) 18 Mar '12

18 Mar '12

While thinking about TorHS key protection, it would be also nice to think about "re-organizing" the way the TorHS describe store it's data. One of the example issue i see is that currently the hostname of a TorHS is written to a text file. This provide two major drawbacks: - Application integration Any application willing to integrate with Tor and ship Tor together with the application (GlobaLeaks, TorChat, etc) must do a file i/o operation to know the hostname. If the hostname could be known via Tor ControlPort the applications integrating Tor would have a much clean and dynamic way to know it's local TorHS hostname. - Security issue Looking at the server seizure threat scenario, who seize the computer running TorHS will be able to know the identity of the TorHS itself by looking at the "hostname" file. In the context of protection by using a password to protect the TorHS key, also the hostname information (currently in "hostname" file), would need to be protected. So in such context it would be eventually useful to think about changing the structure of the HiddenServiceDir files, by merging together the "hostname" file and the TorHS key. Even better it would be cool to have an abstracted "data storage" for such kind of information, so that it would be possible to keep it file based, sql based, remotely hosted over an web services, etc. Having something like: HiddenServiceStorage file://etc/tor/hiddenservice HiddenServiceStorage dbm://etc/tor/hiddenservice.db HiddenServiceStorage http://username@password:myremotekeyhostingservice/givemykeys?${{TorServerI… While for the protection schema it may have a file protection schema like: HiddenServiceEncryptionMethod pgp, scrypt, plain, exec://usr/bin/customscript -naif

2 4

Tor HS keys password protection against impersonation attacks?
by Fabio Pietrosanti (naif) 18 Mar '12

18 Mar '12

Hi, thinking about Tor Hidden services, they are managed by using Hidden Services client keys. The Tor HS keys are "private keys" that may require to be protected because they represent also the "identity" of the Tor HS and if stolen, it would be possible to carry on impersonation attack on connecting to Tor HS. Accepting connections on behalf of the real TorHS, with the goal to steal passwords, provide fake data to clients, exploit them, etc. The Tor HS keys are even more sensible than the X509v3, as it does provide: - identity (similar to an internet domain name) - routing (similar to an internet IP address) - encryption (they provide e2e encryption, i don't know if there are attacks on crypto if they get stolen) So owning a Tor HS key it's like owning a user domain name, acquiring it's ip address and the x509v3 private key of his digital certificate bound to his domain name. As a protection schema it would be possible to create the Tor HS private key encrypted with a passphrase, like it's possible to do for x509v3 PEM certificates. That the passphrase to unlock the Tor HS key, could be provided via Tor Control Port, so an external process (UI, scripts) could manage the setup of the passphrase. That way even in case of seizure of the server running the Tor HS it would not be possible to who seized the Tor HS Server to do actively Impersonation attacks of the Tor HS. -naif

3 4

[PATCH] tor-exit-notice.html: shorten Cornell URLs
by Christian Kujau 17 Mar '12

17 Mar '12

Hi, these ever so long law.cornell.edu URLs are now automatically redirecting to a shorter version - let's use that in our tor-exit-notice.html as well. Christian. diff --git a/contrib/tor-exit-notice.html b/contrib/tor-exit-notice.html index de3be17..8cf5c29 100644 --- a/contrib/tor-exit-notice.html +++ b/contrib/tor-exit-notice.html @@ -87,7 +87,7 @@ seize this router will accomplish nothing. Furthermore, this machine also serves as a carrier of email, which means that its contents are further protected under the ECPA. <a -href="http://www4.law.cornell.edu/uscode/html/uscode18/usc_sec_18_00002707----000…">18 +href="http://www.law.cornell.edu/uscode/text/18/2707">18 USC 2707</a> explicitly allows for civil remedies ($1000/account plus legal fees) in the event of a seizure executed without good faith or probable cause (it @@ -105,7 +105,7 @@ used to violate the DMCA, please be aware that this machine does not host or contain any illegal content. Also be aware that network infrastructure maintainers are not liable for the type of content that passes over their equipment, in accordance with <a -href="http://www4.law.cornell.edu/uscode/html/uscode17/usc_sec_17_00000512----000…">DMCA +href="http://www.law.cornell.edu/uscode/text/17/512">DMCA "safe harbor" provisions</a>. In other words, you will have just as much luck sending a takedown notice to the Internet backbone providers. Please consult <a href="https://www.torproject.org/eff/tor-dmca-response">EFF's prepared -- BOFH excuse #151: Some one needed the powerstrip, so they pulled the switch plug.

2 1

Proposal: Message-based Inter-controller IPC Channel
by Mike Perry 17 Mar '12

17 Mar '12

Filename: xxx-postmessage-ipc.txt Title: Message-based Inter-controller IPC Channel Author: Mike Perry Created: 16-03-2012 Status: Proposed Target: 0.2.4.x Overview This proposal seeks to create a means for inter-controller communication using the Tor Control Port. Motivation With the advent of pluggable transports, bridge discovery mechanisms, and tighter browser-Vidalia integration, we're going to have an increasing number of collaborating Tor controller programs communicating with each other. Rather than define new pairwise IPC mechanisms for each case, we will instead create a generalized message-passing mechanism through the Tor Control Port. Control Protocol Specification Changes CONTROLLERNAME command Sent from the client to the server. The syntax is: "CONTROLLERNAME" SP ControllerID ControllerID = 1*(ALNUM / "_") Server returns "250 OK" and records the ControllerID to use for this control port connection for messaging information if successful, or "553 Controller name already in use" if the name is in use by another controller, or if an attempt is made to register the special names "all" or "unset". [CONTROLLERNAME need not be issued to send POSTMESSAGE commands, and CONTROLLERNAME may be unsupported by initial POSTMESSAGE implementations in Tor.] POSTMESSAGE command Sent from the client to the server. The syntax is: "POSTMESSAGE" SP "@" DestControllerID SP LineItem CRLF DestControllerID = "all" / 1*(ALNUM / "_") If DestControllerID is "all", the message will be posted to all controllers that have "SETEVENTS POSTMESSAGE" set. Otherwise, the message should be posted to the controller with the appropriate ControllerID. Server returns "250 OK" if successful, or "552 Invalid destination controller name" if the name is not registered. [Initial implementations may require DestControllerID always be "all"] POSTMESSAGE event "650" SP "POSTMESSAGE" SP MessageID SP SourceControllerID SP "@" DestControllerID SP LineItem CRLF MessageID = 1*DIGIT SourceControllerID = "unset" / 1*(ALNUM / "_") DestControllerID = "all" / 1*(ALNUM / "_") MessageID is an incrementing integer identifier that uniquely identifies this message to all controllers. The SourceControllerID is the value from the sending controller's CONTROLLERNAME command, or "unset" if the CONTROLLERNAME command was not used or unimplemented. GETINFO commands "recent-messages" -- Retrieves messages sent to ControllerIDs that match the current controller in POSTMESSAGE event format. This list should be generated on the fly, to handle disconnecting controllers. "new-messages" -- Retrieves the last 10 "unread" messages sent to this controller, in POSTMESSAGE event format. If SETEVENTS POSTMESSAGE was set, this command should always return nothing. "list-controllers" -- Retrieves a list of all connected controllers with either their registered ControllerID or "unset". Implementation plan The POSTMESSAGE protocol is designed to be incrementally deployable. Initial implementations are only expected to implement broadcast capabilities and SETEVENTS based delivery. CONTROLLERNAME need not be supported, nor do non-"@all" POSTMESSAGE destinations. To support command-based controllers (which do not use SETEVENTS) such as Torbutton, at minimum the "GETINFO recent-messages" command is needed. However, Torbutton does not have immediate need for this protocol. -- Mike Perry

2 2

Tor and DNS - draft finalized into proposal
by Ondrej Mikle 15 Mar '12

15 Mar '12

Hi all, the DNS/DNSSEC resolving draft for seems to be finished. I added a few thoughts on mitigating circuit correlation (mentioned in proposal 171). Somebody could look at those if they are not totally stupid (last two paragraphs of section 7). A note is added about the "DNSSEC stapling" [1] (extremely difficult, won't be implemented). The draft is here (full text pasted at the end of this mail): https://github.com/hiviah/torspec/blob/master/proposals/ideas/xxx-dns-dnsse… The draft could probably be given a "proposal number" and merged into torspec proposals directory unless there is an objection. I'll leave few weeks (2-3) in case someone finds a vulnerability or has an objection. After that I could slowly begin implementing it in a separate branch. [1] https://lists.torproject.org/pipermail/tor-dev/2012-February/003285.html Ondrej ---- pasted proposal (hopfully will wrap well) ---- Filename: xxx-dns-dnssec.txt Title: Support for full DNS and DNSSEC resolution in Tor Authors: Ondrej Mikle Created: 4 February 2012 Modified: 10 March 2012 Status: Draft 0. Overview Adding support for any DNS query type to Tor, as well as DNSSEC support. 0.1. Motivation Many applications running over Tor need more than just resolving FQDN to IPv4 and vice versa. Sometimes to prevent DNS leaks the applications have to be hacked around to be supplied necessary data by hand (e.g. SRV records in XMPP). TLS connections will benefit from planned TLSA record that provides certificate pinning to avoid another Diginotar-like fiasco. DNSSEC is part of the DNS protocol and the most appropriate place for DNSSEC API would be probably in OS libraries (e.g. libc). However that will probably take time until it becomes widespread. On the Tor's side (as opposed to application's side), DNSSEC will provide protection against DNS cache-poisoning attacks (provided that exit is not malicious itself, but still reduces attack surface). 1. Design 1.1 New cells There will be two new cells, RELAY_DNS_BEGIN and RELAY_DNS_RESPONSE (we'll use DNS_BEGIN and DNS_RESPONSE for short below). DNS_BEGIN payload: DNS packet data (variable length) The DNS packet must be generated internally by libunbound to avoid fingerprinting users by differences in client resolvers' behavior. DNS_RESPONSE payload: total length (2 octets) data (variable) Data contains the reply DNS packet or its part if packet would not fit into the cell. Total length describes length of complete response packet. AXFR and IXRF are not supported in this cell by design (see specialized tool below). 2. Interfaces to applications DNSPort evdns - existing implementation will be updated to use DNS_BEGIN. SOCKS proxy - new command will be added, containing RR type, class and query. Response will simply contain the DNS packet. 3. New options in configuration file libunbound takes couple of parameters, e.g. trust anchors and cache-size. In order not to put them all into torrc, there will be only one option, configuration file name. Tor will be distributed with some sensible defaults. New option will be named UnboundConfig and value will be filename. An option DNSQueryPolicy will determine what query types and classes are permitted: - common - class INTERNET, RR types listed on https://en.wikipedia.org/wiki/List_of_DNS_record_types#Resource_records - full - any query type and class is allowed Class CHAOS in "common" would not be of much use, since its prevalent use is for asking authoritative servers. For client side, full validation would be optional described by option DNSValidation (0|1). By default validation is turned on, otherwise it would be easy to fingerprint people who turned it on and asked for not-so-common records like SRV. 4. Changes to directory flags Exit nodes will signal their resolving capability by two flags: - CommonDNS - reflects "common" DNSQueryPolicy - FullDNS - reflects "full" DNSQueryPolicy Exit node asked for a RR type not in CommonDNS policy will return REFUSED in as status in the reply DNS packet contained in DNS_RESPONSE cell. If new types are added to CommonDNS set (e.g. new RFC adds a record type) and exit node's Tor version does not recognize it as allowed, it will send REFUSED as well. 5. Implementation notes There will be one instance of ub_ctx (libunbound resolver structure) in Tor, libunbound is thread-safe. Client will periodically purge incomplete DNS replies. Any unexpected DNS_RESPONSE will be dropped. Request for special names (.onion, .exit, .noconnect) will return REFUSED. RELAY_BEGIN would function "normally", there is no need for returning DNS data. In case of malicious exit, client can't check he's really connected to whatever IP is in A/AAAA. We won't send any NSEC/NSEC3 back in case FQDN does not exist, it would needlessly complicate things. Client can check by extra query on DNSPort. AD flag must be zeroed out on client unless validation is performed. 6. Separate tool for AXFR The AXFR tool will have similar interface like tor-resolve, but will return raw DNS data. Parameters are: query domain, server IP of authoritative DNS. The tool will transfer the data through "ordinary" tunnel using RELAY_BEGIN and related cells. This design decision serves two goals: - DNS_BEGIN and DNS_RESPONSE will be simpler to implement (lower chance of bugs) - in practice it's often useful do AXFR queries on secondary authoritative DNS servers IXFR will not be supported (infrequent corner case, can be done by manual tunnel creation over Tor if truly necessary). 7. Security implications Client as well as exit MUST block attempts to resolve local RFC 1918, 4193, 4291 adresses (PTR). An exit node resolving names will use libunbound for all types of resolving, including lookup of A/AAAA records when connecting stream to desired server. Ordinary streams will gain a small benefit of defense against DNS cache poisoning on exit node's network. Transaction ID is provided randomly by libunbound, no need to modify. This affects only DNSPort and SOCKS interfaces. As proposal 171 mentions, we need mitigate circuit correlation. One solution would be keeping multiple streams to multiple exit nodes and picking one at random for DNS resolution. Other would be keeping DNS-resolving circuit open only for a short time (e.g. 1-2 minutes). Yet another option for mitigating circuit correlation would be having separate circuit for each application, but that would require some cooperation of application and Tor, e.g. via some LD_PRELOAD mechanism. 8. TTL normalization idea A bit complex on implementation, because it requires parsing DNS packets at exit node. TTL in reply DNS packet MUST be normalized at exit node so that client won't learn what other clients queried. The normalization is done in following way: - for a RR, the original TTL value received from authoritative DNS server should be used when sending DNS_RESPONSE, trimming the values to interval [5, 600] - does not pose "ghost-cache-attack", since once RR is flushed from libunbound's cache, it must be fetched anew 9. Implementation notes I noticed that libunbound does not always parallelize requests that could be parallelized when using a forwarder (this does not apply to unrelated queries). Thus, A query for addons.mozilla.org looks like (note the interleaving of query/reponse): Time Info 0.000000 Standard query A addons.mozilla.org 0.178366 Standard query response A 63.245.217.112 RRSIG 0.178572 Standard query DNSKEY <Root> 0.178617 Standard query response DNSKEY DNSKEY RRSIG 0.178981 Standard query DS org 0.179041 Standard query response DS DS RRSIG 0.179192 Standard query DNSKEY org 0.179233 Standard query response DNSKEY DNSKEY DNSKEY DNSKEY RRSIG RRSIG 0.179505 Standard query DS mozilla.org 0.179562 Standard query response DS RRSIG 0.179717 Standard query DNSKEY mozilla.org 0.179762 Standard query response DNSKEY DNSKEY DNSKEY RRSIG RRSIG Further investigation is needed how to work around this. Maybe future version will have it fixed, since I see DNS queries exiting from unbound forwarder to authoritative DNS server are parallelized. 10. "DNSSEC stapling" The following idea tries to mitigate attack where observer of exit node can learn the fact that client's OR is "heating up DNS cache". Instead of asking for several records (DS, DNSKEY, etc.), exit node would send all of them at once in a "stapled response". Unfortunately this is extremely difficult to implement correctly [1] [2]. Thus we need to live with fact that exit node or an eavesdropper of such exit node will know that an OR used some TLD for the first time. Causing unrelated errors or vulnerabilities in Tor by implementing this algorithm is not worth the risk. References [1] https://www.ietf.org/mail-archive/web/dane/current/msg02823.html [2] http://unbound.net/pipermail/unbound-users/2012-February/002239.html

2 3

Pre-draft of Proposal XXX: Extended ORPort and TransportControlPort
by George Kadianakis 15 Mar '12

15 Mar '12

After discussion in tickets #4773 and #3587 this is a pre-draft of a proposal that revamps the Extended ORport, introduced in proposal 180, and specifies the new TransportControlPort. Comments are marked with '#', and there is also: https://trac.torproject.org/projects/tor/ticket/4773#comment:5 Note that this proposal is not ready for prime time. It needs more thought and lots of editing to become functional and implementable. Inlining: Filename: X Title: Extended ORPort and TransportControlPort Author: X Created: X Status: worse-than-draft-still-probably-more-thoughtful-than-sopa 1. Overview Proposal 180 defined Tor pluggable transports, a way to decouple protocol-level obfuscation from the core Tor protocol in order to better resist client-bridge censorship. This is achieved by introducing pluggable transport proxies, programs that obfuscate Tor traffic to resist DPI detection. Proposal 180 defined a way for pluggable transport proxies to communicate with local tor clients and bridges, so as to exchange traffic. This document extends this communication protocol, so that pluggable transport proxies can exchange arbitrary operational information and metadata with tor clients and bridges. 2. Motivation The communication protocol specified in Proposal 180 gives a way for transport proxies to announce the IP address of their clients to tor. Still, modern pluggable transports might have more (?) needs than this. For example: 1. Tor might want to inform pluggable transport proxies on how to rate-limit incoming or outgoing connections. 2. Server pluggable transport proxies might want to pass client information to an anti-active-probing system controlled by tor. 3. Tor might want to temporarily stop a transport proxy from obfuscating traffic. To satisfy the above use cases, there must be real-time communication between the tor process and the pluggable transport proxy. To achieve this, this proposal refactors the extended ORPort protocol specified in Proposal 180, and introduces a new port, TransportControlPort, whose sole role is the exchange of control information between transport proxies and tor. 3. The new extended ORPort protocol Server transport proxies may need to connect to the bridge and pass additional information about client connections that the bridge would ordinarily receive from the kernel's TCP stack. To do this, they connect to the "extended server port" as given in EXTENDED_SERVER_PORT, send a short amount of information, wait for a response, and then send the user traffic on that port. The extended server port protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Commands sent from the transport proxy to the bridge are: [0x0000] DONE: There is no more information to give. (body ignored) [0x0001] USERADDR: an address:port string that represents the user's address. [0x0002] WANT_CONTROL: A body-less message which indicates that the transport proxy wants to use the TransportControlPort of the bridge. It SHOULD be followed by a CONTROL command from the bridge, otherwise the transport may close the connection. # will this work? Replies sent from tor to the proxy are: [0x1000] OKAY: Send the user's traffic. (body ignored) [0x1001] DENY: Tor would prefer not to get more traffic from this address for a while. (body ignored) [0x1002] CONTROL: a NUL-terminated "identifier" string, followed by a second NUL-terminated string of the <address>:<port> of the TransportControlPort. The pluggable transport proxy must use the "identifier" to access the TransportControlPort. # pass TransportControlPort <address>:<port> through env. vars? # what should parties do when they receive a command they don't # understand? should we enforce forward-compatibility with protocol # versioning or with "ignore commands you don't understand", or what? [We could also use an out-of-band signalling method to tell Tor about client addresses, but that's a historically error-prone way to go about annotating connections.] The new TransportControlPort protocol The TransportControlPort protocol is as follows: COMMAND [2 bytes, big-endian] BODYLEN [2 bytes, big-endian] BODY [BODYLEN bytes] Association commands sent from the transport proxy to the bridge are: [0x0000] ASSOCIATE: a NUL-terminated "identifier" string. See 'Association' section below. Association commands sent from the bridge to the transport proxy are: [0x1000] ASSOCIATED: Sent upon receiving a legit ASSOCIATE command from a transport proxy. (body ignored) [0x1001] NOT_ASSOCIATED: Sent after the bridge receives a non-legit ASSOCIATE command from a transport proxy. Also sent when the bridge receives a non-ASSOCIATE command from a non-associated transport proxy. Upon sending this command, the bridge SHOULD close the connection. (body ignored) Configuration commands sent from the transport proxy to the bridge: [0x0001] RATE_LIMITED: Message confirming that the rate limiting request of the bridge was carried out successfully (body ignored). See the 'Rate Limiting' section below. [0x0001] NOT_RATE_LIMITED: Message notifying that the transport proxy failed to carry out the rate limiting request of the bridge (body ignored). See the 'Rate Limiting' section below. Configuration commands sent from the bridge to the transport proxy are: [0x1002] RATE_LIMIT: Carries information on how the pluggable transport proxy should rate-limit its traffic. See the 'Rate Limiting' section below. # what should parties do when they receive a command they don't understand? 3.1. Association and identifier creation For Tor and a transport proxy to communicate using the TransportControlPort, an identifier must have already been negotiated using the 'CONTROL' command of Extended ORPort. The TransportControlPort identifier should not be predictable by a user who hasn't received a 'CONTROL' command from the Extended ORPort. For this reason, the TransportControlPort identifier should not be cryptographically-weak or deterministically created. Tor should create its identifiers by generating 16 bytes of random data and hashing them with the SHA256 cryptographic hash function. The identifier string transmitted with the 'CONTROL' command should be the hex representation of the SHA256 output. 4. Configuration commands 4.1. Rate Limiting A tor relay should be able to inform a transport proxy in real-time about its rate-limiting needs. This can be achieved by using the TransportControlPort and sending a 'RATE_LIMIT' command to the transport proxy. The body of the 'RATE_LIMIT' command should carry two integers, in NUL-terminated ASCII string format, representing the bandwidth rate and bandwidth burst in 'bytes per second', that the transport proxy must set. # better transmit format? After reading langsec.org, I prefer to avoid # length fields. Not that this format is bug-proof... When the transport proxy sets the appropriate rate limiting, it should send back a 'RATE_LIMITED' command. If it fails while setting up rate limiting, it should send back a 'NOT_RATE_LIMITED' command. After sending a 'RATE_LIMIT' command. the tor bridge might want to stop pushing data to the transport proxy, till it receives a 'RATE_LIMITED' command. If, instead, it receives a 'NOT_RATE_LIMITED' command it might want to shutdown its connections to the transport proxy. # is this realistic? 5. Security Considerations Extended ORPort or TransportControlPort do _not_ provide link confidentiality, authentication or integrity. Sensitive data, like cryptographic material, should not be transferred through them. Note that an attacker with superuser access, is able to sniff network traffic, and capture TransportControlPort identifiers and any data passed through those ports. # Is it worth adding an SSL layer (passing pub. key fpr via # env. vars?)? :/ # Talk about Incentives of tor or transport proxies to comply to the # wishes of each other. Ways to detect nonconformism. (threat # model. Should tor speak with 3v1l transport proxies in the first # place?) 6. Future In the future, we might have pluggable transports which require the _client_ transport proxy to use the TransportControlPort and exchange control information with the tor client. The current proposal doesn't yet support this, but we should not add functionality that will prevent it from being possible.

2 6

Proposal 195: TLS certificate normalization for Tor 0.2.4.x
by Nick Mathewson 12 Mar '12

12 Mar '12

Filename: 195-TLS-normalization-for-024.txt Title: TLS certificate normalization for Tor 0.2.4.x Author: Jacob Appelbaum, Gladys Shufflebottom, Nick Mathewson, Tim Wilde Created: 6-Mar-2012 Status: Draft Target: 0.2.4.x 0. Introduction The TLS (Transport Layer Security) protocol was designed for security and extensibility, not for uniformity. Because of this, it's not hard for an attacker to tell one application's use of TLS from another's. We proposes improvements to Tor's current TLS certificates to reduce the distinguishability of Tor traffic. 0.1. History This draft is based on parts of Proposal 179, by Jacob Appelbaum and Gladys Shufflebottom, but removes some already implemented parts and replaces others. 0.2. Non-Goals We do not address making TLS harder to distinguish after the handshake is done. We also do not discuss TLS improvements not related to distinguishability (such as increased key size, algorithm choice, and so on). 1. Certificate Issues Currently, Tor generates certificates according to a fixed pattern, where lifetime is fairly small, the certificate Subject DN is a single randomly generated CN, and the certificate Issuer DN is a different single randomly generated CN. We propose several ways to improve this below. 1.1. Separate initial certificate from link certificate When Tor is using the v2 or v3 link handshake (see tor-spec.txt), it currently presents an initial handshake authenticating the link key with the identity key. We propose instead that Tor should be able to present an arbitrary initial certificate (so long as its key matches the link key used in the actual TLS handshake), and then present the real certificate authenticating the link key during the Tor handshake. (That is, during the v2 handshake's renegotiation step, or in the v3 handshake's CERTS cell.) The TLS protocol and the Tor handshake protocol both allow this, and doing so will give us more freedom for the alternative certificate presentation ideas below. 1.2. Allow externally generated certificates It should be possible for a Tor relay operator to generate and provide their own certificate and secret key. This will allow a relay or bridge operator to use a certificate signed by any member of the "SSL mafia,"[*] to generate their own self-signed certificate, and so on. For compatibility, we need to require that the key be an RSA secret key, of at least 1024 bits, generated with e=65537. As a proposed interface, let's require that the certificate be stored in ${DataDir}/tls_cert/tls_certificate.crt , that the secret key be stored in ${DataDir}/tls_cert/private_tls_key.key , and that they be used instead of generating our own certificate whenever the new boolean option "ProvidedTLSCert" is set to true. (Alternative interface: Allow the cert and key cert to be stored wherever, and have the user provide their respective locations with TLSCertificateFile and TLSCertificateKeyFile options.) 1.3. Longer certificate lifetimes Tor's current certificates aren't long-lived, which makes them different from most other certificates in the wild. Typically, certificates are valid for a year, so let's use that as our default lifetime. [TODO: investigate whether "a year" for most CAs and self-signed certs have their validity dates running for a calendar year ending at the second of issue, one calendar year ending at midnight, or 86400*(365.5 +/- .5) seconds, or what.] There are two ways to approach this. We could continue our current certificate management approach where we frequently generate new certificates (albeit with longer lifetimes), or we could make a cert, store it to disk, and use it for all or most of its declared lifetime. If we continue to use fairly short lifetimes for the _true_ link certificates (the ones presented during the Tor handshake), then presenting long-lived certificates doesn't hurt us much: in the event of a link-key-only compromise, the adversary still couldn't actually impersonate a server for long.[**] Using shorter-lived certificates with long nominal lifetimes doesn't seem to buy us much. It would let us rotate link keys more frequently, but we're already getting forward secrecy from our use of diffie-hellman key agreement. Further, it would make our behavior look less like regular TLS behavior, where certificates are typically used for most of their nominal lifetime. Therefore, let's store and use certs and link keys for the full year. 1.4. Self-signed certificates with better DNs When we generate our own certificates, we currently set no DN fields other than the commonName. This behavior isn't terribly common: users of self-signed certs usually/often set other fields too. [TODO: find out frequency.] Unfortunately, it appears that no particular other set of fields or way of filling them out _is_ universal for self-signed certificates, or even particularly common. The most common schema seem to be for things most censors wouldn't mind blocking, like embedded devices. Even the default openssl schema, though common, doesn't appear to represent a terribly large fraction of self-signed websites. [TODO: get numbers here.] So the best we can do here is probably to reproduce the process that results in self-signed certificates originally: let the bridge and relay operators to pick the DN fields themselves. This is an annoying interface issue, and wants a better solution. 1.5. Better commonName values Our current certificates set the commonName to a randomly generated field like www.rmf4h4h.net. This is also a weird behavior: nearly all TLS certs used for web purposes will have a hostname that resolves to their IP. The simplest way to get a plausible commonName here would be to do a reverse lookup on our IP and try to find a good hostname. It's not clear whether this would actually work out in practice, or whether we'd just get dynamic-IP-pool hostnames everywhere blocked when they appear in certificates. Alternatively, if we are told a hostname in our Torrc (possibly in the Address field), we could try to use that. 2. TLS handshake issues 2.1. Session ID. Currently we do not send an SSL session ID, as we do not support session resumption. However, Apache (and likely other major SSL servers) do have this support, and do send a 32 byte SSLv3/TLSv1 session ID in their Server Hello cleartext. We should do the same to avoid an easy fingerprinting opportunity. It may be necessary to lie to OpenSSL to claim that we are tracking session IDs to cause it to generate them for us. (We should not actually support session resumption.) [*] "Hey buddy, it's a nice website you've got there. Sure would be a shame if somebody started poppin' up warnings on all your user's browsers, tellin' everbody that you're _insecure_..." [**] Furthermore, a link-key-only compromise isn't very realistic atm; nearly any attack that would let an adversary learn a link key would probably let the adversary learn the identity key too. The most plausible way would probably be an implementation bug in OpenSSL or something.

7 9

Torperf and #3036
by Thomas S. Benjamin 12 Mar '12

12 Mar '12

Karsten, I have some time to work on Torperf right now, and I see that there are some changes in the works (#3036). Can you suggest to me which ticket(s) could currently most use my help? --- Sincerely Yours, ---Thomas S. Benjamin

2 1

Deployability of Python software.
by Arturo Filastò 10 Mar '12

10 Mar '12

We were discussing last night with George about deployability of python application on multiple platforms. In particular how it would work out if there were to be a python port of obfsproxy and we wanted to have it deployed inside of the Tor Browser bundle. The issues that he said were raised in other discussions with Nick and Roger are mainly the following: - How do we get a good Windows binary of the Software? - How do we keep the size down to an acceptable level? - What kind of performance drawbacks would we be experiencing? - Is it even secure to do crypto in python? I will try and address these issues as they are something that I ran into also while designing AWAF (Anonymous Web Application Framework): http://wiki.globaleaks.org/index.php/Awaf and https://piratenpad.de/p/AnonymousWebApplicationFramework For packaging python software on Windows and OSX, what is generally done is shipped a precompiled python interpreter and bundle everything up with a nice bow. This technique is already quite tested in real world applications: an example that I particularly like is Tucan Manager (http://www.tucaneando.com/development.html). This application is basically a download manager written in python and gtk. The final size of the packaged software is 20MB. If you remove gtk this size goes down to around 10MB. What they are using to bundle up the application for Windows is py2exe and py2app for OSX. Another very widely used solution for packaging python applications in PyInstaller and that is probably the solution I would recommend. Quite a few open source software uses it already: http://www.pyinstaller.org/wiki/ProjectsUsingPyInstaller George also mentioned to me pypy, though I don't think pypy is ready for building shippable application just yet. The issue of size is something that we should come to an agreement on what is acceptable. What is the maximum size that we are comfortable with shipping? We are already shipping a TBB that has 25 MB of QT libraries in it, I don't think a 13 MB Python interpreter is going to be killer. With respect to performance I don't think it is particularly an issue. Python is pretty fast and if it is not fast enough for what needs to be done you can always rewrite the code in C and integrate that piece of application logic as a python binding. By talking to some of the core python developers my understanding is that there is a way of securely storing keys in memory and wiping that memory region in python. It involves using bytearray. We you override a cell in a byte array you are not simply dereferencing the pointer to the python struct, you are actually overwriting that portion of memory. I think I might write a blog post about this and illustrate what other python crypto software is using to solve this problem (PyCrypto etc.). In conclusion having a python interpreter shipped as part of Tor would allow developers of anonymity related software to integrate their "Tor add-ons" into a Tor bundle easily. I am thinking of for example making a Tor IRCD bundle, a Tor HTTPD bundle, etc. What do you think? - Art.

5 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev March 2012