- tor-dev - lists.torproject.org

maatuska's bwscanner down since 2017-04-14 -> significant drop in relay traffic
by relayoperator＠openmailboxbeta.com 20 Apr '17

20 Apr '17

Hi Tom! since maatuska's bwscanner is down [1] I see a significant drop of traffic on many of my relays, and I believe this is related. Do you have any update to [2] on when maatuska will report bwscan results again? thanks, a concerned relayoperator [1] https://lists.torproject.org/pipermail/tor-consensus-health/2017-April/0078… https://consensus-health.torproject.org/graphs.html#bwauthgraphs [2] https://lists.torproject.org/pipermail/tor-consensus-health/2017-April/0078…

3 2

Re: [tor-dev] maatuska' s bwscanner down since 2017-04-14 -> significant drop in relay traffic
by relayoperator＠openmailboxbeta.com 20 Apr '17

20 Apr '17

> On Thu, Apr 20, 2017 at 10:54:21AM -0000, relayoperator(a)openmailboxbeta.com wrote: >> Hi Tom! >> since maatuska's bwscanner is down [1] I see a significant drop of traffic on many of my relays, and I believe this is related. >> Do you have any update to [2] on when maatuska will report bwscan results again? >> thanks, >> a concerned relayoperator > > I am also seeing a strange sudden drop in usage: > > https://atlas.torproject.org/#details/… [View More]

2 1

Proposition: Applying an AONT to Prop224 addresses?
by Alec Muffett 15 Apr '17

15 Apr '17

Hi, So: a bunch of us were discussing Prop224 Onion addresses, and their UX-malleability. Specifically: that there are small bit fields in the current Prop224 Onion Address schema (eg: version, and other future structure?) which can be tweaked or amended without otherwise changing the functionality of the address, or without much changing what the user sees in the (say) browser address bar. This is a point of significant concern because of issues like phishing and passing-off - by analogy: … [View More]

7 27

Interest in collaborating on a standard Ed25519 key blinding scheme?
by Tony Arcieri 15 Apr '17

15 Apr '17

I'm trying to gauge interest on the IRTF's CFRG mailing list regarding collaborating on a draft for a standard Ed25519 hierarchical derivation / key blinding scheme: https://mailarchive.ietf.org/arch/msg/cfrg/lM1ix9R-0tVzhZorQhQlKvi4wpA The post makes several mentions of Tor's work in the space in regard to the next-generation hidden services design. I think it'd be great if Tor were to collaborate on the design of such a scheme and adopt it for the new hidden services design. I see a lot of … [View More]

5 5

Re: [tor-dev] Interest in collaborating on a standard Ed25519 key blinding scheme?
by Oleg Andreev 15 Apr '17

15 Apr '17

