Re: [Openvpn-devel] build against openssl 1.1.0

[Christian Hesse]

David Sommerseth  on Sat, 2017/02/18 02:52:
> On 17/02/17 22:59, Emmanuel Deloget wrote:
> > I'm not targetting 2.4 -- my work is done on the current master. Adding
> > hundreds of lines to the current 2.4 for the purpose of supporting a
> > library which is not yet present on the user systems does not make much
> > sense :)  
> 
> Currently, master and release/2.4 are fairly close ... so it shouldn't
> be too hard to cherry-pick stuff from master (which we usually prefer to
> do).
> 
> With that said ... I know Fedora have OpenSSL v1.1 support on their wish
> list for for OpenVPN [1] and I believe Arch Linux guys have also been
> asking about this too.  So the more leading edge distros are moving
> towards OpenSSL v1.1 as fast as possible

Arch Linux guy started this thread. ;)

Would be great to have openssl 1.1.0 support in master soon. Maintaining
backported patches downstream should not be a problem.

From my point of view having support for openssl 1.1.0 in release/2.4 would
be even better to minimize packaging workload.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


pgpTx8wUzeaW0.pgp
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH applied] Re: OpenSSL: check for the SSL reason, not the full error

[Gert Doering]

Your patch has been applied to the master and release/2.4 branch.

2.3 does not have this code, as far as I could see, so doesn't get 
the patch.

I can't reach sf.net right now (git.code.sf.net gives me "connection
refused"), so only pushed to github and gitlab.

commit 6ddc43d1bf9b3ea3ee5db8c50d56a98fe4db4c97 (master)
commit c4c359736e3ab7f06a21f1eab09e6fd4cf2bef2f (release/2.4)

Author: Emmanuel Deloget
Date:   Fri Feb 17 23:00:53 2017 +0100

 OpenSSL: check for the SSL reason, not the full error

 Signed-off-by: Emmanuel Deloget 
 Acked-by: Steffan Karger 
 Message-Id: 
<0e0d4a67192b563cd07d3f06685f85e34c304142.1487368114.git.log...@free.fr>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14087.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] build against openssl 1.1.0

[Gert Doering]

Hi,

On Sun, Feb 19, 2017 at 04:12:02PM +0100, David Sommerseth wrote:
> But things may change again.  I heard recently that Red Hat is migrating
> over to OpenVPN as the only internal IT supported VPN solution.  So
> about 10k employees will soon depend on OpenVPN for their daily VPN
> need.  We will see when RHEL 8 gets released :)

Interesting times!

gert

-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

[Gert Doering]

Hi,

On Sun, Feb 19, 2017 at 01:03:45PM +0100, Steffan Karger wrote:
> Thank you very much.  You approach looks good to me, and quite closely
> matches what I had in mind for when I would find the time to tackle
> this.  (Which might have taken me a while, so really happy to see these
> patches!)
[..]
> Also very good that this is split up into small and independently
> reviewable patches.  I'll start review soon.

While Steffan is our resident expert on nasty crypto libraries, I just
want to echo the sentiment - having these "chunks" tackle one API function
at a time, they are easily testable, and in case something explodes, it's
much easier to bisect to find the problematic one.

Now back to being a commit slave for Steffan's ACKs :-)  (I do not know
the APIs well enough to properly comment on the changes, I can only run
tests...)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] build against openssl 1.1.0

[David Sommerseth]

