Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

cryptostorm's Post-Heartbleed Certificate Upgrade Trajector

Looking for a bit more than customer support, and want to learn more about what cryptostorm is , what we've been announcing lately, and how the cryptostorm network makes the magic? This is a great place to start, so make yourself at home!

Topic Author
cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

cryptostorm's Post-Heartbleed Certificate Upgrade Trajector

Postby cryptostorm_ops » Mon Apr 14, 2014 5:37 pm

The purpose of this post is to provide a roadmap for cryptostorm's response to certain security implications relating to the recently-disclosed heartbleed vulnerability. As has been discussed elsewhere, our proactive deployment of DHE-based PFS capability has insulated our membership from any retroactive risk of bulk packet decryption as a result of heartbleed: we do not use persistent "private keys" in our cryptographic model, and as such no theft of same is of concern. Further, our token-based authentication model does not - and never has - made use of (hashed) token values for anything other than session authentication: they are not used as IVs, nonces, or in any step of our cryptographic model. Thus, "stealing" a token - whether via a heartbleed scrape or any other vector - would result only in replicated network access without requirement to purchase a token. This could be a minor hassle for any network member who would find their token stolen - they'd need to acquire a new one, otherwise finding themselves unable to initiate a concurrent network session alongside the stolen token - but does not reflect a security risk for the membership.

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.

Background

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.

Constraints
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.

Tactical Hardening
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.

Recommended Actions

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.

With respect,

    ~ []cyptostorm_ops


Malor
Posts: 13
Joined: Sun Nov 17, 2013 12:33 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Malor » Mon Apr 14, 2014 9:45 pm

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,

It would be easier for me to read these if you were clearer about what parts of your stack are homegrown, and what parts are from external packages. I think what you're saying is "our implementation" for the HMAC checking is probably OpenVPN's, but the DNS stuff is definitely yours. I, at least, would be able to parse and understand your messages better if you said something like, "we're using OpenVPN's HMAC validation, configured to do X and Y, and then we configured the DNS servers to do N and M", as opposed to just saying "we're doing X, Y, N, and M."

Now, admittedly, I may not be the target audience, but I'm fairly technical, and the loose way you phrase stuff has a minor feeling of bafflegab to it. I know you don't intend that at all, and perhaps it's because you yourself aren't one of the people on the ground actually configuring the servers. But there's a fair bit of, um, I guess I want to call it handwavy abstraction, which I have a hard time parsing to understand what's actually happening.

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.

Actually, I'm not sure that's true. The NSA has taps on many cables, including many supposedly private fiber runs by private companies, like Google. It sounds like they have a very large number of them. If they successfully exfiltrated the private key or keys from your servers, I believe they'll be able to do 'bump on the wire' monitoring if they like. But even if I'm misunderstanding the math there, and that's not feasible, we've seen NSA slides showing active decryption of network traffic, on the fly, where apparently they're doing MITM attacks on targets on a routine basis. (Remember Lavabit? The Feds were demanding that Levison install a MITM box. Your Internet hosting providers could easily be compromised in exactly the same way, and aren't likely to commit privacy seppuku to prevent it.)

You paint this as a not-terribly-pressing issue, but I really think you're getting that part wrong. I'm very glad you're rekeying your servers, but I'm still not sure you've internalized just how real the threat is. From what we know of the mass surveillance under way, you are a target of extreme interest to governments in general, and probably the NSA in particular. If you haven't been attacked yet, you will be. It's not an if, but a when. Remember, they're attacking individual sysadmins because they might want to tap the networks they run at a later date, so a privacy-heavy VPN service will be Priority Alpha from their warped and authoritarian perspective. Cryptostorm, almost by definition, is a target-rich environment, and you should assume they hate you and everything you're trying to do, and are actively trying to prevent you from providing real privacy and/or security.

From their perspective, you are the enemy, and you need to hold that near and dear to your hearts.

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.

From what we know, the NSA has control of many, many chokepoints. I strongly believe this is not an academic threat, but a real and pressing one.

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.

Again, maybe I don't understand the math, but if they've got your private key, can't they decrypt the entire key exchange, and therefore all the encrypted data? I mean, without a MITM, just sitting on the wire. (They've got, from what we know, plenty of MITM vectors as well, so I'm not sure it even matters.)

going to the "edge" of the route is the only reliable place to mount such an attack.

For normal, small scale actors, this is absolutely correct. For players that have multi-billion dollar facilities, and top secret rooms in network centers all over the world, mounting an attack of this type from a central location might be feasible. It would certainly, however, be easier to do it near the edge.... and your Internet providers may not be legally able to tell you about the tap rooms in their facilities.

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.

That's actually a good point. Might be worth thinking about. Maybe classified ads with key fingerprints?

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

One thing you could do is to get all your providers to include an extra blurb explaining the rekey with all the tokens they sell. That's the only way you have to reliably reach your users: at the point of token purchase. Eventually, you could make new tokens work only with the new servers, although you probably wouldn't want to do that right away.

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.

The 'cannot be automated' part is, to my knowledge, as wrong as you can be. They're automated at a terrifying level. Adding in VPN taps to their global awareness system would not be terribly difficult. If they've got a way in, meshing it into the massive, massive databases and realtime monitoring systems they've built isn't just possible, it's nearly certain.

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.

I'm really glad you're doing this. In my particular case, it's not actually that critical, but you will probably have customers that are literally betting their careers or even their lives on the integrity of your service. In the world where spy agencies are directly calling their citizens adversaries, running a VPN-type service takes on a fairly frightening amount of responsibility. People could actually die if you get it wrong, and the worst part is, there's a good chance that neither you nor they would ever know what the leak was.

Another thought to limit the damage in the future: put fairly short-term keys on your VPN servers, maybe a couple of months, and then rotate them fairly frequently. And, for the love of Mike, guard your CA, because that file is the freaking crown jewels of England for spies. Black bag jobs would be absolutely in order to try to get it.

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Tue Apr 15, 2014 6:00 am

Malor wrote:...
Now, admittedly, I may not be the target audience, but I'm fairly technical, and the loose way you phrase stuff has a minor feeling of bafflegab to it. I know you don't intend that at all, and perhaps it's because you yourself aren't one of the people on the ground actually configuring the servers. But there's a fair bit of, um, I guess I want to call it handwavy abstraction, which I have a hard time parsing to understand what's actually happening.
...


Just wanted to point out that I was likely the source of the bafflegab. I told them to try to hit a wide audience, so I think they dumbed it down for me. :P Sorry about that... but look at my avatar, I live in a freakin' garbage can, how smart could I be?? :P

G
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)


Topic Author
cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby cryptostorm_ops » Wed Apr 16, 2014 7:38 am

A condensed reply to a number of questions raised:

1. We deploy very few custom-coded components in our security model - this is not for lack of motivation on our part, but rather because bespoke cryptography is a catastrophically wrong-headed approach to security. When we refer to things such as "our implementation of HMAC validation" we mean exactly that: an implementation, not some harebrained effort to re-code the concept of HMAC validation from scratch. In this case, yes the HMAC procedure in question is one embedded in the OpenVPN framework; our specific implementation details are covered extensively in other threads, here on the forum, relating to our cryptographic framework more broadly.

2. We have been working through a full whitepaper describing our 'Hostname Assignment Framework" (HAF, for short) which should be ready for public review shortly. It describes, in detail, the TLD-based redundancy deployed within the HAF. Our apologies this has not yet been fully explored in a public posting; the HAF has been evolving so quickly since our launch that our efforts to 'snapshot' it always end up running behind the most current updates and extensions. At this point, it has stabilised enough that our final draft of the HAF whitepaper looks about ready to post for full community review.

3. Often, we receive concurrent feedback that our explanations are "too technical/verbose" or "short on details" and, unfortunately, our skills are not sufficient to meet both those needs simultaneously. We do our best. However, what we've found is that, if an early explanation ends up being short on details for folks participating in a specific discussion, a request for more detail is a great way for us to narrow in on specific areas of interest. Otherwise, we may well end up explaining fine-grained details of areas of little interest to community members, and unintentionally skipping over those that are. Thus, an iterative process - post, reply, post - is both efficient and mutually respectful.

4. We strive towards explanations in many posts here that abstract away technical detail in favor of systems-level understanding and explanation. This is a feature, and not a bug. Anyone who has read widely within raw RFQs will appreciate how technical detail can swamp out any sort of essential understanding, all to easily, in written explanations. We can always add technical detail, as requested (per above) - but a systems-level analysis of why given decisions have been made wrt to the security model or implementation framework are always our primary goal. We're not always successful in this first try, of course, but it remains the target towards which we strive.

5. There's some fundamental issues with regards to what a "Man In the Middle" attack is - and is not - that likely go beyond the scope of this thread to fully explain. Recall, however, that - definitionally - "MiTM" is distinct from passive surveillance of in-transit packets; MiTM involves decryption/read/re-encryption in one form or another... an actual, live box pulling packets and making substantive transformations of the form and substance of those packets, realtime. Nothing about Lavabit was related in any way to "MiTM" - that's an entirely different issue, in topological terms.

6. We agree with regards to ISP subersion as a known, legitimate attack scenario. As discussed in detail in our earlier post, this is an issue that transcends heartbleed, and is perhaps worthy of its own dedicated thread.

7. We are quite aware of the degree of hatred directed at this project, and at our project team members - this is not a new finding for us, after many years of providing no-compromise network security service. Indeed, we've had team members do prison time as a direct result of their work on this project, more than once. We model all threats against network-level security with this in mind, always. This is not "security theatre," and we are perhaps the last team that would fail to recognize that essential fact.

8. That said, real-work threat modelling and security assessment always - by definition - requires prioritization of threats. Simply categorizing all potential threats as "serious" means no specific class of threats is actually taken seriously; this may seem counter-intuitive from a lay perspective, but in real-world security administration, these prioritisation decisions are life and death. We are constantly reviewing, studying, and classifying threats to network-level security. Those threats range from known, documented, in-the-wild attack vectors to purely hypothetical, non-production scenarios that might be interesting from an academic perspective but are unlikely to be practically relevant in the near-term. Obviously, there is as much art as science in such prioritisation decisions - we do not claim otherwise, and know of no credible security professionals who do.

Just as the CVE's "severity" rankings are in the end entirely subjective, so is threat vector ranking. We make as much of this process public as possible, not because we think we are always right but rather exactly the reverse: we deeply value community insight and feedback on our threat vector mappings, and as such we work hard to bring that input to the surface.

9. Heartbleed is a real threat. However, because we do not and have never used persistent private keys in our cryptographic model, the vast majority of discussions regarding the "dangers" of heartbleed are irrelevant to our security model itself. This is a good thing. It does not mean that we are immune entirely to heartbleed-related concerns, of course; that's why we're addressing, here in public, the certificate authentication issue with respect to heartbleed. However, in doing so, there is no benefit to a "sky is falling" approach to the analytic side of our discussions. Were we - like the vast majority of lower-tier "VPN services" - relying on persistent cryptographic keys, things would be vastly different. We are not in that category, and our absence from that category is (of course) not an accident. Good security architectures matter.

10. It's worth recalling that an active MiTM on IP-routed packet streams requires not only transient root-level access to a chokepoint, but reliable, persistent root access to router resources at that chokepoint over time. Of course, the NSA does have some such access in some geographical nodes. However, a simple traceroute analysis of packets going to and from our exitnodes, from a member's local machine, will show that route details are rarely if ever static over time; they change, evolve, and 'drift' as network characteristics themselves change over time. Internet-based packet routing is inherently quasi-stochastic; from BGP to RIP, routers advertise new route details (and metrics) continuously. Active MiTM is made much more challenging in such
environments, for IP-routed traffic. This is a topological reality.

11. Again, we do not use persistent "private keys" and never have; we deploy DHE-based PFS. What we do use in our security model is RSA-based certificate authentication of server identity, within our network. These are related, but quite distinct, concepts. The former is a fatal, catastrophic risk given heartbleed; the latter does open up a new attack surface for a heartbleed-based campaign to enable active MiTM "evil exitnodes" as a method of achieving visibility into encrypted network traffic. No "bump on the wire" attack is congruent with certificate-based attack vectors.

12. The topological reality of IP-based routing - its inherent stochasticity - means that oracular MiTM must take place at the (logical) edge of a network session between two geographically-distant nodes. If a car was driving from New York to Washington DC, and the goal were to block the car from getting there, attempting to set up roadblocks in the middle of the USA would be inefficient to the point of infeasability; there are no "chokepoints" to target. In contrast, finding the one or two entry paths into/out of each city provides obvious, effective chokepoint locations. This is the same topological
issue as we are describing wrt oracular MiTM.

13. It is entirely correct, as we've said before, that a colo facility could be coerced into providing corrupted routing table updates (or simply root access) to certain nation-state attackers; this is a known, legitimate threat vector. We do not assume that any colo we use would "tell us" if such took place - indeed, they might not even know, in the event of a surreptitious rooting. There is no "magic bullet" to resolve this issue, of which we are aware. Good certificate-based verification of server identity is one of the core defenses against it - which is why this issue is real, and not merely of academic or theoretical interest. There are some inescapable signatures we'll see, sever-side, in the event of corrupted local (with colo) routing (or ARP-based) table attacks: we'd see packet traffic coming in from sessions that appear to be inside the local subnet! This would be highly unusual, and indeed our development team is exploring ways to automate identification of such aberrant network sessions. Thus far, that's our most promising avenue of active defense against this class of attack vectors; we're not ready to deploy the automated version, but we are taking pains to manually scan network exitnodes for such aberrant network sessions. None have, as yet, been seen.

14. Clever ideas for out-of-band distribution of public certificate materials are very much solicited, and encouraged! This is a problem that goes back right to the core of public-key-based cryptography itself: does anyone else remember "key exchange parties?" :-) Also, it's why quantum key distribution (QKD) systems are not only of theoretical interest, but in fact are used by banking institutions today. Good key exchange (which is covalent with good certificate-identity validation) is crucial to good public key cryptography.

15. In terms of tokens, for the integrity of the authentication model all tokens must work across all exitnodes and all clusters: to break that congruence would be to break the core of the authentication model itself. That said, we're open to all ideas with respect to certificate notification.