> From: George Kadianakis > Date: Wed, Apr 12, 2017 at 7:57 AM > > An update: > > After lots of discussions in the Amsterdam Tor meeting, the following > approach was suggested for cleansing keys of their torsion components > that is more friendly towards hierarchical key-derivation schemes: > https://moderncrypto.org/mail-archive/curves/2017/000866.html > > However, my current intuition is to just not do this for hidden service > ed25519 blinded … [View More]keys. Those keys are only used for signing descriptors > which should be safe to do, and we don't plan to use them for D-H any > time soon. If we or some crazy app EVER decides to use those ephemeral > keys for key exchange, we would need to use a special DH function that > kills the tensor component of keys before using them, as suggested by > Trevor here: https://moderncrypto.org/mail-archive/curves/2017/000874.html > > Please let me know if you think this is not a good idea! Thanks for the update, George. TL;DR: your scheme seems to be just fine for signatures, and even torsion-safety issues are not huge issues IMHO. For wide applicability reasons, I am trying to make our scheme ChainKD [1] to fit as many use cases as possible and therefore very interested in Tor's requirements and rationale regarding Tor's key blinding proposal. L;R: After studying the situation with key derivation schemes for Ed25519, my impression is that the central issue is not even safety, but compatibility with existing Ed25519 implementations. People who have to integrate a key derivation scheme in their protocol are often not the same people who write the underlying primitives such as scalar multiplication. This means, that it's safer to be conservative and keep the derivation scheme as compatible with EdDSA as possible so that assumptions that implementors may take by just reading the EdDSA spec without knowing about key derivation schemes, do not cause compatibility problems. Since it's not a trivial task to even learn the landscape of problems around Ed25519 compatibility- and safety-wise, it'd help if we can figure all of that once, implement and reuse the result w/o having to go through this again and again. Hence, our interest in standardizing the scheme that satisfies as many requirements as possible. <comic relief> https://xkcd.com/927/ </comic relief> Following the feedback in BIP32-Ed25519 paper [2], I've updated our ChainKD [1] scheme to make it safely "compatible" with DH use cases (among those is asymmetric encryption such as ECIES). In the Design Rationale section [3] I try to describe the issues with low/high bits and torsion-safe representative and why we choose to keep those bits as defined in Curve25519 instead of "torsion-safe representative" and why we use BIP32-style blinding-by-addition instead of blinding-by-multiplication. One piece of feedback affecting our proposal is missing, though: I'd like to ask Tor developers what is the rationale and requirements for their key blinding proposal. Specifically, why do you choose to blind via multiplication instead of addition: s' = b*s; P' = b*P (Tor's proposal) vs s' = s + b; P' = P + b*G (BIP32, ChainKD) (G -- base point, P -- pubkey, s -- secret scalar, P = s*G, b -- blinding scalar) I know of a few reasons to use addition over multiplication (e.g. performance and bit-compatibility with EdDSA), but would love to learn if that hurts some protocols. PS. I've just joined the list and replying to a forwarded message. I apologize if I break the thread. [1] ChainKD, revised: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications… [2] BIP32-Ed25519: https://drive.google.com/open?id=0ByMtMw2hul0EMFJuNnZORDR2NDA [3] ChainKD rationale: https://github.com/chain/chain/blob/chainkd-dh/docs/protocol/specifications… [View Less]

2 1

Re: [tor-dev] [Twisted-Python] txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

Manish Tomar <manish.tomar(a)gmail.com> writes: > If you don't mind, could you describe your reasoning behind this > decision? I am always curious to learn any concrete reasons behind > this. If this seems spammy to the mailing list, please feel free to > respond only to me. Mostly because I don't want to ever have breaking changes, so then you're "not supposed" to upgdate the big version number. I haven't found that "semantic versioning" has been working very well for the … [View More]

1 0

Release: sandboxed-tor-browser-0.0.5
by Yawning Angel 13 Apr '17

13 Apr '17

Hello, I just tagged sandboxed-tor-browser 0.0.5. Binaries will be built when the next Tor Browser build happens (soon). Astute readers will notice that I skipped the release announcement for 0.0.4, which was tagged yesterday. This is due to changes related to e10s being enabled in the next alpha release, that were caught after the 0.0.4 tag was created. Changes in version 0.0.5 - 2017-04-13: * Bug 21764: Use bubblewrap's `--die-with-parent` when supported. * Fix e10s Web Content crash … [View More]

1 0

txtorcon versioning
by meejah 13 Apr '17

13 Apr '17

I will soon release the next version of txtorcon with a ton of cool new features. This will be called 0.19.0. More details: http://timaq4ygg2iegci7.onion/releases.html Going forward, versioning will switch to a "CalVer.org" variant. At one point, I thought of breaking a few now-regrettable APIs. However, I will not do this. The next version after 0.19.0 will be 17.x.y Changes in any existing APIs will be done by first introducing the new thing, deprecating the old thing and eventually … [View More]

2 2

GNU Guix and Tor Browser Packaging
by bancfc＠openmailbox.org 11 Apr '17

11 Apr '17