On 19/02/17 05:48, Илья Шипицин wrote:
> 
> 
> 2017-02-19 4:16 GMT+05:00 David Sommerseth
>  >:
> 
> On 18/02/17 08:34, Илья Шипицин wrote:
> > I added openssl-1.0.1e to test matrix (do not pay attention to
> > commit title, it happened accidently from iPad), so ...
> >
> > https://travis-ci.org/OpenVPN/openvpn/jobs/202709493
> 
> >
> > t_cltsrv.sh + openssl-1.0.1f  = OK
> > t_cltsrv.sh + openssl-1.0.1e = FAIL
> 
> Okay, lets get a few important details straight first.  When I spoke
> about openssl-1.0.1e, it was in an RHEL context (including CentOS and
> Scientific Linux).  In reality, that is not the same version as OpenSSL
> upstream 1.0.1e.  Red Hat employs people to backport bugfixes and
> security fixes from newer OpenSSL 1.0.x releases to 1.0.1e. So the
> OpenSSL _baseline_ is 1.0.1e [1].  But it must not be compared directly
> against v1.0.1e from openssl.org .  The baseline
> defines a /stable ABI/
> (Application Binary Interface) which applications linking against the
> library can rely on.  This is what makes RHEL and the clones so stable
> over 7-10++ years.  And this is the challenge backporters in Red Hat
> struggle with; not breaking applications which works.
> 
> So unless I have misunderstood your travis commit ... you set the
> version to 1.0.1e regardless of Linux distribution.  This itself does
> not provide any real value for us.  As there are a lot of bugfixes and
> security implemented in the OpenSSL package RHEL ships ... you can get
> an idea by looking at the changelog of the openssl RPM package:
> 
>  
> >
> 
> RHEL6 was released in May 2010 while RHEL7 in June 2014.  What you see
> above is the changelog for RHEL7.  If my count is correct, that is
> currently 127 patches *on top of* the upstream OpenSSL v1.0.1e.  I
> wouldn't expect this patch list to be much longer on RHEL 6 though.
> 
> So unless your travis script is clever enough to only test OpenSSL
> v1.0.1e on RHEL, CentOS or ScientificLinux *or* build OpenSSL using the
> CentOS source RPM ... then I am not surprised things may fail.  Red Hat
> may very well have fixed some bugs which we're hitting.
> 
> 
> 
> well, RedHat not only ship their very own openssl, but also their own
> openvpn package
> 
> https://dl.fedoraproject.org/pub/epel/7/SRPMS/o/

The Fedora EPEL packages are not really Red Hat (even though many Red
Hatters maintain EPEL packages).  The difference is, EPEL packages are
unsupported by Red Hat's support plans.  Packages coming from the
official Red Hat source repositories (which CentOS "clones"), are fully
supported by their support plans.

> I see, there's %check section, but it is commented. Not sure how thay
> test it. We should get in touch with redhat people if we want openvpn
> properly tested and packaged

OpenVPN is not tested by Red Hat.  Official packages by Red Hat (from
the proper RHEL repositories) go through a massive QE process, with
loads of automated regression testing, specially written for each
distributed package.  All bugzillas tied to a package gets its own test
case written and is explicitly tested.  Then the package is installed,
uninstalled, upgraded and downgraded on systems which tries to simulate
a production environment.  And I've probably forgotten a bunch of other
steps as well.

> I'll have a look at 'make check' under centos later

You won't find any explicit OpenVPN package in the CentOS 6 or later
repositories.  You will find el5 packages though, as OpenVPN was an
official package in RHEL5 (but that is 2.1_rc-something, IIRC)

As of RHEL 6, Red Hat removed OpenVPN from the official repositories and
decided users needing it should use Fedora EPEL for it.  The reasoning
is probably to cost related.  Otherwise they need to allocate at least
on person to be the package maintainer, plus the QE and release
management machinery.  If few Enterprise customers depend on OpenVPN for
their critical workloads, it probably wasn't worth the cost.  In
addition they might have looked at the stability and the amount of
security related issues in OpenVPN over many years (which are quite good!)

But things may change again.  I heard recently that Red Hat is migrating
over to OpenVPN as the only internal IT supported VPN solution.  So
about 10k employees will soon depend on OpenVPN for their daily VPN
need.  We will see when RHEL 8 gets released :)


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

[Steffan Karger]

