Re: Preparing openvpn3 packaging for review - openssl challenges
by Tomas Mraz
On Wed, 2020-02-19 at 11:06 +0100, David Sommerseth wrote:
> On 19/02/2020 08:25, Tomas Mraz wrote:
> [...snip...]
> > > if (!SSL_CTX_set_cipher_list(ctx,
> > > /* default list as a
> > > basis
> > > */
> > > "DEFAULT"
> > > /* Disable export
> > > ciphers,
> > > low and medium */
> > > ":!EXP:!LOW:!MEDIUM"
> > > /* Disable static
> > > (EC)DH
> > > keys (no forward secrecy) */
> > > ":!kDH:!kECDH"
> > > /* Disable DSA private
> > > keys */
> > > ":!DSS"
> > > /* Disable RC4 cipher
> > > */
> > > ":!RC4"
> > > /* Disable MD5 */
> > > ":!MD5"
> > > /* Disable unsupported
> > > TLS
> > > modes */
> > > ":!PSK:!SRP:!kRSA"
> > > /* Disable SSLv2
> > > cipher
> > > suites*/
> > > ":!SSLv2"
> > > ))
> > > OPENVPN_THROW(ssl_context_error,
> > > "OpenSSLContext:
>
> [...snip...]
>
> > > The second block should really be fine too, it just strictly
> > > enforces
> > > a fairly
> > > strict default set of ciphers.
> >
> > No, the second call is not correct. Basically there should be no
> > call
> > to SSL_CTX_set_cipher_list() unless the user explicitly wants to
> > override the defaults. The default in Fedora is already sane and
> > safe
> > and ensures the crypto policy is properly applied.
>
> I brought your argument up internally, and added Arne Schwabe on Cc
> as he
> knows both OpenVPN and OpenSSL and how they integrate even better.
>
> We understand and agree that the system running OpenVPN should be
> able to
> define the defaults and avoid hard-coding it. But we explicitly want
> to
> remove any non-PFS compliant ciphers (like kDH, kECDH, kRSA), which
> in most
> cases makes the setup stricter than the system
> configuration. Currently we
> see that Fedora's default ciphers allow some non-DH/ECDH and non-PFS
> capable
> ciphers.
>
> Another aspect is that since OpenVPN is talking strictly to other
> OpenVPN
> capable products (where SoftEther is the only product we're aware of
> not being
> under the fold of OpenVPN Inc or the OpenVPN community). This
> results in
> OpenVPN being able to further reduce the available ciphers further
> than the
> more standard TLS defaults, thus increasing the security level of the
> TLS
> channel for the VPN tunnel.
>
> At the same time we also see the argument where someone wants an even
> stricter
> set of ciphers. In OpenVPN 2, we have that capability via --tls-
> cipher and
> --tls-ciphersuites (for TLSv1.3). I do see that OpenVPN 3 lacks
> these
> options, but that is something we are looking into.
This would not be an issue if these options are used only when user
explicitly configures them.
> If there is a better way to narrow down the list of ciphers we allow
> in
> OpenVPN instead of replacing the cipher list, that would be even
> better from
> our point of view. We are really reluctant to implicitly open up for
> ciphers
> which reduces the security level of OpenVPN, where PFS ability is a
> critical
> part of the ciphers being used.
You can use "PROFILE=SYSTEM" instead of "DEFAULT" as a start. However
this special string is downstream-only.
--
Tomáš Mráz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]
3 years, 3 months
Preparing openvpn3 packaging for review - openssl challenges
by David Sommerseth
Hi,
I'm running rpmlint against packages built based on the Fedora Copr [1] build
I've provided for some time. I'm planning to move this forward for the standard
Fedora and EPEL repositories. But rpmlint complains about the usage of
SSL_CTX_set_cipher_list(), which I in this case would call a false-positive
for OpenVPN.
[1] <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/>
<https://gitlab.com/dazo/copr-openvpn3>
The code which trips this warning is:
-------------------------------------------------------------------------------
if (config->force_aes_cbc_ciphersuites)
{
if (!SSL_CTX_set_cipher_list(ctx, "DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA"))
OPENVPN_THROW(ssl_context_error, "OpenSSLContext: SSL_CTX_set_cipher_list failed for force_aes_cbc_ciphersuites");
}
else
{
if (!SSL_CTX_set_cipher_list(ctx,
/* default list as a basis */
"DEFAULT"
/* Disable export ciphers, low and medium */
":!EXP:!LOW:!MEDIUM"
/* Disable static (EC)DH keys (no forward secrecy) */
":!kDH:!kECDH"
/* Disable DSA private keys */
":!DSS"
/* Disable RC4 cipher */
":!RC4"
/* Disable MD5 */
":!MD5"
/* Disable unsupported TLS modes */
":!PSK:!SRP:!kRSA"
/* Disable SSLv2 cipher suites*/
":!SSLv2"
))
OPENVPN_THROW(ssl_context_error, "OpenSSLContext: SSL_CTX_set_cipher_list failed");
#if OPENSSL_VERSION_NUMBER >= 0x10002000L && OPENSSL_VERSION_NUMBER < 0x10100000L
SSL_CTX_set_ecdh_auto(ctx, 1); // this method becomes a no-op in OpenSSL 1.1
#endif
}
-------------------------------------------------------------------------------
These calls can be found in openvpn/openssl/ssl/sslctx.hpp
<https://github.com/OpenVPN/openvpn3/blob/b62654274fd938ebb82dbe3a2e78d9b8...>
The first SSL_CTX_set_cipher_list() is being slate for removal, as the
"force_aes_cbc_ciphersuits" feature is not considered needed any more;
negotiation works much better nowadays than when this was added
about 5 years ago. But the cipher-list here shouldn't be of that much
concern.
The second block should really be fine too, it just strictly enforces a fairly
strict default set of ciphers.
So my question is if this will be a show-stopper for getting the openvpn3
package into the standard Fedora + EPEL repositories?
--
kind regards,
David Sommerseth
OpenVPN Inc
3 years, 3 months