There is a serious Tor Browser packaging effort [3][4] being done by ng0 (GNUnet dev) for the GNU Guix [0] package manager. GNU Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles and most importantly reproducible builds. I have checked with Guix's upstream and they are working on making a binary mirror available over a Tor Hidden Service. [2] Also planned is resilience [2] to the attack outlined in the TUF threat model. [1] Back to the … [View More]

2 2

Re: [tor-dev] Contents of tor-dev digest...
by Mike Guidry 11 Apr '17

11 Apr '17

I am not trolling you. I attached a PDF which explains how to trace TOR connections over the internet. It is not a joke. I have some other vulnerabilities at that URL I am releasing. I'll include here: Michael Guidry March 15, 2017 Tracing connections online from the virtual landscape to the physical world Hacking is the intrusion of a computer by an unwanted guest, and is usually used to express gaining access to corporate, or government networks. It requires either installing using … [View More]malware, phishing, or directly connecting to machines and attacking their software with exploits. It is currently impossible to accurately trace hackers online unless they use the same software, and techniques for all their targets. It has become a major problem within the last decade due to globalization, and corporate networks directly connected to the Internet. Tracing Transmission Control Protocol (TCP) connections across the Internet is inaccurate due to how routing is performed across global backbones. The global routing table is modified constantly with nodes, and routes being adjusted for optimization, or quality of service needs. TCP is the most used protocol therefore it is the only protocol which really matters to attempt to trace. User Datagram Protocol (UDP) is state less therefore less reliable for tracking, however has the same vulnerability. UDP is usually used by hackers for exfiltration, or remote control after other actions have been performed. It is currently impossible to track connections over the Internet accurately. Several cases relate to The Onion Router (TOR) sites aka “Dark Web,” which were somehow uncovered using private technologies. Technologies used for those cases do not work properly over regular hacking via proxies online. Its an issue for the landscape of political hacking worldwide which has been increasing annually across the globe. China, for example, has been having a lot of blame lately due to Internet Protocol (IP) addresses assigned within its borders being used in massive amounts of attacks. Some of these attacks have been supposedly verified, however it is impossible for China to have performed them all. Proxy servers being used in chains may just be victims themselves. The problem arises due to possible evidence planting being similar to proxying through their others networks, or borders. It is completely different comparing cyber war to traditional conflicts due to evidence being traceable, and soldiers physical evidence being easily recovered. Hacking back is a concept any government, or corporation is now detailing within their playbook to understand how the liabilities may affect them. It is the terminology used to attack the source of an intrusion by means of hacking itself. Repercussions of hacking a country due to incorrectly assuming an attack was originating there is highly possible. Cyber war policies exists for a lot of nations, and it may easily escalate their attention on whom they believe is performing the attacks. The same happens with ‘proxy wars’ currently within the middle east, etc. Proxy wars traditionally will have global evidence allowing verification of weapon deliveries, or monetary exchanges to determine the origin of funding. Soldiers training methods, and other strategies may be impossible to cloak. It is generally accepted once verified, and escalation is directed towards the proper perpetrator. Internet Service Providers (ISP) have the ability to perform various tasks internally to determine the pathways through their networks which would reflect lateral hacking movements. Connections leaving a single network that enter the realm of dynamic routing via Border Gateway Protocol (BGP) become a nightmare. The percentage of accuracy decreases exponentially as each separate network is used to route the connection to its destination. It becomes nearly impossible to trace after just a few gateways at least publicly, or academically. Unorthodox methods are required to allow tracing of connections under these circumstances. Distributed Denial of Service (DDoS) is a solution that allows you to turn the internet’s own packet distribution system into a tracking mechanism. Most people do not consider performing DDoS attacks for positive reasons. DDoS may have been used by targets to “quarantine” their hacking source temporarily from the Internet. This strategy is beyond the scope of this technique, and is literally only a bandaid for a single attack originating from possibly just a proxy. DDoS is also illegal in most nations which have advanced their cyber crime laws. The fact that this technique requires many computers performing attacks strategically placed across the globe also ensures that they will be performed from countries where these laws are being enforced. The attack requires attacking all networks that you wish to verify against therefore you are immediately breaking laws on the destination side of most of the world simultaneously. It should not be used lightly, or regularly without cause and understanding. DDoS attacks transmit more data to a destination than a that network can handle which forces it to stop responding in a timely fashion. The latency is so high that the TCP timeouts are reached, and connections break. New connections are also impossible during these attacks. It has only had negative effects since it began being used globally regularly. This technique could be considered a reverse DDoS. The approach is to attack the entire world in a very strategically timed manner using worldwide machines. Each separate DDoS attack using machines worldwide would use different synchronization, and timing information which would allow embedding information directly into the latency it causes on those networks. The purpose is to compare that latency with the hack taking place to verify its source location. If the attack disrupts networks your attempting to verify against for milliseconds up to a few seconds then you can perform several of these sequentially to embed information in this timing itself. DDoS then becomes a positive useful solution even though technically illegal to a currently difficult problem. You wouldn’t necessarily have to attack the entire world. Conceptually it would be better to use databases of networks wishing to verify against. Residential, and commercial IP delegations throughout most nations would cover a large portion. Government hacking groups have their IPs leaked often as well. It is possible to just perform the attacks on these particular sets of IP addresses rather than the world as a whole. It is also equally possible to perform the attacks on entire ISPs, and countries to quickly determine although this would not be accurate due to possible proxies in between being within that country. If the technique is used on a major ISP network rather than a gateway going into an office then it is possible that a proxy exists within their network which would read off as a false positive. Accuracy relies on the networks your verifying against to be actual end user machines which would have human attackers. If you were to attack a network, or router of a network which has an office then it is highly likely they are going to notice other hackers using their network to hack externally on scales which would involve this type of solution. If you were to attack an entire country then you are going to have a problem of not recognizing from timing alone whether or not a proxy (of possibly several) just exist in that country. It is imperative to understand this, and always attempt to get as close to the networks in question being verified. Original message: Are you trolling us? I don't get it! On Sun, Apr 09, 2017 at 08:19:28PM -0400, Mike Guidry wrote: > Hello, > > Here is a document I've wrote regarding a concept to trace connections even > through TOR. If you have any questions feel free to respond, and I'll > attempt to explain. I have also considered a way to mitigate this > situation being allowing TOR to be traced by using 'Transactional > Requests.' I'll proceed to write it up, and post soon. > > I have released some other short papers as well. It contains several files > regarding a few vulnerabilities, and a couple concepts regarding things > like quantum resistant cryptography, etc.. > > URL: https://mega.nz/#F!QnZRXKyS!oluyILlMPpyJjPS57w7axQ > > Feel free to e-mail me directly.. > > Thanks, > Mike Guidry [View Less]