16. Naturalisch, we can say that any conceivable attack can be "automated" - in the same way we can say that a program can be written to undertake any possible series of computations or algorithmic transformations. However, we also recognize that "degree of difficult in automating an attack" is a real metric - just as the degree of compressability of an algorithm (the algorithm's "Kolgomorov complexity") is a real metric. We do recognize that this metric is scalar and not binary - there's no such thing as "automateable" and "non-automateable" attacks. So when we say something "cannot be automated" we mean, more formally, that the degree of difficulty in automating the attack is such that it would be impractical to do so relative to simply mounting the attack manually on an as-needed basis. Any programmer will be familiar with cases in which efforts to automate a given task become so difficult as to dwarf the effort required to simply do the task manually; such circumstances tend to evolve into Rube Goldberg-esque algorithmic contraptions, lacking in both elegance and robustness. Active MiTM attack vectors are, by definition, bespoke in nature; certainly some components of the attack methodology can be automated, but the actual in-process deployment of a session-interception box between a given network member and a given
exitnode cluster must be overseen, manually, by an expert systems operator. This is not a "point and click" attack as it depends crucially on the current-state topological realities of the network sessions themselves. Saying this doesn't mean the attack is "impractical" or "unlikely" - not at all. Rather, it simply means that the attack does not scale smoothly to global levels... nor, perhaps, even to a full-network level within our darknet. The implications of this flow out into our defensive stance with respect to this attack vector, as well: understanding the need for manual tuning of such attacks allows us to
in-build extra layers of obfuscation and/or complexity with which the attacker must come to terms for a successful attack.

17. We are in complete agreement that any member information exfiltrated as a result of such an attack by an entity such as the NSA would most certainly end up being loaded into automated, large-scale database systems for tracking individual citizens. This is a distinct issue from the question of automating the attack itself, however.

18. An excellent exercise for those interested in understanding the challenges and opportunities of threat modelling is to ask oneself the following question: if I were an attacker targeting this system, what paths would I tend to follow and which areas would look most tempting in terms of cost/reward metrics implicit in any large-scale surveillance architecture? This kind of thinking, of course, comes more easily if one has firsthand experience building, designing, or administering large-scale information systems... but such is not entirely required for the analytic technique to be quite useful. It is a necessary step towards threat modelling, although of course not sufficient (clever attackers may well have clever techniques of which we are not aware): we must view the "low hanging fruit" attacks and protect against them, first and foremost, as a core element of our attack surface minimization methodology. Conversely, attacks that seem to be fiendishly complex and/or challenging to pull off in real-world systems design are perhaps less likely to be seen as commonly as those which look obvious and easy to deploy.

19. We are again in agreement that a subset of our network members literally put their lives on the line when they entrust our framework with their network security needs. This is both a humbling responsibility, and an inescapable reality for our team. We are not new to this level of operational pressure. We are not perfect - nobody is. We remind ourselves that our members make choices between us and "outside options" - other approaches to security, apart from our network. We do our absolute best to substantially improve upon all outside options, including other services and roll-your-own security models. This work is ongoing.

20. Again, we don't use "private keys" in our security model - those show up occasionally in some documentation, but are purely vestigial and do not play a role in our cryptographic framework (details available in threads here describing our precise crypto architecture and deployed parameters). The challenge of protecting private server authentication certificates is one that is an ongoing area of research and development for us. As we've mentioned last year, our mid-range goal is to leverage either "certificate pinning" based CA-validation techniques or (far more preferred, by our tech team) blockchain-based public validation mechanisms that remove entirely the concept of centralised "certificate authority" itself (we currently self-sign our exitnode certificates, specifically because we mistrust the fundamentals of the current public CA model... very much so).

Namecoin, for example, provides a compelling alternative framework - as does, in a somewhat commutable sense, CJDNS. Our development team
actively experiments with all these tools, in search of a substantively improved model for server verification procedures.

21. That said, if someone roots one of our boxes - in part or in full - this is an inescapable security breach. We run extensive IDS, log-monitoring, and firewall-based rulesets to harden our exitnodes... as well as ongoing, regular, manual monitoring by our sysadmin team. No IDS framework is perfect, and only experienced eyes can fill those gaps. We also minimise how many services run on exitnodes - which do not run any ancillary/administrative services such as production webservers, email, etc. They are stripped-down kernels - in a sense, overgrown, cryptographically enabled routers. This is our goal, as the fewer active services, the fewer attack surface.

As always, and on behalf of our administration team, I appreciate the time and care that goes into these member questions - and the dialog resulting therefrom. Let's continue to build on this constructive process, as part of our ongoing network improvements overall.

With respect,

    ~ cryptostorm_ops


Malor
Posts: 13
Joined: Sun Nov 17, 2013 12:33 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Malor » Thu Apr 17, 2014 10:40 am

Confirmed: Nasty Heartbleed bug exposes OpenVPN private keys, too.

What they're saying here directly contradicts what you guys are saying. They claim that the actual encryption keys can be exfiltrated. You keep saying that this isn't possible, but these people are saying this is incorrect.

What they're saying is that until you issue all new encryption keys and certificates, you are insecure, full stop.

This is probably the biggest security hole in the history of the Internet. I really think you need a flag day, where you just shut down access via the old keys, and it needs to be soon.

It will be disruptive. It will really suck. A lot of people will be mad at you. But if you don't do it, you are not offering the security you promise. Forcing people to reconfigure their clients with no notice is a big hassle, and you will lose customers. But if you don't do it, as far as I can tell, you are taking people's money, and lying to them about what they're buying.

Two weeks ago, you didn't know you were lying, but now you do. Now it's becoming intentional, instead of inadvertent.

In security terms, this is the biggest disaster of my entire life. You're on an island in the Pacific, and a Category 5 storm has just wiped out everything. Smiling and pretending it's mostly business as usual, and that you can do a nice, slow, non-disruptive rebuild of a few damaged houses here and there, is just flat deceptive.

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby parityboy » Thu Apr 17, 2014 3:16 pm

@malor

9. Heartbleed is a real threat. However, because we do not and have never used persistent private keys in our cryptographic model, the vast majority of discussions regarding the "dangers" of heartbleed are irrelevant to our security model itself.
...
Were we - like the vast majority of lower-tier "VPN services" - relying on persistent cryptographic keys, things would be vastly different. We are not in that category, and our absence from that category is (of course) not an accident. Good security architectures matter.

11. Again, we do not use persistent "private keys" and never have; we deploy DHE-based PFS.

20. Again, we don't use "private keys" in our security model - those show up occasionally in some documentation, but are purely vestigial and do not play a role in our cryptographic framework (details available in threads here describing our precise crypto architecture and deployed parameters).


Cryptostorm does NOT use persistent private keys, they are ephemeral. Since they don't hang around, collecting one is a pointless exercise, since you cannot use it to decrypt previous traffic. Accusing the CS team of lying, when they CLEARLY state in their post that they don't use persistent keys, is beyond ridiculous and should be apologised for.

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Thu Apr 17, 2014 4:24 pm

parityboy wrote:...
Cryptostorm does NOT use persistent private keys, they are ephemeral. Since they don't hang around, collecting one is a pointless exercise, since you cannot use it to decrypt previous traffic. Accusing the CS team of lying, when they CLEARLY state in their post that they don't use persistent keys, is beyond ridiculous and should be apologised for.


The techs will respond again (I'm using email - which is the way they prefer to get thoughts out on "paper") but while I don't want an apology - frankly the internet isn't a place where I expect such :P - I really want you to think about what makes us a company, and what our motives would be.

We are differentiating ourselves by being MORE SECURE. That's what we want to do. We also are trying to be OPEN. So while we may suck at corporate communications (hell, I don't have a fucking clue what I'm doing from a business standpoint) we DO "give a shit."

We eat our own dog food, as they say. I need this VPN to work because my friends are trusting it, and they need it to work for various reasons. At this point we're making just enough money to pay server bills and maybe add a few more nodes. We have no fulltime staff. We're not here to become Facebook.

Also, we have techs who hate corp communication even more than I do, and who don't even know this forum exists, and that's fine, because they fucking rock at what they do, which is largely cryptography, networks and if statements.

So - ya, we're not here to screw anyone, we won't lie to cover our asses if we fuck up. Note that we will fuck up. That's a guarantee - but we'll not be lying about it, we'll be admitting it and trying to fix it.
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby parityboy » Fri Apr 18, 2014 2:11 am

7. We are quite aware of the degree of hatred directed at this project, and at our project team members - this is not a new finding for us, after many years of providing no-compromise network security service. Indeed, we've had team members do prison time as a direct result of their work on this project, more than once. We model all threats against network-level security with this in mind, always. This is not "security theatre," and we are perhaps the last team that would fail to recognize that essential fact.


If you're getting hit with flak, it means you're over the target. :D Keep on bombin'! :D


Topic Author
cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

details matter; boring... but still true

Postby cryptostorm_ops » Fri Apr 18, 2014 4:37 am

This is becoming something of a tedious exercise in repetition of the same point over and over. And, unfortunately, some of the press reporting linked to in your post does an excellent job of confusing two related - but quite distinct - issues. I will once again explain the core distinction, and beyond that I do not see it as particularly useful to keep repeating this over and over. Either we care about facts, or we can just run about in a misinformed panic, helping nobody in the process.

First, let me quote from the OpenVPN team themselves. They are discussing their commercial version "Server" product specifically, which is dispositive:

"Only the server that your client connects to could possibly exploit this vulnerability, and even then it is unlikely because we use Perfect Forward Security {sic} and TLS-auth on top of the SSL connection." [the conventional phrase is "perfect forward secrecy"]


As I have explained repeatedly, the use of PFS involves generation of ephemeral keys for use in the asymmetrically-secured symmetric key exchange. This is explained, as well, in detail in our crypto framework thread elsewhere on this forum. There are no "permanent keys" used on our cryptographic model. There never have been. This is not an "upgrade" to our framework; it has been the case since day one.

Those who designed our model (namely, our founding team and outside cryptographic advisors) made this decision specifically in order to protect against any potential exfiltration of "private (server) keys," via any method or vulnerability, at any point in the future. Panicking about someone "stealing our keys" makes about as much sense as worrying someone will steal a painting from a museum... a museum that does not house the painting, and never has. It borders on silly.

There are extensive resources online explaining the fundamentals of "PFS" (we dislike the acronym and always have, preferring "transient keying" ourselves) and how it works from a mathematical perspective. I don't see the value in an attempt on my part to re-explain it here, as I'll do a poor job compared to others who have already done it quite well.

To "steal" a transient, discrete-logs coordinated, "private key" by exfiltrating gigabytes of raw memory dump via heartbleed - within the 20 minute window during which re-keying occurs - is not only impractical, it's functionally impossible given bandwidth constraints (it'd melt down any of our nodes, in the attempt: a firehose of malformed packets fired at one machine in a short timespan). The theft of such a "private key" would also be useless outside of that 20 minute window, on that particular machine: hence the use of the word "transient."

We cannot "issue all new encryption keys" - as you vehemently demand... because we do not make use of persistent encryption keys in our security model. Please study that sentence, if it is at first unclear, as it is quite dispositive to your anger.

With respect to server identification certificates, as has already been extensively discussed in this thread, we are in process of re-issuing new certificate materials across the network. This is being done in a professional, staged, calm manner: not in a frenzied, sloppy, hare-brained panic. That is how we do things, here.

Passion is wonderful, but being passionately wrong does not help. Thank you for reading this post carefully.

    ~ cryptostorm_admin

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Fri Apr 18, 2014 12:03 pm

While making the migration process as smooth and unobtrusive as possible is very considerate of you, something tells me that most of your customers are here for security, first and foremost. So, I think that you should just hit the kill switch and roll out all the necessary updates ASAP, and most - if not all - of your users will be grateful. If they won't... Well, maybe they never needed a VPN in the first place.

As you yourselves said:

cryptostorm_support wrote:SECURITY > CONVENIENCE


On an unrelated note, isn't "trajector" a Latin word?

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby parityboy » Fri Apr 18, 2014 3:19 pm

@Operandi

It probably is. It's also what happens when the forum software limits the thread title to x number of characters where x is simply too short. :P

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Fri Apr 18, 2014 4:40 pm

parityboy wrote:It probably is. It's also what happens when the forum software limits the thread title to x number of characters where x is simply too short. :P

Heh, thought so.

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

PFS & cryptographic competence

Postby Pattern_Juggled » Sat Apr 19, 2014 4:00 am

To follow up on earlier conversations, I'd like to quote from two of my colleagues in the area of security research and cryptographic systems - two who for me carry both high credibility and the ability to explain substantive concepts in concise language.

Starting with Dr. Matthew Green, of Johns Hopkins:

"However... since an attacker who obtaions the server's main private keys can potentially decrypt past sessions (if made using the non-PFS RSA handshake)..."


And here is Ivan Ristic, of Qualys, reiterating this point:

"Unless your server used Forward Secrecy (only about 7% do), it is also possible that any past traffic could be compromised..."


To me, what this whole heartbleed wrt OpenVPN situation clearly highlights is this:

Any "VPN service" that was previously was - or is currently - using non-PFS-based encryption for RSA symmetric key exchange has demonstrated near-criminal incompetence in their choice of cryptographic foundations. There is, quite literally, no credible reason not to use PFS and there has not been any such reason for quite some time. The only reason that the vast, overwhelming majority of "VPN services" use brittle, non-PFS RSA key exchange is because it is the "default" setting in the "default" install of OpenVPN's framework. Call that laziness, or call it incompetence, or call it a total lack of understanding of how cryptographic primitives actually work... or some awful combination of all three. Whatever the case, any service who failed that most basic test has shown its incompetence - even before heartbleed was made public.

That's the lesson learned here, in a nutshell. Take a look around. Take a look at how many self-styled "VPN services" out there have been pushing non-PFS crypto for years and years. Often, the same ones who were earlier pushing hopelessly-broken PPTP-based "VPN service" until they were finally shamed into dropping that broken protocol.

As far as I know, personally, the only encrypted routing / network security service / darknet service that has deployed solely PFS-based transit crypto since the first day it began operation is: cryptostorm. That's a decision I personally supported, during the long development process for this project. In hindsight, it was worth the hard work that our entire team put into implementing that decision (amoungst many others). After last week, I'm sure others will attempt to follow us, or at least will make a lot of "coming soon" announcements.

Those who took the lazy/short approach and just naively accepted the default OpenVPN settings... well, let's hope they get weeded out of the field. They have no credible claim to competence, at this point.

That's what heartbleed has shown us, in our particular corner of the world.

Cheers,

    ~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github
bitmessage:
BM-NBBqTcefbdgjCyQpAKFGKw9udBZzDr7f

User avatar

ABISprotocol
Posts: 36
Joined: Fri Feb 14, 2014 6:53 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby ABISprotocol » Sun Apr 20, 2014 3:37 pm

Well, I know you are busy but a reply would be nice.
ABISprotocol ~ https://keybase.io/odinn
PGP 0x6c70abf8a7486f02
http://abis.io


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Tue Apr 22, 2014 3:57 am

Handwavy, bafflegab, self-felating, technobabble- sums up my feelings on the CS responce to this; it's horribly disapointing.

It starts off explaining the whole world has a preditor problem, in CS's particular case it's "only" Lions- then the thread seams to focus on how well CS protects you from Crocodiles, that plainly Crocodiles are not and have never been a problem for CS customers like they are for the rest of the world. No where is it mentioned that CS's excellent Crocodile protection actually makes you more vulnerable to Lions (there's way more stuff the bad guys have to compromise in a standard VPN model to mount a full MITM- ie: more private certs/keys more redundant old-school two-way authentication, these are ditched by CS to provide genuian segregated anonymity layers) - presumably becuase everyone is so distracted by the non-existant threat of Crocodiles, but it seams just as likely that CS feels it's better to just gloss over this silly business about lions- Crocodile protection is where it's at! Besides, if Lions are after you, your fucked anyway. meanwhile- whoa, who's that fat bloke on the hills side wearing a fashonable CS tailored meat suit? Shit- it's me.

it's not the keys to the castle that are at risk, it's the fucking deed- that's not reasuring.

The VPN I left to come to CS (mullvad) had all software updated and all certs/keys reissued within HOURS of the news. You still haven't, and far worse- you chose to allow your customers to keep connecting with the old certs when you do reissue.
I came to CS because after updating openvpn/openssl and my keys/certs, it apeared my connection was being attacked (out of the blue: tls cert mismatchs, keys out of sync, malformed packets, possible replay attacks), later I read a post on HN from the founder of mullvad saying they had succesfully tested a weaponised heartbleed exploit. This week the bsd guys have made over 250 commits to the openssl codebase... I'm not sure how you havn't noticed- but the sky HAS fallen; the security world is in chaos right now and that's not going to change anytime soon.

I now assume my former vpn service has been compromised for months if not years. But honestly with your lack of action on the Ca Cert, I think CS is a step backwards for me. I suspect the current lack of errors from my router just means my router/isp/NSA/cs connection is working flawlessly. If someone more knowlegable is willing to help instruct me how to test that theory, I've got plenty of time/motivation. Thankfully I don't think I'm in a critical use senario at all, so there's no panic here. (the us isn't far enough along it's slow orweillian desent for me to be a real target yet... I'm hopfull it will never get there.)

CS talks the best game in the business- least that's what I thought before reading this thread. if only they'd live up to their hype.

YOU SHOULD FLATLY CUT OFF SERVICE AND RISSUE CERTS. there's no other way to ethically handle this. As a customer I absolutely EXPECT you to cut my conection if there's a known fixable exploit, and of course I expect you to fix it. I expect you to be parinoid (if that's what you'd call this), it really doesn't seam a strech to assume your private Ca Cert is compromised. Also- clearly eplaining known theoretical risks (which CS usually excells at).

Since when can a routing service not route packets- ie: to redirect http connections to a page explaining how to update, and block all other connections.
You don't have a way to reach all your customers??? I call UTTER BULLSHIT on that. I suspect a vlan, and set of simple IPtable commands would do it.

why would you have to retest the server images after a simple (SINGLE!) cert, and subnet change (if thats even needed?)? do you supect the server images themselves are allready compromised? maybe I don't understand how this works...

You have no full time employees- well that explains some things. you should probably put that gem of info on the sign up page- seams like CS is more a passionate hobby then a real viable security/privacy service at this point.

I WANT you guys to succeed, I really do; but this is just piss poor performance on your part- it's seriously fucked up your reputation in my eye's and I doubt I'm the only one. there's no excuse for such lax policy as this.

swap your certs- get on that out-of-band verification (great idea!). get your shit together.

User avatar

ABISprotocol
Posts: 36
Joined: Fri Feb 14, 2014 6:53 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby ABISprotocol » Wed Apr 23, 2014 12:04 am

I'm just gonna go out on a limb here and suggest that reissuing certs might be a good thing. I understand (well, at least I think I do) the Cryptostorm model and how there are ephemeral aspects of it that resist certain problems and issues, but, to get right to the point, I do think that reissuing certs would be good... depending. for example, the cert for this site was issued on 8/13/2013 and expires on 8/16/2014... or so it would seem from a simple peek here, just on the cert for this particular forum in which I am posting. Woudl that cert be good to redo? Possibly so.

But then the question becomes how are cert decisions implemented and I have zero expertise in that regard, and won't pretend to in terms of cert management, tack, pinning and whatnot. I will throw out a few links for reference...

1) Regarding certs generally, I found this to be a pretty good article that seems to approach the issue in a way that I can understand, which is important to me:
https://security.stackexchange.com/ques ... ssl-server
Admittedly the answers on stackexchange are long reads, but a lot of thought went into them. Check them out!

