However, our cryptographic and network authentication model does make use of certificate-based server verification; this post outlines the issues related to that component of our security model.
As can be explored on other posts here for extra detail, cryptostorm's cryptographic authentication model does not make use of a naive, two-directional certificate framework for network validation. Rather, we have removed a substantial component of the default method of validation commonly found in "VPN services," because this deployment framework is discongruent with the real-world security needs of network members. Instead, we deploy cryptographic (RSA-based) certificate authentication only for server verification.
The purpose of certificates, in our model, is to lessen the risk of an attack scenario in which the attacker "masquerades" as a legitimate cryptostorm exitnode, thereby causing network members to connect to this false node as if it were genuine. In such an attack scenario, the attacker then gains plaintext access to network member traffic as a result of the attacker running what is fundamentally an "evil exitnode" (as is found so often in Tor attacks) pretending to be genuine. Through the use of RSA-validated session parameters, cryptostorm network session initiation is limited only to servers which have the "private" component of the RSA-model key material ("public" key data for this certificate framework is, of course, published publicly and is found in all inlined conf files as well as bundled with widget installs as "ca.crt").
An attacker who has gained access to cryptostorm's private certificate component will be able, if they can meet the requirements outlined below, to run an "evil exitnode" that pretends to be cryptostorm but is in fact not run by our team. This is a legitimate security concern.
Preexisting Mitigation Layers
This description of "evil cryptostorm exitnodes" is commutable with an active MiTM attack; the two are, in functional terms, identical. Our security model deploys several layers of protection against both passive and active MiTM attacks; our defensive layering is not solely dependent on certificate-based verification of server authenticity, although such is a core component of our defensive framework.
Additionally, our implementation of per-packet HMAC validation with heavy cryptographic algorithms assists in ensuring that "partial" MiTM attacks will result in active session termination at the legitimate exitnode end, thereby subverting the ability of a partially-successful active MiTM attacker from instantiating persistent network sessions. Further, We actively monitor and protect against DNS-based (cache or realtime) attacks on node/cluster lookup parameters, by ensuring that multiple TLDs in multiple jurisdictions, managed by multiple registrars, are concurrently deployed for hostname-to-IP lookup duties. To subvert this via a successful MiTM attack requires comprehensive subersion of all deployed TLDs, across registrars (this is feasible for nation-state level attackers who control "edge" routing within a given geographic terrain, for example, via corrution of BGP route data).
The end result of these additional layers of anti-MiTM protections is that the only functionally effective MiTM attack that represents what we feel is a substantive real-world threat for network members is an active, "oracular" attack that intercepts via route poisoning all packets destined for a legitimate cryptostorm exitnode/cluster.
As we have discussed elsewhere, all cryptostorm exitnodes - throughout our network - have been brought fully current with newly-patched OpenSSL libraries, and all dependent binaries have been re-compiled to ensure these libraries are called at runtime. Independent testing via heartbleed exploit code generator/testing suites can confirm this for network members. Secondary, non-frontline backend systems such as our websites do not impact member network sessions in any way and, a heartbleed-based attack on such secondary systems, if successful, would not expose any member data or other member-sensitive information. In short, spoofing our website would allow someone to pretend to have competed a successful "defacement" of the site itself... this is not a security-core concern for us, relative to member-impacting issues.
This leaves the matter of private certificate materials carried on our production exitnodes worldwide. Given the known parameters of the heartbleed vulnerability within OpenSSL, it is preferred to issue new certificate materials on these nodes now that they are fully patched to post-heartbleed status. However, there is a core constraint to be considered: certificate-based handshake is completed via mathematical "matching" of the public key materials, as circulated via conf files and with widget installs, with private key data on exitnodes (this is an oversimplification of the maths; those curious as to the fundamentals are encouraged to explore available literature on RSA-based certificate models). Issuance of new key materials on exitnodes will break backwards compatability for all network members seeking to initiate sessions based on the old public component of the replaced keys. Unlike, for example, HTTPS sessions based on TLS/SSL, cryptostorm's public key data are not mediated via outside CAs (certificate authorities); we find this model less than compelling given our network's use-case scenario, and thus circulate such materials directly to members as part of conf's and widget installs.
The issue of backward compatability is nontrivial. Many of our network members do not routinely check our website or forum to review newly-issued conf's, and we make a strong priority of backwards compatability in such matters. Further, of course, we have no way to contact "all" of our members - our token-based authentication model successfully decouples network member identity from network activity, and simply put we don't know who the vast majority of our members are. There are no "broadcast mailings" to members, as a result - it is simply not possible.
Prospective Attack Scenario
For an attacker targeting the heartbleed-exposed private server certificate materials attack surface, our threat modelling suggests that an effective strategy would require full "oracular" control of a key routing chokepoint. This is the case because, in order to successfulyl masquerade as a  exitnode, the attacker must intercept all IP-routed UDP packets to and from the network member, destined for a specific -controlled IP octet. To do this requires more than passive MiTM tactics (which are sometimes called "bump on the wire" attacks); rather, they require the ability to infect route data.
Route data could be infected either close to the member's session initiation point (in physical and/or topologic terms), or in the colo facility housing a legitimate cryptostorm exitnode cluster. It is easy to see why this is the case, when one considers traceroute data and the essential stochasticity of within-internet route details; going to the "edge" of the route is the only reliable place to mount such an attack. In the case of the latter attack model - setting up an "evil exitnode" within a colo facility, full control/ownership of on-subnet switching our routing hardware would be required (or, alternatively ARP cache poisoning... which is morphologically similar). This is possible, but would require either the active assistance of the colo or a level of attacker capability in gaining root control of remote routing infrastructure that is highly advanced.
Attacks based on ISP-level routing subversion are perhaps more likely for network members located in geographically attacker-intensive locations such as unfriendly national governmental regimes. In this case, oracular control of route data presents not only issues with regard to heartbleed, but brings up the entire spectrum of oracular MiTM risks. In short, absent an out-of-band "control channel" to validate key/certificate materials, members facing such attacks are vulnerable irrespective of heartbleed. The full scope of such vulnerabilities - metaphorically similar to the famous 'Ken Thompson' issues surrounding compiler design - are beyond the scope of this post.
As a go-forward strategy, our approach is as follows:
- 1. We will be instantiating newly-created server instances on each exitnode and cluster, which deploy newly-issued certificate material (both private and public, of course). As those instances are spun up, tested, and placed in production, we will post their public key materials and requisite hostname mappings to this thread. Members who want to connect only to these "updated" nodes will then be able to modify their connection configurations, proactively, to ensure exactly that.
2. In the meantime, those members still using network parameters from before the upgrade will continue to see successful network connections. All future releases of configuration files and widget versions (such as the v1.0 which is in alpha testing) will include only new key materials, and we will taper off the old, pre-update instances across exitnodes and clusters. When each old instance reaches a critical threshold of member usage, we will decommission them manually, one at a time.
For many network members, immediate migration to the new instances carrying new certificate materials may not be absolutely essential - the ability to mount active, oracular MiTM-style attacks on IP-routed packet data (without missing packets & triggering HMAC-based defensive spin-down of sessions) is nontrivial. Very few attackers or attacker organizations have the expertise, resources, and capacity to mount such attacks; further, such attacks would need to be bespoke-generated, cannot be automated, and as such reflect mostly TAO-style tactics. These tactics are certainly known to exist, but are not common and do not scale across broad target populations.
However, for some members who require higher levels of security hardening against exactly this level of attack scenario, immediate migration to the new exitnode instances is warranted. We will accelerate our deployment of these new instances, within constraints of required in-house testing & security validation prior to public availability, specifically to meet the needs of this class of network members. We respect that those needs are genuine, and have concluded that we can meet those needs without breaking backwards compatibility for the concomitant class of members who do not require immediate upgrade.
Finally, we strongly encourage members concerned with this kind of active/oracular MiTM (or, to put it another way, "evil exitnode") attack scenario to validate future public key data out-of-band from their local ISP or connection channel. Obviously, anyone able to have full oracular control over local routing data can spoof any and all source/destination data not only at the IP (link) layer but also at any layers "up" the OSI model from there (transport, application, etc.) - such spoofing makes it trivially easy to, for example, pass down false "public certificate" materials when new conf files are downloaded (via packet payload replacement, among other techniques); this would obviate the entire benefit of upgrading private certificate data. Out-of-band verification of these data, and of widget installer MD5 checksums, is as such strongly recommended for those members in this category.
~ ~ ~
Questions & feedback encouraged & appreciated, as always.
- ~ cyptostorm_ops