Ξ 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 Ξ

"WARNING: No server certificate verification method has been enabled." in logs

Post a reply

In an effort to prevent automatic submissions, we require that you enter the letters that are written in red.
:D :) ;) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :!: :?: :idea: :arrow: :| :mrgreen: :geek: :ugeek: :angel: :clap: :crazy: :eh: :lolno: :problem: :shh: :shifty: :sick: :silent: :think: :thumbdown: :thumbup: :wave: :wtf: :yawn:

BBCode is ON
[img] is ON
[flash] is OFF
[url] is ON
Smilies are ON

Topic review

If you wish to attach one or more files enter the details below.

Expand view Topic review: "WARNING: No server certificate verification method has been enabled." in logs

1.0 - 1.2 & ECC & brainpool & c25519

Post by Pattern_Juggled » Sat Mar 14, 2015 4:57 am

Guest wrote:I see TLS 1.0 in that pic you posted. is that right? I kinda assumed CS was TLS 1.2 and non-backwards compatable.
Isn't TLS 1.0 vulnerable to beast and poodle?

Nah, there's nothing intrinsically terrible about 1.0. Most all the core patches for the BEAST-class stuff have backported to 1.0 concurrently with the upgrades into 1.2, so in practical terms that's not a good reason to push for 1.2.

To me, the parts of 1.2 that matter are the ECC inclusion... which we're not using yet, because NIST. If you want that full backstory, this is the thread for immersion.




Post by Pattern_Juggled » Sat Mar 14, 2015 4:52 am

I'd finished most of the research to reply to this a few days back, then managed to get pulled off the project and now I've to gather up the data for posting. I should have that done properly, in short order.

Meanwhile, I believe the answer is that there's two closely related OpenSSL cipher suites in play here. Their full expression in the relevant syntax is as follows:

Code: Select all


I refer to them as "33" and "39," respectively, although of course that's all sorts of sloppy.

My preference in our initial spec was to tip towards AES256, out of an abundance of caution in such matters (given the lack of serious performance concerns in deploying synmmetric ciphers nowadays) and I set the parameters for that suite, which does require full 1.2 support. However, I can't say that the same suite with AES128 substituted in makes me in the least uncomfortable, and thus I was comfortable with that suite down-cycling to 128 if needed - for platforms not able to carry full TLS1.2. Of course we could force the 1.2 issue and require the 256, but it's just not something I feel makes anyone safer... and it'll push quite a few mobile platform folks off the network.

