- tor-dev - lists.torproject.org

botnet detection
by Enkidu Mo Shiri 07 Dec '14

07 Dec '14

is there any new method for botnet detection through tor?anyway can find the hidden service which been used by botmaster to c&c botnets? as communication all are encrypted and the decryption happens only node by node, how can i detect which HS been used bt botmaster? help me plz

1 0

Re: [tor-dev] [tor-reports] Help desk report for November 2014
by David Fifield 06 Dec '14

06 Dec '14

On Mon, Dec 01, 2014 at 09:41:58AM -0600, Colin C. wrote: > Hi everyone, > > Here is the help desk chart for November 2014: > > | ar | en | es | fa | fr | zh | Total | (Rejected) > ----------+------+------+------+------+------+------+-------+----------- > boklm | | | | | 7 | | 7 | > harmony | | 113 | | 38 | | | 151 | 33 > jason | | 271 | | | | 76 | 347 | 38 > lunar | | 36 | | | 28 | | 64 | 22 > mttp | | 140 | | | | | 140 | 1 > noel | | 2 | 56 | | | | 58 | > phoul | | 185 | | | | | 185 | 39 > sherief | 6 | 277 | | | | | 283 | 45 > vmon | | | | 2 | | | 2 | > ----------+------+------+------+------+------+------+-------+----------- > Total | 6 | 1024 | 56 | 40 | 35 | 76 | 1237 | 182 > (Open) | 1 | 40 | 1 | 14 | 4 | 4 | 64 | > > That's almost 41 tickets resolved each day on average. > > See also the attached charts for the amount of incoming tickets each > day and for the past twelve months. > > Top answer templates used by the support team for this month: > > usage | article > -------+----------------------------------------------------------------- > 67 | Get your own bridges. > 36 | Get TB's Tor Log. > 33 | Exclude Tor Browser from an Antivirus/Firewall/AntiMalware > 30 | Tor Browser doesn't work (Windows) > 13 | Redirect to Guardian Project's support > 11 | How to get bridges and use Tor in mainland China > 11 | Please try meek > 10 | [debug] Tor Browser 4.0 is crashing on Windows > 9 | Can't connect to my favorite onion site! > 8 | Unsupported language > 7 | Redirect to Tails support > 7 | Suggest the tor-talk mailing list > 6 | Tor-related error window from browser. > 5 | How to use bridges > 5 | Set Country > 4 | TBB no Flash/Java other plugins (Replied to from https://lists.torproject.org/pipermail/tor-reports/2014-December/000711.html.) Colin, is it possible to see what's in the answer templates? At the 2014 dev meeting, a note in the support session (https://trac.torproject.org/projects/tor/wiki/org/meetings/2014SummerDevMee…) said "Lunar wants to take the RT articles out of the RT DB, put them on a public web page, allow others to review them." Does anything like that exist? David Fifield

2 1

Summary of meek's costs, November 2014
by David Fifield 05 Dec '14

05 Dec '14

Here's the summary of meek's CDN fees for November 2014. Earlier reports: https://lists.torproject.org/pipermail/tor-dev/2014-August/007429.html https://lists.torproject.org/pipermail/tor-dev/2014-October/007576.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007716.html If you're just tuning in, meek is a pluggable transport introduced a few months ago. https://trac.torproject.org/projects/tor/wiki/doc/meek. App Engine + Amazon + Azure = total by month February 2014 $0.09 + -- + -- = $0.09 March 2014 $0.00 + -- + -- = $0.00 April 2014 $0.73 + -- + -- = $0.73 May 2014 $0.69 + -- + -- = $0.69 June 2014 $0.65 + -- + -- = $0.65 July 2014 $0.56 + $0.00 + -- = $0.56 August 2014 $1.56 + $3.10 + -- = $4.66 September 2014 $4.02 + $4.59 + $0.00 = $8.61 October 2014 $40.85 + $130.29 + $0.00 = $171.14 November 2014 $224.65 + $362.60 + $0.00 = $587.25 -- total by CDN $273.80 + $500.58 + $0.00 = $774.38 grand total Average usage (by count of simultaneous users) was about 3.04× greater in November than in the October (750 users per day versus 247). See the attached userstats-bridge-transport-meek-2014-09-01-2014-11-30.png. https://metrics.torproject.org/userstats-bridge-transport.html?graph=userst… The number of users was 3.04× according to Tor Metrics, but the cost for meek-google was 5.50× and meek-amazon was 2.78×. A possible explanation is that in addition to gaining more users, each user is also using more bandwidth. App Engine bandwidth was up 4.76× compared to last month and Amazon bandwidth was up only 2.65×. == App Engine a.k.a. meek-google == Google is migrating App Engine accounts to their new "Cloud Platform." Because I had to create a new Cloud Platform account, I got a free trial credit of $300. For technical reasons (relating to the Cloud Platform migration) I couldn't apply the credit until November 11. Up to then, we had been charged $75.70 for the month. The remaining $148.95 was paid by the credit. After this one, I have another $500 credit, which should get us into the new year. Here is how the costs broke down: 1375 GB $165.10 1191 instance hours $59.55 The attached meek-google-costs-2014-12-01.png shows the breakdown of costs between bandwidth and instance hours for the last few months. The attached meek-google-2014-12-01.png shows B/s for the month. There's a nice visible daily and weekly cycle. == Amazon a.k.a. meek-amazon == The Amazon bill breaks down in a complicated way by region. Asia Pacific (Singapore) 76M requests $91.43 500 GB $75.34 Asia Pacific (Sydney) 245K requests $0.01 1 GB $0.25 Asia Pacific (Tokyo) 27M requests $33.05 160 GB $26.23 EU (Ireland) 50M requests $58.34 490 GB $51.78 South America (Sao Paulo) 450K requests $0.00 3 GB $0.06 US East (Northern Virginia) 13M requests $13.12 115 GB $12.99 -- total 167M requests $195.95 1269 GB $166.65 == Azure a.k.a. meek-azure == Azure is still on a free grant for a year. Unfortunately I don't see a way to find out what it would be costing or even get a report of monthly bandwidth usage. The attached meek-azure-2014-12-01.png shows GB/hour for the last seven days of the month. David Fifield

1 0

Pluggable transports meeting tomorrow (16:00UTC Wednesday 3rd of December 2014)
by Yawning Angel 03 Dec '14

03 Dec '14

Hello! just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Thanks for your attention! -- Yawning Angel

1 0

Re: [tor-dev] Feedback on obfuscating hidden-service statistics
by George Kadianakis 02 Dec '14

02 Dec '14

"A. Johnson" <aaron.m.johnson(a)nrl.navy.mil> writes: > Hello all, > > <snip> > >> We put in some simple obfuscations in order to not reveal too >> sensitive data: we multiplied actual values with a random number in >> [0.9, 1.1] before including those obfuscated values in extra-info >> descriptors. Maybe there's something smarter we could do? Or is this >> okay? > > I actually think that additive rather than multiplicative noise > (i.e. randomness) makes sense here. Let’s suppose that you would like > to obscure any individual connection that contains C cells or fewer > (obscuring extremely and unusually large connections seems hopeless > but unnecessary). That is, you don’t want the (distribution of) the RP > cellcount from any relay to change by much whether or not C cells are > removed The standard differential privacy approach would be to *add* > noise from the Laplace distribution Lab(\epsilon/C), where \epsilon > controls how much the statistics *distribution* can multiplicatively > differ. I’m not saying that we need to add noise exactly from that > distribution (maybe we weaken the guarantee slightly to get better > accuracy), but the same idea applies. This would apply the same to > both large and small relays. You *want* to learn roughly how much RP > traffic each relay has - you just want to obscure the exact number > within some tolerance. > Hello Aaron, I posted an initial draft of the proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-November/007863.html Any feedback would be awesome. Specifically, I would be interested in undertanding the concept of additive noise a bit better. As you can see the proposal draft is still using multiplicative noise, and if you think that additive is better we should change it. Unfortunately, I couldn't find any good resources on the Internet explaining the difference between additive and multiplicative noise. Could you expand a bit on what you said above? Or link to a paper that explains more? Or link to some other system that is doing additive noise (or even better its implementation)? Thanks!

2 4

Is PublishServerDescriptor needed to collect metrics?
by David Fifield 02 Dec '14

02 Dec '14

If a bridge has PublishServerDescriptor 0 does that prevent it from counting in metrics? If so, what's the right setting to enable metrics (0|1|v3|bridge,...)? Is there a way to send metrics data without also ending up in BridgeDB? David Fifield

4 7

New documentation for Tor Metrics website
by Karsten Loesing 02 Dec '14

02 Dec '14

Dear list, writing documentation is hard work. I'm sure you already knew that, but let me re-assure you that I now believe it, too. At least until I forget it again and carelessly start documenting something else that looks tiny and friendly and trivial to document. Anyway, I spent the last day (felt like half a week) on rewriting the relevant text for the Tor Metrics website, and I wrote a short glossary of terms I didn't want to explain over and over. Would people on this list mind reviewing my text and suggesting improvements? For reference, the old text and real graphs, tables, etc. are still available here: https://metrics.torproject.org/ The new text with sample graphs and the glossary are here, conveniently packaged into a single HTML page: https://people.torproject.org/~karsten/volatile/metrics.html I'd be happy for any suggestions here or off-list, either as comments, patches, or edited HTML files. Whatever works best for you works for me. I'll update the .html file whenever I include suggestions. I hope to put the new text on the real Tor Metrics next week. Thanks in advance, much appreciated! In fact, I'm pretty sure that all future visitors of Tor Metrics will appreciate your efforts. All the best, Karsten

4 8

Re: [tor-dev] tor-dev Digest, Vol 47, Issue 3
by teor 02 Dec '14

02 Dec '14

Hi Tom, Can you please describe the bug? Is it in the Tor Trac with a bug number? In general, if you start in the tor directory of a source distribution: (I'll use gitweb links, but you can use git and clone a local copy) tor/src/or https://gitweb.torproject.org/tor.git/tree/src/or Contains the tor onion routing-specific source code Your bug is likely to be here tor/src/common https://gitweb.torproject.org/tor.git/tree/src/common Contains the common facilities used by the tor/src/or code Your bug is also likely to be here tor/src/ext tor/src/trunnel tor/src/win32 https://gitweb.torproject.org/tor.git/tree/src Contain external libraries and platform-specific source Your bug is probably not here, or in any of the other directories teor pgp 0xABFED1AC hkp://pgp.mit.edu/ https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 http://0bin.net/paste/Mu92kPyphK0bqmbA#Zvt3gzMrSCAwDN6GKsUk7Q8G-eG+Y+BLpe7w… > Date: Tue, 2 Dec 2014 07:05:45 +0530 > From: Tom Mody <bug29195(a)gmail.com> > Subject: Re: [tor-dev] Help regarding Development > > hi list , > I am having troubles on bug solving , im new to it and i want to know where > to search in code for a particular bug ,, > please help ?? > >> On Tue, Nov 18, 2014 at 10:22 PM, rl1987 <rl1987(a)sdf.lonestar.org> wrote: >> >> 1. Read doc/HACKING. >> 2. Browse "Easy tickets" page [1] and see if you can solve any of them. >> >> [1] https://trac.torproject.org/projects/tor/query?status= >> accepted&status=assigned&status=needs_review&status= >> new&status=reopened&order=priority&keywords=~easy&col= >> id&col=summary&col=component&col=status&col=type&col= >> priority&col=milestone&report=30 >> >> 2014-11-14 03:53, Tom Mody ra??: >> >>> I would like to contribute to Tor ,, >>> >>> I'm not getting where to start .... >>> >>> Please , Can anyone help me how to start ??

1 0

Help regarding Development
by Tom Mody 02 Dec '14

02 Dec '14

I would like to contribute to Tor ,, I'm not getting where to start .... Please , Can anyone help me how to start ??

2 2

[PATCH] Tor Weather: Switched preferences and unsubscribes URLs.
by Ondrej Novy 01 Dec '14

01 Dec '14

--- weather/weatherapp/emails.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weather/weatherapp/emails.py b/weather/weatherapp/emails.py index 2b5a0f5..cc298c9 100644 --- a/weather/weatherapp/emails.py +++ b/weather/weatherapp/emails.py @@ -179,7 +179,7 @@ def _add_generic_footer(msg, unsubs_auth, pref_auth): unsubURL = url_helper.get_unsubscribe_url(unsubs_auth) prefURL = url_helper.get_preferences_url(pref_auth) - footer = _GENERIC_FOOTER % (unsubURL, prefURL) + footer = _GENERIC_FOOTER % (prefURL, unsubURL) return msg + footer -- 1.9.3 (Apple Git-50)

1 0

Specification for 'How to Safely Sign a statement with a .onion key'
by Tom Ritter 01 Dec '14

01 Dec '14

Attached is a document written in the specification format for one aspect of CA-signed .onion addresses - specifically a "What is a safe way to sign (or not sign) a statement using the .onion key" It presents a couple options - I'd love to get feedback from folks on which they prefer. I recognize that no consensus or decision has been reached on whether to encourage or guide CAs on issuing .onions. (Although I'm in favor[0].) Although this is obviously written skewed towards CAs, it addresses a generic problem, and could be rewritten in that form. Excerpting from the Introduction/Motivation: Several organizations, such as Facebook, (collectively, 'applicants') have expressed a desire for an end-entity SSL certificate valid for their .onion Hidden Service address signed by a Certificate Authority (CA) present in browser trust stores. The existing Facebook .onion URL was issued by Digicert under a loophole in certificate issuance requirements. The Basic Requirements [0] is a document created by the Certificate Authority/Browser Forum that governs acceptable certificate issuing policies. Adherence to its policies is required for inclusion in many browsers' trust stores. .onion counts as an 'internal hostname' as it is not a recognized TLD by IANA. November 1, 2015 sets the deadline for when all internal server certificates must be revoked and no new certificates may be issued. Resolving the requirements and preferences for issuing .onion certificates before this date is extremely desirable, as it will determine if organizations such as Facebook will invest in the time and engineering effort needed to deploy Hidden Services. The full requirements for issuing .onion certificates is TBD, although recognition of .onion by IANA as a reserved domain is likely required. During discussions about the requirements for issuing for .onion one question that has arisen is what is a safe way to assert ownership of a .onion address and format an x509 certificate with a .onion Subject Alternate Name (SAN). This document is designed to address some of those questions. -tom [0] https://lists.torproject.org/pipermail/tor-dev/2014-November/007786.html

5 7

Reminder for weekly OONI dev meeting Monday 18:00 UTC (19:00 CET)
by Arturo Filastò 01 Dec '14

01 Dec '14

Hi, This is a reminder that today there will be the weekly OONI meeting. As I am writing this I am on a plane heading towards London and will be working on a GlobaLeaks workshop in some office there. The schedule for the workshop is not very well defined so I am not 100% sure I will manage to be online at the above defined time. If I am not there please start without me and I will be sure to read the backlog and write feedback asynchronously. ~ Arturo

1 0

Re: [tor-dev] [tor-reports] Tom's November 2014
by Karsten Loesing 01 Dec '14

01 Dec '14

On 01/12/14 02:34, Tom Ritter wrote: > With my shiny new ldap I got access to a user and official repo for > Depictor [0][1]. Not sure how I'll manage the difference. The code > for depictor is in both of them. Hi Tom, here's how I use official and user repos for my code: - The official repo contains what's deployed on the server, in its master branch. There are usually no other branches than master in that repo, though there would be for different version branches, or in the case of DocTor the old Java branch. I never rebase the master branch in the official repo. - The user repo has feature branches that I'm working on. For example, the feature branch for #23456 would be called task-23456, or task-23456-2, -3, etc. when I rebase that branch or mess with history in some other way. The user repo has no master branch, because that would be out of date most of the time anyway. I sometimes delete branches after they're merged into the official master branch, if I'm sure that nobody would base their work on those branches. There may be better approaches to using official vs. user repos, but maybe this is useful as a first data point for you. The Githax repo may contain more ideas: https://gitweb.torproject.org/githax.git/tree/doc/Howto.txt All the best, Karsten

1 0

Integration testing plans, draft, v1
by Nick Mathewson 01 Dec '14

01 Dec '14

Hi! This is the outcome of some discussion I've had with dgoulet, and some work I've done at identifying current problem-points in our use of integration testing tools. I'm posting it here for initial feedback, and so I have a URL to link to in my monthly report. :) INTEGRATION TEST PLANS FOR TOR November 2014 1. Goals and nongoals and scope This is not a list of all the tests we need; this is just a list of the kind of tests we can and should run with Chutney. These tests need to be the kind that a random developer can run on their own and reasonably hope to do. Longer/more expensive tests may be okay too, but if it needs anything spiffer than a linux desktop, consider using Shadow instead. Setting up an environment to run the tests needs to be so easy that nobody who writes C for Tor is likely to be dissuaded from running them. Writing new tests needs to be pretty simple too. Most tests need to be runnable on all the platforms we support. We should support load tests. Though doing so is not likely to give an accurate picture of how the network behaves under load, it's probably good enough to identify bottlenecks in the code. (David Goulet has had some success here already for identifying HS performance issues.) We should specify our design and interfaces to keep components loosely coupled and easily replaceable. With that done, we should avoid over-designing components at first: experience teaches that only experience can teach what facilities need which features. 2. Architecture Here are the components. I'm treating them as conceptually separate, though in practice several of them may get folded into Chutney. A. Usage simulator One or more programs that emulate users and servers on the internet. It reports what succeeded and what failed and how long everything took. Right now we're using curl and nc for this. B. Network manager This is what Chutney does today. It launches a set of Tor nodes according to a provided configuration. C. Testcase scripts We do this in shell today: launch the network, wait for it to bootstrap, send some traffic through it, and report success or failure. D. Test driver This part is responsible for determining which testcases to run, in what order, on what network. There is no current analogue to this step; we've only got the one test-network.sh script, and it assumes a single type of network. One thing to notice here is that testcase scripts need to work with multiple kinds of network manager configurations. For example, we'd like to be able to run HTTP-style connectivity tests on small networks, large networks, heterogenous networks, dispersed networks, and so on. We therefore need to make sure that each kind of network can work with as many tests as possible, so that the work needed to write the tests doesn't grow quadratically. The coupling for the components will go as possible: A. Usage simulations will need to expose their status to test scripts. B. The network manager will need to expose information about available networks and network configurations to the test scripts, so that the test scripts know how to configure usage simulations to use them. It will need to expose commands like "wait until bootstrapped", "check server logs for trouble", etc. C. Each testcase needs to be able to identify which features it needs from a network, invoke the network commands it needs, and invoke usage simulations. It needs to export information about its running status, and whether it's making progress. D. The test driver needs to be able to enumerate networks and testcases and figure out which are compatible with each other, and which can run locally, and which ones meet the user's requirements. 2.1. Minimal versions of the above: A. The minimal user tools are an http server and client. Use appropriate tooling to support generating and receiving hundreds to thousands of simultaneous requests. B. The minimal network manager is probably chutney. It needs the ability to export information about networks, to "wait until bootstrapped", to export information about servers, and so on. Its network list needs to turn into a database of named networks. C. Testcases need to be independent, and ideally abstracted. They shouldn't run in-process with chutney. For starters, they can duplicate the current functionality of test-network and of dgoulet's hidden service tests. Probing for features can be keyword-based. reporting results can use some logging framework. D. The test driver can do its initial matching by keyword tags exported by the other objects. It should treat testcases and networks as abitrary subprocesses that it can launch, so that they can be written in any language. 3. A short inventory of use-cases - Voting - Controllers - HS * IP+RP up/down * HSDir up/down * Authenticated HS - Bad clients * Wrong handshake * Wrong desc. - Bad relays * dropping cells/circ/traffic * BAD TLS - Pathing * Does it behaves the way we think? * 4 hops for HS - Relay * Up/Down * Multiple IPs for a single key * OOM handling * Scheduling - Client * Does traffic goes through? - For HS and Exit * DNS testing - Caches at the exit * Stream isolation using n SocksPort * AddressMap 4. Longer-term We might look into using "The Internet" (no, not that one. The one at https://github.com/nsec/the-internet) on Linux to simulate latency between nodes. When designing tools and systems, we should do so with an eye to migrating them into shadow. We should refactor or adapt chutney to support using stem, to take advantage of stem's improved templating and control features, so we can better inspect running servers. We should probably retain the original hands-off non-controller chutney design too, to better detect heisenbugs. 5. Immediate steps - Turn the above into a work plan. - Specify initial interfaces, with plan for migration to better ones once we have more experience. - Identify current chutney and test-network issues standing in the way of reliably getting current tests to work. - Refactor our current integration tests to the above framework.

1 0

Of CA-signed certs and .onion URIs
by Tom Ritter 30 Nov '14

30 Nov '14

There's been a spirited debate on irc, so I thought I would try and capture my thoughts in long form. I think it's important to look at the long-term goals rather than how to get there, so that's where I'm going to start, and then at each item maybe talk a little bit about how to get there. So I think the Tor Project and Tor Browser should: a) Eliminate self-signed certificate errors when browsing https:// on an onion site b) Consider how Mixed Content should interact with .onion browsing c) Get .onion IANA reserved d) Address the problems that Facebook is/was concerned about when deploying a .onion e) Consider how EV treatment could be used to improve poor .onion readability (If you're not familiar with DV [Domain Validated] and EV [Extended Validation] certificates and their UI differences, you should take a peek. For example [0]. There are other subtleties and requirements on EV certs like OCSP checking that removes the indicator, and the forthcoming CT effort in Chrome, but that's mostly orthogonal.) -------------------- a) Self Signed Errors on .onion A .onion specifies the key needed. As far as little-t tor is concerned, it got you to the correct endpoint safely, so whatever SSL certificate is presented could be considered valid. However, if the Hidden Service is on box A and the webserver on box B - you'd need to do some out-of-application tricks (like stunnel) to prevent a MITM from attacking that connection. So as Roger suggested, perhaps requiring the SSL certificate to be signed by the .onion key would be a reasonable choice. But if you make that requirement, it also implies that HTTP .onions are less secure than HTTPS .onions. Which may or not be the case - you don't know. I'm not religious about anything other than getting rid of the error: I don't like that users are trained to click through security errors. This is a weakly held opinion right now - but I think it's fair to give DV treatment to http://.onion because it is, from little-t tor's point of view, secure. Following that conclusion, it is therefore fair to accept self-signed certificates and _not_ require a certificate for a https://.onion be signed by the .onion key. (Because otherwise, we're saying that SSL on .onion requires more hoops to achieve security than HTTP on .onion, which isn't the case.) -------------------- b) Mixed Content on .onion This is a can of worms I'm not going to open in this mail. But it's there, and I think it's worth thinking about whether a .onion requesting resources from http://.com or https://.com is acceptable. -------------------- c) Get .onion IANA reserved I think this is fairly apparent in itself, and is in the works [1]. Not sure its status but I would be happy to lend time in whatever IETF group/work is needed if it will help. -------------------- d) Address the problems that Facebook is/was concerned about when deploying a .onion There are reasons, technical and political, why Facebook went and got a HTTPS cert for their .onion. I've copied Alec so hopefully he'll agree, refute, or add. But from my perspective, if I were Facebook or another large company like that: i) I don't want to train my users to click through HTTPS warnings. (Conversely, I like training my users to type https://mysite.com) ii) I don't want to have to do the development and QA work to cut my site over to be sometimes-HTTP if it's normally always HTTPS iii) It would be convenient if I didn't have to do stunnel tricks to encrypt the connection between my Hidden Service server and (e.g.) load balancer, which is on another box iv) I'd really like to get a green box showing my org name, and it's even better that it'd be very difficult a phisher to get that (iii) can contradict with (A) above of course. Because I came to the conclusion of allowing invalid certificates, a MITM could attack Facebook between the HS server and load balancer. I'm not sure there is an elegant solution there. One would probably have to tunnel the connection over a mutually authenticated stunnel connection to prevent a MITM. But frankly, if we assume users are used to clicking through self-signed certs and we want to start the process of training them _not_ to, Facebook would have to do this now _anyway_. So... =/ I guess documenting the crap out of this concern and providing examples may be the best solution based off my mindset right now. It's awesome that Facebook set up a Hidden Service. I'd love to get a lot more large orgs doing that. We should reach out and figure out what the blockers are, what's painful about it, and what we can do to help. I would love doing that, it would be awesome. (And I'm not afraid to NDA myself up if necessary, seeing as I'm under NDA with half of the Bay Area anyway.) -------------------- e) Consider how EV treatment could be used to improve poor .onion readability This is the trickiest one, and it overlaps the most with the question of "Should we encourage CAs to issue certificates?" EV treatment in Tor Browser is a tool in the toolbox. I think it would be wasteful of written code and users who are accustomed to seeing it to not make use of it. I also think it dovetails nicely with how unreadable HS addresses are and how much more unreadable they're going to get soon when they get longer. I don't want a system that _requires_ participating in the DNS or CA model. Free or Paid, you still have to provide identifying information - and for an anonymity project I think we can all agree that's unacceptable. But as we hopefully expand hidden services to more and more corporate services - these organizations are legitimately concerned about (e.g.) phishing, and it's unreasonable to expect users to meticulously validate a .onion address. (Let alone how you find what the address should be validated against.) But a problem is that if we allow a .onion to certify anything it wants, it can certify any fraudulent information it wants. Bootstrapping off the other axis of Zooko's Triangle (Secure and Human Meaningful, but Centralized) is a way to combat that fraudulent information. (Not the only way, but a way.) Syrup-tan had an idea on irc: Have a DV certificate sign a certificate that is valid for the .onion URL, and display the URL of the DV certificate. This doesn't eliminate phishing - I can register facebok.com and then get that displayed. But doing bootstapping off DNS and DV certificates is a fairly low bar in terms of the cost to a .onion operator. (There are other concerns here, I'm not completely comfortable with repurposing the EV indicator in this way. Asa on irc had the good point that if we did this, maybe we'd want to change the EV green to another color just to be a little bit different. Not that I really expect users to notice that though...) Allowing an organization to purchase an EV certificate from a CA, and display the organization's name in the address bar, is another way - albeit a very high bar in terms of cost to an onion operator. A petname system based off who-knows-what (for example the namecoin/sovereign-keys like system of a land-grab, first-to-the-name approach) is a third, and would meet the goal of not requiring participating in the DNS and CA systems. but a high bar in terms of engineering effort for Tor. I think Tor Browser should do several of them. I think the EV certificates + partnering with CAs is dead simple and requires no engineering effort on behalf of Tor Browser. So that's a win, and I think worth doing. But there should be at least one more solution in the short to long term (e.g. a petname approach). Unfortunately, if the time between now and the 'long term' solution is too long, it locks out everyone who can't get an EV cert - which is a legitimate concern. Perhaps after there's a spec Tor likes, some large organization concerned about preventing phishing could throw some engineering time at the problem. Anyway, if it's not clear, I am volunteering to work on these things as I'm able. -tom [0] https://ftt-uploads.s3.amazonaws.com/browser-ssl-ui-comparison.png [1] https://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/

