- tor-dev - lists.torproject.org

Re: [tor-dev] Proposal 193: Safe cookie authentication
by Robert Ransom 22 Mar '12

22 Mar '12

I've pushed a revised protocol change to branch safecookie of git.tpo/rransom/torspec.git, and a (messy, needs rebase, untested) implementation to branch safecookie-023 of git.tpo/rransom/tor.git. Now, the client and server nonces are fed to the same HMAC invocation, so that the client can believe (modulo Merkle-Damgard and general iterative hash function ‘features’) that the server knows the cookie (rather than just HMAC(constant, cookie)). Almost all controllers must drop almost all support for non-safe cookie authentication ASAP, because a compromised system-wide Tor process could drop a symlink to /home/rransom/.ed25519-secret-key in where it was supposed to put a cookie file. The sole exception to ‘non-safe cookie authentication must die’ is when a controller knows that it is connected to a server process with equal or greater access to the same filesystem it has access to. In practice, this means ‘only if you're completely sure that Tor is running in the same user account as the controller, and you're completely sure that you're connected to Tor’, and no controller is sure of either of those. Robert Ransom

2 2

Proposal 200: Adding new, extensible CREATE, EXTEND, and related cells
by Nick Mathewson 22 Mar '12

22 Mar '12

Filename: 200-new-create-and-extend-cells.txt Title: Adding new, extensible CREATE, EXTEND, and related cells Author: Robert Ransom Created: 2012-03-22 Status: Open History The original draft of this proposal was from 2010-12-27; nickm revised it slightly on 2012-03-22 and added it as proposal 200. Overview and Motivation: In Tor's current circuit protocol, every field, including the 'onion skin', in the EXTEND relay cell has a fixed meaning and length. This prevents us from extending the current EXTEND cell to support IPv6 relays, efficient UDP-based link protocols, larger 'onion keys', new circuit-extension handshake protocols, or larger identity-key fingerprints. We will need to support all of these extensions in the near future. This proposal specifies a replacement EXTEND2 cell and related cells that provide more room for future extension. Design: FIXME - allocate command ID numbers (non-RELAY commands for CREATE2 and CREATED2; RELAY commands for EXTEND2 and EXTENDED2) The CREATE2 cell contains the following payload: Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The relay payload for an EXTEND2 relay cell contains the following payload: Number of link specifiers [1 byte] N times: Link specifier type [1 byte] Link specifier length [1 byte] Link specifier [variable] Handshake type [2 bytes] Handshake data length [2 bytes] Handshake data [variable] The CREATED2 cell and EXTENDED2 relay cell both contain the following payload: Handshake data length [2 bytes] Handshake data [variable] All four cell types are padded to 512-byte cells. When a relay X receives an EXTEND2 relay cell: * X finds or opens a link to the relay Y using the link target specifiers in the EXTEND2 relay cell; if X fails to open a link, it replies with a TRUNCATED relay cell. (FIXME: what do we do now?) * X copies the handshake type and data into a CREATE2 cell and sends it along the link to Y. * If the handshake data is valid, Y replies by sending a CREATED2 cell along the link to X; otherwise, Y replies with a TRUNCATED relay cell. (XXX: we currently use a DESTROY cell?) * X copies the contents of the CREATED2 cell into an EXTENDED2 relay cell and sends it along the circuit to the OP. Link target specifiers: The list of link target specifiers must include at least one address and at least one identity fingerprint, in a format that the extending node is known to recognize. The extending node MUST NOT accept the connection unless at least one identity matches, and should follow the current rules for making sure that addresses match. [00] TLS-over-TCP, IPv4 address A four-byte IPv4 address plus two-byte ORPort [01] TLS-over-TCP, IPv6 address A sixteen-byte IPv6 address plus two-byte ORPort [02] Legacy identity A 20-byte SHA1 identity fingerprint. At most one may be listed. As always, values are sent in network (big-endian) order. Legacy handshake type: The current "onionskin" handshake type is defined to be handshake type [00 00], or "legacy". The first (client->relay) message in a handshake of type “legacy” contains the following data: ‘Onion skin’ (as in CREATE cell) [DH_LEN+KEY_LEN+PK_PAD_LEN bytes] This value is generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATE cell. The second (relay->client) message in a handshake of type “legacy” contains the following data: Relay DH public key [DH_LEN bytes] KH (see section 5.2 of tor-spec.txt) [HASH_LEN bytes] These values are generated and processed as sections 5.1 and 5.2 of tor-spec.txt specify for the current CREATED cell. After successfully completing a handshake of type “legacy”, the client and relay use the current relay cryptography protocol. Bugs: This specification does not accommodate: * circuit-extension handshakes requiring more than one round No circuit-extension handshake should ever require more than one round (i.e. more than one message from the client and one reply from the relay). We can easily extend the protocol to handle this, but we will never need to. * circuit-extension handshakes in which either message cannot fit in a single 512-byte cell along with the other required fields This can be handled by specifying a dummy handshake type whose data (sent from the client) consists of another handshake type and the beginning of the data required by that handshake type, and then using several (newly defined) HANDSHAKE_COMPLETION relay cells sent in each direction to transport the remaining handshake data. The specification of a HANDSHAKE_COMPLETION relay cell and its associated dummy handshake type can safely be postponed until we develop a circuit-extension handshake protocol that would require it. * link target specifiers that cause EXTEND2 cells to exceed 512 bytes This can be handled by specifying a LONG_COMMAND relay cell type that can be used to transport a large ‘virtual cell’ in multiple 512-byte cells. The specification of a LONG_COMMAND relay cell can safely be postponed until we develop a link target specifier, a RELAY_BEGIN2 relay cell and stream target specifier, or some other relay cell type that would require it.

