tor-dev

tor-dev@lists.torproject.org

3581 discussions

Changing Rendezvous Single Onion Service at Runtime
by teor 10 Nov '15

10 Nov '15

Hi all, Is there any reason an onion service would want to temporarily switch from 1-hop to 3-hop paths? Is it ok if we force operators to restart the tor instance when onion service path lengths change? The original proposal for rendezvous single onion services (RSOS) was silent on whether path lengths could change at runtime. (I honestly didn't think anyone would do that!) The existing proposal doesn't allow operators to run hidden services (HS) and RSOS on the same Tor instance at the same time. I'd like to strengthen this security feature, and ensure operators can't run HS and RSOS on the same instance sequentially. This would also mean that operators can't switch an onion service's flavour from HS to RSOS or vice versa at runtime. In detail, this means that after an onion service is launched, a Tor instance can only run all RSOS, or all HS, until Tor is restarted. This design change protects operators from inadvertent network address disclosure from running onion services with 1 and 3 hop paths on the same Tor instance. But it also supports an ephemeral RSOS use-case, where the operator launches Tor, sets (or unsets) RendezvousSingleOnionServiceNonAnonymousServer, then launches an onion service. To implement this change, Tor needs to check: if RendezvousSingleOnionServiceNonAnonymousServer is changed, and there are any onion services active (excluding deleted/inactive services, if this is a feature of (ephemeral) services), then reject the change and warn the user. (Tell them to restart if they really want to change it.) For what it's worth, the implementation is also much simpler if we force a restart when this parameter changes. If we start enforcing the recommended options, like disabling entry guards and pathbias, a restart will be even more important. I've been talking with asn about this on Trac ticket #17178. Please feel free to comment by email or on the ticket. I'll modify the proposal after I'm sure this covers all use cases. In summary: Is there any rendezvous single onion service use case that wouldn't be possible with this new restriction? I want to check we aren't breaking any neat onion service uses, if we force Tor to restart when changing path lengths. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com PGP 968F094B teor at blah dot im OTR CAD08081 9755866D 89E2A06F E3558B7F B5A9D14F

3 2

Proposal: Adding x-namespace to relay descriptor for key:value pairs
by Virgil Griffith 09 Nov '15

09 Nov '15

Filename: ExtraRelayDescriptorFields.txt Title: Adding x-namespace to relay descriptor for key:value pairs Author: Virgil Griffith Created: 2015-09-30 Status: Open 1. Motivation We wish to allow developers to build new applications atop relays. Towards this end, we wish to add the ability for users to specify arbitrary new key-value entries under the "X-" namespace to the router descriptor [1]. The canonical applications for this are adding a bitcoin donation address and networking of tor2web nodes. 2. Proposal Allow optional key-value lines in the relay's torrc file. These lines will be mirrored in the relay's descriptor which is then published in the directory consensus. The following would be added to section 2.1.2 of the dir-spec (Extra-info document format): ======================================================== "X-" CustomKey SP CustomValue NL CustomKeyChar = "a"-"z" / "0" - "9" / "-" / "_" CustomKey = 1*32 CustomKeyChar CustomValueChar = atext / specials CustomValue = 1*1024 CustomValueChar Custom fields can appear multiple times, for example... X-bitcoin 19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 X-gravatar https://s.gravatar.com/avatar/d27fce46c9ac41a41bb52455ae75701d X-favoritequote Be excellent to each other. Party on dudes! X-foo bar If the same CustomKey appearing more than once is disallowed. Possible values for CustomValueChar as specified per RFC 2822. The sum size accounting for all such custom fields is truncated to 5 kilobytes. ======================================================== To mitigate the chance of a malformed torrc file, I additionally propose that the relay descriptor be scanned and if it does not match the specification, that it exit with error telling her torrc file is a likely culprit. -V

3 5

Update of prop#250: Random Number Generation During Tor Voting
by David Goulet 09 Nov '15

09 Nov '15

Hello Tor-Dev! We've almost completed the implementation [1] for prop#250 so we've reviewed part of the proposal to correct part of it to reflect reality (because you know a proposal is just wishful thinking until you implement it :). Attached is the new version that we've been working on. We would like feedback from the community before at least calling it "ACCEPTED" and updated in tor-spec.git [2]. Here is a small summary of the big changes and also we need feedback on something that we are not fully in agreement. First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 -> 24:00 so the protocol run is not over two days. Seemed more logical and less confusing :). Second, we've removed the need of having majority for a commit to be considered for the shared random computation. Yes this sounds intense!! so it needs your attention. We think that majority concept was only protecting us against was a partition attack during commit phase but it turns out that having a conflict detection mechanism (see COMMITCONFLICT section) already protect us of most of them during the commit phase except maybe one that is described in Section 5.3.1. With this proposal change, an authority only keeps commits that are authoritative that is a commit coming directly from an authority. We've added section 5.3 on Partition Attack. Choosing commit by majority was protecting us against a partition attack in the commit phase but not all so with or without it, we still need an external monitoring party that makes sure attack are not ongoing (or bugs). DocTor is the obvious candidate so we'll work on a partition attacks detection since all of them are noisy and detectable. A sub-section (4.1.7) has also been added which address the need of a shared random key that signs the commit values so they can be verified by other authorities [3]. Finally, we would like your opinion also on if we should keep the conflict mechanism or not?. Since those partition attacks are basically dumb, do not achive much result for an attacker and it's at a high cost of comprimising a directory authority, should we keep them? Keep in mind that it adds a layer of complexity in the code especially with shared random keys which rotates every 30 days and are only available in the vote of an authority. It gets difficult to validate a conflict of an authority if we haven't seen yet a vote from that authority. There are ways to fix that code wise but is this worth it considering that every partition attack will be detected anyway by DocTor? One argument to keep it is resilience of the protocol. With conflict line, if one dirauth does stupid things, it will get ignored for the rest of the protocol run so we can still compute a fresh random value in the end. Again, does it worth it? Don't hesitate to ask about sections that are not clear or could be incorrect or you do not understand fully. Also, a ACK is a valid reply :). Thanks to all! David [1] https://trac.torproject.org/projects/tor/ticket/16943 [2] https://gitweb.torproject.org/torspec.git/tree/proposals/250-commit-reveal-… [3] https://trac.torproject.org/projects/tor/ticket/17349

5 9

Hidden service patch workshop on #tor-dev IRC channel
by George Kadianakis 09 Nov '15

09 Nov '15

Dear tor-dev, Everyone who is working on any kind of improvement to hidden services or related applications and would like to give or receive assistance (code reviews, advice, etc.) is welcome on: Thursday November 12, 16:00 UTC @ #tor-dev OFTC channel This might become a regular biweekly thing, if it proves to be successful. Cheers!

2 1

Re: [tor-dev] [tor-commits] [tor-messenger-build/master] Bug 17492: Include default bridges configuration
by Roger Dingledine 08 Nov '15

08 Nov '15

On Sat, Nov 07, 2015 at 12:13:45AM +0000, boklm(a)torproject.org wrote: > commit 7a1c6fd121dd001eb999ef03ebbbed264da37026 > Author: Nicolas Vigier <boklm(a)torproject.org> > Date: Sat Nov 7 00:45:48 2015 +0100 > > Bug 17492: Include default bridges configuration > > However, we exclude meek from the bridges configuration, as it currently > doesn't work in Tor Messenger because it requires firefox. This could be a great opportunity for Yawning's recent meek variant that doesn't use an actual browser. (It won't work as well as the real meek, but maybe no actual adversaries care about the difference quite yet?) --Roger