2) Regarding reverse heartbleed which attacks clients as well as servers, really expanding the whole range of vulnerabilities which one might imagine, see: https://reverseheartbleed.com/ (That site hasn't gotten as much traffic as it should.)

3) Tack. I am really curious since I have been mentioning this off and on for longer than I can remember. I don't know what the interest level is in it but I am guessing it's more now than it used to be?
http://tack.io/ (Has internet draft, source code, test server, more shown at the page)

Also, I am still waiting for a reply to my question(s) in the ABIS private subforum. (hint-hint to mods, I'm looking for / waiting for your thoughts. Still.) :D
ABISprotocol ~ https://keybase.io/odinn
PGP 0x6c70abf8a7486f02
http://abis.io


Topic Author
cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby cryptostorm_ops » Wed Apr 23, 2014 5:21 am

Well, I've done my best - along with several colleagues - to explain the relevant distinctions in modeling threats related to the heartbleed vulnerability. Others have explained the upgrade path put in place to cycle all server-side certificate material which, in an abundance of caution, is a step being undertaken to ensure ongoing hardening against second-order threat vectors related to server-side spoofing (often - with varying levels of accuracy - referred to as "MiTM" or, only tangentially related "session hijacking").

I've also done my best to explain the severe routing-based challenges involved in making real-world use of an exploit related to a compromised server-side authentication certificate, although I do think my efforts in this regard have been less than stellar. It's a difficult subject to explain, in mere words, without use of diagrams or topological models to help set the foundational elements in place. The core distinction between packet- and circuit-switched network topologies (at a logical level) is essential in understanding the challenge of mounting a successful server-side spoof in this scenario. Because every packet coming, and going, from the cryptostorm network is hard-coded at the OSI 3 layer with a known-good cryptostorm IP address, a "session hijack" must also entail some mechanism for enabling mis-routing of all packets - coming and going - for a given legitimate session. This is a non-trivial challenge, as anyone familiar with routing mechanics will surely understand.

Beyond these efforts, I am not convinced that further benefit is gained from going back and forth in a "let's all panic" - "well, perhaps not" - cycle. There is a definite lack of technical detail in replies to efforts made in explaining the details of the cryptostorm model as it relates to this particular vulnerability. I know that the mainstream media outlets have jumped on the heartbleed bandwagon to (justifiably, in many cases) hype it as the Next Big Thing... but that doesn't mean that technical professionals suddenly stop caring about the actual packets, actual code, and actual cryptographic foundations of real-world security modelling and deployment. For us, it's still the details that matter - not the generalisations about heartbleed itself.

Finally, let me make one personal observation: Mullvad, like every other "VPN service," had deployed non-PFS asymmetric key exchange before heartbleed hit. Our cryptostorm model has never made this tragic error. In contrast, every "customer" of Mullvad now knows that any and all stored packet traffic - going back several years - is perfectly vulnerable to decryption if anyone bothered to snag the private keys from their servers during this time. I can only imagine that such customers are not sleeping too soundly at this point in time, knowing that their "secure" traffic was - and is - anything but. It's all fine and good that they've now issued new private keys... but those cows left the barn a long time ago. They're out in the field, happily eating grass. Putting new locks on the barn door is more than a bit late.

So, if you - or anyone else - wants to switch to a "VPN service" like Mullvad that has proven themselves incompetent in their selection of cryptographic primitives... well, I can only wish you the best of luck. I would not make such a mistake - but I'm perhaps close enough to the code to fully understand what a catastrophic failure it is to deply poorly-suited cryptographic models in real-world security context. I don't care about the marketing hype, or whether Ars (again) falls for a publicity-hype claim of "proof of concept" code that is not publicly released. What's the CVE on that vaporware, eh?

We, on this team, stand by our work to ensure that real security threats are first and foremost in the priority queue. We stand by our record of making solid decisions about real security threats, before it ends up on the BBC news and it's prime time to hype "fixes" to said threats. Perhaps ironically, we have no "fix" to hype... because we pre-emptively avoided the problem in the first place. In this world - real security systems - avoiding problems is top priority. It doesn't make for good hype in the Ars or HN context, perhaps... but it's what our members expect from us.

And we deliver.

As always, ongoing discussion is appreciated and closely followed by our core tech team. However, repetitive exhortations towards generalised panic aren't, in sum, particularly useful. Just like PoC code that isn't published, vague panic doesn't get anyone in the direction of functionally better security.

We don't live in a world of hype, or marketing-catnip nonsense. We live in the world of reality, and real attacks. It can be frustrating for some folks, I understand, when compared to hype-centric "VPN services" that jump on whatever bandwagon in an attempt to fool customers into trusting them. In our world, trust is earned - not given. We earn trust by avoiding disasters (such as non-PFS crypto in network security deployments), not by bragging about how fast we jump on the bandwagon after they've been exposed by others.

Thank you,

    ~ cryptostorm_admin


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Wed Apr 23, 2014 10:26 am

You posted as I was typing this up-
I'm not sure you're right about the lack of PFS on mullvad- I assume it was comprimised due to key exchange capture rather then due to symetric keys- if I'm not mistaken they're used to start the session, and authenticate each party- it's pfs from there, but if all keys/certs are leaked, at that point it doesn't really matter. fuck now I'm going to have to try and look that up... good job making me feel stupid. and thanks for the pointers. I certainly wasn't making a plug for mullvad- they have weak ciphers, and an outdated setup; I'd been thinking of switching for awhile. I still don't understand the nessessity for all this testing over a cert change. or why you can't notify customers with a simple routing to webpage trick. -I did have a few decent questions in that shitty drunken rant. apoliges for that, and further below.



If I understand correctly- with capable infastructure in place, a compromise of the cryptostorm site server cert would allow a hijack of the site- they could then modify the widgets and config files to impliment a VPN MITM against users who downloaded those configs/widget from that compromised fake instance of the site. Since CS uses standard certificate authorities for their website, rather then self-signed, this same attack could also be done Via fraudulently issed certificates, which presumably nation state level players could get, no compromise nessasary- and reissuing won't help. In this instance, with these lions, and this attack, you really are fucked. This is a tough nut to crack; self signed site certs with out of band conformation could help?- but ironically, users would get a warning from their browsers whenever they loaded the site- making a fake site, look more legit then the real one. I agree with whats been said allready in this thread and elsewhere on the site on this though- it's not an efficent area/means of attack, not as likely as:

Seams to me like the more likely threat is the (self signed iirc) openvpn server cert (which is verified by the openvpn client on the customers computer, via the public ca cert in the vpn client config). If that private cert is compromised, then mounting MITM is trivially easy, again, provided the infastructure is in place (a very safe/likely assumption IMO- though you seam to disagree???). With CS's archetecture, that cert is the ONLY authentication the client has to verify it's really connecting to CS, rather then being silently forwarded (from isp, or end choke point) to an gov box which then decrypts/logs/reencrypts and sends data on it's way to the real CS.

it's not a streach to assume this certificate is compromised, they've had years with heartbleed. ...and on that note- the bsd guys are absolutely gutting openssl now- 150,000+ lines of code removed- there are far far more problems with it then just hartbleed. If you where saying 'Hey, we're not updating our certs yet, because there are surely going to be more critical patches to do soon, and we'd just have to reissue again after that' - That would be a bit more understandable; But it seams like your just pretending there's no real problem- while waxing lyrical about how great your service is, and how open and honest you are. My sincere apologies for the counter-productive venom in my last post, and any in this, but it's shocking to me that your not handling this in a more professional manner. Also- I wish I'd posted somthing more like this post before, rather then the rant- I've been quite frustrated with the world here lately, I was also a bit drunk, but that's no excuse for being a snarky asshole though. Sorry :/

If there's any inacuracies in my posts please point them out- I've tried to be verbose in this post to allow for any such to stick out. for all the time over all the years I've spent trying to learn about this stuff I certainly can't call myself an expert yet.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Wed Apr 23, 2014 11:10 am

Yea, I was right- they do use PFS. but again, if the initial keys/certs were leaked through heartbleed, it wouldn't do much good after the compromise. they also only use a 128bit blowfish cipher for the main stream -seams rather weak.

http://freedomhacker.net/interview-mullvad-vpn/


Regaurdless; I sleep fine.
The 1st, 4th, and 5th arn't quite dead yet; and I would imagine nothing I would do or have done be of much interest to the feds- far far bigger tastier fish to fry. I just want my privacy.


Lignus
Posts: 33
Joined: Sat Nov 02, 2013 1:26 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Lignus » Thu Apr 24, 2014 5:20 am

Guest wrote:But it seams like your just pretending there's no real problem- while waxing lyrical about how great your service is, and how open and honest you are. My sincere apologies for the counter-productive venom in my last post, and any in this, but it's shocking to me that your not handling this in a more professional manner. Also- I wish I'd posted somthing more like this post before, rather then the rant- I've been quite frustrated with the world here lately, I was also a bit drunk, but that's no excuse for being a snarky asshole though. Sorry :/


The reason a compromised ca.crt is only a vector for MiTM is because when, to my understanding of PFS, the client connects to the server, the server does a key exchange with the client using newly generated asymetric keys. These keys are not in any way related to the ca.crt. The 20 minute rekey means that, even if they were able to exploit heartbleed and extract the keys from the server, they would have to do it in that 20 minute window and that key extraction would only be useful for the 20 minutes of traffic that were encrypted with that key. In other words, to capture the plain text of a particular user would mean that they would have to successfully extract they key for that user 72 times, per day. Without PFS, a single extraction per user is all that is required. This means any company not using PFS has left their users so wide open to attack to the point that they may as well have been running no encryption at all when dealing with a determined predator.

The one good that comes out of this whole heartbleed incident is that PFS is now placed in the limelight as being the only real mitigation against this threat. This shines light on the criminal negligence/incompetence of most VPN providers, as they did not use PFS, and may very well be the push that was needed for PFS to become a standard part of HTTPS connections all over the web.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Thu Apr 24, 2014 1:17 pm

The reason a compromised ca.crt is only a vector for MiTM is because when, to my understanding of PFS, the client connects to the server, the server does a key exchange with the client using newly generated asymetric keys. These keys are not in any way related to the ca.crt. The 20 minute rekey means that, even if they were able to exploit heartbleed and extract the keys from the server, they would have to do it in that 20 minute window and that key extraction would only be useful for the 20 minutes of traffic that were encrypted with that key. In other words, to capture the plain text of a particular user would mean that they would have to successfully extract they key for that user 72 times, per day. Without PFS, a single extraction per user is all that is required. This means any company not using PFS has left their users so wide open to attack to the point that they may as well have been running no encryption at all when dealing with a determined predator.


I belive what you said here is correct. Heartbleed didn't just leak keys though- it leaked any and every thing in the systems memory- including certs. Keys encrypt, Certificates authenticate servers to clients. CS has not updated their Certificates (ca.crt)
People keep minimising the idea of MiTM- as if it would be harder. I don't understand why, seams to me it's far more simple.

From an attack perspective, which is easier:
1. sitting bump on the wire (man on the side) style and breaking the whole system packet by packed, and key by key, such as what you described above. (crocodiles- yes, you can probably outrun/avoid them)
2. just creating a fake CS openvpn server, with the official ca.crt and matching config, changing the routing from isp or chokepoint (so CS's IP goes from you to the gov box) and then bridging that to a real CS server session. (here be lions- inception level problems/difficulties)

There's no cracking required in the second senario, no breaking of encryption or keys or session packets required. just some rerouting at a chokepoint, or more likely local isp. It's transperent- neither you nor CS could see it was being done (I think, not 100% here- maybe wouldn't survive genuain scrutiny- but how many people do that?) MiTM isn't hard at all if you have the infastructure and routing authority....and credentials, such as ca.crt when nessasary. In a way- everytime somone connects to my wifi, they are being MiTM'd- the router forwards them through the vpn rather then my local connection- it's not something they have to ask for or configure with their computer. they asked for local IP/DNS, my router tunnels them to a foreign one- "what the hell, why does my computer allways think I'm in sweeden when I'm at your place" In this usage it's obviouly not malicious, and generally not called MiTM, but it's the same sort of technical process I'm reffering to above, minus the illigitimate vpn session forwarded to a real one. my router even has an openvpn server built in and local dns/logging- heck maybe even it could do an attack like this, on my local network, where it has authority.

Elsewhere on this board there was a post or tweet? about a CS server, accepting a known expired token- how did that happen? would proxy athenticating tokens in my hypotetical MiTM be more like to aleart CS to the activity? -I bet the startup would be longer too- maybe easier just to forward to a pre-existing vpn session. enough hypoteticals... you guys would know this stuff better then I.

Maybe it'd be good to hear some factual argument that the government doesn't have (or use) this capability built in, at every isp- but that'd honestly be a hard sell for me. From what I've heard first hand, they've had it for many years- before the snowden leaks, I assumed it was only used case-by-case for serious clear and known legitimate threats- these days that thinking seams nieve at best.

I want to apoligise again for my abismal behavior the other night and the lousy tone it set. I don't want to have an arguement, or bash CS, or make people panic, or plug mullvad, or anything like that... I do think this is a very important issue though, and don't feel satisfied at all with the answers and explainations given in this thread thus far (they set off my... hmm... my wtf sense to put it nicely- maybe I have some misunderstandings though). Mostly the lack of action on cert reissuing, strikes me as really odd.

I've been a fan of you guys since way way back. I know you guys are pioneers in VPN tech/service, I've read your tweets and blogs for many years, and I've heard your pitches so many times that it can't help but sound like marketing to me at this point- good marketing usually. the best kind of marketing- straight up passion for your cause, to the point, fact based, no bs, no hype, no lies or misdirection. this thread feels different. maybe it's me, or maybe I've got you on too much of a pedistal and expect too much.

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Fri Apr 25, 2014 8:19 am

Guest wrote:
Elsewhere on this board there was a post or tweet? about a CS server, accepting a known expired token- how did that happen?
...



Sigh. I'm going to have to do a wee little rant over this in particular, as some devs (including myself) were just working on this issue (thx to the redbull girls for visiting, btw :) )...

We can speak to this little bit of "gee, look at how that flag is hanging, it sure looks like the whole lunar landing is staged!!!!111one" stuff here with the "accepting a known expired token = obviously the NSA is listening now": The exitnodes each work with independent databases filled with basically just SHA512's and start dates and a few other things. We made the databases so that they were not at all valuable if p0wned (not that we skimp on anti-p0wnage) as there is no cust data AT ALL on these exitnodes, etc. as we've mentioned often before and which is sort of an aside to all this stuff... But because of that, the exitnodes do NOT need to communicate in hyper-real-time with any magic central registry of users as most VPN companies do, thus they do NOT stay perfectly in sync as there are very few bits of data they really need from each other in real-time. One exception is the "when was this token started?"

In fact, up until a release planned for tomorrow, there is a bug in which the replication would "fall over" (that's a geek euphemism for "stop communicating") and thus they were kept in sync rather haphazardly with very non-reliable replication. This is why they were accepting a known expired token. There are just a bunch of really stupid and sometimes non-chatty functionally disposable exitnodes talking to no-one except you, the clients.

Please, don't stop questioning the security, but pah-lease do so with facts, and less with - what I'd have to respectfully now call serious stretching for "was it the same cat?". Throwing random speculation like this out just to panic people (unless you're working for HideMySass or whatever they're called and you're getting pissed off at how we're eating at your market share and all that, in which case - ya, I guess that's your job - panic away... ;) )

Thanks!
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

Pattern_Juggled
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am
Contact:

threat modelling

Postby Pattern_Juggled » Fri Apr 25, 2014 8:27 am

I'm taking the liberty of jumping in here, which I hope proves to be constructive.

Speaking personally, I don't see any big issue with the injection of snark into the discussion on occasion. We're all adults here, and when we're passionate about things... well, occasionally snark happens. No capital crime committed, eh? :-P

Your modelling of the genuine MiTM attack vector here is fairly accurate at this point in time: a dual-prong requirement to both compromise underling client-side certificate, as distributed (in order to suborn the otherwise-legitimate routing path embedded in the conf's), and compromise path characteristics for in-transit session traffic. There's some additional steps to ensure that no packets "leak" from within the suborned network session (between client and 'masquerading' cryptostorm exitnode), but compared to the first two these are fairly straightfoward to accomplish.

And to be clear: cryptostorm does not use external CAs for validation/authentication of server-side key materials... neither for exitnodes, nor for hosted website resources. We find nothing in the current CA model that inspires our confidence (watch Moxie Marlinspike's classic YouTube video on the deep structural flaws of the current CA model for an excellent summation), and although self-signing doesn't "fix" these problems, at least it's honest about the brittle nature of the model and thus encourages all of us to work harder on better alternatives (as mentioned earlier in this thread by my colleagues, blockchain-based validation models are where we're focussing our efforts internally, at present).

That said, "only" stealing a self-signed server-side certificate for a given website doesn't enable MiTM by itself: also required is path subversion (usually via some flavour of DNS lookup subversion). Once this is (hypothetically) accomplished the false exitnode certs can be served up. It's worth nothing, however, that public cert materials are widely dispersed for our project; in addition to core website versions, they're posted on our forum and offered via a range of independent token resellers. As such, it's (reasonably) easy to validate that the public cert materials in one's possession are legitimate and not suborned. I know there's work afoot to make that manual validation process easier, more robust, and thus more widely available to a larger slice of the member pool.

Also note that all cryptostorm webserver certificate (and key) materials have long since been hard-cycled, post-heartbleed. So a current check for server cert materials would be reasonably predicted to yield accurate results, even before manual verification. (of course, there's no need to "re-distribute" key materials for webserver certs since this is done dynamically on a per-session/per-visit basis)

As to why it's not trivial to "just issue new certificates" across exitnodes, please remember that we've thousands of members accessing the network, spread across the globe. For many of those members, they have no direct interaction with "cryptostorm" whatsoever (apart from actual network connections): they've purchased tokens via resellers or other channels, which we strongly encourage. We don't know them, and they don't really know us - as it should be. Thus, to "notify" them of newly-issued exitnode public certificate verification materials is... nontrivial. It would be, in theory, possible to interrupt active secure network sessions via packet injection or some such - but that would go against every tenet of our operational philosophy, and will not be done. For this reason, the upgrade to new server-side certificate materials is a process, rather than a one-step event. For traditional "VPN services" that store extensive private information about their "customers," they can just battle-spam their "customers" with new materials (and most are quite happy if "customers" don't connect because their old cert materials suddenly stop working; we have a different view of such matters) and hope for the best.

We don't do much of the "hope" thing, around here. As one of our founding team members often reminds us in staff scrums: "hope is not a plan."

As such, we're spooling out entirely new server-side instances with fully re-issued certificate materials, and then engaging in a monotonic migration process of members from old instances to new instances. To members, this will be essentially transparent: when they upgrade certs (or widget versions), everything "just works" via new instances. As discussed earlier, this is important to us - shoddy UI/UX is commutative with bad security, insofar as it decreases the rate of uptake of otherwise-valid security tools.

(any customer who wants to manually validate the identity of old-version instances can, of course, do so easily via manual ping/traceroute analytics on exitnode path dynamics; if anyone's curious how to do this, let me know and I - or a fellow team member - will be glad to provide a guide)

Finally, as to OpenSSL... it's somewhat au courant nowadays to piss all over the OpenSSL project team, the code itself, and the whole idea of shared cryptographic libraries. This is foolish, mean-spirited, factually inaccurate, and entirely unwise. Anyone who has perused the PolarSSL codebase, for example, will likely understand exactly what outside options exist in terms of widely-supported shared crypto libraries. And, lest anyone think "gee, we'll just hand-roll our own crypto libraries for our project"... well, down that path lies madness. And tragic crypto flaws. And endless security fails.

In this analysis, I defer as is so often the case to Dr. Matthew Green of Johns Hopkins. Dr. Green observes that...

"Should we rail against the OpenSSL developers for this? Dont even think about it. The OpenSSL team, which is surprisingly small, has been given the taks of maintaing the world's most popular TLS library. It's a hard job with essentially no pay. It involves taking other folks' code (as in the case of Heartbeat) and doing a best-possible job of reviewing it. Then you hope others will notice it and disclose it responsbily before disasters happen... [t]he OpenSSL developers have a pretty amazing record cosidering the amoutn of use this library gets and the quantity of legacy cruft and the number of platforms (over eighty!) they have to support."


What we could all stand to do, rather than engaging in public flagellation of a hardworking and, as Dr. Green points out, largely quite successful, volunteer project team is to help out with code review! This isn't something for "someone else" to do - it's us, and we can (and should) be doing it. Anyone with a decent working knowledge of C can pitch in usefully, and the OpenSSL project team is known (rightly) for a constructive, open, friendly attitude towards new contributors (this isn't Wikipedia with its snarky, insiders-only, pathological project culture in other words). Grab a relatively un-reviewed chunk from Github, take it apart, poke at it, ask others if your analysis looks correct... and share back what you find.

The whole idea of opensource projects such as this is that we all pitch in: many eyes, and many reviews, means that an intentional (or accidental) subversion of security via a bug is less likely to remain active over time, ceteris paribus.

Personally, this reminds me when Nadim was mercilessly abused for not "catching" bugs in the Cryptocat codebase... code that had been nicely, professionally, and consistently pushed to public visibility since the day it was launched. Sure, it'd be great if Nadim (or anyone else) was a Perfect Coder - making no mistakes, avoiding all (after the fact) "obvious bugs" - but in reality nobody's perfect (except, perhaps, Moxie :-) ). We all failed to spot those bugs in the Cryptocat code: it's not uniquely "Nadim's fault" they were there; it's our fault that we, as a community, failed to do enough solid code review to catch them earlier.

Well, there's my oblique commentary on OpenSSL, fwiw.

Cheers,

    ~ pj

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Fri Apr 25, 2014 10:17 pm

After much discussion, we've heard you.

We're going to expedite this as best we can.

There are issues, obviously (we're going to have to prepare for an influx of support requests for those unaware, I suspect) but we'll try to get this done ASAP.

Apologies that we've put it off, but my understanding is that the intent was to make it a more painless experience for the users so we wanted a controlled and thoughtful rollout - there is a tension here between customer experience and security, and as you've pointed out, our reason for existence is more about the latter than the former.

We will keep you informed.

Thanks again, and again apologies for the delay.
G
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Fri Apr 25, 2014 10:53 pm

Here's some info for anyone who wants to be a beta tester:

There's an instance now on bruno that's using 174.142.78.195 along with new certs. The client will have to use the new client certs I put up @ newclientcerts.zip (the files there are named ca2.crt, clientgeneric2.crt, clientgeneric2.key). So for clients to be able to use that new instance ASAP, they'll have to mod their .conf to use those files instead of the old ca.crt & clientgeneric.crt/key. I just tested it and seems to work fine, even with the widget (once you manually grab the new certs and put them in \user and change the vpn to use the 174.142.78.195 IP.)


Thanks!
G
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

severide
Posts: 27
Joined: Sun Nov 10, 2013 1:09 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby severide » Sat Apr 26, 2014 2:37 am

Graze wrote:Here's some info for anyone who wants to be a beta tester:

There's an instance now on bruno that's using 174.142.78.195 along with new certs. The client will have to use the new client certs I put up @ newclientcerts.zip (the files there are named ca2.crt, clientgeneric2.crt, clientgeneric2.key). So for clients to be able to use that new instance ASAP, they'll have to mod their .conf to use those files instead of the old ca.crt & clientgeneric.crt/key. I just tested it and seems to work fine, even with the widget (once you manually grab the new certs and put them in \user and change the vpn to use the 174.142.78.195 IP.)


Thanks!
G


Alright I've done it and it seems to be working just fine.
cryptofree via iOS
CS Node List
CS Wiki maintained by vpnDarknet
PGP
Bitmessage: BM-2cUCkRBnNEhhW3qyNoEpRK6LtQjUs281wT


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Sat Apr 26, 2014 7:10 pm

Hi Graze and everyone!
I can't get around posting here sooner or later, can I? :P

Other than you two I am able to connect to the new instance but I can't route any traffic through it.
I tried everything: Using terminal, using openvpn autoconnect (by placing the config and certs into /etc/openvpn/ and telling the config where it can find the certs and the password) and using Ubuntu Networt-Manager Plugin.

I must go wrong somewhere but I don't know where. Does the new instance has an other exit IP than 174.142.78.195 so it conflicts with my leakblock?
I just realize that I should create some log files to present here. Will do so later.

Any ideas in the meantime?


PS: I know it's an awfully bad time to ask such a question but I realized that OpenVPN (or just Networ-Manager?) offers a new cipher type: AES-256-CBC-HMAC-SHA1 with HMAC-Authentication SHA512. Currently we use "just" AES-256-CBC with HMAC-Auth SHA512. tbh this confuses me. Doesn't such a setting contradict itself?! Could you forward this to a Techno(black)mage and ask him to comment about this? Thanks. :)


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Sat Apr 26, 2014 7:40 pm

Code: Select all

Sat Apr 26 16:23:06 2014 us=57309 Current Parameter Settings:
Sat Apr 26 16:23:06 2014 us=57353 NOTE: --mute triggered...
Sat Apr 26 16:23:06 2014 us=57381 273 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:06 2014 us=57388 OpenVPN 2.3.3 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [EPOLL] [PKCS11] [MH] [IPv6] built on Apr 10 2014
Sat Apr 26 16:23:06 2014 us=102345 LZO compression initialized
Sat Apr 26 16:23:06 2014 us=102401 Control Channel MTU parms [ L:1602 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sat Apr 26 16:23:06 2014 us=102424 Socket Buffers: R=[212992->212992] S=[212992->212992]
Sat Apr 26 16:23:06 2014 us=102441 Data Channel MTU parms [ L:1602 D:1400 EF:102 EB:135 ET:0 EL:0 AF:3/1 ]
Sat Apr 26 16:23:06 2014 us=102454 Local Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Sat Apr 26 16:23:06 2014 us=102460 NOTE: --mute triggered...
Sat Apr 26 16:23:06 2014 us=102464 1 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:06 2014 us=102478 Local Options hash (VER=V4): '9c102b00'
Sat Apr 26 16:23:06 2014 us=102483 NOTE: --mute triggered...
Sat Apr 26 16:23:06 2014 us=102761 1 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:06 2014 us=102795 UDPv4 link local: [undef]
Sat Apr 26 16:23:06 2014 us=102828 UDPv4 link remote: [AF_INET]174.142.78.195:443
WSat Apr 26 16:23:06 2014 us=102942 write UDPv4: Network is unreachable (code=101)
WRSat Apr 26 16:23:08 2014 us=507874 TLS: Initial packet from [AF_INET]174.142.78.195:443, sid=22b73ef3 c4339220
WSat Apr 26 16:23:08 2014 us=507925 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
WRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRSat Apr 26 16:23:09 2014 us=253553 VERIFY OK: depth=1, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
Sat Apr 26 16:23:09 2014 us=253706 NOTE: --mute triggered...
WRWRWRWRWRWRWRWRWWWWRRRRWWWWRWRWRRRRWRWRSat Apr 26 16:23:09 2014 us=914191 2 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:09 2014 us=914208 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Sat Apr 26 16:23:09 2014 us=914237 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
Sat Apr 26 16:23:09 2014 us=914315 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sat Apr 26 16:23:09 2014 us=914324 NOTE: --mute triggered...
WSat Apr 26 16:23:09 2014 us=914368 4 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:09 2014 us=914374 [server] Peer Connection Initiated with [AF_INET]174.142.78.195:443
Sat Apr 26 16:23:12 2014 us=212729 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
WRRWRWRWRSat Apr 26 16:23:12 2014 us=323691 NOTE: --mute triggered...
Sat Apr 26 16:23:12 2014 us=324006 7 variation(s) on previous 1 message(s) suppressed by --mute
Sat Apr 26 16:23:12 2014 us=324019 TUN/TAP device tun0 opened
Sat Apr 26 16:23:12 2014 us=324032 TUN/TAP TX queue length set to 686
Sat Apr 26 16:23:12 2014 us=324048 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Sat Apr 26 16:23:12 2014 us=324770 /sbin/ifconfig tun0 10.44.0.3 netmask 255.255.0.0 mtu 1500 broadcast 10.44.255.255
Sat Apr 26 16:23:12 2014 us=326504 /sbin/route add -net 174.142.78.195 netmask 255.255.255.255 gw 192.168.1.1
Sat Apr 26 16:23:12 2014 us=527049 /sbin/route add -net 0.0.0.0 netmask 128.0.0.0 gw 10.44.0.1
Sat Apr 26 16:23:12 2014 us=527609 /sbin/route add -net 128.0.0.0 netmask 128.0.0.0 gw 10.44.0.1
Sat Apr 26 16:23:12 2014 us=562657 Initialization Sequence Completed
WrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWRrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWRrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWrWRSat Apr 26 16:24:12 2014 us=65842 [server] Inactivity timeout (--ping-restart), restarting
Sat Apr 26 16:24:12 2014 us=66065 TCP/UDP: Closing socket
Sat Apr 26 16:24:12 2014 us=66111 SIGUSR1[soft,ping-restart] received, process restarting
Sat Apr 26 16:24:12 2014 us=66136 Restart pause, 2 second(s)
Sat Apr 26 16:24:14 2014 us=66230 Re-using SSL/TLS context
Sat Apr 26 16:24:14 2014 us=66292 NOTE: --mute triggered...


And exactly this repeats over and over.

Some problems to catch my attention are:

Code: Select all

WSat Apr 26 16:23:06 2014 us=102942 write UDPv4: Network is unreachable (code=101)

Sat Apr 26 16:23:09 2014 us=914208 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
Sat Apr 26 16:23:09 2014 us=914237 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'

Apr 26 16:24:12 2014 us=65842 [server] Inactivity timeout (--ping-restart), restarting



Also: Whats with all this WrWrWrWr stuff?!

User avatar

vpnDarknet
Posts: 128
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby vpnDarknet » Sun Apr 27, 2014 3:37 am

Welcome back Desu!

I've had success connecting to Montreal via the new instance, all working as expected... although I don't have a sophisticated firewall leakblock setup

Ubuntu Networt-Manager has not been working great for me lately, upgrade to 14.04 issues maybe?
I dropped the files into /etc/openvpn and the usual:
sudo openvpn --config newdynamic.conf
plus credentials seems to have worked.

Traceroute returns one hop from 174.142.78.195, seems to be working
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Sun Apr 27, 2014 5:08 am

Thanks, but it won't be for long though. But this situation is really exceptional and I do follow it closesly from day one. I'm happy that other people took over and are really supportive and active on the forums. I bet everyone knows who I mean and I don't have to say names. :)

Back to topic:
I tried your approach as well and it didn't work... :\
This is my config for the new instance. Do you see any mistakes?

Code: Select all

client
dev tun
resolv-retry 16
nobind
float

txqueuelen 686

sndbuf size 1655368
rcvbuf size 1655368


remote 174.142.78.195 443


comp-lzo no

down-pre

allow-pull-fqdn

explicit-exit-notify 3

hand-window 37

mssfix 1400

auth-user-pass password

ca /etc/openvpn/ca2.crt

cert /etc/openvpn/clientgeneric2.crt

key /etc/openvpn/clientgeneric2.key

ns-cert-type server

auth SHA512

cipher AES-256-CBC

replay-window 128 30

tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA

tls-client
key-method 2

log devnull.txt
verb 5
mute 1



For quick reference: Those are the only lines I changed from the old Montreal config:

Code: Select all

remote 174.142.78.195 443
# New IP with Port 443 that is always used by CS.

auth-user-pass password
# path to the file with password&username. Works perfect with old config.

ca /etc/openvpn/ca2.crt
cert /etc/openvpn/clientgeneric2.crt
key /etc/openvpn/clientgeneric2.key
# paths to the new cert/key files.


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Sun Apr 27, 2014 2:59 pm

Here's the Android log:

Code: Select all

2014-04-27 11:49:15 Running on Nexus 4 (MAKO) google, Android API 17, version 0.6.11, official build
2014-04-27 11:49:15 Log cleared.
2014-04-27 11:49:18 Building configuration…
2014-04-27 11:49:21 started Socket Thread
2014-04-27 11:49:21 P:Initializing Google Breakpad!
2014-04-27 11:49:21 Current Parameter Settings:
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 182 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 OpenVPN 2.4-icsopenvpn [git:icsopenvpn_70-078981e61dfdf105] android-14-armeabi-v7a [SSL (OpenSSL)] [LZO] [SNAPPY] [LZ4] [EPOLL] [MH] [IPv6] built on Mar 12 2014
2014-04-27 11:49:21 MANAGEMENT: Connected to management server at /data/data/de.blinkt.openvpn/cache/mgmtsocket
2014-04-27 11:49:21 Network Status: CONNECTED  to WIFI
2014-04-27 11:49:21 MANAGEMENT: CMD 'hold release'
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 4 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 LZO compression initializing
2014-04-27 11:49:21 Control Channel MTU parms [ L:1602 D:138 EF:38 EB:0 ET:0 EL:0 ]
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 Local Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 Local Options hash (VER=V4): '9c102b00'
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 TCP/UDP: Preserving recently used remote address: [AF_INET]174.142.78.195:443
2014-04-27 11:49:21 Socket Buffers: R=[163840->163840] S=[163840->163840]
2014-04-27 11:49:21 Protecting socket fd 4
2014-04-27 11:49:21 MANAGEMENT: CMD 'needok 'PROTECTFD' ok'
2014-04-27 11:49:21 UDP link local: (not bound)
2014-04-27 11:49:21 UDP link remote: [AF_INET]174.142.78.195:443
2014-04-27 11:49:21 MANAGEMENT: >STATE:1398592161,WAIT,,,
2014-04-27 11:49:21 NOTE: --mute triggered...
2014-04-27 11:49:21 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:21 TLS: Initial packet from [AF_INET]174.142.78.195:443, sid=b47e3888 9fdc7e0f
2014-04-27 11:49:21 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
2014-04-27 11:49:23 VERIFY OK: depth=1, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
2014-04-27 11:49:23 NOTE: --mute triggered...
2014-04-27 11:49:24 8 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:24 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
2014-04-27 11:49:24 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
2014-04-27 11:49:24 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2014-04-27 11:49:24 NOTE: --mute triggered...
2014-04-27 11:49:24 4 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:24 [server] Peer Connection Initiated with [AF_INET]174.142.78.195:443
2014-04-27 11:49:25 MANAGEMENT: >STATE:1398592165,GET_CONFIG,,,
2014-04-27 11:49:26 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2014-04-27 11:49:26 NOTE: --mute triggered...
2014-04-27 11:49:26 7 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:26 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=98:d6:f7:61:0b:fc
2014-04-27 11:49:26 ROUTE6: default_gateway=UNDEF
2014-04-27 11:49:26 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2014-04-27 11:49:26 OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/0
2014-04-27 11:49:26 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2014-04-27 11:49:26 MANAGEMENT: >STATE:1398592166,ASSIGN_IP,,10.44.0.3,
2014-04-27 11:49:26 MANAGEMENT: CMD 'needok 'IFCONFIG' ok'
2014-04-27 11:49:26 NOTE: --mute triggered...
2014-04-27 11:49:26 2 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:26 MANAGEMENT: >STATE:1398592166,ADD_ROUTES,,,
2014-04-27 11:49:26 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2014-04-27 11:49:26 NOTE: --mute triggered...
2014-04-27 11:49:26 Opening tun interface:
2014-04-27 11:49:26 Local IPv4: 10.44.0.3/16 IPv6: null MTU: 1500
2014-04-27 11:49:26 DNS Server: 198.100.146.51, 76.74.205.228, 91.191.136.152, 213.73.91.35, Domain: null
2014-04-27 11:49:27 Routes: 0.0.0.0/1, 0.0.0.0/0, 128.0.0.0/1, 192.168.1.0/25, 192.168.1.128/25
2014-04-27 11:49:27 Routes excluded: 
2014-04-27 11:49:27 VpnService routes installed: 0.0.0.0/0, 0.0.0.0/1, 128.0.0.0/1, 192.168.1.0/25, 192.168.1.128/25
2014-04-27 11:49:27 8 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:49:27 Initialization Sequence Completed
2014-04-27 11:49:27 MANAGEMENT: >STATE:1398592167,CONNECTED,SUCCESS,10.44.0.3,174.142.78.195
2014-04-27 11:49:46 Bad LZO decompression header byte: 0
2014-04-27 11:50:06 NOTE: --mute triggered...
2014-04-27 11:50:26 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 [server] Inactivity timeout (--ping-restart), restarting
2014-04-27 11:50:26 TCP/UDP: Closing socket
2014-04-27 11:50:26 SIGUSR1[soft,ping-restart] received, process restarting
2014-04-27 11:50:26 MANAGEMENT: >STATE:1398592226,RECONNECTING,ping-restart,,
2014-04-27 11:50:26 MANAGEMENT: CMD 'hold release'
2014-04-27 11:50:26 Re-using SSL/TLS context
2014-04-27 11:50:26 NOTE: --mute triggered...
2014-04-27 11:50:26 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 Control Channel MTU parms [ L:1602 D:138 EF:38 EB:0 ET:0 EL:0 ]
2014-04-27 11:50:26 NOTE: --mute triggered...
2014-04-27 11:50:26 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 Local Options String: 'V4,dev-type tun,link-mtu 1602,tun-mtu 1500,proto UDPv4,comp-lzo,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
2014-04-27 11:50:26 NOTE: --mute triggered...
2014-04-27 11:50:26 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 Local Options hash (VER=V4): '9c102b00'
2014-04-27 11:50:26 NOTE: --mute triggered...
2014-04-27 11:50:26 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 TCP/UDP: Preserving recently used remote address: [AF_INET]174.142.78.195:443
2014-04-27 11:50:26 Socket Buffers: R=[163840->163840] S=[163840->163840]
2014-04-27 11:50:26 Protecting socket fd 4
2014-04-27 11:50:26 MANAGEMENT: CMD 'bytecount 2'
2014-04-27 11:50:26 NOTE: --mute triggered...
2014-04-27 11:50:26 2 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:26 UDP link local: (not bound)
2014-04-27 11:50:26 UDP link remote: [AF_INET]174.142.78.195:443
2014-04-27 11:50:26 MANAGEMENT: >STATE:1398592226,WAIT,,,
2014-04-27 11:50:27 NOTE: --mute triggered...
2014-04-27 11:50:27 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:27 TLS: Initial packet from [AF_INET]174.142.78.195:443, sid=6c0b2542 7ba870c6
2014-04-27 11:50:28 NOTE: --mute triggered...
2014-04-27 11:50:31 9 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:31 WARNING: 'link-mtu' is used inconsistently, local='link-mtu 1602', remote='link-mtu 1606'
2014-04-27 11:50:31 WARNING: 'mtu-dynamic' is present in remote config but missing in local config, remote='mtu-dynamic'
2014-04-27 11:50:31 Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
2014-04-27 11:50:31 NOTE: --mute triggered...
2014-04-27 11:50:31 4 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:31 [server] Peer Connection Initiated with [AF_INET]174.142.78.195:443
2014-04-27 11:50:32 MANAGEMENT: >STATE:1398592232,GET_CONFIG,,,
2014-04-27 11:50:34 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
2014-04-27 11:50:34 NOTE: --mute triggered...
2014-04-27 11:50:34 7 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:34 ROUTE_GATEWAY 192.168.1.1/255.255.255.0 IFACE=wlan0 HWADDR=98:d6:f7:61:0b:fc
2014-04-27 11:50:34 ROUTE6: default_gateway=UNDEF
2014-04-27 11:50:34 OpenVPN ROUTE6: OpenVPN needs a gateway parameter for a --route-ipv6 option and no default was specified by either --route-ipv6-gateway or --ifconfig-ipv6 options
2014-04-27 11:50:34 OpenVPN ROUTE: failed to parse/resolve route for host/network: ::/0
2014-04-27 11:50:34 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
2014-04-27 11:50:34 MANAGEMENT: >STATE:1398592234,ASSIGN_IP,,10.44.0.4,
2014-04-27 11:50:34 MANAGEMENT: CMD 'needok 'IFCONFIG' ok'
2014-04-27 11:50:34 NOTE: --mute triggered...
2014-04-27 11:50:34 2 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:34 MANAGEMENT: >STATE:1398592234,ADD_ROUTES,,,
2014-04-27 11:50:34 MANAGEMENT: CMD 'needok 'ROUTE' ok'
2014-04-27 11:50:34 NOTE: --mute triggered...
2014-04-27 11:50:34 Opening tun interface:
2014-04-27 11:50:34 Local IPv4: 10.44.0.4/16 IPv6: null MTU: 1500
2014-04-27 11:50:34 DNS Server: 198.100.146.51, 76.74.205.228, 91.191.136.152, 213.73.91.35, Domain: null
2014-04-27 11:50:34 Routes: 0.0.0.0/1, 0.0.0.0/0, 128.0.0.0/1, 192.168.1.0/25, 192.168.1.128/25
2014-04-27 11:50:34 Routes excluded: 
2014-04-27 11:50:34 VpnService routes installed: 0.0.0.0/0, 0.0.0.0/1, 128.0.0.0/1, 192.168.1.0/25, 192.168.1.128/25
2014-04-27 11:50:35 8 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:35 Initialization Sequence Completed
2014-04-27 11:50:35 MANAGEMENT: >STATE:1398592235,CONNECTED,SUCCESS,10.44.0.4,174.142.78.195
2014-04-27 11:50:41 MANAGEMENT: CMD 'signal SIGINT'
2014-04-27 11:50:41 SIGTERM received, sending exit notification to peer
2014-04-27 11:50:41 MANAGEMENT: Client disconnected
2014-04-27 11:50:41 NOTE: --mute triggered...
2014-04-27 11:50:41 1 variation(s) on previous 1 message(s) suppressed by --mute
2014-04-27 11:50:41 TCP/UDP: Closing socket
2014-04-27 11:50:41 Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.
2014-04-27 11:50:41 Sorry, deleting routes on Android is not possible. The VpnService API allows routes to be set on connect only.
2014-04-27 11:50:41 Closing TUN/TAP interface
2014-04-27 11:50:42 SIGTERM[soft,management-exit] received, process exiting
2014-04-27 11:50:42 MANAGEMENT: >STATE:1398592242,EXITING,management-exit,,


And the config I used:

Code: Select all

# Enables connection to GUI
management /data/data/de.blinkt.openvpn/cache/mgmtsocket unix
management-client
management-query-passwords
management-hold

setenv IV_GUI_VER "de.blinkt.openvpn 0.6.11"
machine-readable-output
client
verb 4
connect-retry 5
resolv-retry 60
dev tun
remote 174.142.78.195 433 udp
auth-user-pass
<ca>
-----BEGIN CERTIFICATE-----
MIIFHjCCBAagAwIBAgIJAKekpGXxXvhbMA0GCSqGSIb3DQEBCwUAMIG6MQswCQYD
VQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcTCE1vbnRyZWFsMTYwNAYDVQQK
FC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNyeXB0b3N0b3JtX2RhcmtuZXQx
ETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5jcnlwdG9zdG9ybV9pczEnMCUG
CSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0b3JtLmlzMB4XDTE0MDQyNTE3
MTAxNVoXDTE3MTIyMjE3MTAxNVowgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJR
QzERMA8GA1UEBxMITW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBM
aW1pdGUgLyAgY3J5cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMx
FzAVBgNVBAMUDmNyeXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRt
aW5AY3J5cHRvc3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB
AQDJaOSYIX/sm+4/OkCgyAPYB/VPjDo9YBc+zznKGxd1F8fAkeqcuPpGNCxMBLOu
mLsBdxLdR2sppK8cu9kYx6g+fBUQtShoOj84Q6+n6F4DqbjsHlLwUy0ulkeQWk1v
vKKkpBViGVFsZ5ODdZ6caJ2UY2C41OACTQdblCqaebsLQvp/VGKTWdh9UsGQ3LaS
Tcxt0PskqpGiWEUeOGG3mKE0KWyvxt6Ox9is9QbDXJOYdklQaPX9yUuII03Gj3xm
+vi6q2vzD5VymOeTMyky7Geatbd2U459Lwzu/g+8V6EQl8qvWrXESX/ZXZvNG8QA
cOXU4ktNBOoZtws6TzknpQF3AgMBAAGjggEjMIIBHzAdBgNVHQ4EFgQUOFjh918z
L4vR8x1q3vkp6npwUSUwge8GA1UdIwSB5zCB5IAUOFjh918zL4vR8x1q3vkp6npw
USWhgcCkgb0wgboxCzAJBgNVBAYTAkNBMQswCQYDVQQIEwJRQzERMA8GA1UEBxMI
TW9udHJlYWwxNjA0BgNVBAoULUthdGFuYSBIb2xkaW5ncyBMaW1pdGUgLyAgY3J5
cHRvc3Rvcm1fZGFya25ldDERMA8GA1UECxMIVGVjaCBPcHMxFzAVBgNVBAMUDmNy
eXB0b3N0b3JtX2lzMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRvc3Rv
cm0uaXOCCQCnpKRl8V74WzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IB
AQAK6B7AOEqbaYjXoyhXeWK1NjpcCLCuRcwhMSvf+gVfrcMsJ5ySTHg5iR1/LFay
IEGFsOFEpoNkY4H5UqLnBByzFp55nYwqJUmLqa/nfIc0vfiXL5rFZLao0npLrTr/
inF/hecIghLGVDeVcC24uIdgfMr3Z/EXSpUxvFLGE7ELlsnmpYBxm0rf7s9S9wtH
o6PjBpb9iurF7KxDjoXsIgHmYAEnI4+rrArQqn7ny4vgvXE1xfAkFPWR8Ty1ZlxZ
gEyypTkIWhphdHLSdifoOqo83snmCObHgyHG2zo4njXGExQhxS1ywPvZJRt7fhjn
X03mQP3ssBs2YRNR5hR5cMdC
-----END CERTIFICATE-----

</ca>
<key>
-----BEGIN PRIVATE KEY-----
MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDUromepwJM/suI
tyY82WIngO5A+jlrMWnP7WkpjLKKDh8KBRPj/M2Jw75llOEJqk3PEWKUlPVOyb7/
aNjbs9kHqYlmTUvgYEN9e7QcAoHkyFv1gVpv9NFQFDweLmfc6RgNmf+iOkmJ76Mr
p6uXmnZSDC16xtWRnJ3S+nprq05w/JlTSaAd/REGmJL1P3S4oamJYpdTtltPzYw0
//vF8byHLI6hs0JIDkjgDrfOExrND4M1d/WO1Mb5B+8+i+z7lI0VYJ22mdgPTTXq
pmA94o4qAMjNqZAaE44QsvYmf0fEqbhQihkhe6CmISGn4MpS6Xnrr3xiUQPZavsB
i7El/NeZAgMBAAECggEBAMjMPMxYW5i8Gwfp+yUKDFzFoqwgUuO8lG0mddovp0Um
jfGU17GxtZCzCWi4xjqs2qd8f3lOpcgMO9LCd7P+OhK84yd+JPwjhrTLfUHQsDiD
XicNSIhZOOGFKTlJkPAF9pqo4ayVoWakpIaL2DrbL4jJTIsVfP/sQSm3KKvM4dNT
QPbTltFGZvbMDxbEdhiKlAaRCogAHLkcWl0+3BglNU0+wHdPxesIrLafJ/HIK5mg
H/nS1MXRCJXi/Ol79iFCanvaVKGvDRHc9o02iRpZkiwZQgQ6XWxrJ0nxedJQmvgF
k6ne+TiLE7SZ3xI4c7ZrQgaQvhEzhcz+Ac+Xuui1KAECgYEA7Xjo1mbAvzQBN0TB
lh8tqFis4ISdTbIqeQfhQeSXjoLuYtFpjrtBhNmjWv30BIZXYy0PIAISpcT2lInP
NqpmXQQwtKbgvla3aqAlsv3kmLcj/o5UUi8c9Db24AdO2vhmQc0Hksl1Xkc3b5H1
/R9WHbJh2MvoaGu4/o4k7UOu3QECgYEA5UZ7MbNw1IaL1PgOxOojLb/K1tDGZMwu
oXVDMhVYa2WTCLUu1zCstdyTFDkXG8vdfcxhkyNfN0GEGeAjg910sI5p71//aGsa
uejAsFuMXGNN3S2R1L0IK2LqGV/qprGXfXu7rIeYQPUEv0VjIyoKApBEh7CAJyZN
MTdkBi8AwpkCgYAGSlWgmEgyyGXf2Opn15uWAgNSTzD7heSqIBNPc4awN7eo1nM9
XKh3pGw3VNLJ6+UUs3TbHDLyQS1m8d+TSyA7Boljv6fkYteo82UMQL11biR98bc6
FhVmQq53cLoeAsZyp8Ozl7KMNMa7JdqmQdY+IyOEYqJdYb0cwRcpUcmoAQKBgB3a
/bPNIAYstwy2eIXfz1DnxqwOZ6c8h13y/RsKeIcTpP/fSAgxiGvuGyDpBj9SXrdA
4/vbAU0atO8Bpt5G+ij7goPvRjz8pXBMBLtyUGa/b6Y7ht/i9atgqAdB3DZ0rbtj
X17qEUN0JHgbuvsbQE5xJttcenOeozKjedzsRfcRAoGAN1Bsr9OgCSB8Gy3Nsu4T
glYYpJSWOufG6fRZ+s4PHgKzzWrM5lyy/CnbXtQxb1KAJjZ6iSymsThF4zSJ6nlA
jDDxDO1gAhN6jOQxO8fpxcngUG2tPXsVCxuNY8nhmAyZB/lbE3qMFzxxcRk+9BG/
yUpn9Ld29egm4sSj47+tS1k=
-----END PRIVATE KEY-----

</key>
<cert>
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 2 (0x2)
    Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is/emailAddress=certadmin@cryptostorm.is
        Validity
            Not Before: Apr 25 17:12:33 2014 GMT
            Not After : Dec 22 17:12:33 2017 GMT
        Subject: C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=clientgeneric/emailAddress=certadmin@cryptostorm.is
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:d4:ae:89:9e:a7:02:4c:fe:cb:88:b7:26:3c:d9:
                    62:27:80:ee:40:fa:39:6b:31:69:cf:ed:69:29:8c:
                    b2:8a:0e:1f:0a:05:13:e3:fc:cd:89:c3:be:65:94:
                    e1:09:aa:4d:cf:11:62:94:94:f5:4e:c9:be:ff:68:
                    d8:db:b3:d9:07:a9:89:66:4d:4b:e0:60:43:7d:7b:
                    b4:1c:02:81:e4:c8:5b:f5:81:5a:6f:f4:d1:50:14:
                    3c:1e:2e:67:dc:e9:18:0d:99:ff:a2:3a:49:89:ef:
                    a3:2b:a7:ab:97:9a:76:52:0c:2d:7a:c6:d5:91:9c:
                    9d:d2:fa:7a:6b:ab:4e:70:fc:99:53:49:a0:1d:fd:
                    11:06:98:92:f5:3f:74:b8:a1:a9:89:62:97:53:b6:
                    5b:4f:cd:8c:34:ff:fb:c5:f1:bc:87:2c:8e:a1:b3:
                    42:48:0e:48:e0:0e:b7:ce:13:1a:cd:0f:83:35:77:
                    f5:8e:d4:c6:f9:07:ef:3e:8b:ec:fb:94:8d:15:60:
                    9d:b6:99:d8:0f:4d:35:ea:a6:60:3d:e2:8e:2a:00:
                    c8:cd:a9:90:1a:13:8e:10:b2:f6:26:7f:47:c4:a9:
                    b8:50:8a:19:21:7b:a0:a6:21:21:a7:e0:ca:52:e9:
                    79:eb:af:7c:62:51:03:d9:6a:fb:01:8b:b1:25:fc:
                    d7:99
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            Netscape Comment:
                Easy-RSA Generated Certificate
            X509v3 Subject Key Identifier:
                A7:F4:C0:57:73:F8:B7:14:17:2B:28:20:C7:42:02:10:2A:20:40:9A
            X509v3 Authority Key Identifier:
                keyid:38:58:E1:F7:5F:33:2F:8B:D1:F3:1D:6A:DE:F9:29:EA:7A:70:51:25
                DirName:/C=CA/ST=QC/L=Montreal/O=Katana Holdings Limite /  cryptostorm_darknet/OU=Tech Ops/CN=cryptostorm_is/emailAddress=certadmin@cryptostorm.is
                serial:A7:A4:A4:65:F1:5E:F8:5B

            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Key Usage:
                Digital Signature
    Signature Algorithm: sha256WithRSAEncryption
         4a:b9:22:15:07:1d:70:10:b1:bd:0d:e5:3b:9a:9d:a8:57:72:
         02:f0:c2:bb:d9:ce:86:e9:f4:21:6d:88:fb:25:e9:30:b9:57:
         6d:51:ad:dc:bd:ca:83:0f:2f:5f:5e:58:a1:4b:6e:05:eb:5b:
         44:b7:b3:ab:cf:bc:23:3b:92:ae:70:52:41:0e:30:72:fb:08:
         d2:2d:82:91:7f:40:9f:54:d7:63:21:d2:8e:ed:2e:f4:dc:4d:
         e9:ae:64:bc:84:87:65:fe:3f:74:22:52:d7:88:a9:77:e3:ec:
         f6:68:e4:48:c7:2f:04:b7:84:7b:a1:40:b9:44:bc:1d:5b:69:
         65:85:20:1c:91:04:90:67:e4:65:cb:5d:4c:f8:9a:1c:65:03:
         3f:a6:22:46:7f:09:a0:e6:09:1d:1a:54:40:2d:39:6a:57:f0:
         76:ca:3e:bf:62:e8:5c:4e:e1:c8:37:71:ca:7c:e5:14:4c:ef:
         fa:ca:ef:77:6d:36:8a:85:cc:6d:cc:b8:0c:2a:ef:ba:03:32:
         71:53:24:19:92:b3:42:22:c9:c6:17:1d:64:4d:ce:da:77:01:
         48:ed:32:15:92:51:1b:f9:42:18:8a:43:8e:c2:66:8e:b5:24:
         c5:12:14:99:0f:98:9d:81:30:2e:37:a9:24:85:4e:3c:70:97:
         f3:ac:3c:2f
-----BEGIN CERTIFICATE-----
MIIFYzCCBEugAwIBAgIBAjANBgkqhkiG9w0BAQsFADCBujELMAkGA1UEBhMCQ0Ex
CzAJBgNVBAgTAlFDMREwDwYDVQQHEwhNb250cmVhbDE2MDQGA1UEChQtS2F0YW5h
IEhvbGRpbmdzIExpbWl0ZSAvICBjcnlwdG9zdG9ybV9kYXJrbmV0MREwDwYDVQQL
EwhUZWNoIE9wczEXMBUGA1UEAxQOY3J5cHRvc3Rvcm1faXMxJzAlBgkqhkiG9w0B
CQEWGGNlcnRhZG1pbkBjcnlwdG9zdG9ybS5pczAeFw0xNDA0MjUxNzEyMzNaFw0x
NzEyMjIxNzEyMzNaMIG5MQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNV
BAcTCE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8g
IGNyeXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2ggT3BzMRYwFAYDVQQD
Ew1jbGllbnRnZW5lcmljMScwJQYJKoZIhvcNAQkBFhhjZXJ0YWRtaW5AY3J5cHRv
c3Rvcm0uaXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDUromepwJM
/suItyY82WIngO5A+jlrMWnP7WkpjLKKDh8KBRPj/M2Jw75llOEJqk3PEWKUlPVO
yb7/aNjbs9kHqYlmTUvgYEN9e7QcAoHkyFv1gVpv9NFQFDweLmfc6RgNmf+iOkmJ
76Mrp6uXmnZSDC16xtWRnJ3S+nprq05w/JlTSaAd/REGmJL1P3S4oamJYpdTtltP
zYw0//vF8byHLI6hs0JIDkjgDrfOExrND4M1d/WO1Mb5B+8+i+z7lI0VYJ22mdgP
TTXqpmA94o4qAMjNqZAaE44QsvYmf0fEqbhQihkhe6CmISGn4MpS6Xnrr3xiUQPZ
avsBi7El/NeZAgMBAAGjggFxMIIBbTAJBgNVHRMEAjAAMC0GCWCGSAGG+EIBDQQg
Fh5FYXN5LVJTQSBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFKf0wFdz
+LcUFysoIMdCAhAqIECaMIHvBgNVHSMEgecwgeSAFDhY4fdfMy+L0fMdat75Kep6
cFEloYHApIG9MIG6MQswCQYDVQQGEwJDQTELMAkGA1UECBMCUUMxETAPBgNVBAcT
CE1vbnRyZWFsMTYwNAYDVQQKFC1LYXRhbmEgSG9sZGluZ3MgTGltaXRlIC8gIGNy
eXB0b3N0b3JtX2RhcmtuZXQxETAPBgNVBAsTCFRlY2ggT3BzMRcwFQYDVQQDFA5j
cnlwdG9zdG9ybV9pczEnMCUGCSqGSIb3DQEJARYYY2VydGFkbWluQGNyeXB0b3N0
b3JtLmlzggkAp6SkZfFe+FswEwYDVR0lBAwwCgYIKwYBBQUHAwIwCwYDVR0PBAQD
AgeAMA0GCSqGSIb3DQEBCwUAA4IBAQBKuSIVBx1wELG9DeU7mp2oV3IC8MK72c6G
6fQhbYj7JekwuVdtUa3cvcqDDy9fXlihS24F61tEt7Orz7wjO5KucFJBDjBy+wjS
LYKRf0CfVNdjIdKO7S703E3prmS8hIdl/j90IlLXiKl34+z2aORIxy8Et4R7oUC5
RLwdW2llhSAckQSQZ+Rly11M+JocZQM/piJGfwmg5gkdGlRALTlqV/B2yj6/Yuhc
TuHIN3HKfOUUTO/6yu93bTaKhcxtzLgMKu+6AzJxUyQZkrNCIsnGFx1kTc7adwFI
7TIVklEb+UIYikOOwmaOtSTFEhSZD5idgTAuN6kkhU48cJfzrDwv
-----END CERTIFICATE-----

</cert>
comp-lzo
redirect-private block-local
route-ipv6 ::/0
route 0.0.0.0 0.0.0.0 vpn_gateway
nobind
remote-cert-tls server
cipher AES-256-CBC
auth SHA512
float
persist-tun
# persist-tun also enables pre resolving to avoid DNS resolve problem
preresolve
# Custom configuration options
# You are on your on own here :)
# These Options were found in the config file do not map to config settings:
sndbuf size 1655368
rcvbuf size 1655368
mssfix 1400
key-method 2
allow-pull-fqdn
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
down-pre
replay-window 128 30
ns-cert-type server
explicit-exit-notify 3
resolv-retry 16
hand-window 37
mute 1
ping 10

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby parityboy » Sun Apr 27, 2014 3:07 pm

@Desu

WrWr is a write/read sequence, so it must be the read/write of VPN packets. That new node responds to pings, so see if you can ping it. "Network unreachable" likely means traffic can't get past your firewall...


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Sun Apr 27, 2014 3:52 pm

@Parityboy: I tried the same on android without FW and had the same problems... :\

What also confuses me:
Up until now we only had Username/Password + CA
Now we have User/Password +CA + Client Crt/Key
Why the change? The fun part being still able to connect and authenticate to the new instance when using only User/PW + CA... Shouldn't that be impossible?!

I hope Graze, PJ or Support are soon able to drag out a Staffer from the dungeon so he can comment on all that. :)

User avatar

marzametal
Posts: 517
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby marzametal » Mon Apr 28, 2014 5:07 am

In regards to "Now we have User/Password +CA + Client Crt/Key"...
It's been like that for me since I started up CS on Android. How long was the config "Username/Password + CA" only?


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Mon Apr 28, 2014 3:02 pm

marzametal wrote:In regards to "Now we have User/Password +CA + Client Crt/Key"...
It's been like that for me since I started up CS on Android. How long was the config "Username/Password + CA" only?


I still use only Username/Password + CA because I can't connect to the new instance. In fact you can also connect to the new instance with only Username/PW + CA. Try it out! It will correctly authenticate and connect.
This is something very strange a staffer should comment on. This is either a (dangerous?) bug or the Client crt/key is useless anyways. (Because it's generic anyways I guess the latter.)

User avatar

parityboy
Site Admin
Posts: 1233
Joined: Wed Feb 05, 2014 3:47 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby parityboy » Mon Apr 28, 2014 4:05 pm

@Desu,@marza

I cannot speak for Android, but on Linux (Mint 14 KDE) the Network Manager uses username/password and CA. You shouldn't need a separate .key file.


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Mon Apr 28, 2014 10:06 pm

Can somebody please post their raw config in here? It doesn't contain any sensitive information but it would help me big time to check for any mistakes I might have made.

User avatar

marzametal
Posts: 517
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby marzametal » Tue Apr 29, 2014 5:36 am

parityboy wrote:@Desu,@marza

I cannot speak for Android, but on Linux (Mint 14 KDE) the Network Manager uses username/password and CA. You shouldn't need a separate .key file.


When I loaded up CS on Android for the first time, it defaulted to "User/Password +CA + Client Crt/Key"...
Thinking about this again, I had all 5 files copied over from my user directory on Windows to my phone, as per screenshot capture in Graze's initial HOW TO for Android HOW TO for Android - Step 0, but should be step 10.

I just read through the new one created by Tealc, which was linked on Graze's HOW TO via first post slot, and all Tealc mentions is to import the config file, nothing else... not sure if it was an assumption that the other files had to be there too (most likely have to since the config file calls them).

Would be good to pinpoint when it exactly swapped over from User/Password +CA to User/Password +CA + Client Crt/Key. I think I have been using a custom ROM for about a month now, and it defaulted to the full 3, so I have no clue when it swapped from a 2 auth combo to a 3 auth combo...

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Tue Apr 29, 2014 5:46 am

marzametal wrote:...
When I loaded up CS on Android for the first time, it defaulted to "User/Password +CA + Client Crt/Key"...
Thinking about this again, I had all 5 files copied over from my user directory on Windows to my phone, as per screenshot capture in Graze's initial HOW TO for Android HOW TO for Android - Step 0, but should be step 10.

I just read through the new one created by Tealc, which was linked on Graze's HOW TO via first post slot, and all Tealc mentions is to import the config file, nothing else... not sure if it was an assumption that the other files had to be there too (most likely have to since the config file calls them).

Would be good to pinpoint when it exactly swapped over from User/Password +CA to User/Password +CA + Client Crt/Key. I think I have been using a custom ROM for about a month now, and it defaulted to the full 3, so I have no clue when it swapped from a 2 auth combo to a 3 auth combo...


Note that the later versions of OpenVPN allow "inline certs" so you - in theory - don't need to have the cert files. HOWEVER, I believe the inline ones override - but I'm not sure. :-/
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)


Topic Author
cryptostorm_ops
ForumHelper
Posts: 104
Joined: Wed Jan 16, 2013 9:20 pm
Contact:

routers & routing

Postby cryptostorm_ops » Tue Apr 29, 2014 5:48 am

I wanted to step in and provide some clarification on the functionality of routers (or "residential gateways," which is the au courant nomenclature for residential routers in some locales). You say that:

"they ash for local IP/DNS, my router tunnels them to a foreign one...


Unless you're running cryptostorm sessions directly from your router (which you may be doing, and which we strongly encourage), your router isn't being asked about "tunnelling" by anything. Routers, by definition, route packets: they look at OSI layer 3 - only! They check the "destination IP : destination port" metrics and make decisions about where to send packets based solely on that information, not on any layer 4 (or higher) payload. For a residential router connected to cryptostorm, it's a pretty easy process: "oh, look, another packet headed for IP address xxx.xxx.xxx.xxx {which is the address of a given instance on a given cryptostorm exitnode, somewhere]... guess I'll route it that-a-way." :-)

    (many residential routers also do some DHCP-stuffs as an ancillary service, which is really OSI 2 / ARP more than it is a "traditional" function of a standard router... and some decide to be firewalls in their spare time, which is often a terrible idea for a host of reasons - but in any case, they are almost universally state-less in their actions and don't do any sort of DPI on packet contents along the way)


Thinking about what routers really do is helpful to understand why a successful MiTM attack requires full ("oracular") control of routing parameters at some place in the required path of packets in transit (bidirectionally): the local machine of network members already knows what IP it wants to send packets to - a legitimate cryptostorm instance/node - and something "upstream" is going to have to have fully-corrupted routing table data in order to send those packets elsewhere, rather than to the intended instance/node.

As you say, a local ISP could exert oracular control over packets in this way... but if it's doing so, there's all sorts of other attack vectors that also open up and which are very difficult to control with full confidence. This has been mentioned earlier by my colleagues, and to go into that subject in depth is I think beyond the scope of this threat (might be interesting in a parallel thread). In short, if someone can poison the routing tables of every packet coming and going to a given machine - either via direct pwnage of routing hardware or via full DNS injection control - the challenge to creation of secure network communications is very much, as we say, "nontrivial." Impossible? Perhaps not... but most every scenario requires a discrete chunk of out-of-band comms to be provably secure. Which is worth remembering, always.

As to the automation question, you state that...

"...the government {has had} this capability built in, at every ISP... they've had it for many years."


I think you are conflating apples and oranges here. The automated attack vectors on "VPN" sessions disclosed by Snowden thus far relate to (as far as I know) two specific sorts of technical foundations: IPsec, and PPTP. IPSec, as we now know, is a standard that has been poisoned internally by NSA scheming (via NIST) to make it so bloody complex, intractable, and internally contradictory as to be all but impossible to implement in-the-wild in a secure manner. Anyone who has reviewed the standard firsthand can see this with their own eyes; it's a bloody mess. Unfortunately, some "VPN companies" offer naive IPsec-based services that are, as a result, terrifically insecure from top to bottom. It might look good in marketing literature to "support" IPsec, but personally I'd not feel comfortable configuring such a connection for my own use... and I do this for a living. How a non-technical (or even moderately technically sophisticated) "customer" could ever be expected to do so is beyond my understanding.

Anyway, that's how the NSA was bulk-breaking IPsec VPN sessions (and most certainly still is): default misconfigurations. As to PPTP... well, what can we really say? As far back as 2008, anyone who was "trusting" PPTP for security purposes - ten years after Schneier's famous paper exposing its deep flaws - was not exacly taking prudent steps. Any "VPN company" that was offering such service, back then or today, is criminally negilgent (to use Graze's apt phrase): when Peter Sunde admitted that IPredator's PPTP-based service was utterly insecure and intended merely as a "political statement," he was at least speaking the truth... why he kept offering that broken service - and charging "customers" for it! - for years afterwards is anyone's guess.

Automating an attack against cryptostorm exitnodes requires replicating the exitnode from top to bottom. This is not deeply challenging - we publish, as a matter of security fundamentals, all of our server-side configuration and paramaterizations, so it's easy enough to spin up an exitnode. But, that's not something that's automated by the NSA - let's be frank about that. We're growing like the proverbial healthy weed... but we're still small in the larger ecosystem out there. The TAO might spin up a fake cryptostorm node, but it's not built into a GUI at NSA headquarters just yet.

Too, that effort will need to keep track of current hostname <--> IP mappings, realtime, to ensure it stays correctly routed. Again, not impossible - those data are not "secret" in our model... but not trivial, and certainly not something that'd be worth automating with a point-and-click system.

I know that the dev folks are in process of testing out a new widget with the new cert materials embedded, and I believe a whack of additional, newly-spawned server instances (with new cert materials) are due to arrive imminently. So it's not that this isn't being "taken seriously" by our team; rather, it's that we're approaching it soberly, carefully, and with an eye towards full network functionality. Not in a panic.

Which is the way we tend to do things, around here.

With respect,

    ~ cryptostorm_ops


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Tue Apr 29, 2014 7:50 am

Graze wrote:Note that the later versions of OpenVPN allow "inline certs" so you - in theory - don't need to have the cert files. HOWEVER, I believe the inline ones override - but I'm not sure. :-/


You are right Graze, but inline only contains CA.crt so yeah... Clientgeneric key/crt is not used at all. So it seems like it is ignored by the exit nodes anyways. As I said: I use only User/PW + CA ever since and Parityboi is doing the same. So srsly: If you don't know please get a staffer on here and let him explain the situation because I really can't verify if this is a dangerous bug or not. Either way its very shitty to have those things out there no matter if they are unnecessary or important because they are not actively used. You fucked up either way and I count that as a stupid fuckup on your side.

I didn't speak out public critic for a long time but no matter how short you are on staff and how busy you are privately you are not making a good impression right now.

This is really 0% related to my connection problems. Fuck that, I'm able to use the old instances. This is 100% about those clientgeneric key/crt. What's it all about? What purpose does it serve? Why are we able to connect to old and new instances without using it? Is this a bug? Is this dangerous? If no: Why are you even issuing them? etc etc etc. I pay you. I expect answers. You know I love this project with my heart and you know I look up to every single one of you working on CS. I'm a freakin' fanboi. When I get pissed it's really because you don't do your fucking job. I know I will feel sorry about you in a couple of hours but right now at this moment I am really really pissed about you. Please explain!

On a side note: I don't care about your staffers hating the forum or not even knowing about it. Either whip them so hard that they visit this forum regularly by themselves or get our questions that you can't answer yourself forwarded to them in a timely manner. This is a security service. Security is always about quick reaction times. So if there is something that smells fishy (even if it is harmless) we need somebody competent to make an educated comment about it so we can act accordingly. I'm not angry if you say "Sorry, we can't provide the expected level on security right now because of reason A, B and C." This gives me the possibility to act accordingly. But getting no answer or "I'm not sure. :-/"-answers (sorry Graze. I hope you know I like you personally... :\) is absolutely unacceptable.

Srsly. What the fuck is wrong lately?! I can understand that PJ can't lift the whole forum weight by himself but get some freaking grip on the situation!
I'm serious! Pay me some shitty wage and I do all the freakin' community work for you because I love this project but either way DO SOMETHING ABOUT IT! I really feel left alone by you here and other do as well. They are just not that vocal about it like I am.


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Tue Apr 29, 2014 8:06 am

The last anon post was made by me "DesuStrike" of course. I forgot to enter my name. Sry...

@community: I'm coming back to get this forum moderated at least somehow because I'm very disappointed about the staff right now. Don't get me wrong. All in all they do a great job but this forum is not getting the amount of love it deserves. I will be here to approve unregistered posts and do some basic moderation work in a more timely manner. But as long as I don't get paid at least a breadline wage I can't do any advanced community work. I don't even have access to staff communication channels anyways. I'm just a normal guy like you are but who is in love with this project.

I sent a request to restore my account yesterday at lunch time. As soon as I get my account back you will see me posting under my old acronym like you are used to see.

Let's see if I can get this forum somewhat useful again and maybe I'm even able to whip some sense into the staff...

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby cryptostorm_support » Wed Apr 30, 2014 12:32 am

Sorry for the delay in approving some of the unregistered comments. I've been out of town the past couple days with only access via my phone. Data connection was spotty, and browsing/posting on mobile devices is incredibly tedious IMO. Post approval time and whatnot should return to normal
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm


Desu

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Desu » Wed Apr 30, 2014 6:10 am

Hey cryptostorm_support. This was in no way about you. Please don't feel attacked by me if you did. :)
Getting posts approved is nothing that worries me and actually I put myslef into this situation anyways. So I'm not in the position to complain. :silent:

This is about me being kinda frustrtated that I have no way to reach a staffer to explain to us what's up with the client crt/key.
We just learned that one half of the community uses only User/PW + CA and the other half User/PW + CA + Client Crt/Key. So yea... One group of us is doing something pretty wrong for pretty long and we can't figure out if this has an impact on anything. This is a VPN and I must be able to trust that everything is running fine. And well... I would just repeat myself.

I really do feel unhappy about me being harsh to you guys every single time I do it but believe me or not: I'm actually a pretty calm person. You must really frustrate me on personal level to get me explode like this. But lately some shortcomings on here are really getting to me. I hate to say this publicly but you guys are obviously short on men big time. That's bad and I wish I could change it but I can't. But this doesn't stop me from getting very angry at you when you, all hardships aside, are falling short even though you work your asses off day and night.

It really sucks to be the best VPN out there, does it? People create major expectations and if you don't meet them: BOOM! Disappointment. "No good deed goes unpunished." they say. ;)

Cheers!

User avatar

Graze
Posts: 247
Joined: Mon Dec 17, 2012 2:37 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Graze » Thu May 01, 2014 8:32 am

Desu wrote:...
You must really frustrate me on personal level to get me explode like this. But lately some shortcomings on here are really getting to me. I hate to say this publicly but you guys are obviously short on men big time. That's bad and I wish I could change it but I can't. But this doesn't stop me from getting very angry at you when you, all hardships aside, are falling short even though you work your asses off day and night.

It really sucks to be the best VPN out there, does it? People create major expectations and if you don't meet them: BOOM! Disappointment. "No good deed goes unpunished." they say. ;)
...


This is - obviously - a very valid point.

We're short of people - and what's worse is we've worked so hard to create a trust-based company that adding new people (when all of the best said crypto-foilhat people in this day and age are merely an n-character handle on the interwebs) is fairly difficult to vet: We want the best folks, but not the best folks who happen to also be working for some .gov ... so we revert back to the same overworked team of smart people who go off and attend a few conferences, write exams, or whatever... We're very aware of the problem, and we've got a few people in the hopper to take over the business side of things so that the tech people can get back to doing tech stuff instead of more or less failing at the biz stuff.

We do need a couple tech's, don't get me wrong: Besides the Windows client, which is almost complete, there's all the other tech stuff that a growing company needs to keep the engines fired. As a couple of people have noted, we need to shove in a real ticket system. And, mostly, we need a real biz guy so that people like me don't speak their mind and admit mistakes all over the forum. ;)

Anyway, I hear you, and I deeply apologize. We've got the core tech stuff humming, and it's pretty solid, in our defence. Ya, we've got to add some new instances again (as shown by that MTU problem you highlighted which is - I believe - likely the reason we have different MTU frames for different tech platforms (the windows-montreal vs the linux-montreal, etc.) which had caused issues in the past when starting up the android vpns, I believe. I suspect if you used that instance for Windows it will work fine.

We just need more humans and/or bots, and/or less sleep. :)

Thanks for complaining so that we get better (and as a non-corporate person who just wants a better world, I really mean this) , and hang in there: The wheels of corporate change are turning, slowly.
------------------------
My avatar is pretty much what I look like. ;) <-- ...actually true, says pj
WebMonkey, Foilhat, cstorm evangelnomitron.
Twitter: @grazestorm.
For any time sensitive help requests, best to email the fine bots in support@cryptostorm.is or via Bitmessage at BM-NBjJaLNBwWiwZeQF5BMLYqarawbgycwJ ;)

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Thu May 01, 2014 5:50 pm

I finally got a round tuit, and tried to connect using a newly modified config (with cryptostorm_client_windows-dynamic0.93.conf being the reference). Everything seems to work fine so far. Here's the connection log:

Code: Select all

Thu May 01 09:54:06 2014 us=422716 Current Parameter Settings:
Thu May 01 09:54:06 2014 us=422716 NOTE: --mute triggered...
Thu May 01 09:54:06 2014 us=422716 284 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:06 2014 us=422716 OpenVPN 2.3.3 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Apr 14 2014
Enter Management Password:
Thu May 01 09:54:06 2014 us=438316 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340
Thu May 01 09:54:06 2014 us=438316 NOTE: --mute triggered...
Thu May 01 09:54:06 2014 us=921917 2 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:06 2014 us=921917 MANAGEMENT: CMD 'state on'
Thu May 01 09:54:06 2014 us=921917 NOTE: --mute triggered...
Thu May 01 09:54:07 2014 us=124717 3 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:07 2014 us=124717 LZO compression initialized
Thu May 01 09:54:07 2014 us=124717 Control Channel MTU parms [ L:1606 D:138 EF:38 EB:0 ET:0 EL:0 ]
Thu May 01 09:54:07 2014 us=124717 Socket Buffers: R=[8192->8192] S=[8192->8192]
Thu May 01 09:54:07 2014 us=124717 MANAGEMENT: >STATE:1398938047,RESOLVE,,,
Thu May 01 09:54:07 2014 us=249517 Data Channel MTU parms [ L:1606 D:1400 EF:106 EB:135 ET:0 EL:0 AF:3/1 ]
Thu May 01 09:54:07 2014 us=249517 NOTE: --mute triggered...
Thu May 01 09:54:07 2014 us=249517 1 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:07 2014 us=249517 Local Options String: 'V4,dev-type tun,link-mtu 1606,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,cipher AES-256-CBC,auth SHA512,keysize 256,key-method 2,tls-client'
Thu May 01 09:54:07 2014 us=249517 NOTE: --mute triggered...
Thu May 01 09:54:07 2014 us=249517 1 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:07 2014 us=249517 Local Options hash (VER=V4): 'ff724a72'
Thu May 01 09:54:07 2014 us=249517 NOTE: --mute triggered...
Thu May 01 09:54:07 2014 us=249517 1 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:07 2014 us=249517 UDPv4 link local: [undef]
Thu May 01 09:54:07 2014 us=249517 UDPv4 link remote: [AF_INET]70.38.46.226:443
Thu May 01 09:54:07 2014 us=249517 MANAGEMENT: >STATE:1398938047,WAIT,,,
Thu May 01 09:54:07 2014 us=374317 NOTE: --mute triggered...
Thu May 01 09:54:07 2014 us=374317 1 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:07 2014 us=374317 TLS: Initial packet from [AF_INET]70.38.46.226:443, sid=fbce63ea 851b0a1b
Thu May 01 09:54:07 2014 us=374317 WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Thu May 01 09:54:08 2014 us=279119 VERIFY OK: depth=1, C=CA, ST=QC, L=Montreal, O=Katana Holdings Limite /  cryptostorm_darknet, OU=Tech Ops, CN=cryptostorm_is, emailAddress=certadmin@cryptostorm.is
Thu May 01 09:54:08 2014 us=279119 NOTE: --mute triggered...
Thu May 01 09:54:09 2014 us=43520 7 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:09 2014 us=43520 [server] Peer Connection Initiated with [AF_INET]70.38.46.226:443
Thu May 01 09:54:10 2014 us=104322 MANAGEMENT: >STATE:1398938050,GET_CONFIG,,,
Thu May 01 09:54:11 2014 us=165124 SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Thu May 01 09:54:11 2014 us=289924 NOTE: --mute triggered...
Thu May 01 09:54:11 2014 us=305524 7 variation(s) on previous 1 message(s) suppressed by --mute
Thu May 01 09:54:11 2014 us=305524 do_ifconfig, tt->ipv6=0, tt->did_ifconfig_ipv6_setup=0
Thu May 01 09:54:11 2014 us=305524 MANAGEMENT: >STATE:1398938051,ASSIGN_IP,,10.77.0.10,
Thu May 01 09:54:11 2014 us=305524 open_tun, tt->ipv6=0
Thu May 01 09:54:11 2014 us=305524 TAP-WIN32 device [OpenVPN] opened: \\.\Global\{70CE431D-44C5-4B47-86E3-F1F5CC3989F1}.tap
Thu May 01 09:54:11 2014 us=305524 TAP-Windows Driver Version 9.9
Thu May 01 09:54:11 2014 us=305524 TAP-Windows MTU=1500
Thu May 01 09:54:11 2014 us=305524 Set TAP-Windows TUN subnet mode network/local/netmask = 10.77.0.0/10.77.0.10/255.255.0.0 [SUCCEEDED]
Thu May 01 09:54:11 2014 us=305524 Notified TAP-Windows driver to set a DHCP IP/netmask of 10.77.0.10/255.255.0.0 on interface {70CE431D-44C5-4B47-86E3-F1F5CC3989F1} [DHCP-serv: 10.77.255.254, lease-time: 31536000]
Thu May 01 09:54:11 2014 us=305524 DHCP option string: 0610c664 92334c4a cde45bbf 8898d549 5b23
Thu May 01 09:54:11 2014 us=305524 Successful ARP Flush on interface [16] {70CE431D-44C5-4B47-86E3-F1F5CC3989F1}
Thu May 01 09:54:16 2014 us=375533 TEST ROUTES: 1/1 succeeded len=0 ret=1 a=0 u/d=up
Thu May 01 09:54:16 2014 us=375533 C:\Windows\system32\route.exe ADD 70.38.46.226 MASK 255.255.255.255 10.200.249.129
Thu May 01 09:54:16 2014 us=375533 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=20 and dwForwardType=4
Thu May 01 09:54:16 2014 us=375533 Route addition via IPAPI succeeded [adaptive]
Thu May 01 09:54:16 2014 us=375533 C:\Windows\system32\route.exe ADD 0.0.0.0 MASK 128.0.0.0 10.77.0.1
Thu May 01 09:54:16 2014 us=375533 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu May 01 09:54:16 2014 us=375533 Route addition via IPAPI succeeded [adaptive]
Thu May 01 09:54:16 2014 us=375533 C:\Windows\system32\route.exe ADD 128.0.0.0 MASK 128.0.0.0 10.77.0.1
Thu May 01 09:54:16 2014 us=375533 ROUTE: CreateIpForwardEntry succeeded with dwForwardMetric1=30 and dwForwardType=4
Thu May 01 09:54:16 2014 us=375533 Route addition via IPAPI succeeded [adaptive]
Thu May 01 09:54:16 2014 us=375533 Initialization Sequence Completed
Thu May 01 09:54:16 2014 us=375533 MANAGEMENT: >STATE:1398938056,CONNECTED,SUCCESS,10.77.0.10,70.38.46.226
Thu May 01 09:54:16 2014 Start net commands...
Thu May 01 09:54:16 2014 C:\Windows\system32\net.exe stop dnscache
Thu May 01 09:54:19 2014 C:\Windows\system32\net.exe start dnscache
Thu May 01 09:54:21 2014 C:\Windows\system32\ipconfig.exe /flushdns
Thu May 01 09:54:21 2014 C:\Windows\system32\ipconfig.exe /registerdns
Thu May 01 09:54:28 2014 End net commands...
[WR...]


Also...

Graze, for heaven's sake, fix the Mac config download link already!

It's the third and last time I'm saying this.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Fri May 02, 2014 8:07 pm

Chaning mssfix to fragment will fix the problem on linux.
On Android it also worked for a couple of minutes but now it's back to being connected but not routing traffic through the node. Linux continues to work.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Sun May 04, 2014 2:47 am

Android suddenly works again if you use the fragment directive


P144N
Posts: 3
Joined: Sun May 04, 2014 1:16 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby P144N » Sun May 04, 2014 4:26 am

Hail Isis, goddess of chaos and darkness!

The union of dynamic discord request a comment on the recent outage of the newly created more secure bruno instance and demands the immediate restoration of normal functionality!
The union also requests secure instances on all available exit node locations within a reasonable but very short time frame as this is what the chaotic darkness needs to stay truly dark in future. The gate watchers were irresponsibly sleeping lately causing order to gain a lot of territory formerly owned by chaos. This cannot continue. Isis demands for the restoration of chaos in her realms and she won't take no for an answer and wont accept any further delays!

Not complying with Isis demands will inevitably result in death of all people responsible of this chaotic dark realm named cryptostorm. Isis is a kind and loving goddess but she won't tolerate any negligence that provides order opportunity to gain more ground on the already shrinking chaos realms.

Hail Isis, goddess of chaos and darkness!

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby cryptostorm_support » Sun May 04, 2014 10:21 am

I'll see if I can find someone able to parse that particular dialect of nerd (along with your other.. ehm...reply, if necessary)
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm


b3lt3r5
Posts: 27
Joined: Sun Dec 23, 2012 2:55 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby b3lt3r5 » Sun May 04, 2014 12:06 pm

P144N wrote:Not complying with Isis demands will inevitably result in death of all people responsible of this chaotic dark realm named cryptostorm.


That's a big call bro.

To expedite resolution of your reported issue, please complete the attached form and give to a responsible adult.

Image


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Sun May 04, 2014 2:26 pm

I wouldn't take this post too seriously. It's rather creative after all.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Mon May 05, 2014 4:44 pm

good question btw. How IS the actual status of getting up new instances on every exit node? I also experience lots of outages from canada and wish there were more than just one server to connect to if you don't want to get pwned by man in the middle attacks. No matter how serious the thread might actually be. Why go with less security if you can have more?

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Tue May 06, 2014 9:18 am

Just an FYI, when I put up the new client certs I forgot to remove the "clientgeneric" ones that aren't even used by our setup.
Our setup still only requires the CA cert (ca2.crt, or whatever inline).

To everyone who's been waiting forever and a day (sorry, busy with the techie devy stuff), here's the current list of instances using the new certs:

Canada:bruno:raw:174.142.78.196
Canada:bruno:windows:174.142.78.195
Germany:cantus:windows:46.165.222.245
Canada:shadow:raw:198.50.119.173
Canada:shadow:windows:198.50.119.174
Iceland:fenrir:raw:79.134.235.133
Iceland:fenrir:windows:79.134.235.134
United States:chili:windows:199.115.119.135

As you can probably guess, the format is "Country:nodename:raw/win:IP".
That list will be at https://cryptostorm.nu/nodelist.txt and updated from there.
So the ca2.crt from https://cryptostorm.org/newclientcerts.zip is what you would use for those above instances (I removed the other clientgeneric files from that .zip just to make this less complicated, a bit too late it seems).

In possibly related news, the 1.0 release of the widget is coming up very soon (as in a few days).
New features include:
An option for automatically connecting on widget start up.
An option for automatically running the widget when windows starts up.
An embedded tool that will find the node that has the best latency relevant to you (i.e., responds fastest).
Another tool that tells you which node has the least amount of members logged in.
Node selection drop-down list.
Update button next to that drop-down list so the node list can be easily updated.

Stay tuned ;-)


grystch_

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby grystch_ » Tue May 06, 2014 12:55 pm

Canada Bruno works fine for me. I'm confused though.

Somewhere on this forum there's a thread that says very explicit "don't use ip numbr use domain name instead" (paraphrase, since I can't find the post). The reason stated iirc is the ip number might change for some reason but the domain name would always route correctly. Should we still be using raw-montreal.cryptostorm.nu type of address? Or the ip numbers listed? I used the listed ip address.

Also, is a raw nUSA coming soon?

One more thing. Previusly the Montreal had no reverse dns when I checked the ip. New configuration says Name Address: cryptostorm.nu (Name Address field was blank before, this using http://www.ipchicken.com). Im not sure it makes a difference but I kind of liked no info being there. Is this a bug or feature? :mrgreen:

~grystch


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Tue May 06, 2014 2:02 pm

Wow df, thanks! This is the best post since quite some time! :)
To everyone who might got mixed feelings about CS lately: Posts like these are proof to the fact that CS is run by people who know their stuff and who care. They just lack the time and/or skills to always properly handle communication with the community. They also work hard behind the scenes even if it looks like they do nothing from the outside.

I will do some test runs today.


On a serious side note: I see the reasoning behind different instances for different OS/Devices. It is necessary unfortunately. I also see the motivation for connecting to less used instances. But in terms of privacy wouldn't it be better to connect to an instance with lots of users, so correlation attacks become useless and for some other reasons, too? As far as I know being the only one using an instance degrades lots of benefits you'd usually expect from a VPN. Depending on the location, config version and time of day I can imagine this will be the case regularly.

If you agree: Wouldn't it be desirable to reduce the fragmentation caused by heartbleed in the future?

If yes: I unfortunately don't see how a future merge would work without "hurting" those you try to go easy with today by not changing their certs. Maybe routing all instances of one physical location through one gateway could be a solution? So no matter if you are raw/win with old/new certs at iceland you'll always have the same public ip regardless of the ip the instance itself uses.

Just a crazy idea but I wanted to highlight this possible issue as it could become a problem if we fragment users further and further.


PS: Dammit! No matter how hard you try there is always something that could or even should be done better or differently when it comes to online security. And the solution is never an easy one. I'm sorry for always being a worrier even when I try to thank and commend you.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Tue May 06, 2014 2:07 pm

Also: Boo for not having a RAW Cantus! :thumbdown: :P

Will those new instances get redundant hostnames in the future or stay IP only?

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Tue May 06, 2014 6:33 pm

Yea, they'll get hostnames shortly. While it's true that you shouldn't get too used to using the IPs, I figured I might as well just send these out as is so people can connect to something with new certs. We'll order more IPs on some of the servers (i.e., cantus) so they all can have an equal amount of windows & raw instances. That's the reason some of them don't have the new instances, there just wasn't any extra IPs available. The plan is to keep the old instances running so everyone's setup doesn't just stop working. Over the next couple of months, through DNS changes and widget node list updates the old instances will be weaned off until there's only one or two users on each one. Then those can be shutdown and replaced with new ones.

User avatar

Tealc
ForumHelper
Posts: 283
Joined: Tue Jan 28, 2014 12:38 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Tealc » Wed May 07, 2014 12:06 am

We can't be a drama queen like P144N, but I have my "two cents" in all of this...

At this moment both the config files, certs, new certs, etc. are all in two different places.... in this threat and in the conf.cryptostorm.org, and they are different ?! The main problem is that this isn't organized.
Can't we do something like this:

1) One topic with all the exit nodes both windows and raw, information only, with IP's, location and if possible the proper hostnames
2) Another topic with the config files for Windows based users that use OpenVPN, each config should have every available node, this way it's download and run, no changes needed (maybe a small tutorial on how to put this files in the right place and run the program)
3) Another topic with the config files for RAW, each config should have every available node, this way it's download and run, no changes needed
4) Another topic with only the widget for the windows users

