Hi,
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.
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.
Server should not fail if user won't specify DH nor ECDH - it just could
fall back into ECDH.
Piotr Jarosz
On 02/25/14 01:39, Steffan Karger wrote:
Hi Piotr,
On 24-02-14 01:28, pietrek -- wrote:
Hi Steffan,
I modified my patch again. And thanks for your code - it helped me.
Good to hear it helped you. But your new patch basically is my code now,
except that it accepts a configuration without a DH-file.
1) In such case server will set ecdh=auto.
2)That's a good idea.
I added initializing both ECDH and DH on server side if they're
specified in config.
Good.
3)It works for me without specifying anything on client side.
I can also specify different curve for ECDH than used in certificates
without any errors.
You're completely right, sorry for putting you on this side track.
I added warning if DH isn't specified - old client may not support ECDH.
Autodetecting ecdh is a good idea - I made option ecdh=auto.
On the long run I agree that a warning should suffice, but for now I
would really like to stick with forcing the DH-file to be present. Lots
of people using OpenVPN do not understand the crypto or configuration
options properly, but do rely on it for secure communication. As long as
EC-crypto is not common, I prefer to make sure OpenVPN can always fall
back on DH.
Most of the curves secp, prime, sect work, but some of them ( eg.
wap-wsg-idm-ecid-wtls10 ) cause ssl error 'no shared cipher'.
Working curves examples:
...
Failing examples:
...
Not all curves supported by OpenSSL are available for use in SSL/TLS,
wap-wsg-idm-ecid-wtls10 sounds like a perfect example of that.
Furthermore, the available curves depend on you version and
configuration of OpenSSL.
One of the things I do not completely grasp yet is why some cipher
suites succeed (e.g. TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA works for me),
but some slightly different ones do not (e.g.
TLS-ECDHE-ECDSA-WITH-AES-256-CBC-SHA384 and
TLS-ECDH-ECDSA-WITH-AES-256-CBC-SHA do not work for me), even though all
the primitives for those suites are available from the version of
OpenSSL I'm using. Still, the behaviour is different for various OpenSSL
versions. Have you stumbled across this already?
I also copied from your code option --show-curves, manual entries and EC
curve autodetection.
Credits for those lines go to Jan Just actually. About the copying,
wouldn't it make more sense if you'd review my implementation, instead
of copying it? The bulk of it is my code now anyway.
Although there is apparently more work to do to get more cipher suites
working, this does give us a start on working with EC-crypto. Maybe this
part can go in (once ACK'ed) as 'the start of EC-support', so more
people can help improve the code. Any other opinions on this?
Regards,
-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