1 0

Tor for iOS via official channels
by Linas Valiukas 21 Mar '12

21 Mar '12

Hello, I was thinking about a GSoC 2012 project I could propose, and I came to the question of why there's no Tor iOS (iPhone / iPad / iPod touch) application distributed on the official iTunes App Store? There's this "test package" of Tor for iOS available [1], but it has to be installed via Cydia and not everyone's phone is jailbroken. Distributing an application via the App Store has some benefits of its own too (additional marketing and visibility, easier installation, to name a few). So, what is the problem? * Would it comply with the iOS Developer Program License Agreement? I'm no lawyer, but last I read the document there's nothing in it that would prevent distributing an app which would create a "local" HTTP proxy to be used by the other applications. * Since the iPhone 3GS, the applications can retain running in the background, so I guess we're fine on the purely technical side too. * There are US Export laws that require a so-called CCATS review and approval to be done with each application that employs strong encryption. I don't think that's a blocker though. * Maybe that Tor iOS application wouldn't reach various "interesting" markets such as PRC (for example, a commercial yet pricy "Covert Browser" [2] is not available in China's App Store) because of the legal restrictions. Still, I would argue that it is worth having such an application. Regards, [1]: http://sid77.slackware.it/ios/ [2]: http://itunes.apple.com/us/app/covert-browser/id477438328?mt=8 -- Linas Valiukas +370 687 65870 www.pypt.lt

5 6

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Jacob Appelbaum 21 Mar '12

21 Mar '12