2 4

Re: [tor-dev] Tracing TCP Connections online..
by Mike Guidry 10 Apr '17

10 Apr '17

re: grarpamp I am writing a possible countermeasure which uses transactional requests. You submit entire requests which are processed by the exit node. Several other situations can take place while routing to the exit node. It would also only require exit nodes to have updated to the newer feature. I'll post as soon as I'm finished.. Thanks, Mike Guidry ----- >This appears to describe an active network modulation attack (node DoS). >Either hammer tree on nodes of the expected path … [View More]

1 0

Control-port filtering: can it have a reasonable threat model?
by Nick Mathewson 10 Apr '17

10 Apr '17

Hi! As you may know, the Tor control port assumes that if you can authenticate to it, you are completely trusted with respect to the Tor instance you have authenticated to. But there are a few programs and tools that filter access to the Tor control port, in an attempt to provide more restricted access. When I've been asked to think about including such a feature in Tor in the past, I've pointed out that while filtering commands is fairly easy, defining a safe subset of the Tor control … [View More]protocol is not. The problem is that many subsets of the control port protocol are sufficient for a hostile application to deanonymize users in surprising ways. But I could be wrong! Maybe there are subsets that are safer than others. Let me try to illustrate. I'll be looking at a few filter sets for example. ===== Filters from https://github.com/subgraph/roflcoptor/filters : 1. gnome-shell.json This filter allows "SIGNAL NEWNYM", which can potentially be used to deanonymize a user who is on a single site for a long time by causing that user to rebuild new circuits with a given timing pattern. 2. onioncircuits.json Allows "GETINFO circuit-status" and "GETINFO stream-status", which expose to the application a complete list of where the user is visiting and how they are getting there. 3. onionshare-gui.json Allows "SETEVENTS HS_DESC", which is exposes to the application every hidden service which the user is visiting. 4. ricochet.json Allows "SETEVENTS HS_DESC", for which see "onionshare-gui" above. 5. tbb.json Allows "SETEVENTS STREAM" and "GETINFO circuit-status", for which see "onioncircuits" above. ===== Filters from https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/to… : 1. onioncircuits.yml See onioncircuits.json above; it allows the same GETINFO stuff. 2. onionshare.yml As above, appears to allow HS_DESC events. It allows "GETINFO onions/current", which can expose a list of every onion service locally hosted, even those not launched through onionshare. 3. tor-browser.yml As "tbb.json" above. 4. tor-launcher.yml Allows setconf of bridges, which allows the app to pick a hostile bridge on purpose. Similar issues with Socks*Proxy. The app can also use ReachableAddresses to restrict guards on the . Allows SAVECONF, which lets the application make the above changes permanent (for as long as the torrc file is persisted) ===== So above, I see a few common patterns: * Many restrictive filters still let the application learn enough about the user's behavior to deanonymize them. If the threat model is intended to resist a hostile application, then that application can't be allowed to communicate with the outside world, even over Tor. * Many restrictive filters block SETCONF and SAVECONF. These two changes together should be enough to make sure that a hostile application can only deanonymize _current_ traffic, not future Tor traffic. Is that the threat model? It's coherent, at least. * Some applications that care about their own onion services inadvertantly find themselves informed about everyone else's onion services. I wonder if there's a way around that? * The NEWNYM-based side-channel above is a little scary. And where do we go forward from here? The filters above seem to have been created by granting the applications only the commands that they actually need, and by filtering all the other commands. But if we'd like filters that actually provide some security against hostile applications using the control port, we'll need to take a different tactic: we'll need to define the threat models that we're trying to work within, and see what we can safely expose under those models. Here are a few _possible_ models we could think about, but I'd like to hear from app developers and filter authors and distributors more about what they think: A. Completely trusted controller. (What we have now) B. Controller is untrusted, but is blocked from exfiltrating information. B.1. Controller can't connect to the network at all. B.2. Controller can't connect to the network except over tor. C. Controller is trusted wrt all current private information, but future private information must remain secure. D. Controller is trusted wrt a fraction of the requests that the clients are handling. (For example, all requests going over a single SOCKSPort, or all ADD_ONION requests that it makes itself.) E. Your thoughts here....? signing-off-before-this-turns-into-a-capabilities-based-system, -- Nick [View Less]

