On 14/11/2019 16:39, Thomas Luening wrote: > Hello David, Gert > > Thank you very much for your answers.... which were partially now also a > confirmation of how I have understood that so far. > > Am 14.11.19 um 11:51 schrieb Gert Doering: >> As David explained in great detail just last week, the data channel keying > is seeded from the TLS handshake. Always. > > I have work with it the last days :-) The problem was probably due to a > misunderstanding, because I thought, I have (!) to force (!) explicit DH'E' or > ECDH'E' to determine, that a ephemeral key with the DH-Algorithm is determined > for symmetric encryption on the Data-Channel ... and without the 'E' the > session-key on Data-Channel could repeat itself, like static. But it seems to > be different ...TLS V1.3 on the Control-Channel always negotiates an ephemeral > session key for the data channel. But that was the point, I could see that > earlier about the TLS-Cipher-Statement (EC)DH'E'. And the 'E' says to me > "ephemeral key is forced to use". At now I only have missed some hint on it, > but that seems to be the default behavior with TLS V1.3. > > Am 14.11.19 um 11:51 schrieb Gert Doering: >> So unless you decide to run OpenVPN without TLS (which you can, but which > has not >> been recommended since 10+ years), you will never have a static key for data > channel. > > I think the sentence above has answered my main-question. > > Am 14.11.19 um 12:51 schrieb David Sommerseth: >> I would still recommend to kick out --tls-cipher, and consider setting > --tls-version-min to at least 1.2. >> If you know all your clients are capable of TLSv1.3, then set it to 1.3. > > tls-version-min 1.2 and tls-crypt has always been set. And at the moment I > haven't yet decided to set 1.3 as the default. I'll check that out at next, to > see if that is possible with my Hardware. > > Am 14.11.19 um 12:51 schrieb David Sommerseth: >> I would recommend to*not* use --tls-cipher. > > OK, that's decided, I'm not going to use the cipher statement in the future, > because TLS will always choose the best one. > > I just don't know yet, how I have to deal with --dh or --ecdh-curve now.
You will need --dh on the server side. For the --ecdh-curve, you need to have
a certificate and key file using EC, not RSA key.
To verify your key, run this command:
$ openssl ec -noout -text -in /path/to/private.key
If that fails, then try:
$ openssl rsa -noout -text -in /path/to/private.key
The first command will dump out the characteristics of an EC key, the second
one an RSA key.
> In
> the past I used either to specify a dh.pem file or --dn none and --ecdh-curve.
--dh none is not advisable, that will basically use a hard coded DH parameters
file. Which is known to be vulnerable for attacks (logjam/weakdh attack).
But I'm not sure how that affect an EC setup, but afaik, it is needed.
> Now, if I don't specify --ecdh-curve, secp384r1 will be added automatically.
> If I only use a dh.pem file, the message "Diffie-Hellman initialized with 4096
> bit key" will appear and secp384r1 is added anyway with the message "Failed to
> extract curve from certificate (UNDEF), using secp384r1 instead".
That sounds odd. I run a server with this version:
OpenVPN 2.4.8 x86_64-redhat-linux-gnu [Fedora EPEL patched] [SSL (OpenSSL)]
[LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] built on Nov 1 2019
library versions: OpenSSL 1.0.2k-fips 26 Jan 2017, LZO 2.06
And I see these lines in my log:
Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384,
521 bit EC, curve: secp521r1
Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Please notice the 'ECDHE-ECDSA'.
This server config uses:
ecdh-curve secp521r1
cipher AES-256-GCM
tls-version-min 1.2
tls-crypt vpn.tc
dh dh4096.pem
And addition the mandatory key, cert and ca options. The certificate has the
key parameters (extract from 'openssl ec'):
ASN1 OID: secp521r1
NIST CURVE: P-521
When checking the certificate (openssl x509 -noout -text -in /path/to/cert), I
see:
Subject Public Key Info:
Public Key Algorithm: id-ecPublicKey
Public-Key: (521 bit)
[...]
ASN1 OID: secp521r1
NIST CURVE: P-521
> How can I decide on whether ECDH or DH should be used? Is it even necessary
> to specify this explicitly as before? At the moment I would prefer the dh.pem
> file, even if EC are supposed to be more perfomanter.
That is actually controlled by the TLS handshake, and further restricted by
the --tls-cipher option. But if you key and certificate is a RSA key-pair,
you will not see the ECDSA part in the cipher. ECDHE might be related to what
both client and server side supports (are both sides running the same OpenSSL
and OpenVPN versions?).
> Sorry, I have a little bit a guilty conscience because of my questions, but
> with the change from 1.2 to 1.3 more has changed than you might think at first
> sight. And this topic is so extremely demanding, that you alone can never find
> the right way without hints. BTW, what you can find on the internet is
> sometimes quite contradictory... which doesn't make it easy either.
There are areas here where I am on thinner ground. But as long as I am not
corrected by other trusted community members (Gert, Arne, Steffan), I
shouldn't be comletely wrong :) But there are lots of blog posts on the
Interweb which is just plain wrong; unfortunately also too many posts on how
to setup a "secure" OpenVPN server (many which do fail badly here).
--
kind regards,
David Sommerseth
OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