On 19-02-17 15:58, David Sommerseth wrote:
> On 19/02/17 13:03, Steffan Karger wrote:
> 
>> As discussed in other threads, we do want to support building on RHEL6,
>> which is why we would prefer to be compatible with (patched) OpenSSL
>> 0.9.8.  I haven't tested anything yet, but looking at the patches this
>> might very well just work, or otherwise just needs some minor tweaking.
> 
> RHEL6 ships with OpenSSL 1.0.1e.  We don't need anything older for git
> master, and I would even argue release/2.4.
> 
> RHEL5 (which goes EOL by end of next month) ships with OpenSSL 0.9.8e.
> So I vote for ditching 0.9.8e now.

Oh, very good.  I messed up the versions again...

The other big long-term-support distro, SLES, does still ship and
support 0.9.8 in SELS11 until 2019 (2022 for extended support), but can
be updated to 1.0.1.

As far as I'm concerned, that is enough reason to only support OpenSSL
1.0.1+ for OpenVPN 2.4 (and newer).

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

[Emmanuel Deloget]

Hello,

On Sun, Feb 19, 2017 at 1:03 PM, Steffan Karger  wrote:
>
> Hi Emmanuel,
>
> Thank you very much.  You approach looks good to me, and quite closely
> matches what I had in mind for when I would find the time to tackle
> this.  (Which might have taken me a while, so really happy to see these
> patches!)
>

Thanks Steffan,

> As discussed in other threads, we do want to support building on RHEL6,
> which is why we would prefer to be compatible with (patched) OpenSSL
> 0.9.8.  I haven't tested anything yet, but looking at the patches this
> might very well just work, or otherwise just needs some minor tweaking.

I haven't tested compilation with 0.9.8 but unless some massive
changes in the interface occured, this should not be a problem. I'd do
that at the beginning of next week.

> Also very good that this is split up into small and independently
> reviewable patches.  I'll start review soon.
>
> -Steffan

For the record, most of the patches deal with changing how the code
access to one selected OpenSSL type. I hope it will ease review -- in
the sense that people who are accustomed to the code might be able to
see if something is missing.

BR,

-- Emmanuel Deloget

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

[David Sommerseth]

On 19/02/17 13:03, Steffan Karger wrote:

> As discussed in other threads, we do want to support building on RHEL6,
> which is why we would prefer to be compatible with (patched) OpenSSL
> 0.9.8.  I haven't tested anything yet, but looking at the patches this
> might very well just work, or otherwise just needs some minor tweaking.

RHEL6 ships with OpenSSL 1.0.1e.  We don't need anything older for git
master, and I would even argue release/2.4.