All topic's should be locked! Only staff/moderators should be able to comment and change what's inside.

I'm here to help out the community, but I have to say that I'm kind of lost in the "sea" here... if I haven't opened this topic I would never have found out that there was a new cert installed in several exit nodes.

Question: Is it possible that windows config's are slower in speed them raw's?

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Wed May 07, 2014 12:12 am

I agree this needs to be organized more. I just happened to stumble upon this thread myself, and while I normally don't do anything on the forum I thought it would be nice to share those IPs since they're all setup and good to go. Only thing left is the threads about them. Normally, other people organize the forums, but a lot of those people are busy on other projects atm. I might end up just doing the threads myself, but I'm sure the windows users out there would prefer me to be working on getting v1.0 of the widget ready for release.

P.S.
To be honest I'm not a big fan of forums in general. For something like cryptostorm I would setup like what's on the main cryptostorm.is page, but instead of linking to forum threads containing config files and widgets and whatnot, just providing a direct link to a file on the site (maybe with a link to the forum if the user wants to read up on further information about the file) seems like a better way.

User avatar

Tealc
ForumHelper
Posts: 283
Joined: Tue Jan 28, 2014 12:38 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Tealc » Wed May 07, 2014 12:23 am

@df

That would be great! I had recommend this VPN to more people them you can ever imagine, but when they see the cryptostorm main site and access the forum as guest, they tell me that they can't even figure out how to buy the "login" to access the VPN, after I've explained how they can do it, they ask's me "Where are the servers located? What's a exit node? How can I connect to different servers without re-installing the widget?"

