Re: Preparing openvpn3 packaging for review - openssl challenges

[Tomas Mraz]

On Wed, 2020-02-19 at 12:35 +0100, David Sommerseth wrote:
> On 19/02/2020 11:33, Tomas Mraz wrote:
> > 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:!MEDIU
> > > > > M"
> > > > >/* 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.
> 
> OpenVPN 2.x does a similar call today, and has done it since at least
> the
> early days in v2.3 (February 2012) - possibly even longer (the source
> tree
> changed a lot from 2.3, so didn't try to follow the code any more
> than this).
> 
> This cipher list has gradually become stricter and stricter over the
> years,
> and is nowadays fairly similar to what we have in OpenVPN 3.  That
> is, this
> OpenVPN default setting will be overridden if the user adds --tls-
> ciphers to
> their config with a list of allowed ciphers.  And we normally
> discourage users
> from setting their own list of TLS ciphers.
> 
> > > 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" i

Re: Preparing openvpn3 packaging for review - openssl challenges

[David Sommerseth]

On 19/02/2020 11:33, Tomas Mraz wrote:
> 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.

OpenVPN 2.x does a similar call today, and has done it since at least the
early days in v2.3 (February 2012) - possibly even longer (the source tree
changed a lot from 2.3, so didn't try to follow the code any more than this).

This cipher list has gradually become stricter and stricter over the years,
and is nowadays fairly similar to what we have in OpenVPN 3.  That is, this
OpenVPN default setting will be overridden if the user adds --tls-ciphers to
their config with a list of allowed ciphers.  And we normally discourage users
from setting their own list of TLS ciphers.

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

It's a pity that this is Fedora (and possibly RHEL?) specific.  But that is
something we can use.  Do you know if any other distros than Fedora/RHEL have
taken this approach?  Just wondering if I should just do the patching in the
.spec file, or add some build-time macros in the upstream OpenVPN 3 project.
If it is only Fedora/RHEL, it makes it hard to push for an upstream OpenVPN 3
change.


-- 
kind regards,

David Sommerseth
OpenVPN Inc
___
security mailing list -- security@lists.fedorapr

Re: Preparing openvpn3 packaging for review - openssl challenges

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

___
security mailing list -- security@lists.fedoraproject.org
To unsubscribe send an email to security-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/security@lists.fedoraproject.org

Re: Preparing openvpn3 packaging for review - openssl challenges

[Tomas Mraz]

On Tue, 2020-02-18 at 21:16 +0100, David Sommerseth wrote:
> 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] 
> 
> 
> 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 <
> 0x1010L
>   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/b62654274fd938ebb82dbe3a2e78d9b8fd465970/openvpn/openssl/ssl/sslctx.hpp#L1094
> >
> 
> 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;

As this would be non-default setting, it would be fine anyway.

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

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.

> So my question is if this will be a show-stopper for getting the
> openvpn3
> package into the standard Fedora + EPEL repositories?

Please just patch out the second call.

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

___
security mailing list -- security@lists.fedoraproject.org
To unsubscribe send an email to security-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/security@lists.fedoraproject.org

Preparing openvpn3 packaging for review - openssl challenges

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


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 < 
0x1010L
  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


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
___
security mailing list -- security@lists.fedoraproject.org
To unsubscribe send an email to security-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/security@lists.fedoraproject.org