On 03/20/2012 09:08 PM, Nick Mathewson wrote: > On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > [...] >> Ah ha. That sounds like a nightmare. Is there a bug report we can pile >> on to request that they don't create a headache for everyone in the future? > > There is, but I don't currently see much point: their developers are > irritated, and know that other developers are irritated, and believe > that they can't take any actual action without word from their legal > department. > We can provide packages for users or a spec file for their users as an alternative, I guess? I think generally we're already doing this by providing the Tor Browser but all users with system tors are going to be left out... >>>> It seems that our integration with >>>> platforms is really heading in a bad direction. I'd like to figure out >>>> how to not diverge entirely and if possible to fix or document the issues. >>> >>> I don't know what you mean by "diverge" here -- do you mean that >>> different platforms may advertise different ciphers based on their >>> version of OpenSSL or whether their legal department fears ECC? If >>> so, then all non-Tor OpenSSL applications running on those hosts >>> already leak this information. >> >> I mean - Tor's cipher suite advertisement will be really wacky, >> basically on a platform by platform basis, version by version basis. >> What we expect to say about tor's fingerprint is less and less easy to >> say concisely, or perhaps it's easy but has a few variants? It seems >> like we'll have to track it more closely, perhaps by sniffing network >> traces on a per OS basis? > > It should be fairly easy to notice what ciphers we are really > advertising, and warn when it isn't the list we want to advertise. > Sure, it's just a simple matter of programming. ;-) > What we can expect to say about the fingerprint will be: "If you have > a default build of OpenSSL 1.0.0 or later, then you will look like > Firefox 8+ (modulo other issues not related to ciphersuites). If you > have an ECC-disabled build of OpenSSL 1.0.0 or later, then you will > look like FF8+ with all the ECC turned off. (I am pretty sure that > Fedora does indeed turn off the ECC in the Firefox they ship.) > Otherwise, if you have a really weird OpenSSL build, or an older > version of OpenSSL, your fingerprint will be weird." > I think that's a lot of stuff to say - we'll probably want to keep track of our various fingerprints somewhere - a bug or the wiki, perhaps? > [...] >> My thought was as follows - we have a >> pt_client{many-cipher-suites-support} that can be made to impersonate >> many browsers, it can try to connect to either relays which it can thus >> become Firefox without issue or to a bridge with this >> pt_server{many-cipher-suites-support} support and so it can pretend to >> be nearly anything. I probably should have made that suggestion more >> explicit. >> >> But yes, I agree, unless we can make the servers support the required >> ciphers, I think we're doomed. I didn't miss that, I was just trying to >> suggest a hack whereby we can impersonate IE as a pluggable transport. >> >> I've wondered for a while about cipher suites, specifically, why can't >> we just lie on the wire and then internally map ciphers as we like? For >> example - our client sends ECDHE but our server understands this is us >> trying as a client to impersonate IE and maps that to some other forward >> secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a >> TLS nightmare but, I guess it feels like we're heading there anyway...? > > Actually, we are heading AWAY from the TLS nightmare. That's the point > of this proposal: to minimize our use of ClientHello ciphersuite > fakery, so that the TLS ciphersuite negotiation handshake can > eventually just work again. > Well, OK, I think I understand that. Sorta. I agree that it is a step in the right direction but I do think it's a nightmare unless we have some way to basically make tor perform uniformly without us tracking things. Basically, we can impersonate a few browsers on the client side but the relays limit our ability to impersonate properly. It seems like a lot of stuff to keep track up, I already want a lookup table to know which version of tor, which version of openssl, which platform, etc to know what my handshake looks like and so on. It's not that complicated, it's just complicated enough though... > The idea above wouldn't work in any straightforward way: It is easy to > tell a DHE handshake from an ECDHE handshake -- for example, by > looking at the group parameters, which are sent in the clear! -- so if > the server says that it picks one but then the server and the client > do another, that would be really easy to detect. Ok, I admit, I had no idea that the group parameters were sent in the clear - I agree, just hacking up the cipher suites isn't actually useful in that case. Argh! All the best, Jake

1 0

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 21 Mar '12

21 Mar '12