And with all this questions they end up going somewhere else, has they think it's very complicated .... This is a saying of several people that I've recommend. In some cases I've end up paying their subscriptions for 1 month and configuring their computer, and if they do like it..... well they buy another token



P.S. - I agree that would be much more simpler for the begginer, a link to the config file or the widget and a "Read More" link to the forums.

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Wed May 07, 2014 12:39 am

Yea, that's a problem I've talked with PJ about before. I think it's great to provide the in-depth analysis of every aspect of what's going on here, but only to the people who actually care about that stuff. Average users just wanna click a buy button, throw some money at it, then click "Connect" to login to the VPN.

We'll get to that point eventually. For now, at least the 1.0 widget has that concept embedded. Plus a few basic things to make it a little more configurable, but still simple enough that anyone wanting to just connect and not think about anything can get through it.

Attached is what the new widget looks like atm.
First window is the main window,
second is after you click "Options"
third is after you click the "Nodes" tab
fourth is the main window after you click the node selection dropdown list.
Attachments
wins.png

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Wed May 07, 2014 1:22 am

Operandi wrote:Also...

Graze, for heaven's sake, fix the Mac config download link already!

It's the third and last time I'm saying this.

Wait, did I say "third"? It was the fourth time, actually.

Tealc wrote:2) Another topic with the config files for Windows based users that use OpenVPN, each config should have every available node, this way it's download and run, no changes needed (maybe a small tutorial on how to put this files in the right place and run the program)

