.onion hidden services gateway: what it is & how it works

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.
cryptostorm_team .onion hidden services gateway: what it is & how it works

Post by cryptostorm_team » Thu Dec 04, 2014 2:38 pm

{direct link:}
full cryptographic overview:

admin note: discussion on this topic has been split off to a separate thread, and this announcement post will be updated with current data as it becomes available. It is locked, and follow-on questions or comments are best placed in this thread, or feel free to simply open a new topic; both forum members & non-registered guests can post here, freely.

As we've all become increasingly aware of the reality of global dragnet surveillance of activities online, the use of privacy-protecting technologies has continued to grow apace. Leading that field are protocols and software suites created and maintained by the Tor Project, a nonprofit organization staffed with best-in-class software, network, and cryptographic engineers.

With the growing popularity and use of Tor's software and tools, more and more use-case scenarios have evolved from the core vision of the team: one of the benefits of an opensource, community-driven project such ass Tor is that elastic creativity that comes from the open-ended, unbounded nature of software that's published and available for modification and expansion. From operating systems, to browsers, to embedded systems, to mobile tools, Tor's foundation has nurtured a growing ecosystem of exciting new applications.

Update 7 December 2014: we've upgraded the internals of torstorm to a Lua-based, nginx-served architecture and away from the Pythonic approach of tor2web. Some of this is personal preference on the part of our development and tech operations team; some of it is a haunting sense that Python's attack surfaces are too numerous to enumerate fully. In the end, we have more confidence in both the production stability and the security characteristics of our upgraded approach. The earlier text regarding tor2web is kept as well, for reference:
One novel remix of Tor's core strengths comes as tor2web, a server-side proxy allowing visitors using standard browsers to view Hidden Services-based .onion websites. This platform, originally developed by Aaron Swartz and Virgil Griffith, is now maintained by the HERMES Center for Transparency and Digital Human Rights, and is supported by a growing community of developers and contributors.
As our contribution to this creative Tor ecosystem, cryptostorm has crafted what we call "torstorm", a hybrid aggregation of tor2web and our own encapsulation-based network security service. Simply put, torstorm allows anyone connected to the cryptostorm network to view .onion sites in any browser window by entering the address in syntax:

Topologically, torstorm provides serially-linked network transit in this form:

member_PC <---> cryptostorm_exitnode <---> torstorm_node <---> hidden_services

From the member PC, data are encrypted and encapsulated via established cryptostorm secure network session to a cryptostorm exitnode anywhere in the world. That exitnode then routes the traffic, encrypted via https instantiated by the torstorm's SSL-enabled nginx backend, to the torstorm node itself. There, it transits through and comes out as Tor-protocol traffic, travelling the Tor network itself to reach it's hidden-service destination. Return queries follow the same path, opposite direction.

For members, the benefits of torstorm are obvious and substantive:
  • First, any member can from any standard web browser visit any Tor hidden service, simply by entering the address into the browser's window as described above. For many use-case scenarios this is convenient and the security trade-off (see below) is reasonable or not impactful. For those members requiring full, end-to-end Tor connectivity, the Tor browser will continue to be the preference.

    Second, as compared to a "naive" tor2web install, torstorm network sessions are substantially protected against the most commonplace passive traffic analysis attacks. Rather than having packets transit from a members's local computer directly to the tor2web gateway server, as in a naive setup, all traffic in the torstorm model routes through a cryptostorm exitnode bidirectionally. Thus, traffic analysis must rely on timing-based vectors rather than simple trace of https packet trajectories. This is a substantive decrease in attack surface.

    Third: we've done a bit of work to deploy torstorm with a enforced cipher suite selection requiring PFS-supporting ECDHE via curve brainpoolP512r1, which is generally regarded as not backdoored and robust in production context. Thus, version-rollback attacks targeting broken TLS cipher primitives (like RC4) are not possible; those lacking modern cipher capabilities in their browsers will be unable to make insecure torstorm connections using known-broken fallback ciphers. To us, this is a crucial security guarantee and a much-needed refusal to allow insecure sessions that members understandably assume are secure since they are enabled.
Simultaneously with these benefits, we emphasise the following security considerations as compared to conventional Tor-entire routing of hidden services browsing.
  • First, the entity acting as administrator of the torstorm nodes themselves has access to plaintext traffic if it chooses to make fairly trivial edits to the code running on those machines. This is the case because, absent end-to-end Tor session mechanics, traffic coming through the Tor-internet gateway comes across a plane that requires protocol transition. During that transition, it is definitionally possible for root to have access to plaintext surreptitiously, if it so chooses. Of course, we are not doing this - however this cannot be formally proven to an outside observer, and that is different than end-to-end Tor sessions.

    Second, as noted above, a well-resourced attacker could in theory execute timing-based traffic analysis attacks on end-to-end network sessions outside of the Tor cloud itself (the first three "segment" in the linear topology, above). These attacks are nontrivial, but far from impossible. Without some for of stochastic "fuzzing" of packet transit schedules in cryptostorm exitnodes, this attack represents a tempting surface for metadata harvesting. Although recent timing-based attacks on Tor protocol traffic have recently been discussed widely, it is our opinion that those attacks on Tor are substantively more challenging that the concomitant attack on the outside-Tor segments of the torstorm topology.

    Third, an outside attacker gaining root privileges on a torstorm server has, per the first risk above, access to plaintext traffic. We have hardened these machines and run them with security best-practices, but it is impossible to provide perfect security in this as in many areas of technical systems. This contrasts with the end-to-end Tor model, in which intermediate nodes, even if malicious, are (in theory) unable to gain information content on the payload or routing information relating to packets they relay.

    Fourth, torstorm is currently a beta deployment and should not be trusted with security-intensive uses! We are deploying torstorm in beta form to gain additional testing data, to stress-load the framework under production workloads, and to encourage constructive review and critique of the model and deployed technology from independent researchers and analysts. We have done internal analysis during deployment, but not at a level suitable to give strong security assurances to users. More, the modified Lua-based torstorm codebase itself is somewhat young and only moderately tested in practice, in our opinion: that's a substantial difference from foundational end-to-end Tor technologies, which have undergone years of independent review, analysis, and testing under extreme attack scenarios. Further, our technical team has limited experience with Tor-based applications and we may make errors in our work as a result of this, particularly during beta testing.
In summary, we feel this is an interesting and perhaps useful addition to the constellation of tools making use of the core Tor protocol and network components. However, it needs some serious beta testing and we may do substantial adjustments to the model and/or deployment details as that process unfolds. No matter what, please - PLEASE - do not use torstorm during beta phase for security-intensive activities! That would be, if we may be honest, a really stupid thing to do. Don't be stupid - that's our job. :angel:

Did we mention that this is a BETA TESTING deployment? We did, right. Here's a scary image to remind you again, because it's important:
pictograms-aem-0015-rotating_shaft.png (2.94 KiB) Viewed 81838 times
That looks painful, doesn't it? Ouch. How about this:
pictograms-aem-0019-gears.png (4.43 KiB) Viewed 81838 times

Ok then, hopefully we made that clear.

Our thanks to the Tor team for years of contributions to online privacy. Without those enormous resources, none of our work would be possible.

Please share with us experiences, critiques, bug reports, and suggestions in this thread. We will do our best to embrace community findings, and improve torstorm as time goes by.

With respect,

  • cryptostorm_team

important notice!

This product is produced independently from the Tor® anonymity software and carries no guarantee from The Tor Project about quality, suitability or anything else.