8 10

Tracing TCP Connections online..
by grarpamp 10 Apr '17

10 Apr '17

re: "tcp_tracing_internet.pdf" This appears to describe an active network modulation attack (node DoS). Either hammer tree on nodes of the expected path and trace the modulation, or on all but the expected path to find unmodulated. It generally requires GPA, deploying nodes, or being one end of the path... in order to observe the results. And it's old news. As noted before, since Tor (and all other current anonymous overlays) nodes do not perform their own independant buffering, reclocking and … [View More]

2 1

Re: [tor-dev] Feedback Extension for Tor Browser
by Jayati Dev 10 Apr '17

10 Apr '17

Dear Mentors, Is the project 'Feedback Extension for Tor Browser' still a part of GSoC 2017? I have already submitted a proposal and would like to work on it. Please help. Regards, Jayati Dev

2 1

Tracing TCP Connections online..
by Mike Guidry 10 Apr '17

10 Apr '17

Hello, Here is a document I've wrote regarding a concept to trace connections even through TOR. If you have any questions feel free to respond, and I'll attempt to explain. I have also considered a way to mitigate this situation being allowing TOR to be traced by using 'Transactional Requests.' I'll proceed to write it up, and post soon. I have released some other short papers as well. It contains several files regarding a few vulnerabilities, and a couple concepts regarding things like … [View More]