Regarding a Windows tutorial, there is one already: http://windows.cryptostorm.org/.

df wrote:I agree this needs to be organized more.

How about adding a brief summary on what's going on (along with the links to the node list and updated certs) to the config thread, for the time being?


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Wed May 07, 2014 1:53 am

I always was a big fan of this forum approach because it does give in depth information that is important to provide the needed transparency for an open source like project like CryptoStorm.
On the other hand such an approach does require lots and lots of hard and continuous work to keep things organized. What we see now is the result of desperately keeping things in order with way too less people and time at hand.

I don't say we should close the forum. For heavens sake it had such a positive influence on the VPN in the past and we found lots of the worst snags and best solutions working together. So keep it open and active!
But we also need the other extreme, like df said: The super simple "click, pay'n go" solution. This is especially for the windows folks who love to download exe files from the internet and double click them. But also Linux folks need a more easy solution that is at least appropriate to their OS type. I think about something like a nice and clean Page on cryptostorm.is that has all the most recent config files and certs. As a personal bonus wish I'd also love to have all the hostnames with their according IPs in a list until we have an automatic leakblock.
In fact this little list you posted today df: I LOVE IT! <3
It makes my live so much more easy as I don't have to look up the IPs myself. This will be especially awesome when IPs change in future. :)

I'm a wannabe geek just like any other and thus I love to fiddle around but there are times where I just need things to run fast, reliable and secure without long setup and (re)configuration times. So one place for all information needed would help a lot. I also spend quite some time looking into the forums if there is important information that just popped up somewhere unexpectedly. We all could use this time more productive if we had everything in one place: Put a changedetection.com onto it and I get RSS updates as soon as IMPORTANT information changes. :)