Jacob sent me this message in reply to my last; sending to tor-dev with permission. On Tue, Mar 20, 2012 at 11:57 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > On 03/20/2012 08:14 PM, Nick Mathewson wrote: >> On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: >>> On 03/20/2012 08:33 AM, Nick Mathewson wrote: >>>> Filename: 198-restore-clienthello-semantics.txt >>>> Title: Restore semantics of TLS ClientHello >>>> Author: Nick Mathewson >>>> Created: 19-Mar-2012 >>>> Status: Open >>>> >>> >>> [ ... ] >>> >>> >>>> Currently, OpenSSL 1.0.0 (in its default configuration) supports every >>>> cipher that we would need in order to give the same list as Firefox >>>> versions 8 through 11 give in their default configuration, with the >>>> exception of the FIPS ciphersuite above. Therefore, we will be able >>>> to fake the new ciphersuite list correctly in all of our bundles that >>>> include OpenSSL, and on every version of Unix that keeps up-to-date. >>>> >>>> However, versions of Tor compiled to use older versions of OpenSSL, or >>>> versions of OpenSSL with some ciphersuites disabled, will no >>>> longer give the same ciphersuite lists as other versions of Tor. On >>>> these platforms, Tor clients will no longer impersonate Firefox. >>>> Users who need to do so will have to download one of our bundles, or >>>> use a (non-system) OpenSSL. >>>> >>> >>> What platforms have this issue? >> >> The ones that don't have OpenSSL 1.0.0, and the ones that turn off >> some of the relevant ciphersuites in OpenSSL 1.0.0. > > > Sure, I understand the pre-OpenSSL 1.0.0 issue - I mostly wondered what > platforms don't support the relevant ciphersuites in their builds of > OpenSSL 1.0.0. We should either 0) file bug reports 1) offer packages > that fix the issue or 2) something else such as ignoring it and simply > tracking the issues. > >> >> With time, the number of platforms that don't ship 1.0.0 or later will >> fall. Furthermore, we can support them just fine with a TBB that >> includes OpenSSL. >> > > Sure. That makes sense. The main downside is that TBB is a UX nightmare. > It works OK for browsing and basically everything else becomes ten times > the nightmare. > >> To the best of my knowledge, Fedora is the only major OS that ships >> OpenSSL and turns off any of the ciphersuites we care about, though >> there could be more. Last I heard, their legal department were >> reviewing that decision. >> > > Ah ha. That sounds like a nightmare. Is there a bug report we can pile > on to request that they don't create a headache for everyone in the future? > >>> It seems that our integration with >>> platforms is really heading in a bad direction. I'd like to figure out >>> how to not diverge entirely and if possible to fix or document the issues. >> >> I don't know what you mean by "diverge" here -- do you mean that >> different platforms may advertise different ciphers based on their >> version of OpenSSL or whether their legal department fears ECC? If >> so, then all non-Tor OpenSSL applications running on those hosts >> already leak this information. > > I mean - Tor's cipher suite advertisement will be really wacky, > basically on a platform by platform basis, version by version basis. > What we expect to say about tor's fingerprint is less and less easy to > say concisely, or perhaps it's easy but has a few variants? It seems > like we'll have to track it more closely, perhaps by sniffing network > traces on a per OS basis? >> >> But in any case, I think that the damage is self-healing (as people >> upgrade to OpenSSL 1.0.0) and the alternative of being stuck on our >> current ciphersuites forever is worse. >> > > Ok. That I find pretty convincing. > >>>> Open questions: >>>> >>>> Should the client drop connections if the server chooses a bad >>>> cipher, or a suite without forward secrecy? >>>> >>> >>> I think so. Do we have any relays that do not currently support forward >>> secrecy? >> >> No. >> > > Ok. > >> The question is, what should a client do if the relay selects, say, >> TLS_RSA_AES_128_CBC_SHA1 (ciphersuite name may not be exact). If it >> drops the connection immediately, that might be unusual behavior. >> Some other behavior might be smarter: perhaps it should pause for a >> while, then drop. Or perhaps it should send a little junk data then >> drop. I'm not sure there, though. > > Ah. What does s_client do if that selected cipher is not supported? When > in doubt, I often just punt and do what s_client does... > >> >> [...] >>>> Can we do anything to eventually allow the IE7+[**] cipher list as >>>> well? IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or >>>> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current >>>> Tor servers, which _only_ support those. It looks like the only >>>> forward-secure ciphersuites that IE7+ *does* support are ECDHE ones, >>>> and DHE+DSS ones. So if we want this flexibility, we could mandate >>>> server-side ECDHE, or somehow get DHE+DSS support (which would play >>>> havoc with our current certificate generation code IIUC), or say that >>>> it is sometimes acceptable to have a non-forward-secure link >>>> protocol[***]. None of these answers seems like a great one. Is one >>>> best? Are there other options? >>>> >>> >>> This sounds like a job for pluggable transports! >>> >>> I think as long as the servers support as many ciphers as possible, we >>> can make simple pluggable transports that setup the cipher suites we >>> want to use - no? >> >> Pluggable transports feel out-of-scope for this proposal. But even if >> they are, I don't see how they answer my question: Because (as a >> given!) current servers do not support any of the forward-secure >> ciphers on the IE7 list, if we want to impersonate IE7 or later, we >> will be doing something that current servers cannot support. Whether >> this impersonation is done somehow as a plugin, or in Tor, it would >> still be something we needed to coordinate with the servers in >> question. >> > > My thought was as follows - we have a > pt_client{many-cipher-suites-support} that can be made to impersonate > many browsers, it can try to connect to either relays which it can thus > become Firefox without issue or to a bridge with this > pt_server{many-cipher-suites-support} support and so it can pretend to > be nearly anything. I probably should have made that suggestion more > explicit. > > But yes, I agree, unless we can make the servers support the required > ciphers, I think we're doomed. I didn't miss that, I was just trying to > suggest a hack whereby we can impersonate IE as a pluggable transport. > > I've wondered for a while about cipher suites, specifically, why can't > we just lie on the wire and then internally map ciphers as we like? For > example - our client sends ECDHE but our server understands this is us > trying as a client to impersonate IE and maps that to some other forward > secret cipher suite like TLS_DHE_RSA_WITH_AES_128_SHA? I'm sure it's a > TLS nightmare but, I guess it feels like we're heading there anyway...? > > (I'm sorry if this seems rambly, I've been pretty sick...) > > All the best, > Jake

1 1

Re: [tor-dev] Proposal 198: Restore semantics of TLS ClientHello
by Nick Mathewson 21 Mar '12

21 Mar '12