2 1

Comments on proposal 279 (Name API)
by Nick Mathewson 09 Apr '17

09 Apr '17

Hi ! I'll make some comments here on the draft onion naming API at https://gitweb.torproject.org/torspec.git/tree/proposals/279-naming-layer-a… (Some of these are probably things you already meant, or already said elsewhere.) Section 2.1 and elsewhere: I suggest that we require all address suffixes to end with .onion; other TLDs are not reserved like .onion is, and maybe we shouldn't squat any we haven't squatted already. I think we might also want to have all output addresses end … [View More]with .onion too. I suggest also that we might want to reserve part of the namespace for standardized namespaces and some for experimental or local ones. Like, if we standardize on namecoin that could be .bit.onion, but if we don't, it could be .bit.x.onion. I finally suggest that we distinguish names that are supposed to be global from ones that aren't. Section 2.3: How about we require that the suffixes be distinct? If we do that, we can drop this "priority" business and we can make the system's behavior much easier to understand and explain. Let's require that the TLDs actually begin with a dot. (That is, I think that ".foo.onion" can include "bar.foo.onion", but I don't like the idea of "foo.onion" including "barfoo.onion".) Section 2.3.1: Does the algorithm apply recursively? That is, can more then one plugin rewrite the same address, or can one plugin rewrite its own output? (I would suggest "no".) I think there should be a way for a plugin to say "This address definitely does not exist" and stop resolution. Otherwise no plugin can be authoritative over a TLD. Section 2.5.1: Is the algorithm allowed to produce non-onion addresses? Should it be? Must query IDs be unique? Over what scope must they be unique? Who enforces that? May query IDs be negative? Can they be arbitrarily large? I think result should indeed be optional on failure. Section 2.5.1 and 2.5.2: We should specify what exactly clients and plugins will do if they receive an unrecognized message, or a malformed message. Section 2.5.3. See security notes on caching below; client-side caching can lead to undesirable results. As noted above, I agree with requiring all result addresses to be .onion. Section 3.1: I prefer the "put everything under .onion" option. I also think that we should require that the second-level domain be 10 characters or less, to avoid confusion with existing onion addresses. General questions: I know we've done stdout/stdin for communication before, but I wonder if we should consider how well it's worked for us. The portability on Windows can be kind of hard. Two alternatives are TCP and named pipes. Another alternative might be just using the DNS protocol and asking for some kind of "ONION_CNAME" record. (DNS is ugly, but at least it's nice and standard.) Security notes: I'd like to know what the browser people think about the risks here of (eg) probing to see whether the user has certain extensions installed or names mapped. Maybe .hosts.onion should only be allowed in the address bar, not in HREF attributes et al? We might want to think about cache-related timing attacks here. Perhaps we should have a "no caching" rule. We should probably add a security notes section for how to write plugins that aren't dangerous: a bad plugin potentially breaks user anonymity. [View Less]

7 10

Reverse Naming Proposals?
by grarpamp 09 Apr '17

09 Apr '17

These recent naming proposals on list, for forward naming 'string --> onion, 1:1', I think. Is anyone working on doing reverse naming, 'onion --> string, 1:1' ? With links to such work?

1 0

Adding Single Onion Service support to Bitcoin Core
by James Evans 08 Apr '17

08 Apr '17

Core is preparing to support this new tor feature. Any helpful suggestions would be appreciated. :) https://github.com/bitcoin/bitcoin/issues/9836 https://github.com/bitcoin/bitcoin/pull/10161 Thanks for all the great onion work! James