User avatar

vpnDarknet
Posts: 128
Joined: Thu Feb 27, 2014 2:42 pm
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby vpnDarknet » Wed May 07, 2014 4:43 am

Tealc, I couldn't agree with you more!
I've been reluctant to promote the site as the connection guides are disheveled around the message board.

As discussed with Graze I think a wiki could be a suitable solution, even if temporary.
Here's something I've started to put together http://vpndark.net/wiki/index.php?title=Main_Page
All contributions welcome, and thanks again Tealc for the guides that you have already put together. :clap:
Buy your tokens via vpnDark.net and cryptostorm cannot and does not know anything about users - no link between a token & purchase details
Unofficial Wiki cryptostorm access guide
Ways to talk to me

User avatar

marzametal
Posts: 517
Joined: Mon Aug 05, 2013 11:39 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby marzametal » Wed May 07, 2014 6:18 am

I got it to work successfully on both Windows, and then Android via "United States:chili:windows:199.115.119.135". I had to use # to comment out the two lines in the config file that reference clientgeneric, and renamed the files to oldclientgeneric just to be safe.
In Windows, just replaced the config entry "windows-unsae.cstorm.pw" with "199.115.119.135". Then I copied over config.ovpn along with client.dat and the new certificate to my Android device, ran through the changes mentioned in Graze's HOW TO, that's it.