10 18

sending command from Exit node to client
by Mohiuddin Ebna Kawsar 30 Nov '14

30 Nov '14

Hi, 1* I want to know is it possible to send command from Exit node to Client? if yes then How? 2* I also want to know is it possible to communicate with tor with other software like snort? Regards kawsar

2 1

obfs4 questions
by Michael Rogers 29 Nov '14

29 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, In the obfs4 spec I couldn't find a description of how the secretbox nonces for the frames are constructed. A 16-byte nonce prefix comes from the KDF, but what about the remaining 8 (presumably frame-specific) bytes? If an attacker changes the order of the secretboxes so that the recipient tries to open a secretbox with the wrong nonce, is that guaranteed to fail, as it would if the secretbox had been modified? I can make a hand-wavy argument for why I think it will fail, but I don't know whether the secretbox construct is designed to ensure this. Any particular reason for using two different MACs (HMAC-SHA256-128 for the handshake, Poly1305 for the frames) and two different hashes (SHA-256 for the handshake, SipHash-2-4 for obfuscation)? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJUeHO0AAoJEBEET9GfxSfMcPEH/iEYxlXtceeG3/wzp97oW/He lPNqqowyXczlyJO0SDG8L96hG6RYQZb7M0t8KJsYJapAznioZi2/qRQEC2/VFXg1 1EN//Bd9iO7QUXaIo1djC97Qoq3qmR/GY50xKYIjxr/gZSLk2dAAtleFUuerBrl9 nLrTr7kSKk3xzY0GFYtYKbj3bvuGusGrFioAIgfnKtF8iAlSjEIo8uE2Y1RFVu2d Q9GOake1VjC5V7Ue/MDCpWagwebPhnDHXSCWSXhvrYT5rmkjrkR2nhl2hAIq/0pA sfjsGquMrT5fdXcRrQaxHsamCt1228/ZlEAkCep/PRpS0NgLDJlRtPe49RD44Gk= =OHtY -----END PGP SIGNATURE-----