RHEL5 (which goes EOL by end of next month) ships with OpenSSL 0.9.8e.
So I vote for ditching 0.9.8e now.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 14/15] OpenSSL: check for the SSL reason, not the full error

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 changed the SSLv3 API and removed many SSL_L_SSL3_*
> constants. Moreover, new code might use different function
> code for the same error.
> 
> Thus, we extract the error reason from the error code before
> we compare it instead of trying to rebuild an error code
> that might not be correct.
> 
> The new version is compatible with OpenSSL 1.0.x as well as
> with older versions (starting at 0.9.8).
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/crypto_openssl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index 
> 2f77a9853ac484770dcd808efdf13671ade7e758..23de17542bf0f4a311825373ecf8d8261fd21c73
>  100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -194,8 +194,7 @@ crypto_print_openssl_errors(const unsigned int flags)
>  while ((err = ERR_get_error()))
>  {
>  /* Be more clear about frequently occurring "no shared cipher" error 
> */
> -if (err == ERR_PACK(ERR_LIB_SSL,SSL_F_SSL3_GET_CLIENT_HELLO,
> -SSL_R_NO_SHARED_CIPHER))
> +if (ERR_GET_REASON(err) == SSL_R_NO_SHARED_CIPHER)
>  {
>  msg(D_CRYPT_ERRORS, "TLS error: The server has no TLS 
> ciphersuites "
>  "in common with the client. Your --tls-cipher setting might 
> be "
> 

This patch is correct even outside the context of the transition to 1.1,
and can be applied immediately.  ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 00/15] Add support for OpenSSL 1.1.x

[Steffan Karger]

Hi Emmanuel,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> The purpose of this RFC series is to make the latest master of OpenVPN
> (2.5-git) linkable with OpenSSL v1.1.x. It may not be complete (I may
> have missed something due to my work environment, but any missing pieces
> will be added next week) so be a bit cautious with this. The 
> configuration I used (--without-systemd, --without-lzo) seems to work
> but I must confess I did not tested much. 
> 
> As you may know, the important information about the API of OpenSSL 1.1
> if that it no longer provide access to the content of its objects. The
> structure types are now opaque and various functions have been added to
> fetch information from these objects. 
> 
> Once theses patches have been applied, it is possible to compile 
> OpenSSL with the latest 1.0.1 and with the latest 1.1.0. I still have to
> check whether compilation with 1.0.0 and 0.9.8 works. I don't try to 
> get the OpenSSL version -- I instead decided to check for the presence
> of individual functions in the library and chose to reimplement the 
> missing ones. Then I changed caller code in order to use this new
> interface. The net result is that OpenVPN is now using the OpenSSL 1.1
> API -- regardless of the real version of OpenSSL. This might make futur
> changes simpler at the cost of adding more functions in the 
> openssl_compat.h file. 
> 
> Las but not least, because of the way I worked I introduced some strange 
> artefacts (I believe they are not really relevant but some of them are 
> weird enough to need some explaination). 
> 
> * I had to introduce a function of the 1.0 API in the 1.1 code. In the
>   1.0 API, HMAC_CTX is populated with HMAC_CTX_init() and cleaned with
>   HMAC_CTX_cleanup(). In 1.1 these two functions are gone and replaced
>   with HMAC_CTX_reset(). I decided to use _reset() to implement 
>   _cleanup() but since I then could not use it for _init() (that would
>   break an OpenVPN linked with 1.0) I created a small wrapper in 1.1
>   mode. So, in 1.1, HMAC_CTX_init() calls _reset() -- and everybody is
>   happy (well, maybe not everybody).  
>   
> * HMAC_CTX, EVP_MD_CTX and a few other objects cannot be allocated using
>   malloc() so I had to change the way these object are used and 
>   initialized. I introduces a few new functions in the crypto backend to
>   handle this.
> 
> * x509_verify_ns_cert_type() checks had to be changed. OpenSSL 1.1 does 
>   not provide any solution to access both X509::ex_flags and 
>   X509::ex_nscert so the check could not be implemented this way. The
>   only solution I found was to use X509_check_purpose() but I'm worried
>   that the implemented test is now far more strict. 
> 
> * weirdly enough, it's no longer possible to duplicate the n parameter
>   of a RSA public key into another RSA public key. If you do so, you
>   also need to duplicate the e parameter. The reason is that you cannot
>   have (n && !e) or (!n && e) (see RSA_set0_key[1]). I deciced to go
>   the same route in my implementation and thus I needed to change the
>   code in tls_ctx_use_external_private_key(). 
> 
> Thanks for your comprehension, 
> 
> [1] https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_lib.c#L191
> 
> -- Emmanuel Deloget

Thank you very much.  You approach looks good to me, and quite closely
matches what I had in mind for when I would find the time to tackle
this.  (Which might have taken me a while, so really happy to see these
patches!)

As discussed in other threads, we do want to support building on RHEL6,
which is why we would prefer to be compatible with (patched) OpenSSL
0.9.8.  I haven't tested anything yet, but looking at the patches this
might very well just work, or otherwise just needs some minor tweaking.

Also very good that this is split up into small and independently
reviewable patches.  I'll start review soon.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel