----- Original Message ----- > From: "Jan Just Keijser" <janj...@nikhef.nl> > To: "Steffan Karger" <stef...@karger.me>, openvpn-devel@lists.sourceforge.net > Sent: Saturday, 12 July, 2014 1:17:22 AM > Subject: Re: [Openvpn-devel] [PATCH] Add topology in sample server > configuration file > > Hi, > > On 11/07/14 20:35, Steffan Karger wrote: > > Hi, > > > > On 11-07-14 20:17, Jan Just Keijser wrote: > >> on CentOS 5 I get > >> > >> checking for SSL_OP_NO_TICKET flag in OpenSSL... no > >> configure: error: OpenVPN 2.4+ requires SSL_OP_NO_TICKET in OpenSSL > >> > >> which is logical as the "stock" openssl lib on CentOS 5 is openssl 0.9.8 > >> ; to me, this breaks CentOS 5 builds, as I have no option nor desire to > >> build & install openssl 1.0 on them. > > Hmm, I actually checked that 0.9.8 (the minimum version supported by > > 2.4) has SSL_OP_NO_TICKET. From the OpenSSL changelog: > > > > "Changes between 0.9.8e and 0.9.8f [11 Oct 2007] > > [...] > > If a client or server wishes to disable RFC4507 support then the option > > SSL_OP_NO_TICKET can be set." > > > > I expected distributions had incorporated that by now. Not sure whether > > to add extra code here, or just declare it ancient and let distros/users > > either backport newer OpenSSL or use 2.3. > > > > > RHEL5 (on which CentOS 5 is based) includes openssl 0.9.8e + bug fixes > and apparently no SSL_OP_NO_TICKET ; this will not change for the > duration of RHEL5 which is a couple of more years, IIRC. > > my question would be : why does openvpn need SSL_OP_NO_TICKET? why not > #ifdef the code, e.g. > > SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 > #ifdef SSL_OP_NO_TICKET > | SSL_OP_NO_TICKET > #endif > ); > > (this is non-openvpn code) ?
I agree, this seems to be the best approach. I suspect the issues related to SSL_OP_NO_TICKET has been resolved by Red Hat on EL5, but the fix may not have provided that flag. In addition, EL5 is the oldest distro we support (after we convinced James to ditch EL4 when that went officially EOL; not counting the extended support some few customers may pay for). -- kind regards, David Sommerseth