4 3

Ideas for TorBrowser
by Michał Dziczkowski 06 Nov '15

06 Nov '15

Hello. I would like to propose following for the TorBrowser: * request folder structure change because the actual one is a big mess and it's hard to find anything without browsing each folder * add the patches with fix the bugs of not working functions (like by example: options, addons, etc.) of current version of browser (till the next version of TorBrowser get ready to download) Mcgiwer

1 0

Mail Address Translation Protocol Tor>Internet, Internet<Tor
by Liste 06 Nov '15

06 Nov '15

Enter/Exit OnionMail SMTP servers connect the Internet and Tor. The addressed must be translated from hidden service address to Internet address ad viceversa. There are some way to do this: MAT = Mail Address Translation: localpart.hiddenservice.onion(a)internetServer.tld = localpart(a)hiddenservice.onion VMAT = Virtual Mail Address Translation: localpart1(a)internetServer.tld = localpart2(a)hiddenservice.onion (With public Database) SMAT = Scrambled Mail Address Translation: base32encryptedWithHC256Address-HiddenServiceIdAndSalt.so(a)internetServer.tld = localpart(a)hiddenservice.onion (With private hidden service salt and id; without database). VCMAT = Virtual circuit VMAT. localpart2.vc(a)internetServer.tld = (firstHop.vc(a)server.onion) = (secondHop.vc(a)server.onion) = ... (nHop.vc(a)server.onion) = localpart(a)hiddenservice.onion (False connection). (False connection). Available from OnionMail2. And others.... Valid characters of localpart: [a-zA-Z0-9\-\.\_] The last part after the character dot "." declare the type of address. *.onion = M.A.T. Address. *.list = Mailing list. *.news = Newsgroup. *.op = SysOp reserved. *.app = Applications / bot. *.sys = OnionMail system. *.so = Scrambled VMAT. *.vc or *.iam = Virtual circuit VMAT. *.o = VMAT 3 Reserved. *.tor (or other word with 3 ot less characters) = Old only Tor address protocol (Removed in OnionMail 1.8.1 Alpha). *.a = Anonymous remailer address. *.x = Reserved. sysop = SysOp System administrator. server = Server bot. All others *.* are free for user as normal address local part. Example: user.wxyz(a)hiddenservice.onion is a normal user's OnionMail address. (The MAT address is: user.wxyz.hiddenservice.onion(a)internetSevewr.tld ) Some address functions may be encapsulated. *.list.*.onion(a)internetServer.tld = A mailing list MAT address. OR *.list(a)internetServer.tld = VMAT address of a mailing list. VMAT Mail type must be the same of tor address type. The special characters: +~ and others, except -_ Reserved for future use. The special address: iam.onion The meaning of this invalid hidden service address is "the otherside address". Can be used to set the local addresses on the same server only for special users like: sysop(a)iam.onion, server(a)iam.onion This address is used by TORM IAM request by the OnionMail server's IAM/InterNos protocol. for example if you send a request "TORM IAM iam.onion V2" you will receive the server's manifest without reversed request. All IP addresses are set to [0.0.0.0]