(we've required proper 1.2 support for torstorm and I've little hesitation to do so if circumstances require... but at the same time I"ve no interest in being tendentious about such matters for no credible reason}

Now, in practice what I've seen from our pcaps and test connects over the last 18 months is an essentially universal synchronisation on "33" for cstorm sessions, for reasons only openssl (and perhaps Filippo :-) ) can really understand. Were that an issue, in cryptographic terms, I'd re-parameterise and push new confs - but, again, I just can't say it's bothering me in fundamental terms.

I'm also keen to avoid wasting time niggling with AES trivialities, when the next iteration we've set for the core cipher suites on the network is a proper integration of c25519... a longstanding goal of the team, for obvious reasons. The relevant libraries are quite close, I think, and we're about ready to do some alpha testing. I'll also look to wrap a ChaCha inclusion in that upgrade, as it seems to have reached a critical mass in deployment terms, and there's certainly nothing bad I can say about it's performance.

Anyhow that's the short form from memory. I've got some nice reference papers set aside to add in as links, and so on - even a diagram or two - but I figured I'd get something up now, rather than let this go further stale in the meantime.



Re: "WARNING: No server certificate verification method has been enabled." in logs

Post by Guest » Tue Mar 10, 2015 8:54 pm

Guest wrote:Hey PJ-
I see TLS 1.0 in that pic you posted. is that right? I kinda assumed CS was TLS 1.2 and non-backwards compatable.
Isn't TLS 1.0 vulnerable to beast and poodle?

That is odd, since https://www.openssl.org/docs/apps/ciphe ... her-suites shows that by using the
line from the CS config, we should be using TLS-v1.2.

Re: cert management: security theatre v. actually understanding cryptography in practice

Post by pants » Tue Mar 10, 2015 4:51 pm

Pattern_Juggled wrote:
pants wrote:snip

Thank you for the thorough explanation, I truly appreciate it!

I' m still learning about OpenVPN and I apologize for my ignorance and resulting odd questions.
Can you recommend me any reading material to further educate myself about OpenVPN and encryption?

Re: "WARNING: No server certificate verification method has been enabled." in logs

Post by Guest » Tue Mar 10, 2015 1:15 pm

Hey PJ-
I see TLS 1.0 in that pic you posted. is that right? I kinda assumed CS was TLS 1.2 and non-backwards compatable.
Isn't TLS 1.0 vulnerable to beast and poodle?

cert management: security theatre v. actually understanding cryptography in practice

Post by Pattern_Juggled » Tue Mar 10, 2015 11:36 am

pants wrote:Hi, I'm just testing cryptostorm here, what's the deal with "WARNING: No server certificate verification method has been enabled. See http://openvpn.net/howto.html#mitm for more info." in the logs?

I understand you're using a self signed certificate but what about this: http://openvpn.net/index.php/open-sourc ... .html#mitm ?

We're quite attentive to MiTM-style attack vectors. In fact, we've been accused - with some justification - more than once of being completely obsessed with these attacks. I'd say that's the case because MiTM attacks work, and are known to be widely deployed.

However, substantive protection against MiTM attacks takes more than reading manual pages that themselves predate modern MiTM attack techniques by many years. I've also read those pages... indeed, I remember the OpenVPN manpages before those entries were added by the team, so I'm familiar with their trajectory. They were good at the time, to explain to people with little formal experience or background in real-world network security issues why some of the functions of OpenVPN existed, and were encouraged in deployment. Remember, that was back when iPredator was deploying an all-PPTP "VPN service" that left every packet sent and received effectively plaintext to any attacker with so much as an old Windows machine at their disposal.

So I was supportive of the inclusion of these comments about MiTM attacks, although - even back then - I had some concerns that the full complexity of these attacks weren't really being communicated in these short notes. However, they were a good start and in their own way groundbreaking at the time.

Using them as guidelines for today's MiTM attack vectors would be, to be blunt, childishly naive.

Server cert verification within OpenVPN checks to see if the cert being presented has embedded in its defined characteristics that it's a server cert. The idea there is to prevent other clients on the network from presenting their certificates and having them accepted (due to horrific misconfiguration of quite a few other parameters), as proof of server status. This would then not really be a MiTM, but rather a resource substitution attack: connecting not to a server ("node," in modern terms), but rather to some random entity with merely a client certificate for the same VPN network.

That's really not an attack model we're hardening against, for a fairly simple reason: we don't use client certificates. So spoofing a client cert really wouldn't make much sense. Plus they don't actually exist. So that would be a challenge to implement.

The actual RSA-based validation of cert fingerprint and modulus is, of course, done by openssl - not openvpn. One can sit on the pcaps and watch that process unfold...


There's the flag in question; I've highlighted it in the screenshot.

When looking at competitor Ipredator, they use TLS auth: ssl-server: TRUE/FALSE

It'd be easy enough to implement this in our conf's (actually our current confs have an old version of the switch-param for this constraint in them, that I've not upgraded and will likely drop from the 1.5 conf entirely), but doing so would be purely for show. Legitimate security modelling builds scenarios from credible methodologies available to credible attackers via credible attack vectors. Now, if I'm modelling a MiTM attacker against cryptostorm network sessions, I'm going to model in the fact that they're smart enough to generate their hijack-certs with that parameter simply flipped to 'true'... this is obvious, right?

There's no external CA issuing these certs, no authority enforcing these extended attributes. Just like Superfish was able to set whatever conditions on their own self-signed root certs, any MiTM attacker can simply print up super-duper-special server-only certificates... right? So setting that variable would protect against what attackers, exactly? The ones too dumb to know how to change a parameter from false to true? Those aren't the ones we are defending against, either in formal theory or in our daily work.

If one added them up, there's dozens of viable, proven attacks against certificate-protected network security. Our team has been deep in studying those attack vectors for months at this point, on top of years of firsthand experience in the field with the topic. I'd say we have good sense of the lay of the land; there may be super-obscure (or advanced) attack models out there we don't know anything about, but apart from that we are familiar with the ways this system fails.

That's the basis of substantive security assurances: a deep, long-term, engaged dedication to understanding the full range of attacks and defensive methods. From there, one can begin building new attack models not yet discovered by others, and thereby enable proactive defences for them in production. That's the stage we're at, as a team, here. I cannot speak directly to whether other "VPN services" are similarly engaged in the work, but from what I've seen I'd not bet on it.

I understand you're using a self signed certificate but what about this: http://openvpn.net/index.php/open-sourc ... .html#mitm ?

Oh no, not the "self signed certificate" thing.

Should we go pay DigiCert or Comodo or one of the more seedy of the USERtrust mutant offspring to print up a certificate for us and sign it with their root credentials? That will help this process... how? There's no CRLs in this model, right? No OCSP. No cert pinning. Without all of those pieces - which, incidentally, are fundamentally broken for https nowadays, in so many ways I couldn't begin to enumerate them - having a signature from a CA (or chain of fishy CAs, the illustrious "trust store") is worse than useless. It's delusional.

Look, the certificate thing is mostly a distraction from what's really going on here: this is basic RSA asymmetric cryptography in service of identity validation. Private key, public key. That's it. The math is interesting but not horrifically complex. The implementation mechanisms are well-understood and have few obvious crypto engineering fail-states nowadays. We know how to do RSA verifications across the wire, in other words.

The point of that is the mathematical relationship between the private key and the public key. Adding a bit of exogenous entropy to the public key that says "this is a public key for this class of private key" is pretty silly when you get to the core of the entity-relationship structure at work here. That's essentially a one-bit shared secret. Except it's a secret published in the specifications and known to everyone. So... not much of a secret.

We'll pass thanks. Ipredator might think that's a big deal, security-wise. Dunno. We're a bit beyond kindergarten in that regard.

When looking at competitor Ipredator, they use TLS auth


I'm not entirely sure whether you're making a rather nicely-structured joke about what it means to misunderstand the fundamentals of the TLS protocol, or whether this is intended to be serious. I'll at least give the assumption of the latter for as long as I can do so without sounding sarcastic - which is beneath all of us, so we'll not do that.

Using a shared secret - the eponymous "TLS key" - requires the sharing and the secret. It doesn't count as "secret" if you publish the bloody thing on the internet, ffs!


Code: Select all

# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
-----END OpenVPN Static key V1-----

echoed to cleanVPN github repository for research reference

To be clear, there's no harm done in publishing this "static key" - it's not paired with a private key in the conventional sense and having it be shared by the whole world doesn't break anything. Well, except any claim that this "shared secret" does anything useful in protecting network traffic. Because it's not secret. That's sort of the whole point: secret.

Quoting Yonan, again:

...a pre-shared key is generated and shared between both OpenVPN peers before the tunnel is started

"Pre-shared secret." That means it's transmitted out-of-band, securely, prior to the creation of a VPN session.

Further, this feature isn't even intended to be a security layer in the sense of adding cryptographic defence in the conventional sense: protection against decryption of plaintext. Rather, it's designed to mitigate certain classes of DDoS. From the 2.2 documentation:

The rationale for this feature is as follows

TLS requires a multi-packet exchange before it is able to authenticate a peer. During this time before authentication, OpenVPN is allocating resources (memory and CPU) to this potential peer. The potential peer is also exposing many parts of OpenVPN and the OpenSSL library to the packets it is sending. Most successful network attacks today seek to either exploit bugs in programs (such as buffer overflow attacks) or force a program to consume so many resources that it becomes unusable. Of course the first line of defense is always to produce clean, well-audited code. OpenVPN has been written with buffer overflow attack prevention as a top priority. But as history has shown, many of the most widely used network applications have, from time to time, fallen to buffer overflow attacks.

So as a second line of defense, OpenVPN offers this special layer of authentication on top of the TLS control channel so that every packet on the control channel is authenticated by an HMAC signature and a unique ID for replay protection. This signature will also help protect against DoS (Denial of Service) attacks. An important rule of thumb in reducing vulnerability to DoS attacks is to minimize the amount of resources a potential, but as yet unauthenticated, client is able to consume.

--tls-auth does this by signing every TLS control channel packet with an HMAC signature, including packets which are sent before the TLS level has had a chance to authenticate the peer. The result is that packets without the correct signature can be dropped immediately upon reception, before they have a chance to consume additional system resources such as by initiating a TLS handshake. --tls-auth can be strengthened by adding the --replay-persist option which will keep OpenVPN's replay protection state in a file so that it is not lost across restarts.

It should be emphasized that this feature is optional and that the passphrase/key file used with --tls-auth gives a peer nothing more than the power to initiate a TLS handshake. It is not used to encrypt or authenticate any tunnel data.

In terms of DDoS protection... yeah. Booters work fine without needing consume TLS-layer resources. So I think this was well-intended, but not terribly effective in actual practice - this is hardly a failure or flaw in the design of the function more or less a decade ago, and merely reflects the evolution of attack techniques since then. Amplified, DNS-based packet floods are so broadly deployed nowadays that talking about TLS-layer, targeted, technically clever DDoS mechanisms seems rather quaint.

There's a second possible benefit to this TLS-auth key/HMAC scheme, which is nicely summarised in Yonan's documentation:

One notable security improvement that OpenVPN provides over vanilla TLS is that it gives the user the opportunity to use a pre-shared passphrase (or static key) in conjunction with the --tls-auth directive to generate an HMAC key to authenticate the packets that are themselves part of the TLS handshake sequence. This protects against buffer overflows in the OpenSSL TLS implementation, because an attacker cannot even initiate a TLS handshake without being able to generate packets with the currect HMAC signature.

Yes, well, I have never been terribly convinced this is a substantive security benefit. Turns out that was not too far off-based, because Heartbleed. So much for the theory of buffer overflow protection from tls "static keys."

Indeed, adding extra fiddly bits to cryptographic processes that provide minimal actual security benefit can itself be a serious security risk. All those fiddly little bits accrue bugs or are born with them outright, and those bugs are exploits waiting to be developed. How can I say this? Well, because Heartbleed. And Shellshock. And GHOST. And FREAK. And on and on...

ὅπερ ἔδει δεῖξαι άλφα

Also, obviously, the fact that these static keys (or a tiny bit of them; see below) serve as the cipher key for this HMAC and are widely distributed in public means that an attacker who did want to implement this TLS-layer vector can simply grab the key materials from the published "private" key and use it to remove any potential hindrance offered by tls-auth whatsoever. Making the entire process completely, totally useless... worse than useless in fact, as it adds non-constructive complexity to a cryptographic procedure and this, ceteris paribus, decreases overall system security.

So yay for iPredator for following Yonan's yellowed, old, well-meaning sentences about auth-tls... but maybe it's not really a reflection of their superior cryptographic awareness. Or perhaps they did a deep analytic dive into these waters, and just happened to come to exactly the same archaic conclusions Yonan did all those years ago... the same ones published in that outdated howto for making openvpn secure. Unlikely, but possible I suppose.

A final bit of historical data comes from the full specification of the TLS-key parameter in the openvpn documentation. I note that ipredator has proudly included the text "2048 bit OpenVPN static key" in their distributed keyfile (perhaps not "proudly" - it might just auto-generate during the process... still, they do distribute it with that phrase embedded in the strings, which seems sort of goofy to me, fwiw). Because - WOW - that's alot of bits! Bits are good, right?

Well, actually...

The 2048 bit static key is designed to be large enough to allow 512 bit encrypt, decrypt, HMAC send, and HMAC receive keys to be extracted from it.

However, this key size is far too large for current conventional OpenVPN usage. OpenVPN uses the 128 bit blowfish cipher by default. It also uses the 160 bit HMAC-SHA1 as a cryptographic signature on packets to protect against tampering. Since you probably didn't specify a key direction parameter, the encrypt/decrypt keys for both directions are the same and the HMAC keys for both directions are also the same.

That means that OpenVPN is only actually using 128 + 160 = 288 bits out of the file -- much less than the 2048 bits which are available. Below, I will show a sample 2048 bit OpenVPN key, bracketed to show which bits are actually used for key material, assuming default crypto settings:

# 2048 bit OpenVPN static key
-----BEGIN OpenVPN Static key V1-----
[eac9ae92cd73c5c2d6a2338b5a22263a] -> 128 bits for cipher
[f702cb04c7d15ff2606736c1825e830a -> 160 bits for HMAC SHA1
7e30a796] 4b82825d6767a04b3c8f4583
-----END OpenVPN Static key V1-----

As you can see, the only lines actually used are 1, 5, and 6. And of course, that matches up perfectly with what you observed.

To verify this, run OpenVPN as follows:

Code: Select all

openvpn --dev null --verb 7 --secret key | grep 'crypt:'

where 'key' is a file containing the key shown above.

    Static Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Static Encrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
    Static Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Static Encrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796
    Static Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
    Static Decrypt: CIPHER KEY: eac9ae92 cd73c5c2 d6a2338b 5a22263a
    Static Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
    Static Decrypt: HMAC KEY: f702cb04 c7d15ff2 606736c1 825e830a 7e30a796

Note that the keys which are shown in the OpenVPN output exactly match the bracketed section of the key source.


So you might ask why is the OpenVPN static key file so large, if such a small percentage of the bits are currently used? The answer is to accomodate future ciphers and HMAC hashes which use large keys. Changing a file format is obviously problematic from a compatibility perspective, so 2048 bits were chosen so that two sets of 512-bit encrypt and HMAC keys could be derived for two separate key directions.

So, in actual practice, the entropy from the keyfile that's actually used in the TLS-auth parameter's implementation is 160 bits, just enough to sign the SHA1'd hash of the packet HMAC (I am not sure what signing algorithm is used in this, and haven't yet gone to the source code to learn the details - if anyone does, and wants to post that in replies to this thread, that'd be pretty interesting to see). It's exactly the fifth line in the PEM"d keyfile itself.

So for the ipredator TLS key, this is what's actually used in any cryptographic algorithm:

Code: Select all


That's in hexadecimal. Let's convert to binary (as in bits, small-b), just for the fun of it. We get...

Code: Select all


Which neither comes out to a full 160 bits of entropy (it's 128 bits, actually), nor does it give much confidence in its entropic content. The latter makes one wonder what PRNG seed was being used for the RSA generation algorithm when this key was created... but at this point we're pretty far into the weeds with all this, and it might be time to step back and wrap up this boring post.

edited to add: I bet they use the 128 bits of data as the Blowfish key, and they bring in the 160 bit (always) output of the SHA1 hash of the contents of the packet (and header) as plaintext to be run through Blowfish. But I'm not going to confirm this, because I'm supposed to be wrapping up this post!

(Incidentally, leaving some extra capacity in the defined keyspace for future use is to me excellent thinking on the part of the designers of the protocol. It shows foresight and a willingness to do smart things even if it's not likely many folks will notice them until much later, if ever. One does see such decisions throughout the openvpn codebase, one reason the protocol has justifiably gained such widespread support.)

One final question was asked:

There is this thread, but this should be automated, no?

The question relates to our thread here in the forum entitled "HOWTO: confirm authenticity of cryptostorm.is & cryptostorm.org SSL certs," an excerpt of which reads as follows...

Here are the currently-installed SSL certificates (public exponent) for our two main production websites, cryptostorm.org & cryptostorm.is. We will also add certificate materials for secondary domains such as torstorm.org, as well as keep this post updated with current materials as we upgrade or otherwise adjust our CA credentials server-side.

Note that neither of these two identity-verifying server certificates are part of connections to cryptostorm's network; rather, they simply exist to confirm that the websites folks are visiting using TLS/SSL (https protocol) are actually the websites we run, and not a Man-In-The-Middle replacement undertaken by an attacker.

Although this thread is discussing keying materials that back the https sessions of cryptostorm.is and cryptostorm.org, respectively, your question is insightful and highly relevant. The process of confirming validity of those certificate materials is currently automated for https web sessions... by web browsers, via the Certificate Authority (CA) PKI model. Which is a horror. The reason we do a non-automated validation is exactly to enable manual confirmation of those materials. It is difficult for attackers to model systems designs that include manual elements, because manual stuff is all squishy and weird because humans.

That's a feature, not a bug, in this context. Stick a human in the mix, and an automated attack model has a much more complex challenge to face.

That said, we are in process of automating validation via out-of-band mechanisms the authenticity of public key materials for web-based (and other online) resources. That project, Decentralised Attestation, has as its Proof of Concept (PoC) confirmation of exactly the cert/key materials backing cryptostorm network sessions that we've been discussing in this thread.

So that's a really solid question, that touches on the core of alot of the work the cryptostorm team has been doing this winter.

I don't know of similar work ipredator is doing in such areas, but perhaps I've just not run into their published contributions in my literature review thus far.

~ ~ ~

I apologise if I have sounded crabby in this post. It's not intended as disrespect, and in truth these conversations are always helpful - dialogue is the core of good security process. I've been, personally, buried in cert-based validation systems analysis for... a while now, as cryptostorm prepares to deploy its own 'Decentralised Attestation" (DA) model as an alternative to the broken CA model. And that research has left me more than a little crabby, for a host of reasons I'll not bore you with here.

Suffice it to say that there's oceans of legitimate CA/PKI/identity authentication issues to concern ourselves with in the real world (as opposed to the "VPN industry" which is... broken, in so many ways, even more so than the CA world is - which is amazing), as well as a crying need for deployed systems that address those issues in a substantive and credible way. This silly stuff with old advice about old understandings of old attacks that even in the old days nobody did because real attacks were faster, easier, and worked better... it's really not the most crucial parts of the dialogue, imho.

That said, it's a starting point, eh? So, again, my apologies for the crab-ness - and I thank you for the questions posed.


    ~ pj

ps: ipredator is using cert signatures generated with SHA1 = "Signature Algorithm: sha1WithRSAEncryption" - which is long since recommended against in any security-intensive context, and they've issued a decade-long self-signing CA certificate which is generally considered bad security practice. We certainly don't do either in production context. Fwiw.

"WARNING: No server certificate verification method has been enabled." in logs

Post by pants » Mon Mar 09, 2015 10:16 pm

{direct link: cryptostorm.org/certcrypto}
{edited to make links click-y & image appear in-post ~admin}

Hi, I'm just testing cryptostorm here, what's the deal with "WARNING: No server certificate verification method has been enabled. See openvpn.net/howto.html#mitm for more info." in the logs?

I understand you're using a self signed certificate but what about this: openvpn.net/index.php/open-source/documentation/howto.html#mitm?

When looking at competitor Ipredator, they use TLS auth:


There is this thread - cryptostorm.org/sslcerts but this should be automated, no?


Nothing to display.