Hi,

On 26-02-14 21:04, pietrek -- wrote:
> I tested what would happen if any key exchange protocol will be specified.
> It works as I expected: connection failed with error: 'no such cipher'.
> So session cannot work without ECDH and DH.
> Also, if OpenSSL would accept it, it would be an invitatation for men in 
> the middle ;)
>
> For clients without ECDH connection will just fail.

Interesting, with the current setup and OpenSSL behaviour (at least up
to OpenSSL 1.0.1) you are right. Since commit 813aa55 (last January),
where ephemeral RSA support was dropped, OpenVPN knows no other way for
key exchange but DH (and ECDH after the updates). Without that, OpenVPN
would fall back to RSA for key exchange, which is not directly
vulnerable to man-in-the-middle attacks, but it would mean falling back
to less secure cipher suites.

However, we completely depend on OpenSSL being incapable of doing some
sort of key exchange automatically, which I think is a bit risky. If we
can make absolutely sure OpenSSL will not fall back, we might be able to
remove the requirement for the DH-file from a security perspective.

> In my opinion forcing users to specify DH key isn no longer neccessary, 
> because this file generates
> long and protection against men in the middle attack is as strong as the 
> weakest encryption algorithm
> so if DH will be weaker than ECDH curve, even the best curve won't 
> improve security against such attack.

OpenSSL prefers ECDH over DH, so if both client and server support it,
the connection would not use DH. A user who does not trust DH anymore
could specifiy something like --tls-cipher DEFAULT:\!DH:\!EXP to
explicitly forbid usage of DH.

I agree that the DH-file generation is not one of OpenVPN's most
user-friendly features, but a server administrator has to it just once
and clients are not bothered by it at all.

Furthermore, I expect that if we would make it 'too easy' to create
ECDH-only servers many people would run into trouble when one of their
peers has an older version of OpenVPN (of which there are a *lot*) and
gets the "no shared cipher" error. An administrator diving into the
crypto, specifying explicitly to not trust DH should be able to cope
with that, but new users probably do not.

To conclude, I agree with you that the restriction on the DH-file should
eventually disappear, I just think right now is a bit premature.

-Steffan

Reply via email to