2 7

Stormy - request for feedback
by Griffin Boyce 28 Nov '14

28 Nov '14

Hello all, So as some of you know, I've been working on installers for hidden services, to ideally make very common services (such as blogs and plain websites) easy to deploy and automatically update. This is a very rough version of the one-click hidden service installer, but I'd love to get feedback on places where it breaks and where it could use a major structural change. Script is here, please feel free to flag bugs or tell me how I'm doing it wrong: https://github.com/glamrock/Stormy/blob/master/one-click-blog.sh Q: Can I use this right now to set up a hidden service? A: Please don't use this in production until firewall settings are in place. Q: Are there firewall settings in place? A: Not yet - the current setup is entirely for development and should not be used as-is. best, Griffin -- "I believe that usability is a security concern; systems that do not pay close attention to the human interaction factors involved risk failing to provide security by failing to attract users." ~Len Sassaman

5 5

The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network
by Liste 27 Nov '14

27 Nov '14

http://www.nrl.navy.mil/itd/chacs/biblio/sniper-attack-anonymously-deanonym…

2 1

Potential projects for SponsorR (Hidden Services)
by George Kadianakis 27 Nov '14

27 Nov '14

Hello, this is an attempt to collect tasks that should be done for SponsorR. You can find the SponsorR page here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR I'm going to focus only on the subset of those categories that Roger/David told me are the most important for the sponsor. These are: - Safe statistics collection - Tor controller API improvements - Performance improvements - Opt-in HS indexing service I haven't yet split projects into deliverables; this is a middle step to getting there. Next step is to filter and then ticketify what we have. After that we need to prioritize and pick the projects that will become deliverables. In each category, I have slightly ordered the items (so, more important items will usually be on the top, but that's not always true). I have also tried to include all the tickets that are marked as SponsorR in trac. So, let's go: == Safe statistics collection == We've discussed this quite a bit over the past year and I think we all pretty much agree on which stats are safe to collect and which not. I think we all agree that collecting the number of HS circuits and traffic volume from RPs (#13192) is harmless [0] and useful information to have. We need to clean up Roger's patch to add that information in extra-info descriptors, and then do some visualisations. That would give us a good idea of how much HSes are used. OTOH, other statistics like "# of HS descriptors" are not that harmless and the upcoming HS redesign will block us from getting this information anyway. For now, I think we should focus on #13192 for this project. == Tor controller API improvements == To better refine this project, we should think about what we want to get out of it. Here are some outcomes: a) A better control API allows us to perform better performance measurements for HSes. Karsten in #1944 worked on performance measurements of HS circuit establishment. You can find his very useful results here: http://ec2-54-92-231-52.compute-1.amazonaws.com/ We should understand exactly how Karsten is gathering those events, and see whether we can improve the timing accuracy or if we are missing any events. We need to also figure out how to do useful measurements in causal events like the race between the INTRODUCE_ACK cell and the RENDEZVOUS2. We also need to find a way to match rendezvous circuits with introduction circuits: https://trac.torproject.org/projects/tor/ticket/1944#comment:35 All in all, this seems like a project worth doing right because it will be useful in the future. It can even act as an automated regression test. b) This might also be a good time to start working on automated integration tests for HSes. It should be possible to spin up private Chutney networks and test that particular HSes are reachable. Or perform regression tests; for example, Roger recently suggested writing a regression test to make sure that clocks don't need to be synchronized to build HS circuits (#13494). We should also make testing networks better for HS testing: - #13401 TestingTorNetwork should crank down RendPostPeriod too? c) Tor should better expose error messages of failed operations. For example, this could allow TBB to inform users whether they mistyped the onion address or the HS is actually down, and it would also let us do #13208. Proposal 229 and ticket #13212 are related to this. We should see whether the PT team is planning to implement proposal 229 and how we can synchronise. d) There are various projects that are using HSes these days (TorChat, Pond, GlobaLeaks, Ricochet, etc.). We should think whether we want to support these use cases and how we can make their life easier. For example, Fabio has been asking for a way to spin up HSes using the control port (#5976). What other features do people want from the control port? And here are some more tickets marked as SponsorR from this category: - #8993 Better hidden service support on Tor control interface - #13206 Write up walkthrough of control port events when accessing a hidden service - #2554 extend torperf to record hidden service time components == Performance Improvements == This is the most juicy section. How can we make HS performance better? IIUC, we are mainly interested in client-side performance, but if a change makes both sides faster that's even better. Some projects: a) Looking at Karsten's #1944 results http://ec2-54-92-231-52.compute-1.amazonaws.com/ we see that fetching HS descriptors takes much more time than it should. I wonder why this is the case. Is there another ntohl bug there? We should perform measurements and get a good understanding of what's going on in this step. Here are some tickets that Roger opened to do exactly that: - #13208 What's the average number of hsdir fetches before we get the hsdesc? - #13209 Write a hidden service hsdir health measurer And here is a ticket with a potential issue: - #13207 Is rend_cache_clean_v2_descs_as_dir cutoff crazy high? b) Improving the other parts of the circuit establishment process is also important: - #8239 Hidden services should try harder to reuse their old intro points - #3733 Tor should abandon rendezvous circuits that cause a client request to time out - #13222 Clients accessing a hidden service can establish their rend point in parallel to fetching the hsdesc Furthermore, an area of Tor that might give us better performance but we haven't really explored yet is preemptive circuits. #13239 is about building more internal circuits for HSes. And here is a ticket suggesting more measurements: - #13194 Track time between ESTABLISH_RENDEZVOUS and RENDEZVOUS1 cell c) Another important project in this area is parallelizing HS crypto. I haven't looked at what this would actually entail, but it will probably involve implementing the undone parts of proposal 220/224. d) This might be the time to implement Encrypted Services? Many people have been asking for this feature and this might be the right time to do it: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-en… e) Following the trail of #13207, we should look at all the magic numbers currently used by HSes, document them and see if they make sense. This includes the number of IPs (#8950), the number of HSDirs/replicas, the intro point expiration date, etc. Also, we should revisit the flags used when doing path selection for RPs, IPs, etc. f) On a more researchy tone, this might also be a good point to start poking at the HS scalability project since it will really affect HS performance. We should look at Christopher Baines' ideas and write a Tor proposal out of them: https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html https://lists.torproject.org/pipermail/tor-dev/2014-May/006812.html Last time I looked, Christopher's ideas required implementing proposal225 and #8239. g) All the projects above are aiming at improving circuit establishment performance, but none of them are dealing with performance improvements after the HS circuit has been established. On an even more researchy tone, Qingping Hou et al wrote a proposal to reduce the length of HS circuits to 5 hops (down from 6). You can find their proposal here: https://lists.torproject.org/pipermail/tor-dev/2014-February/006198.html The project is crazy and dangerous and needs lots of analysis, but it's something worth considering. Maybe this is a good time to do this analysis? h) Back to the community again. There have recently appeared a few messaging protocols that are inherently using HSes to provide link layer confidentiality and anonymity [1]. Examples include Pond, Ricochet and TorChat. Some of these applications are creating one or more HSes per user, with the assumption that HSes are something easy to make and there is no problem in having lots of them. People are wondering how well these applications scale and whether they are using the Tor network the right way. See John Brooks' mail for a small analysis: https://moderncrypto.org/mail-archive/messaging/2014/000434.html It might be worth researching these use cases to see how well Tor supports them and how they can be supported better (or whether they are a bad idea entirely). == Opt-in HS indexing service == This seems like a fun project that can be used in various ways in the future. Of course, the feature must remain opt-in so that only services that want to be public will surface. For this project, we could make some sort of 'HS authority' which collects HS information (the HS descriptor?) from volunteering HSes. It's unclear who will run an HS authority; maybe we can work with ahmia so that they integrate it in their infrastructure? If we are more experimental, we can even build a basic petname system using the HS authority [2]. Maybe just a "simple" NAME <-> PUBKEY database where HSes can register themselves in a FIFO fashion. This might cause tons of domain camping and attempts for dirty sybil attacks, but it might develop into something useful. Worst case we can shut it down and call the experiment done? AFAIK, I2P has been doing something similar at https://geti2p.net/en/docs/naming == Security / Miscellaneous == I also noticed that some tickets on trac were assigned to SponsorR but I couldn't fit them in the above categories. They are mainly security enhancements or code improvements. Here is a dump of the tickets: Security: - #13214 HS clients don't validate descriptor-id returned by HSDir - #7803 Clients shouldn't send timestamps in INTRODUCE1 cells - #8243 Getting the HSDir flag should require more effort - #2715 Is rephist-calculated uptime the right metric for HSDir assignment? Miscellaneous: - #13223 Refactor rend_client_refetch_v2_renddesc() - #13287 Investigate mysterious 24-hour lump in hsdir desc fetches - #8902 Rumors that hidden services have trouble scaling to 100 concurrent connections == Epilogue == What useful projects/tickets did I forget here? Which tasks from the above we should not do? I just went ahead and wrote down all the projects I could think of, with the idea that we will filter stuff later. Thanks! Footnotes: [0]: since RPs are picked at random by the client and not by the HS. [1]: see https://moderncrypto.org/mail-archive/messaging/2014/000434.html [2]: or if someone is more crazy, try to integrate GNUnet's GNS: https://gnunet.org/gns

16 25

Malicious relays and honeypots
by Gareth Owen 26 Nov '14

26 Nov '14

Hi all I wonder if it might be worth having a discussion on how to detect malicious and/or suspicious relays. To my knowledge, the project currently only scans for MITM and tries to detect larger Sybil attacks (but doesn't always act when detected). We have a lot of knowledge now about types of attacks and the unusual behaviours that might present if they are being deployed. For example: 1) Relays changing their ident every 24 hours are likely trying to be in a position to be the directory node for a HS (there are several of these relays active today). 2) Many relays being launched on sequential IP addresses, and/or with two nodes per IP - again - likely intercepting DHT publications or Sybil. 3) I have spotted several times a large number of relays in the same subnet, or adjacent /24 subnets. You could extend this to ASes. 4) Honeypot relays that try to spot unusual cells or traffic patterns traversing the tor network. For example, this could have detected the RELAY_EARLY attack if it was based on a different code base. One could define very robust and tight rules for what is permitted - flagging nodes sending unusual traffic. Additionally, PADDING cells are not currently used by the official client but are used very widely in traffic confirmation attacks - whilst intermediate relays wont be able to detect this, clients can and could flag it with an authority (via a 3-hop circuit). 5) One could scan for unusual descriptors being returned too - e.g., the descriptor is currently with in tight size bounds - but one could pad with bytes to support traffic confirmation if PADDING cells are put on the red flag list. 6) We also have the wider question of traffic tampering by exits, like the recent binary patching exit which I believe was not detected by the project. 7) And finally, Exits that only exit ports which permit tampering - e.g. the exits that only exit Bitcoin traffic for example. The question of course is where is the threshold and what does one do in the event of one of these.. Personally I am of the view that suspicious relays are not worth keeping in favour of diversity - but that view does contradict the project's I think. Best Gareth -- Dr Gareth Owen Senior Lecturer Forensic Computing Course Leader School of Computing, University of Portsmouth *Office:* BK1.25 *Tel:* +44 (0)2392 84 (6423) *Web*: ghowen.me

2 1

Re: [tor-dev] Feedback on obfuscating hidden-service statistics
by George Kadianakis 25 Nov '14

25 Nov '14

"A. Johnson" <aaron.m.johnson(a)nrl.navy.mil> writes: >>>> George and I have been working on a small proposal to add two >>>> hidden-service related statistics: number of hidden services and >>>> total hidden-service traffic. >>> >>> Great, I’m starting to focus more on this project now. Well, >>> actually I’m going on a trip for a week today, but *then* I’m >>> focusing more on this project :-) >> >> Sounds great! We're meeting every Tuesday at 16:00 UTC in #tor-dev. >> Feel free to drop by. > > Excellent. I won’t be there this coming Tuesday, but I’ll be there the next Tuesday. > >> Replicas mean that each descriptor is stored under two identifiers, so >> that's two places. Further, descriptor identifiers change once per >> day, so during a 24-hour period, there are up to four descriptor >> identifiers for a hidden service. > > That makes sense. It would be nice if the statistics would allow you > to identify how long (i.e. how many hour periods) each descriptor was > observed being published. That would allow us to figure out if there > are lots of short-lived services or fewer long-lived > services. Publishing statistics every hour would pretty much take care > of this. If you are really set on 24 hours, then perhaps you could add > the total number of published descriptors in addition to the number of > *unique* published descriptors. > > Also, my suggestion about using additive noise applies equally well to > the descriptor statistics. And multiplicative noise is a *bad idea* if > you don’t have some adjustment for small values (e.g. 10% noise of a 0 > value is 0, and 10% of 1 is only 0.1). > >> We have been thinking about many more hidden-service related >> statistics in a separate document. We're currently discussing whether >> we should turn it into a tech report, because we'll probably not want >> to implement most of those statistics. If you have remarks or more >> ideas, please feel free to edit the document. We're going to have a >> public review round for this, too, but that might not happen in the >> next week or two. >> >> https://etherpad.wikimedia.org/p/hs_stats_78281091 > > Great! I think we should go for at least a little more data in the > current proposal (what is the timeline for this, btw?). I think we > should come up with a list of statistics we might imagine gathering > and identify the subset of those that we’re comfortable gathering at > this point. For example, I think failure statistics is much more > innocuous than other data, and those would be very useful. For > example, they would help us understand how to improve the protocol is > failing, and it might help us identify misuse of hidden services > (e.g. by botnets clients stupidly looking for non-existent descriptors > or by malicious crawlers attempting to brute force descriptors). So > here are some ideas: > 1. Number of fetch requests for descriptors that don’t exist (number of fetch requests that do succeed would of course be very useful as well) > 2. Number of descriptor publishes to the wrong HSDir (actually I suspect that the HSDir doesn’t check this and wants to be accepting of any publish) > 3. Number of rendezvous circuits that never connect (from the RP perspective) > 4. Number of rendezvous circuits on which no data cells are ever sent > (CC'ed [tor-dev]) Thanks for the input Aaron! The timeline here is that we are hoping the proposal _and_ the implementation to be ready by mid-December. Then we are hoping that we can deploy the code to a few relays so that we have some data by January. So, time is tight. I'm currently OK with the two statistics in: https://people.torproject.org/~karsten/volatile/238-hs-relay-stats.txt I feel that any other statistics will need to be carefully analyzed. We should add the ideas you mentioned in the etherpad, and get them included in the tech report (which we are also hoping to have ready in some form by mid-January). The tech report is supposed to contain and analyze most of the HS statistics we can think of. It will likely contain many stats that we will never do, but also some stats that might be a good idea. The good ones we should eventually integrate to the Tor proposal and write code for. >> Thanks for the very valuable input! Let me know if the following >> draft looks okay, and I'll start another thread on tor-dev@. >> >> https://people.torproject.org/~karsten/volatile/238-hs-relay-stats-2014-11-… > > "Lab(\epsilon/C)” -> "Lap(\epsilon/C)” (that was my mistake. I think > having the added noise both parameterized and included in the reported > statistics is an idea worth thinking about. Making it a parameter > allows you to easily change it without upgrading. Including it in the > statistics would allow us to correct better for noise if different > relays might be adding different amounts of noise due to inconsistent > opinions of the noise parameter (if this should never happen, then I > guess this wouldn’t be necessary). > > So again, sorry that I’m not going to be very responsive on this for the next week. I’m really happy that you’re working on it! > > Best, > Aaron