1 0

Proposal 258: Denial-of-service resistance for directory authorities
by Nick Mathewson 06 Nov '15

06 Nov '15

[Here's a new proposal from Andrea. See ticket 4581 for implementation details.] Filename: 258-dirauth-dos.txt Title: Denial-of-service resistance for directory authorities Author: Andrea Shepard Created: 2015-10-27 Status: Open 1. Problem statement The directory authorities are few in number and vital for the functioning of the Tor network; threats of denial of service attacks against them have occurred in the past. They should be more resistant to unreasonably large connection volumes. 2. Design overview There are two possible ways a new connection to a directory authority can be established, directly by a TCP connection to the DirPort, or tunneled inside a Tor circuit and initiated with a begindir cell. The client can originate the former as direct connections or from a Tor exit, and the latter either as fully anonymized circuits or one-hop links to the dirauth's ORPort. The dirauth will try to heuristically classify incoming requests as one of these four indirection types, and then in the two non-anonymized cases further sort them into hash buckets on the basis of source IP. It will use an exponentially-weighted moving average to measure the rate of connection attempts in each bucket, and also separately limit the number of begindir cells permitted on each circuit. It will periodically scan the hash tables and forget counters which have fallen below a threshold to prevent memory exhaustion. 3. Classification of incoming connections Clients can originate connections as one of four indirection types: - DIRIND_ONEHOP: begindir cell on a single-hop Tor circuit - DIRIND_ANONYMOUS: begindir cell on a fully anonymized Tor circuit - DIRIND_DIRECT_CONN: direct TCP connection to dirport - DIRIND_ANON_DIRPORT: TCP connection to dirport from an exit relay The directory authority can always tell a dirport connection from a begindir, but it must use its knowledge of the current consensus and exit policies to disambiguate whether the connection is anonymized. It should treat a begindir as DIRIND_ANONYMOUS when the previous hop in the circuit it appears on is in the current consensus, and as DIRIND_ONEHOP otherwise; it should treat a dirport connection as DIRIND_ANON_DIRPORT if the source address appears in the consensus and allows exits to the dirport in question, or as DIRIND_DIRECT_CONN otherwise. In the case of relays which also act as clients, these heuristics may falsely classify direct/onehop connections as anonymous, but will never falsely classify anonymous connections as direct/onehop. 4. Exponentially-weighted moving average counters and hash table The directory authority implements a set of exponentially-weighted moving averages to measure the rate of incoming connections in each bucket. The two anonymous connection types are each a single bucket, but the two non- anonymous cases get a single bucket per source IP each, stored in a hash table. The directory authority must periodically scan this hash table for counters which have decayed close to zero and free them to avoid permitting memory exhaustion. This introduces five new configuration parameters: - DirDoSFilterEWMATimeConstant: the time for an EWMA counter to decay by a factor of 1/e, in seconds. - DirDoSFilterMaxAnonConnectRate: the threshold to trigger the DoS filter on DIRIND_ANONYMOUS connections. - DirDoSFilterMaxAnonDirportConnectRate: the threshold to trigger the DoS filter on DIRIND_ANON_DIRPORT connections. - DirDoSFilterMaxBegindirRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_ONEHOP connections. - DirDoSFilterMaxDirectConnRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_DIRECT_CONN connections. When incrementing a counter would put it over the relevant threshold, the filter is said to be triggered. In this case, the directory authority does not update the counter, but instead suppresses the incoming request. In the DIRIND_ONEHOP and DIRIND_ANONYMOUS cases, the directory authority must kill the circuit rather than merely refusing the request, to prevent an unending stream of client retries on the same circuit. 5. Begindir cap Directory authorities limit the number of begindir cells permitted in the lifetime of a particular circuit, separately from the EWMA counters. This can only affect the DIRIND_ANONYMOUS and DIRIND_ONEHOP connetion types. A sixth configuration variable, DirDoSFilterMaxBegindirPerCircuit, controls this feature. 6. Limitations Widely distributed DoS attacks with many source IPs may still be able to avoid raising any single DIRIND_ONEHOP or DIRIND_DIRECT_CONN counter above threshold.

2 1

Re: [tor-dev] stale entries in bwscan.20151029-1145
by starlight.2015q3＠binnacle.cx 06 Nov '15

06 Nov '15

aAt 20:56 11/5/2015 -0600, you wrote: >On 5 November 2015 at 16:37, <starlight.2015q3(a)binnacle.cx> wrote: >> By having a single thread handle >> consensus retrieval and sub-division, >> issues of "lost" relays should >> go away entirely. > >So I'm coming around to this idea, after spending >an hour trying to explain why it was bad. . . :-D happy to hear that It can be expressed and implemented various ways, but the core idea of centralizing this function is hard to escape. >So the >main problem as I see it is that it's easy to move >relays between slices that haven't happened yet - >but how do you do this when some slices are >completed and some aren't? >. . .if you used a work queue instead of a scanner. . . I'm thinking of it more as a set of circular work lists, since scanning never ends. Not then a question of "haven't happened yet" for new relays since regardless of where they're inserted they will be measured. More a question of giving priority to new relays and giving priority to relays that have exhibited a large change of bandwidth, particularly in the downward direction. If radical restructuring is on the menu (as the remainder of your comments imply) let me put out an idea I've come up with: I'm not enthusiastic about the current design where nine scanners blindly compete with each other for the local Tor client-router and link bandwidth. The goal should be to figure out what percent of the BWauth link's bandwidth should be consumed to minimize scanning time while ensuring quality measurement. Nine scanners could be replaced with one scanner that runs the entire list of relays sorted from fastest to slowest. This scanner would keep the slice approach of firing-up scans until a quota is filled. But instead of that quota being a somewhat arbitrary fixed value, the quota would be a minimum bandwidth target per the output of 'SETEVENTS BW'. A rough guess is that whatever bandwidth is available should be 35% subscribed, though the actual setting would require empirical determination. On a 100mbps link the target might then be a continuous 4.5 million bytes/sec of scanning. This might result in the 100 or so fastest relays being measured one-at-time, but of course it would happen rather quickly. As the scanner works down the list the number of concurrent scans would rise rapidly as the bandwidth of the targets decline and so perhaps several hundred of the slowest relays would be under measurement near the end of each pass. My belief is the end result would be dramatically faster than the current approach, have a low circuit-fail rate, and that the measurements would be far more reliable and consistent. >FWIW, looking at >https://bwauth.ritter.vg/bwauth/AA_scanner_loop_times.txt , it >seems like (for whatever weird reason) scanner1 took way longer than >the others. (Scanner 9 is very different, so ignore that one.) > >Scanner 1 > 5 days, 11:07:27 Yes noticed this a few days ago, examined ticket 17482 more closely and saw it was 6.5 days for scanner-one just before the 10/30 restart. The scanner-one log shows huge numbers of circuit failures. Observation partly inspired the above restructuring idea.

1 0

Re: [tor-dev] stale entries in bwscan.20151029-1145
by starlight.2015q3＠binnacle.cx 06 Nov '15

06 Nov '15

At 11:47 11/5/2015 -0600, Tom Ritter wrote: > . . . >So them falling between the slices would be my >best guess. . . Immediately comes to mind that dealing with the changing consensus while scanning might be handled in a different but nonetheless straightforward manner. Why not create a snapshot of the consensus at the time scanning commences then-- without disturbing the scanners-- pull each new update with an asynchronous thread or process. The consensus thread would diff against the previous state snapshot and produce an updated snapshot plus deltas for each scanner and/or slice as the implementation requires. Then briefly lock the working list for each active scanner and apply the delta to it. By having a single thread handle consensus retrieval and sub-division, issues of "lost" relays should go away entirely. No need to hold locks for extended periods. The consensus allocation thread would run continuously, so individual slices and scanners can complete and restart asynchronous to each other without glitches or delays. Consensus allocation worker could also manage migrating relays from one scanner to another, again preventing lost relays.

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev