Add topology in sample server configuration file
PATCH 1/1 Add topology in sample server configuration file
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.
--- sample/sample-config-files/server.conf | 7 +++++++ 1 file changed, 7 insertions(+)
(quoted diff) +0 -0
b/sample/sample-config-files/server.conf
index f483b6b..6a2b4c2 100644
sample/sample-config-files/server.conf +7 -0
@@ -86,6 +86,13 @@ key server.key # This file should be kept secret # 2048 bit keys. dh dh1024.pem +# Network topology +# Should be subnet (addressing via IP) +# unless Windows clients v2.0.9 and lower have to +# be supported (then net30, i.e. a /30 per client) +# Defaults to net30 (not recommended) +;topology subnet + # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself,
Signature · 1 line
2.0.1
Jan Just Keijser
NAKQuoted 3 lines · Philipp Hagemeister
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.
NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>
that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
JJK
Quoted 38 lines
Signed-off-by Philipp Hagemeister <[email protected]...>--- sample/sample-config-files/server.conf | 7 +++++++ 1 file changed, 7 insertions(+)sample/sample-config-files/server.conf +7
-1@@ -86,6 +86,13 @@ key server.key # This file should be kept secret # 2048 bit keys. dh dh1024.pem +# Network topology +# Should be subnet (addressing via IP) +# unless Windows clients v2.0.9 and lower have to +# be supported (then net30, i.e. a /30 per client) +# Defaults to net30 (not recommended) +;topology subnet + # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, ------------------------------------------------------------------------------Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Am 11.07.14 10:51, schrieb Jan Just Keijser:
Quoted 12 lines · Philipp Hagemeister
Quoted 3 lines
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
I am confused here, route <remote subnet> <mask> would expand to
route <remote subnet> <mask> remote_gw in p2p, net30 and subnet toplogy. And that should work in all topology modes. What am I missing here?
Arne
Hi Arne,
Quoted 12 lines · Arne Schwabe
Am 11.07.14 10:51, schrieb Jan Just Keijser:
Quoted 11 lines · Philipp Hagemeister
Quoted 4 lines
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>
Quoted 6 lines
Quoted 1 line
that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
I am confused here, route <remote subnet> <mask> would expand to
route <remote subnet> <mask>
remote_gwin p2p, net30 and subnet toplogy. And that should work in all topology modes. What am I missing here?
this is a long standing bug, check out the recent thread on the openvpn-users mailing list
Re: [Openvpn-users] ping tests mostly work. all OK, exceptServer->Client private IP. *almost* there!
Quoted 5 lines · On Mon, Jul 07, 2014 at 11:41:31AM -0700, [email protected]... wrote:
Quoted 4 lines
Switching back to
verb 3, @Server log on server START(not SUPPOSED to be wrapping, at least it doesn't in the web editor -- just in case: http://pastebin.com/KmChijWX )
"Wrapped like hell". Is there no way to do attachments in the web thingie?
Anyway:
Quoted 10 lines
Quoted 9 lines
there's a suspect problem
Mon Jul 7 10:52:42 2014 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Mon Jul 7 10:52:42 2014 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.1.0which looks like a possible culprit.
... indeed. This is, uh, stupid code, and I think we already have a trac ticket for it...
Quoted 2 lines
Quoted 1 line
If yes, what's missing in OpenVPN config, and where?
--route 192.168.1.0 255.255.255.0 10.0.0.8
("just any IP address that's inside your tun subnet, and not the first").
This is really not *necessary*, but the way the code does tun & tap and net30 & subnet, it gets confused about things. Needs fixing, sorry for that.
so in some cases a server-side statement
route 192.168.1.0 255.255.255.0
works fine with 'topology net30' but NOT with 'topology subnet'.
This is a long standing bug that needs to be fixed before we can forcefeed everybody 'topology subnet'.
JJK
Quoted 8 lines
This is really not *necessary*, but the way the code does tun & tap and net30 & subnet, it gets confused about things. Needs fixing, sorry for that.
Quoted 6 lines
so in some cases a server-side statement
route 192.168.1.0 255.255.255.0
works fine with 'topology net30' but NOT with 'topology subnet'.This is a long standing bug that needs to be fixed before we can forcefeed everybody 'topology subnet'.
Okay. I see where the confusion is coming from. if you have net30, the second parameter for the ifconfig is always the gateway. In subnet you explicity need to set the gateway by setting/pushing route-gateway.
In normal setups the --server macro automatically does that for you.
I am not really seeing a bug here but a misconfiguration of OpenVPN. Sure the error messages could be improved and I am all ear to this.
Arne
Hi Arne,
Quoted 14 lines · Arne Schwabe
Quoted 6 lines
This is really not *necessary*, but the way the code does tun & tap and net30 & subnet, it gets confused about things. Needs fixing, sorry for that.
Quoted 7 lines
so in some cases a server-side statement
route 192.168.1.0 255.255.255.0
works fine with 'topology net30' but NOT with 'topology subnet'.This is a long standing bug that needs to be fixed before we can forcefeed everybody 'topology subnet'.
Quoted 6 lines
Okay. I see where the confusion is coming from. if you have net30, the second parameter for the ifconfig is always the gateway. In subnet you explicity need to set the gateway by setting/pushing route-gateway.
In normal setups the --server macro automatically does that for you.
I wish this were true. Consider the following server config:
proto udp
port 1194
dev tun
server 192.168.200.0 255.255.255.0
ca /etc/openvpn/cookbook/ca.crt cert /etc/openvpn/cookbook/server.crt key /etc/openvpn/cookbook/server.key dh /etc/openvpn/cookbook/dh1024.pem
tls-auth /etc/openvpn/cookbook/ta.key 0
persist-key
persist-tun
keepalive 10 60
push "route 10.198.0.0 255.255.0.0"
user nobody
group nobody
client-config-dir /etc/openvpn/cookbook/clients
route 192.168.4.0 255.255.255.0
(example from my cookbook)
this example works fine 'as is' but if you add
topology subnet
you get
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.4.0
Fri Jul 11 11:31:28 2014 TUN/TAP device tun0 opened
so the 'server' macro does not seem to properly publish this in all cases.
JJK
Quoted 10 lines
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.4.0
Fri Jul 11 11:31:28 2014 TUN/TAP device tun0 opened
Quoted 3 lines
so the 'server' macro does not seem to properly publish this in all cases.
I sent a patch to the list which should fix that use case. Can you test that patch and if it works for you too?
Arne
After applying Arne's patch, would you ACK this?
In any case, the default is untouched by this patch. Can you enlist the "few" critical bugs? I'll document them then on
https://community.openvpn.net/openvpn/wiki/Topology .
Best,
Philipp
Quoted 58 lines · Jan Just Keijser
Quoted 3 lines · Philipp Hagemeister
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
JJK
Quoted 40 lines
Signed-off-by Philipp Hagemeister <[email protected]...>--- sample/sample-config-files/server.conf | 7 +++++++ 1 file changed, 7 insertions(+)sample/sample-config-files/server.conf +7
-1@@ -86,6 +86,13 @@ key server.key # This file should be kept secret # 2048 bit keys. dh dh1024.pem +# Network topology +# Should be subnet (addressing via IP) +# unless Windows clients v2.0.9 and lower have to +# be supported (then net30, i.e. a /30 per client) +# Defaults to net30 (not recommended) +;topology subnet + # Configure server mode and supply a VPN subnet # for OpenVPN to draw client addresses from. # The server will take 10.8.0.1 for itself, ------------------------------------------------------------------------------Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Hi,
Quoted 4 lines · Jan Just Keijser
Quoted 3 lines · Philipp Hagemeister
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.
Quoted 8 lines
NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
Well, it's on the roadmap, and Arne has already sent a patch.
So, what other issues exist? This is the only one I'm aware of... (and the recent trac ticket about "topology subnet not working on FreeBSD 10" turned out to be local confusion...)
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Quoted 8 lines · Arne Schwabe
Quoted 8 lines
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: OpenVPN needs a gateway parameter for a --route option and no default was specified by either --route-gateway or --ifconfig options
Fri Jul 11 11:31:28 2014 OpenVPN ROUTE: failed to parse/resolve route for host/network: 192.168.4.0
Fri Jul 11 11:31:28 2014 TUN/TAP device tun0 opened
Quoted 8 lines
Quoted 4 lines
so the 'server' macro does not seem to properly publish this in all cases.
I sent a patch to the list which should fix that use case. Can you test that patch and if it works for you too?
the patch works on the 2.3 branch.
the master branch (from openvpn-testing) currently does not build on either CentOS 5 and 6.
JJK
Hi,
Quoted 14 lines · Gert Doering
Quoted 12 lines · Jan Just Keijser
Quoted 4 lines · Philipp Hagemeister
On modern systems, topology subnet should always be set, but it's missing in the configuration file.
Add it with a short explanation.NACK
There are a few annoying issues with
topology subnet
esp when using server side things like
route <remote subnet> <mask>
Quoted 10 lines
Quoted 2 lines
that will *fail* with 'topology subnet' ; until this is fixed this should NOT be considered the default.
Well, it's on the roadmap, and Arne has already sent a patch.
So, what other issues exist? This is the only one I'm aware of... (and the recent trac ticket about "topology subnet not working on FreeBSD 10" turned out to be local confusion...)
hmm I thought I had a TRAC ticket on this but I cannot find it anymore...
I recall some minor annoyances all having to do with needing to explictly add a gateway for the server-side routes. I'm 99.9% confident that Arne's one-liner will have fixed them.
With those annoyances gone I'd even be in favor of making 'topology subnet' the default for the 2.4 release :)
cheers,
JJK
Hi,
Quoted 2 lines · Jan Just Keijser
the master branch (from openvpn-testing) currently does not build on either CentOS 5 and 6.
Install snappy(-dev) or run configure with --disable-snappy :-) - besides that, it should build just fine.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Hi,
Quoted 9 lines · Gert Doering
Hi,
Quoted 2 lines · Jan Just Keijser
the master branch (from openvpn-testing) currently does not build on either CentOS 5 and 6.
Install snappy(-dev) or run configure with --disable-snappy :-) - besides that, it should build just fine.
an
autoreconf -i
did the trick on CentOS 6; 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.
share and enjoy,
JJK
Hi,
Quoted 8 lines · Jan Just Keijser
on CentOS 5 I get
checking for
SSL_OP_NO_TICKETflag in OpenSSL... no
configure: error: OpenVPN 2.4+ requiresSSL_OP_NO_TICKETin OpenSSLwhich 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.
-Steffan
Hi,
Quoted 10 lines · Jan Just Keijser
Quoted 5 lines · Gert Doering
Quoted 2 lines · Jan Just Keijser
the master branch (from openvpn-testing) currently does not build on either CentOS 5 and 6.
Install snappy(-dev) or run configure with --disable-snappy :-) - besides that, it should build just fine.
an
autoreconf -i
did the trick on CentOS 6;
Yeah, you'll need that if you refresh the git tree and configure.ac or Makefile.am has changed. Sorry, we should display it more prominently :)
Quoted 8 lines
on CentOS 5 I get
checking for
SSL_OP_NO_TICKETflag in OpenSSL... no
configure: error: OpenVPN 2.4+ requiresSSL_OP_NO_TICKETin OpenSSLwhich 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.
Mmmmh. Steffann has already answered this - it "should" work with recent versions of 0.9.8, but some of the distribution vendors have the nasty habit of not bumping their versions but just backporting security fixes - so your 0.9.8 might be "0.9.8d + security fixes", not "0.9.8-current" (which would be 0.9.8za).
You could build using polarssl :-) - but that will require installation of a separate ssl library as well, so, not much better than "build & install openssl 1.0". Hrmph.
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Hi,
Quoted 14 lines · Steffan Karger
Hi,
Quoted 8 lines · Jan Just Keijser
on CentOS 5 I get
checking for
SSL_OP_NO_TICKETflag in OpenSSL... no
configure: error: OpenVPN 2.4+ requiresSSL_OP_NO_TICKETin OpenSSLwhich 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:
Quoted 10 lines
"Changes between 0.9.8e and 0.9.8f [11 Oct 2007]
[...]
If a client or server wishes to disable RFC4507 support then the optionSSL_OP_NO_TICKETcan 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) ?
JM2CW,
JJK
----- Original Message -----
Quoted 39 lines
From: "Jan Just Keijser" <[email protected]...>
To: "Steffan Karger" <[email protected]...>, [email protected]
Sent: Saturday, 12 July, 2014 1:17:22 AM
Subject: Re: [Openvpn-devel] [PATCH] Add topology in sample server configuration fileHi,
Quoted 14 lines · Steffan Karger
Hi,
Quoted 8 lines · Jan Just Keijser
on CentOS 5 I get
checking for
SSL_OP_NO_TICKETflag in OpenSSL... no
configure: error: OpenVPN 2.4+ requiresSSL_OP_NO_TICKETin OpenSSLwhich 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:Quoted 10 lines
"Changes between 0.9.8e and 0.9.8f [11 Oct 2007]
[...]
If a client or server wishes to disable RFC4507 support then the optionSSL_OP_NO_TICKETcan 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.
Quoted 7 lines
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
Hi,
Quoted 9 lines · David Sommerseth
Quoted 9 lines
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 );
Quoted 5 lines
Quoted 1 line
(this is non-openvpn code) ?
I agree, this seems to be the best approach. I suspect the issues related to
SSL_OP_NO_TICKEThas been resolved by Red Hat on EL5, but the fix may not have provided that flag.
This is what we do in 2.3. For 2.4 we decided (on the list, btw!) to require that this is there, instead of silently hoping that the SSL library would get it right (which it does not, according to James). See 25f4d4b49bff342fd9dd54cd and e9b088b208479.
commit 25f4d4b49bff342fd9dd54cd22f14c9de49e9f8b
Author: James Yonan <[email protected]...> Date: Sun Mar 16 18:49:36 2014 -0600
Set SSL_OP_NO_TICKET flag in SSL context for OpenSSL builds, to disable TLS stateless session resumption.
OpenVPN doesn't want or need SSL session renegotiation or resumption, as it handles renegotiation on its own.
For this reason, OpenVPN always disables the SSL session cache:
SSL_CTX_set_session_cache_mode (ctx, SSL_SESS_CACHE_OFF)
However, even with the above code, stateless session resumption is still possible unless explicitly disabled with the SSL_OP_NO_TICKET flag. This patch does this.
Quoted 3 lines
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).
Any way to convince RH to pick up this security-relevant fix?
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...----- Original Message -----
Quoted 6 lines
From: "Gert Doering" <[email protected]...>
To: "David Sommerseth" <[email protected]...>
Cc: "Jan Just Keijser" <[email protected]...>, [email protected]
Sent: Saturday, 12 July, 2014 11:41:30 AM
Subject: Re: [Openvpn-devel] [PATCH] Add topology in sample server configuration file
Quoted 6 lines
Quoted 4 lines
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).Any way to convince RH to pick up this security-relevant fix?
I haven't had time to check the changelog for openssl on EL5 (not close to /my/ computers). But it wouldn't surprise me if they have already fixed this. But as SSL_OP_NO_TICKET was introduced in a newer base release than EL5 uses, they have most likely solved it in another way. Maybe by always adding this flag implicit? (Which would have the benefit of not needing to recompile all OpenSSL applications with this flaw).
IIRC, the guy overseeing the Secure Response Team in RH is Mark Cox, which again is also an upstream OpenSSL maintainer. So I'm quite sure all RH releases have fixed this issue.
--
kind regards,
David Sommerseth
Hi,
Quoted 3 lines · David Sommerseth
IIRC, the guy overseeing the Secure Response Team in RH is Mark Cox, which again is also an upstream OpenSSL maintainer. So I'm quite sure all RH releases have fixed this issue.
Well, OpenSSL considers this a "feature", not an "issue"... and being able to turn off session resumption is also considered a "feature"...
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...----- Original Message -----
Quoted 9 lines
From: "Gert Doering" <[email protected]...>
To: "David Sommerseth" <[email protected]...>
Cc: "Gert Doering" <[email protected]...>, "Jan Just Keijser" <[email protected]...>, [email protected]
Sent: Saturday, 12 July, 2014 1:31:09 PM
Subject: Re: [Openvpn-devel] [PATCH] Add topology in sample server configuration fileHi,
On Sat, Jul 12, 2014 at 12:41:14PM +0200, David Sommerseth wrote:
Quoted 8 lines
Quoted 5 lines
IIRC, the guy overseeing the Secure Response Team in RH is Mark Cox, which again
is also an upstream OpenSSL maintainer. So I'm quite sure all RH releases have
fixed this issue.Well, OpenSSL considers this a "feature", not an "issue"... and being able to turn off session resumption is also considered a "feature"...
Ahh, right!
I thought this was related to a CVE, but it seems not, according the OpenSSL changelog I found on the net [1]. SSL_OP_NO_TICKET comes with the implementation of RFC4507, which was introduced in 0.9.8f. I just double checked EL5, and it uses 0.9.8e as the base version. According to the RPM changelog, I don't see that RFC4507 has ever been backported.
From what I can grasp out of the OpenSSL changelog, RFC4507 is enabled by default *if* compiled into OpenSSL. And if it is compiled into OpenSSL, it can be disabled by setting the SSL_OP_NO_TICKET flag. Which would means 0.9.8e should be safe in this aspect and EL5 is not vulnerable at all.
But it would be good if others can double this and see if I've understood this correctly, just so I don't say anything wrong.
[1] <https://www.openssl.org/news/openssl-0.9.8-notes.html>
--
kind regards,
David Sommerseth
Hi,
Quoted 10 lines · David Sommerseth
Quoted 2 lines
Well, OpenSSL considers this a "feature", not an "issue"... and being able to turn off session resumption is also considered a "feature"...
Ahh, right!
I thought this was related to a CVE, but it seems not, according the OpenSSL changelog I found on the net [1].
SSL_OP_NO_TICKETcomes with the implementation of RFC4507, which was introduced in 0.9.8f. I just double checked EL5, and it uses 0.9.8e as the base version. According to the RPM changelog, I don't see that RFC4507 has ever been backported.
Ah. So if that is correct, our simplistic implementation "if it is not there, just #define SSL_OP_NO_TICKET 0" would be perfectly safe in this regard, then.
Quoted 2 lines
But it would be good if others can double this and see if I've understood this correctly, just so I don't say anything wrong.
Indeed :-) - Steffann?
gert
Signature · 4 lines
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany [email protected]...
fax: +49-89-35655025 [email protected]...Re: [Openvpn-devel] more SSL_OP_NO_TICKET fallout
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
Oh, joy, more SSL_OP_NO_TICKET fallout. Changing the subject to separate this discussion from the original thread about topology subnet.
Quoted 14 lines · Gert Doering
Quoted 4 lines · David Sommerseth
Quoted 3 lines
Well, OpenSSL considers this a "feature", not an "issue"... and being able to turn off session resumption is also considered a "feature"...
Quoted 8 lines
Ahh, right!
I thought this was related to a CVE, but it seems not, according the OpenSSL changelog I found on the net [1].
SSL_OP_NO_TICKETcomes with the implementation of RFC4507, which was introduced in 0.9.8f. I just double checked EL5, and it uses 0.9.8e as the base version. According to the RPM changelog, I don't see that RFC4507 has ever been backported.
Quoted 8 lines
Ah. So if that is correct, our simplistic implementation "if it is not there, just #define
SSL_OP_NO_TICKET0" would be perfectly safe in this regard, then.Quoted 2 lines
But it would be good if others can double this and see if I've understood this correctly, just so I don't say anything wrong.
Indeed :-) - Steffann?
Yes, the SSL_OP_NO_TICKET flag was introduced together with the feature it disables (stateless session resumption). Sane backporters would also backport the flag when backporting the feature. So using the same "#define SSL_OP_NO_TICKET 0"-construction as in 2.3 should be fine.
I think this is the way to go for 2.4 if we want to support RHEL5 until their end-of-production. The alternatives would be to either drop support for RHEL5 (seems unreasonable for such a silly fix) or keep maintaining 2.3 until RHEL5 end-of-support (much more work).
Attached a patch that adds the 2.3 #ifdef construction to -master too. I updated the message to reflect that this is in master too now, and include the string '0.9.8', which should help with stripping this out again if 0.9.8-support is ever dropped.
- -Steffan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBCAAGBQJTwlHPAAoJEJgCyj0AftKImwcH/0mCSnA2LNFDP0542/yRnFTc mwufEafiZ936xY0eEYKERNMuISucAoHiOGrp+5EqSHSoGqX7TTkxZ3hIBVgQ4L37 p4b9pbkXNj5J4RelcFkH78lNKnNr9AnU5JHO1SJEO1qKAY0q5ypRclvTbytcN8o6 6UVnRzcjmDnyUOgPrSct+JK7Rm9BVCpDU2a7PK0fGASs3qS9NZOmBSDV9Eg2P5tn IdvoZUrI9ZPNLDWCoDpMOkpsvQPl2BeMJ0t5Ib/LRSE8dbvfxg+GldYYQ3YA4uu8 xylgnvNTwi1GfFEicwX+9g8NEkqDKmNJd6k/OzclVyhWi3209E6prwk20NX7RDs= =u8ld
-----END PGP SIGNATURE-----
From bbe56efb085138dca65dfe15b480eab47074b7e2 Mon Sep 17 00:00:00 2001
From: Steffan Karger <[email protected]...>
Date: Sun, 13 Jul 2014 11:26:32 +0200
Subject: [PATCH] Define dummy SSL_OP_NO_TICKET flag if not present in OpenSSL.
This restores support for pre-0.9.8f OpenSSL versions, which do not include stateless session resumption, and the accompanying SSL_OP_NO_TICKET flag.
--- configure.ac | 19 ------------------- src/openvpn/ssl_openssl.h | 11 +++++++++++ 2 files changed, 11 insertions(+), 19 deletions(-)
configure.ac +0 -19
@@ -814,25 +814,6 @@ if test "${have_openssl_crypto}" = "yes"; then LIBS="${saved_LIBS}" fi -if test "${enable_ssl}" = "yes" && test "${with_crypto_library}" = "openssl"; -then - saved_CPPFLAGS="${CPPFLAGS}" - CPPFLAGS="${CPPFLAGS} ${OPENSSL_CRYPTO_CFLAGS}" - AC_MSG_CHECKING([for SSL_OP_NO_TICKET flag in OpenSSL]) - AC_EGREP_CPP(have_ssl_op_no_ticket, [ - #include <openssl/ssl.h> - #ifdef SSL_OP_NO_TICKET - have_ssl_op_no_ticket - #endif - ], [ - AC_MSG_RESULT([yes]) - ], [ - AC_MSG_RESULT([no]) - AC_ERROR([OpenVPN 2.4+ requires SSL_OP_NO_TICKET in OpenSSL]) - ]) - CPPFLAGS="${saved_CPPFLAGS}" -fi - AC_ARG_VAR([POLARSSL_CFLAGS], [C compiler flags for polarssl]) AC_ARG_VAR([POLARSSL_LIBS], [linker flags for polarssl]) have_polarssl_ssl="yes"
src/openvpn/ssl_openssl.h +11 -0
@@ -33,6 +33,17 @@#include <openssl/ssl.h> /** +* SSL_OP_NO_TICKET tells OpenSSL to disable "stateless session resumption", +* as this is something we do not want nor need, but could potentially be +* used for a future attack. For compatibility reasons we keep building if the +* OpenSSL version is too old (pre-0.9.8f) to support stateless session +* resumption (and the accompanying SSL_OP_NO_TICKET flag). +*/ +#ifndef SSL_OP_NO_TICKET +# define SSL_OP_NO_TICKET 0 +#endif + +/** * Structure that wraps the TLS context. Contents differ depending on the * SSL library used. */
Signature · 1 line
1.9.1
[Openvpn-devel] [PATCH applied] Re: Define dummy SSL_OP_NO_TICKET flag if not present in OpenSSL.
ACK. RHEL5 is still supported, and with the additional background, this is good enough.
Your patch has been applied to the master branch.
commit 97bd862ed5c22956cb4405eabae64cf55cabb0d3
Author: Steffan Karger Date: Sun Jul 13 11:26:32 2014 +0200
Define dummy SSL_OP_NO_TICKET flag if not present in OpenSSL.
Signed-off-by: Steffan Karger <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8902
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering
ACK.
Your patch has been applied to the master and release/2.3 branch.
commit c277757fcf7fb4c2713db154439f937d48cfae61 (master) commit 6fa97d03de3c70efc59e9fa8a606de12e2135620 (release/2.3)
Author: Philipp Hagemeister Date: Fri Jul 11 10:00:24 2014 +0200
Add topology in sample server configuration file
Signed-off-by: Philipp Hagemeister <[email protected]...>
Acked-by: Gert Doering <[email protected]...>
Message-Id: <[email protected]...>
URL: http://article.gmane.org/gmane.network.openvpn.devel/8878
Signed-off-by: Gert Doering <[email protected]...>--
kind regards,
Gert Doering