Forgot to send this to tor-dev: ouch. Sending now. On Tue, Mar 20, 2012 at 9:30 PM, Jacob Appelbaum <jacob(a)appelbaum.net> wrote: > On 03/20/2012 08:33 AM, Nick Mathewson wrote: >> Filename: 198-restore-clienthello-semantics.txt >> Title: Restore semantics of TLS ClientHello >> Author: Nick Mathewson >> Created: 19-Mar-2012 >> Status: Open >> > > [ ... ] > > >> Currently, OpenSSL 1.0.0 (in its default configuration) supports every >> cipher that we would need in order to give the same list as Firefox >> versions 8 through 11 give in their default configuration, with the >> exception of the FIPS ciphersuite above. Therefore, we will be able >> to fake the new ciphersuite list correctly in all of our bundles that >> include OpenSSL, and on every version of Unix that keeps up-to-date. >> >> However, versions of Tor compiled to use older versions of OpenSSL, or >> versions of OpenSSL with some ciphersuites disabled, will no >> longer give the same ciphersuite lists as other versions of Tor. On >> these platforms, Tor clients will no longer impersonate Firefox. >> Users who need to do so will have to download one of our bundles, or >> use a (non-system) OpenSSL. >> > > What platforms have this issue? The ones that don't have OpenSSL 1.0.0, and the ones that turn off some of the relevant ciphersuites in OpenSSL 1.0.0. With time, the number of platforms that don't ship 1.0.0 or later will fall. Furthermore, we can support them just fine with a TBB that includes OpenSSL. To the best of my knowledge, Fedora is the only major OS that ships OpenSSL and turns off any of the ciphersuites we care about, though there could be more. Last I heard, their legal department were reviewing that decision. > It seems that our integration with > platforms is really heading in a bad direction. I'd like to figure out > how to not diverge entirely and if possible to fix or document the issues. I don't know what you mean by "diverge" here -- do you mean that different platforms may advertise different ciphers based on their version of OpenSSL or whether their legal department fears ECC? If so, then all non-Tor OpenSSL applications running on those hosts already leak this information. But in any case, I think that the damage is self-healing (as people upgrade to OpenSSL 1.0.0) and the alternative of being stuck on our current ciphersuites forever is worse. >> Open questions: >> >> Should the client drop connections if the server chooses a bad >> cipher, or a suite without forward secrecy? >> > > I think so. Do we have any relays that do not currently support forward > secrecy? No. The question is, what should a client do if the relay selects, say, TLS_RSA_AES_128_CBC_SHA1 (ciphersuite name may not be exact). If it drops the connection immediately, that might be unusual behavior. Some other behavior might be smarter: perhaps it should pause for a while, then drop. Or perhaps it should send a little junk data then drop. I'm not sure there, though. [...] >> Can we do anything to eventually allow the IE7+[**] cipher list as >> well? IE does not support TLS_DHE_RSA_WITH_AES_{256,128}_SHA or >> SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, and so wouldn't work with current >> Tor servers, which _only_ support those. It looks like the only >> forward-secure ciphersuites that IE7+ *does* support are ECDHE ones, >> and DHE+DSS ones. So if we want this flexibility, we could mandate >> server-side ECDHE, or somehow get DHE+DSS support (which would play >> havoc with our current certificate generation code IIUC), or say that >> it is sometimes acceptable to have a non-forward-secure link >> protocol[***]. None of these answers seems like a great one. Is one >> best? Are there other options? >> > > This sounds like a job for pluggable transports! > > I think as long as the servers support as many ciphers as possible, we > can make simple pluggable transports that setup the cipher suites we > want to use - no? Pluggable transports feel out-of-scope for this proposal. But even if they are, I don't see how they answer my question: Because (as a given!) current servers do not support any of the forward-secure ciphers on the IE7 list, if we want to impersonate IE7 or later, we will be doing something that current servers cannot support. Whether this impersonation is done somehow as a plugin, or in Tor, it would still be something we needed to coordinate with the servers in question. cheers, -- Nick

1 0

Mnemonic 80-bit phrases (proposal)
by Sai 20 Mar '12

20 Mar '12

Hello all. We've written up our proposal for mnemonic .onion URLs. See https://docs.google.com/document/d/sT5CulCVl0X5JeOv4W_wC_A/edit?disco=AAAAA… for details; please read the full intro for explanations and caveats, as some are important. tl;dr: It's a system that would have all three properties of being secure, distributed, and human-meaningful… but would *not* also have choice of name (though it has the required *canonicality* of names), and has a somewhat absurdist definition of 'meaningful'. :-P Please feel free to put comments there or on list. Right now we're at the stage just before implementation; namely, we haven't yet collated the necessary dictionaries, but we have a reasonably good idea of how the system would work, including needed constraints on the dictionaries. If you have suggestions or comments, now is a good time to talk about them, so that if any of it affects the dictionary collation step we don't waste work. Thanks, Sai

6 13

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