4 6

botnets+tor
by Enkidu Mo Shiri 25 Nov '14

25 Nov '14

nowadays using tor by botnet developers is bringing risk to tor network. the use hidden service feature in tor network ,install their IRC server and by hiding behind relays,packet encryption and layers of tor, control and command botnets and use them for attacks. 1.i am researching about any possibility if i can differentiate between botnet traffic and normal tor network traffic by sniffing and analysing network traffic at gateway of my campus. 2.any idea about this technique: i run a botnet in my computer (sandbox) attach a script to it(developed by myself) ang let botneet works. the botmaster (hacker) receives botnet report( after it pass by 2 relays) and my script runs in his computer and sends me his system information. 3. have a question about tor network structure: how many nodes are between user A 9 outside tor) and user B( in internet but outside tor) ? i dont their communication will pass by two nodes(relay) but what other node? how does hidden service provide service to them? any authentication stuff? sorry if its not related to this mailing list. *Ehsan Moshiri (Enkidu)* *Digital Forensic And Penetration testing Researcher * *H/P:+96 111 2868 696* *Linkedin: http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/ <http://my.linkedin.com/pub/enkidu-moshiri/59/baa/90b/>* *Facebook: Enkidu Oshiri* *wechat: Enkidu-Moshiri* *whatsapp&viber:+961112868696*