1 0

minimizing traffic for IoT Tor node over 3G/LTE
by Razvan Dragomirescu 08 Apr '17

08 Apr '17

Hello, I am working on a project to create very small Tor nodes on embedded devices connected over LTE or 3G. I have it working fine with OpenWRT and just 128MB of RAM, but the main issue is now the amount of data needed to download the consensus. The consensus files appear to be around 2.3MB at the moment and I think the default is to re-download every 3 hours, so that's 18.4MB/day or 552MB/month. Is there any way to reduce this while still maintaining good citizenship on the Tor network? Are … [View More]

2 3

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 07 Apr '17

07 Apr '17

On 04/06/2017 09:13 AM, Jeremy Rand wrote: > Hi Nick! > > Nick Mathewson: >> Section 2.1 and elsewhere: > >> I suggest that we require all address suffixes to end with .onion; >> other TLDs are not reserved like .onion is, and maybe we shouldn't >> squat any we haven't squatted already. > > FWIW it's not at all clear to me that this is a concern that IETF or > ICANN will care about. Most DNS recursive servers (e.g. Unbound) > allow squatting … [View More]

1 0

GSoC: Support all kinds of DNS queries
by Daniel Achleitner 07 Apr '17

07 Apr '17

Hi everyone, I'm a Software Engineering master's student at TU Wien, Austria, with a recent focus on computer security and privacy issues. I am interested in participating in GSoC 2017, particularily in the task to support all kinds of DNS queries via Tor [1]. I've seen the mailing list discussions of 2012 and read the resulting proposition 219 [2]. What do you think, which parts of it (if any) would need to be adapted for DNS in 2017? My current impression is that not much has changed, … [View More]

2 3

Rethinking Bad Exit Defences: Highlighting insecure and sensitive content in Tor Browser
by Donncha O'Cearbhaill 06 Apr '17

06 Apr '17

Hi all, The Tor bad-relay team regularly detects malicious exit relays which are actively manipulating Tor traffic. These attackers appear financial motivated and have primarily been observed modifying Bitcoin and onion address which are displayed on non-HTTPS web pages. Increasingly these attackers are becoming more selective in their targeting. Some attackers are only targeting a handful of pre-configured pages. As a result, we often rely on Tor users to report bad exits and the URLs which … [View More]

7 8

Counter-RAPTOR Paper
by Yixin Sun 06 Apr '17

06 Apr '17

Hi all, Our proposed defenses (Counter-RAPTOR) against active routing attacks on Tor will soon appear at IEEE S&P in May. It's also available here: https://arxiv.org/abs/1704.00843 In short, we have two lines of defenses: (1) Entry Guard Selection (proactive defense, https://github.com/inspire-group/Counter-Raptor-Tor-Client) (2) BGP Monitoring on Tor relays (reactive defense, in progress of making it public) Please let us know if you have any questions/comments. Thanks! Yixin

2 1

"Anomalous keys in Tor relays" technical report now available
by Laura M. Roberts 05 Apr '17

05 Apr '17

Hello, Tor devs! We have just published a (not yet peer-reviewed) technical report entitled "Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/ The project was inspired by the "Mining Your P's and Q's" paper from Heninger et. al., and in it, we take a closer look at the RSA keys used in Tor since 2005. We found that entities had purposely created anomalous keys in order to attack Tor's onion services and that researchers had inadvertently created weak keys while conducting … [View More]

1 0

Re: [tor-dev] Comments on proposal 279 (Name API)
by str4d 04 Apr '17

04 Apr '17