I did notice that the custom options text box pops up a different list of entries. What my text box shows is this:

Code: Select all

#These options were found in the config file do not map to config settings:
key-method 2
tls-cipher TLS-DHE-RSA-WITH-AES-256-CBC-SHA
down-pre
ns-cert-type server
explicit-exit-notify 3
resolv-retry infinite
fragment 1400
hand-window 17
mute 3
ping 10 (I added this one)

Now it says in Basic menu via Android: "User/Password + CA"... woo hoo!

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Wed May 07, 2014 1:35 pm

I just ran through the new Windows exit nodes. They all seem to work, but Iceland:fenrir:windows appears to be an Android node: www.geoiptool.com recognizes it as "android-fenrir-cryptostorm.net".

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Wed May 07, 2014 4:01 pm

Nah, that's just some leftover rDNS from when fenrir did have an android node. Since that's not running anymore and the IP was available, I binded the new windows vpn to it. Don't worry, the rDNS will be changed eventually (and some proper hostnames will be setup).

User avatar

Operandi
Posts: 88
Joined: Fri Nov 22, 2013 4:23 pm

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Operandi » Wed May 07, 2014 7:25 pm

df wrote:Nah, that's just some leftover rDNS from when fenrir did have an android node. Since that's not running anymore and the IP was available, I binded the new windows vpn to it. Don't worry, the rDNS will be changed eventually (and some proper hostnames will be setup).

I see. Thanks for clarifying.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Sun May 11, 2014 2:37 pm

Any progress with the Cantus raw instance? I know leaseweb is pretty quick with assigning additional IPs to existing servers. Or are there other holdups?

User avatar

cryptostorm_support
ForumHelper
Posts: 296
Joined: Sat Jan 26, 2013 4:31 am
Contact:

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby cryptostorm_support » Sun May 11, 2014 11:13 pm

I'll see if I can get a word on what the current situation is
cryptostorm_support shared support team forum account
PLEASE DON'T SEND PRIVATE MESSAGES with support questions!
--> feel free to use any of our other contact channels, or post in the support forum
cryptostorm: structurally anonymous, token-based, unlimited ☂ bandwidth, opensource, darknet data security for everyone!
keybase.io validatorsonename.io validatorsPGP key @ MITnetwork statuscryptostorm github
support team bitmessage address: BM-2cTMH8K5JnjbfSALjZtSkRWCLfc3Tr8GBV
support team email: support@cryptostorm.is
live chat support: #cryptostorm


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Mon May 12, 2014 4:16 am

cryptostorm_support wrote:I'll see if I can get a word on what the current situation is

Thanks css!
I hope I don't sound like an impatient jerk but asking is the only way to get an answer, right? :)

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Mon May 12, 2014 4:38 am

Still waiting on a response from leaseweb. In the meantime, onyx (in France) has a new raw & windows instance at:
raw-onyx-1.cryptostorm.net (212.83.167.81)
and
windows-onyx-2.cryptostorm.net (212.83.163.209)

The balancers raw-balancer-dynamic.cryptostorm.net & windows-balancer-dynamic.cryptostorm.net have been updated with these new instances.


Guest

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby Guest » Mon May 12, 2014 12:37 pm

Huh? Kinda unusual for leaseweb but guess that is just me and my bad luck. :crazy:

Meanwhile Onyx will do as a substitute. Google thinks cantus raw is French anyways, so 2/3 of the web won't see a difference. Haha :angel:

User avatar

df
Site Admin
Posts: 369
Joined: Thu Jan 01, 1970 5:00 am

Re: cryptostorm's Post-Heartbleed Certificate Upgrade Trajec

Postby df » Tue May 13, 2014 2:24 am

Yea, prolly just bad luck. Normally they're quick about this sorta thing, but turns out someone at leaseweb screwed up and gave us an IP that's already assigned to another system on their network. Waiting for the ticket response to that problem now.

When I assigned an eth0 alias to cantus for the new IP I got "Error, some other host already uses address 46.165.222.247." from the /etc/sysconfig/network-scripts/ifup script. Plus I did a telnet to 46.165.222.247 on port 22 and got back "SSH-2.0-OpenSSH_5.2", which means it's definitely not cantus because cantus uses a newer OpenSSH version and it's also not listening on the default SSH port (22). Also there's a webserver on 46.165.222.247, and cantus has no webserver running. So somebody's drunk at leaseweb :-P


Return to “cryptostorm in-depth: announcements, how it works, what it is”

Who is online

Users browsing this forum: No registered users and 10 guests

cron

Login