leonklingele

[ req ]
default_bits = 4096
default_md = sha256
default_keyfile = private.key
distinguished_name = req_distinguished_name
attributes = req_attributes
x509_extensions = v3_user_req
req_extensions = v3_user_req

[ req_distinguished_name ]

leonklingele

Apparently, OpenVPN 2.4.3 was released in two different revisions:
- Revision 1 (openvpn-2.4.3-r1) which was available on Wed Jun 21 14:00:36 2017 +0200
- Revision 2 (openvpn-2.4.3-r2) which was and is still available after r1

---

diff -Naur openvpn-2.4.3-r1/Makefile.in openvpn-2.4.3-r2/Makefile.in
--- openvpn-2.4.3-r1/Makefile.in	2017-06-20 15:10:10.000000000 +0200
+++ openvpn-2.4.3-r2/Makefile.in	2017-06-20 13:07:43.000000000 +0200
@@ -1,7 +1,7 @@

leonklingele

<?php

$crypto = new Crypt('cbe92e0557602e1bf9c05fffe8e54a809c1bdc5b3c3e2011b9153ce0ce672917', 'ok');

$enc = $crypto->encrypt('secretmessage');

// Here we prepend an 'a' -> Decryption should fail, i.e. return false
// It should NOT trigger an E_ERROR, as we can't handle that.
$dec = $crypto->decrypt('a' . $enc);

leonklingele

What we do now:
We use a static record size of 4K. This gives a good balance of latency and
throughput.

Optimize latency:
By initialy sending small (1 TCP segment) sized records, we are able to avoid
HoL blocking of the first byte. This means TTFB is sometime lower by a whole
RTT.

Optimizing throughput:

leonklingele

Encrypting data (Was: AES-CTR with HMAC): Use, in order of preference: (1) The Nacl/libsodium default, (2) Chacha20-Poly1305, or (3) AES-GCM.

You care about this if: you're hiding information from users or the network.

All three options get you "AEAD", which is the only way you want to encrypt in 2015. Options (2) and (3) are morally the same thing: a stream cipher with a polynomial ("thermonuclear CRC") MAC. Option (2) gets there with a native stream cipher and a MAC optimized for general purpose CPUs; Poly1305 is also easier than GCM for library designers to implement safely. Option (3)'s AES-GCM is the industry standard; it's fast and usually hardware accelerated on modern processors, but has implementation safety pitfalls on platforms that aren't accelerated.

Avoid: AES-CBC, AES-CTR by itself, block ciphers with 64-bit blocks --- most especially Blowfish, which is inexplicably popular, OFB mode. Don't ever use RC4, which is comically broken.

Symmetric key length (Was: Use 256 bit keys

leonklingele

Certificate validation/creation pitfalls

A x509 certificate, and in particular the latest version 3, is the standard for authentication in Public Key Infrastructures (PKIs). Think about Google proving that he's Google before you can communicate with him.

So. Heh. This x509 thing is a tad complicated. Trying to parse such a thing usually end up in the creation of a lot of different vulnerabilities. I won't talk about that here. I will talk about the other complicated thing about them: using them correctly!

So here's a list of pitfalls in the creation of such certificates, but also in the validation and use of them when encountering them in the wild wild web (or in your favorite infrastructure).

1. KeyUsage
2. Validity Dates