- direct link: rebirth.cryptostorm.org
Never Stand Still
tl;dr version: we're making some major changes to our billing procedures, we're entirely cutting connection with the com/net/org TLDs, and we're adjusting team member disclosures - all designed to harden the company further against emerging threat vectors, and thereby protect customer privacy from all known and foreseeable threats. This isn't Privacy Seppuku, but certain low-probability scenarios might lead to a full wipe of our network & clean restart, if that's what's required to ensure customer protection. Prospective customers: please do not sign up with Cryptocloud until these changes are complete - once they're done, we'll give the green-light (both here and via twitter) that things are tested & ready for production use!
[align=center]~ ~ ~[/align]
Providing network security service that can stand up against the kind of heavy surveillance pressure we now all know threatens the global internet is not for the faint of heart. There's certainly easier ways to make money in the technology world (for those so motivated), and the omnipresent threat of extra-legal harassment against those individuals providing & teaching core OpSec fundamentals cannot be ignored. Very few teams have the technical experience, practical competence, personal durability, and stubborn dedication to customer protection that are all required to successfully manage serious privacy services.
Cryptocloud has always been one of those teams, since we came together in 2007. We're taking steps now to ensure that we remain at the forefront of best practices in the future. Some of those steps we are announcing today - mostly procedural and staffing related - and others will be coming out publicly in short order. Some will be easy and smooth to implement; a couple are going to be a bit rough. We'll do our best to mitigate these difficulties, and to ensure the end result is a stronger, tighter, more durable service for all of our customers.
Throughout Cryptocloud's history, we've not hesitated to stand up to arbitrary power, on behalf of our customers and our loyalty to them. Our feeling as a team is that, in recent weeks, we've reached a level of visibility different from previous years. This doesn't come from any specific warnings; we've not received any FISA court demands and we don't have anything we're being gagged from discussing. However, as Silent Circle said in recent moves they've made, we're proactively modelling the evolving threat landscape and taking steps to avoid risks to our customers' security before they manifest realtime. Have there been some rumblings? Yes. We have a sense - call it a gut feeling, if you will - that pressure brought to bear via financial transaction processing infrastructure is going to be a serious issue in the near future, for many network privacy providers. We are acting to ensure our customers are as heavily protected against that as possible, whether they pay with credit cards, PayPal, cash, or cryptocurrency. We prefer not to provide more detail than that, to protect certain non-public sources of advance information.
Cryptocloud is not based in the United States. We do lease servers in the US, but they do not contain our customer data. Of course, we don't keep logs so those records are stored nowhere. However, certain payment gateway technology that forms part of our merchant processing interconnection, currently, has ties to the U.S. - and presents a tempting attack surface for a well-funded, well-resourced, highly motivated opponent (read: NSA). This weak link must be strengthened; see below for our decision on how to do so.
Today, we make three specific announcements:
- First, we're cutting all connection with the top-level-domains (TLDs) in the com/net/or registries. This has been hotly debated amoungst our team; words have been said that are hard to take back. This is a big issue for us. Originally, our company was located at cryptocloud.net. Later, it was shifted to cryptocloud.com in order to make Google happy. And, of course, presently cryptocloud.org is the main pointer to our discussion forum.
This is all changing, effective Friday this week (16 August).
Our main home for web visitors will henceforth be cryptocloud.ca. Why Canada? No TLD - and no registry - is perfect. However, we feel that the CIRA is run fairly, transparently, and with a strong commitment to free expression. The .ca TLD has a strong, proven track record when it comes to protection against hijacking and/or seizure by shady entities associated with the U.S. government - not perfect, but there is no perfect TLD currently. CIRA is also stable, well-run, reliable, and supported comprehensively worldwide.
The domain name cryptocloud.ca is already active and currently redirects to cryptocloud.com; on Friday, that will reverse and cryptocloud.ca will be the main TLD with the others redirected onto it. Shortly thereafter, we will redirect cryptocloud.com & cryptocloud.net to pages explaining our decision to discontinue use of these TLDs: U.S. governmental meddling in domains contained within these TLDs has reached a threshold where any content hosted on them cannot be trusted to be authentic. Simply put, it's far too easy for rogue state entities to gain control of these TLDs and point them at replicated sites masquerading as genuine - think of this as the ultimate form of man-in-the-middle attack, or DNS poisoning: visitors think they're getting the "real" Cryptocloud website, but instead it's an imposter. This is the threat vector we seek to protect against
This forum, currently housed at cryptocloud.org, will migrate to a new domain name outside the "poisoned three" of com/net/org. Architecturally, the forum and its underlying infrastructure are all housed in Iceland; it's only the domain name that is at risk of meddling. That would translate simply into a denial of service (DoS) attack, or a redirect of the domain to some other underlying server. Rather than have that open risk hanging out there, we have decided to migrate to a new TLD - and a new domain name - for this forum. That will be announced, here and in our twitter feed, before the end of the day Friday. We hope to have a transitional period, in which cryptocloud.org continues to direct here. That may not be the case, in the event an attack materializes faster than models suggest is likely.
Second, we're engaging in an immediate and radical overhaul of our payment processing backend. Right now, it relies on WHMCS as an interface between our web presentation and the underlying merchant processing networks. It does the job... but it's far from perfect. It's had security issues in the past - which we cannot control, as we don't have de-obfuscated source code with which to test and improve security. It's also clunky and often frustrates our customers with needless complexity.
There are also some deeper issues here, which we are ethnically obligated to avoid discussing in detail - for now. Certain disclosures by Snowden have brought to the surface the risks that non-open code introduce when state-level attackers are involved. The only genuine protection against this class of risks is a complete removal of closed code from infrastructure environments, period. We offer our thanks to certain well-informed, discrete colleagues out there who were kind enough to give us a hint that did wonders in motivating our prioritization of these concerns; we hope to offer those thanks, publicly, someday in the future.
This process of aggressive migration away from our entire current billing framework is likely to be rocky. We won't sugarcoat that. The benefit - dramatically improved systemic security for all customers - is worth the difficulty and risk. That is the conclusion of the Cryptocloud team. We will do our best to minimize the transition drama. We cannot promise it will be nontrivial, however. In part, that's because we are moving fast and moving immediately - based on what we know, this is the best decision, by far, for our customer security. Perhaps in the future we'll be at liberty to disclose why this was necessary, or perhaps it'll end up being disclosed elsewhere in due course. Irrespective, we must act on what we know and in the interests of our customers... even if it is inconvenient for you, and for us... as well as being substantially less than elegant.
Third, we are formally adjusting the manner in which we engage in public outreach with the media and other community resources. This, too, has been a subject of intense debate within our team for quite some time. When we are contacted by folks in the media - be they journalists, bloggers, or anything else in the mix - we've not had a standard policy as to who replies. We don't have dedicated "public relations" staff at Cryptocloud, and we never have. Hell, we don't even have dedicated marketing staff here... and we never have! We're a network security company, and that's where we focus our hiring, staffing, investment, attention, and research.
As media inquiries arrive, they more or less get handled by the staffer who seems best qualified - or who isn't elbows-deep in code at the moment. That's fine, but it doesn't scale - as we get more inquiries, things get disorganized on our end. That's not ideal. You've already seen a test-run of our answer to this conundrum, here in the forum: rather than specific staffers posting news or updates, you see them come from "Cryptocloud Team" - just like this post does. That test run has worked well, so far, and we're expanding it.
Additionally, we're acutely aware of the risk of harassment posed by personally identifying specific staffers here at Cryptocloud. We engage with privacy questions at the highest levels, and as such we to find ourselves at odds with some pretty powerful folks (read: NSA, etc.); that's not to say we feel they are our "enemies" - we don't. But, the temptation to lash out at us - bash the middleman, when the end-target isn't publicly visible - is always there. We understand that, and our colleagues at Baneki are somewhat specialists in that subject area. One thing they've learned - and shared with us - is the benefit of "lowering the attack surface" on individuals involved in serious security projects. We've taken those lessons to heart.
What we'll be doing is posting information about current, past, and emeritus team members... in aggregate. Some folks publicly associated with the company in the past may well make comments regarding relevant topics, here or elsewhere, and given their well-earned team status, we stand behind those statements. That said, henceforth we won't be identifying by name current staffers, period. Indeed, we might just push out bits of disinformation to keep recreational d0xers busy with interesting threads for investigation. If asked whether a particular person has, at some point, been part of our team, we'll answer with a clear yes/no... but that's it. If they, personally, decide to disclose more than that it's entirely up to them - we'll neither confirm, nor deny, any such statements they make.
Our internal team structure is quite fluid, non-hierarchical, and more mesh-based than pyramid-based: it's a holarchy, not a hierarchy. So, "titles" end up being rather silly and don't reflect workflow or responsibility clusters very well anyhow. As we staff up to support dramatic increases in customers and network usage, we're loathe to get sucked into conventional, formal, rigid models of "corporate" structure (even though some of our team members are deeply schooled in such models, both academically and via prior professional experience). Instead, we're going to retain our "pack" model of team cohesion: loyalty, integrity, and respect are the core of who we are, and how we operate.
In sum, you won't see anyone identifying themselves as "President" or "Managing Director" or "Jefe" of Cryptocloud, in the future. Such identifications are neither congruent with our social model internally, nor helpful in protecting against targeted attacks from outside. Instead, we're all "Cryptocloud Team," through and through.
Some parts of these changes aren't going to be easy, and probably won't be smooth either. We're rushing them into production for reasons that, albeit not disclosed publicly in detail here, are supremely relevant. They are the decisions we conclude will best protect our customers, maximize the durability of Cryptocloud as a project and as a particular approach to no-compromise network security, and avoid potential "insider threats" against our team-level dedication to customer loyalty (this last one: read closely, as it matters, alot - far more than it's discussed in the "VPN industry" currently... consider it a #protip).
We're going forward with them, and we're going forward with them now. Indeed, these changes are already in the works. By the end of the day Friday, they'll be far more visible on the public side of things. Our hope is that's a fairly smooth process. If it's not, you have our word we'll get through the rough parts as quick as we can. However, we will cut no corners in ensuring protection, throughout. That's beyond negotiation, for us.
Which brings us to the big, hairy, patient gorilla sitting in the corner...
This is not Privacy Seppuku. Not exactly, or not yet... call it Privacy Seppuku lite: the diet Coke of Privacy Seppuku, etc. Let us explain a bit, as best we can.
We aren't wiping our machines - nor our customer database. However, the three steps we outline above are similar in motivation to 'conventional' #privacyseppuku - that being to remove obvious weak links in our organizational model, and thus prevent otherwise-probable attacks from being attempted in the first place.
Further, let us be blunt: if these transforms don't move through implementation smoothly, there is a nonzero chance we will in fact commit formal Privacy Seppuku as an organization. In that case, we'll delete all databases of customer payment, service, and contact information - permanently and fully. We'll re-instantiate the project in a new company, on new hardware, with the most current jurisdictional insulation against all model-congruent possible future political/economic attacks. All folks who were previous customers will be provided ample "trial period" subscriptions in any such new project. You have our word on that.
To some degree, our goal here is to "cycle" the existing Cryptocloud organisation - in the formal sense of the word - and start tabula rasa with something that embodies every gram of current best-practice when it comes to hardening organizational entities against state-level aggressors. This isn't a bug; it's a feature. "Severing the cord" between the past and the future has deep structural benefits, from a security perspective. We leave it to the curious reader to work out those benefits, in detail, based on the game theoretic elements of the current threat landscape. This isn't a surface level transform; in fact, it's exactly the reverse. Deep down, the structure is doing a massive overhaul - and we're doing our best to minimise the surface impact.
To conclude, our colleagues at Baneki Privacy Labs have written recently on the logical underpinnings of the Privacy Seppuku Pledge, and how it relates to organizational existence versus project existence. We quote:
Because, we forget: a company is just people (and not the Soylent Green kind). These teams, they're (mostly) small. Facebook is a behemoth, but let's not kid ourselves: we won't see Facebook on this list. Most of our teams are a handful of folks - people, with names and email address and twitter handles and stuff. When we "shut down" a company, we're still alive! This isn't real seppuku, the kind where you eviscerate yourself (read: slit your stomach with a sharp sword, cut your abdominal muscles, and watch your intestines fall out and splatter across the floor in front of you). These are just damned companies: pieces of paper, words. It's not even the code: the code can go where it wants, particularly if it's opensourced.
This project - this team - is not only surviving, but it's thriving. If you want to trot out a metaphor that stretches things - but not too far - then think of it this way: the old skin (cryptocloud.com/net) is being shed, as it's been outgrown... and the world around us has evolved to require a different kind of camouflage. We're choosing to do that now, and to do it aggressively, so there's no interim period where we're needlessly vulnerable. It might not be pretty, this process, but it's better to dive in and get it done - done right, done now - than to prevaricate, hesitate, procrastinate, or just plain fuck around.
We have taken our seven breaths. Now, we take action - which, in the end, speaks far louder than words ever can.
- ~ Cryptostorm Team
press inquiries: most efficient is either via firstname.lastname@example.org or twitter; additional options can be found here.