1 0

[PATCH] Pinning middle nodes for HSes: anti-guard-discovery
by George Kadianakis 25 Nov '14

25 Nov '14

Hello, inspired by the recent discussions on guard discovery, I went ahead and implemented a small patch for Tor that tries to help defend against Hidden Service guard discovery attacks. It basically allows the operator to specify a set of nodes that will be pinned as middle nodes in Hidden Service rendezvous circuits. The option only affects HS rendezvous circuits and nothing else. Of course, it doesn't fix guard discovery, it just pushes guard discovery to the next hop, so that they need to compromise two boxes to win. You can find my branch in 'sticky_mids' at https://git.torproject.org/user/asn/tor.git . (Here it is in HTTP shape: https://gitweb.torproject.org/user/asn/tor.git/shortlog/refs/heads/sticky_m… ) I don't expect this to be merged in mainline Tor, but if any HS operators feel like they need it, here it is. I coded it fast and it seems to work for me, but please inform me of any bugs. You can use it by adding a line like this in your torrc: """ HSRendezvousMiddleNodes TorLand1 """ (BTW, I'm not advocating TorLand1, it's just a random relay name I thought of. Please use your own web of trust.)

2 2

doc/HARDENING Draft
by Libertas 24 Nov '14

24 Nov '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I thought I'd share an initial draft of doc/HARDENING. Please share any opinions or contributions you have. This was written in a little more than an hour, so it's still a work in progress. However, in the spirit of prototyping before polishing, I thought I'd share early. Here's the relevant ticket: https://trac.torproject.org/projects/tor/ticket/13703 A specific topic of conversation is how much of the advice should be in the document itself as opposed to linked sources. It could also use more OS diversity. After reading it, you can probably guess which *nix flavors I'm familiar with. Enjoy, Libertas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJUc7qtAAoJELxHvGCsI27NOwsP/1bP+g4W2y1NHefR5bd+5hwo V927TXzarNneNFxfhKJsVewVnU593Ex13iHv+WgA+XM39xiK8KkhpxOaw2IpahZp pIRCk4/XX78YaEc/K3ci2AsNGFVXPBX7nm4/VOZ5qiGfo+FVeipykweF1dF+X1Wc 1wr8Q9LWKoIab+klu/BG5nG5NtwICYslbgXMvNnapHuy0Xn1+fvBx3mW9teMkJ0N Npssiy7XUqJx1XpdYNJr4XI28aHOV2p4FeCdsAgaQ1OBkOvpzMd+fw2Yb3FOiX/l 5pNCPMXFsS/+OXp1qOFKDQoOb7fEP6mY4NqdSovuJU0oWdurnHVk/X3SidALfH/L vFPdTwpCJSMLuYO7HsLLiLx6LkDtrDZ2y9+tUfpqKGAN0upXrIi5GWsbUeLcCqwY UFYdSg1GHsWJz7fU6F1vDLpGsiXU5yVqgaxfP06+nZ/smRt5sA3nlMDCZJi3BDes k0+c4+tAPZ5Yt6kJ5b1GBgxQMokDqnLm/4pb/qlp0EzDfhWpA+Un2lGdvInrz1ds VsVvbq/LLuxYylC3hlF8pNxBVMdbXycWM1w/VHtDjPZFdo9AO4CJHXeShYQa2O0W cBXdU+O59wWoxiCuEfo0O2xaJw2UIRfxauQbcp/A0rg8FKU1c2QeP2t7y8VdVC1Y SgQNVCUKYPBMCywJw9PA =yY3r -----END PGP SIGNATURE-----

1 0