On 04/04/2017 12:50 AM, Nick Mathewson wrote: > On Mon, Apr 3, 2017 at 8:20 AM, George Kadianakis <desnacked(a)riseup.net> wrote: >> Nick Mathewson <nickm(a)torproject.org> writes: >>> Section 2.1 and elsewhere: >>> >>> I suggest that we require all address suffixes to end with .onion; >>> other TLDs are not reserved like .onion is, and maybe we shouldn't >>> squat any we haven't squatted already. I think we might also want to … [View More]>>> have all output addresses end with .onion too. >>> >>> I suggest also that we might want to reserve part of the namespace >>> for standardized namespaces and some for experimental or local ones. >>> Like, if we standardize on namecoin that could be .bit.onion, but if >>> we don't, it could be .bit.x.onion. I2P has been doing this for years with *.b32.i2p for unique identifiers vs *.i2p for hosts.txt-style naming, and I'm planning on writing an I2P proposal to create a formal registry of 2LDs that implementations need to know about, so we have the ability to expand in future under the .i2p TLD. So I don't think it's a stretch for users to understand (although I have other concerns, see below), and I'd be keen to have a common standard for specifying subdomains that we can use for interoperability :) >>> >> >> I have mixed feelings about keeping the .onion suffix. >> >> One one hand it seems like The Right Thing to do, since we managed to >> get .onion standarized in the IETF which comes with various >> benefits. Also, starting to squat other tlds arbitrarily seems like a >> silly thing to do. This is the safest space for Tor to work in from a technical perspective. More specifically, I've been following discussion in DNSOP ever since the original special-use names draft (containing .onion, .i2p etc) was posted, and there is no way that the IETF is going to standardise any new TLD for non-DNS (see below). It's increasingly unlikely that the non-.onion TLDs in the draft will either (without industry support like .onion had), so no CA-supported SSL certs for I2P :( >> >> However, I also dislike asking users to visit something.bit.onion >> instead of something.bit, since people are not used to the second tld >> having a semantic meaning, and I can imagine people getting very >> confused about what it means. There's also the problem of transport-agnosticism. Assume there's some FOOnet that is created for naming that we all decide we want to use. Users would probably expect that FOOnet names all exist in the same space, which would not be the case if we had *.foo.onion, *.foo.i2p, etc. I'm thinking along the lines of IPv4 vs IPv6, where you can have a DNS name delegate to both via A and AAAA records; you wouldn't want the name changing just because the underlying transport changed. > > Indeed. And I'm not only concerned about people becoming confused: I > am also worried about confused programs. > > Right now, it is easy to answer the question "will Tor handle this > address specially" -- the only special addresses are the ones ending > with ".onion", and the legacy suffices ".exit" and ".noconnect" as > documented as address-spec.txt. But if we allowed arbitrary TLDs in > this proposal, then _any_ hostname would potentially be an address > that Tor would handle specially. > There is a draft currently in working-group last call that will specify a .alt TLD (or possibly .alt.arpa, it's still being debated [1]), that future non-DNS names will have to be under. Part of the proposed benefit is that with a standard TLD, DNS resolvers can just stub out that entire namespace, ie. if fqdn.endswith('.alt'): do_non_dns_lookup(fqdn) else: gethostbyname(fqdn) Presumably, browsers would do so as well. So it's possible that you could have *.foo.alt as the URI, but only *.foo is displayed in the browser (along with some chrome indicating it is non-DNS), similar to how only the base domain name is shown for some URIs (IIRC that's an SSL cert verification thing). The question then is how a browser would handle *.foo being typed in. You wouldn't want to query DNS and then try *.foo.alt afterwards, as that would be terrible for privacy, but if they tried *.foo.alt first, and didn't have FOOnet installed, should they try *.foo in the DNS? The browser either needs to know the full contents of *.alt (which is not possibly because by design it will have no official registration), or every registered TLD in DNS (which won't ever be added as a restriction because of various legacy local-net vendor TLDs like *.home). So with this approach, it's likely that .alt would need to stick around. Lots to think about here... str4d [0] https://tools.ietf.org/html/draft-ietf-dnsop-alt-tld-08 [1] https://www.ietf.org/mail-archive/web/dnsop/current/msg19983.html [View Less]

1 0