Bonjour,
Le 10/10/2013 18:29, int0...@safe-mail.net a écrit :
Hi,
I've been asking this on the OpenVPN mailinglist, but didn't get an answer so
far. Therefore I hope you can help me.
We use OpenVPN in our company with the default cipher suite, which should be:
DHE_RSA_BF_CBC_SHA
So RSA is used for authentication, Blowfish in CBC mode for symmetric
encryption. The keys for Blowfish are derived from ephermal Diffie-Hellman and
changed every hour.
Make sure you don't encrypt more than 2^35 bytes with the same BF key.
Otherwise, you have an additional problem.
We use a keysize of 1024 bit for RSA and therefore a modulus of 1024 bit for
Diffie-Hellman (OpenVPN uses the Easy RSA scripts. These scripts use a variable
"KEY_SIZE" when the Diffie-Hellman parameter or the RSA keys ar built. This
variable is set to 1024). Furthermore we use a self-signed CA.
Some days ago I recommended to update the key size to 2048 bit, mainly because
some sources say 1024 bit aren't enough anymore. Because quite a lot of our
staff uses OpenVPN, they asked me, if it is possible, to not update all keys at
once - but only issue user certs with 2048 from now on for new OpenVPN users
(and leave the old ones in places for later update).
The process of doing that should look like that:
a) Change variable KEY_SIZE used in Easy RSA scripts from 1024 to 2048 (bit).
b) Create new Diffie-Hellman params with the Easy RSA build-dh script (will
create the params with 2048 bit modulus).
c) Update the OpenVPN server config with the path of the new Diffie-Hellman
param file.
Now here are my concerns and why _I_ think, that is a bad idea:
If I do it like that, new users would get 2048 bit keys/cert as requested by the company. But theses certs would still
be signed by our self signed CA which still uses the old 1024 bit key/cert. Given that an attacker has enough computing
power, he could factorize "n" (from the pub key in the CA cert) to get "p" and "q". With
that he would have our CA's private key, being able to create a faked server cert and sign it with the CA key. With
that server certificate the attacker could launch a man in the middle attack. That would mean: Authentication via RSA
would be "leveraged".
As in "broken"? Yes.
So my question are:
I. Am I right, or is that rubbish?
You're right. On the other side, how powerful are your opponents? 1024
bits factorization isn't an easy task, it requires a large amount of
money. "Large" isn't a precise number, for sure; I'd place the lower
limit at 1M$. But don't trust me.
II. Is an attacker able to get the CA cert at all? It looks as if during TLS
handshake only the User certificate and the Server certificates are
transmitted, but not the CA cert.
A public key isn't designed to be kept private. Given some certificates
signed by the same private key, the modulus of the signer key can be
guessed.
Consider your CA modulus to be public.
III. To complicate things a bit more:
OpenVPN supports a so called "tls-auth" directive which takes a 160 bit key.
According to the OpenVPN documentation this key is used to generate a HMAC over every
packet during TLS handshake (and append it?). It looks as if this is not part of TLS
itself, but a modified implementation of TLS. They say, that without the key, not even
the handshake would work.
So my last question is:
If the CA cert, can be requested from the OpenVPN Server somehow, that wouldn't
work anymore, if such a key is used. Is that correct?
It depends on how this key is used. I don't have any opinion on this point.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
