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.]
