Hi,
I agree with you that admin may be confused if he won't specify --dh
option and server will work but refusing some clients.
He could just forget adding this option or don't know it's neccessary.
I think we could add option "--dh none" or "--no-dh". It may be
specified, if user knows what he's doing.
Option --no-ecdh( or --ecdh none ) could be useful if user does not want
to use ECDH for some reason.
Also, to avoid unexpected behaviour like fallback into RSA, we could
force openssl to use DH or ECDH only.
Piotr Jarosz
On 02/26/14 21:57, Steffan Karger wrote:
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
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
