options: allow setting default --ca argument value
PATCH 1/1 options: allow setting default --ca argument value
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
--- configure.ac | 5 +++++ src/openvpn/options.c | 9 +++++++++ 2 files changed, 14 insertions(+)
configure.ac +5 -0
@@ -308,6 +308,11 @@ AC_ARG_WITH( [with_plugindir="\$(libdir)/openvpn/plugins"] ) +AC_ARG_WITH( + [ca-bundle], + [AS_HELP_STRING([--with-ca-bundle], [use consolidated CA bundle])], + [AC_DEFINE_UNQUOTED([DEFAULT_CA_FILE], ["$withval"], [Default --ca argument])] +) AC_DEFINE_UNQUOTED([TARGET_ALIAS], ["${host}"], [A string representing our host]) case "$host" in
src/openvpn/options.c +9 -0
@@ -3000,6 +3000,15 @@ options_postprocess_mutate(struct options *o) }#endif +#ifdef DEFAULT_CA_FILE +if (!o->ca_file && !platform_access (DEFAULT_CA_FILE ,R_OK )) + { +msg (M_WARN ,"option '--ca' unspecified; using system bundle '%s'" , +DEFAULT_CA_FILE ); + o->ca_file =DEFAULT_CA_FILE ; + } +#endif +#if ENABLE_MANAGEMENT if (o->http_proxy_override) {
Signature · 1 line
2.9.3
Hi,
Quoted 42 lines · Pavel Raiskup
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
Signed-off-by Pavel Raiskup <[email protected]...>--- configure.ac | 5 +++++ src/openvpn/options.c | 9 +++++++++ 2 files changed, 14 insertions(+)configure.ac +5
-0@@ -308,6 +308,11 @@ AC_ARG_WITH( [with_plugindir="\$(libdir)/openvpn/plugins"] ) +AC_ARG_WITH( + [ca-bundle], + [AS_HELP_STRING([--with-ca-bundle], [use consolidated CA bundle])], + [AC_DEFINE_UNQUOTED([DEFAULT_CA_FILE], ["$withval"], [Default --ca argument])] +) AC_DEFINE_UNQUOTED([TARGET_ALIAS], ["${host}"], [A string representing our host]) case "$host" insrc/openvpn/options.c +2
-0@@ -3000,6 +3000,15 @@ options_postprocess_mutate(struct options *o) }#endif +#ifdef DEFAULT_CA_FILE +if (!o->ca_file && !platform_access (DEFAULT_CA_FILE ,R_OK ))
src/openvpn/options.c options_postprocess_mutate(struct options *o) · line 3014
Quoted 10 lines
src/openvpn/options.c +7
-0+ { +msg (M_WARN ,"option '--ca' unspecified; using system bundle '%s'" , +DEFAULT_CA_FILE ); + o->ca_file =DEFAULT_CA_FILE ; + } +#endif +#if ENABLE_MANAGEMENT if (o->http_proxy_override) {
Feature-NAK. OpenVPN should use it's own CA, not the system CA list.
There is no reason to allow hundreds of parties in the world to man-in-the-middle your OpenVPN connections. Please please please do not use your system CA list for OpenVPN, just specify the CA you do want to trust.
(OpenVPN is /not/ WWW, don't think about OpenVPN's usage of CAs as if it were the WWW.)
-Steffan
Hi,
Quoted 1 line · Steffan Karger
On 15-01-17 07:17, Pavel Raiskup wrote:
[..]
Quoted 4 lines
Quoted 4 lines
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
[..]
Quoted 2 lines
Feature-NAK. OpenVPN should use it's own CA, not the system CA list.
I could see the use-case (enterprise wide list of trusted CAs, and use of it compiled into an enterprise-distribute openvpn bundle), but I agree with Steffan that it's not something we need to have in OpenVPN - "--ca" can reference to a CA bundle today, and enterprise- distributed config files reference the enterprise-maintained CA bundle, it will just work without code changes.
My main reason for not liking this is "another compile-time option" - someone has to maintain and test this, with and without this option, which adds to our maintenance nightmare. So the gain has to be significant.
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 9 lines · Gert Doering
Quoted 1 line · Steffan Karger
On 15-01-17 07:17, Pavel Raiskup wrote:
[..]
Quoted 4 lines
Quoted 4 lines
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
[..]
Quoted 1 line
Quoted 8 lines
Quoted 1 line
Feature-NAK. OpenVPN should use it's own CA, not the system CA list.
I could see the use-case (enterprise wide list of trusted CAs, and use of it compiled into an enterprise-distribute openvpn bundle), but I agree with Steffan that it's not something we need to have in OpenVPN - "--ca" can reference to a CA bundle today, and enterprise- distributed config files reference the enterprise-maintained CA bundle, it will just work without code changes.
Yes, I got that. I'll be a bit more verbose: the use case is sufficiently covered by --ca (as Gert says), and this option is *way* too likely to be misinterpreted to 'point to /etc/ssl/certs/ca-certificates.crt', which will in almost all setups significantly reduces security.
We have plenty of confusing options, we really don't need another one :)
-Steffan
Quoted 9 lines · Pavel Raiskup
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
Quoted 5 lines
Signed-off-by Pavel Raiskup <[email protected]...>--- configure.ac | 5 +++++ src/openvpn/options.c | 9 +++++++++ 2 files changed, 14 insertions(+)
As this was mentioned on a Red Hat Bugzilla (bz #1413343 [1]) as well, I'm reiterating my argument here for closing that bugzilla as notabug.
I completely agree with Steffan, this is a NAK. Such a feature would be a dreamscenario for The Great Firewall of China and similar national routing instances which implements complete network surveillance. It would make it extremely trivial for them to implement a MITM OpenVPN server which would affect users not being aware of this issue.
This feature would elude users configuring OpenVPN it is no problem using certificates from public CA issuers. This is a VERY BAD idea! We should help users configure OpenVPN in a secure way by default. Not the opposite.
[1] <https://bugzilla.redhat.com/show_bug.cgi?id=1413343>
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
Quoted 25 lines · CET David Sommerseth
Quoted 9 lines · Pavel Raiskup
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
Quoted 5 lines
Signed-off-by Pavel Raiskup <[email protected]...>--- configure.ac | 5 +++++ src/openvpn/options.c | 9 +++++++++ 2 files changed, 14 insertions(+)As this was mentioned on a Red Hat Bugzilla (bz #1413343 [1]) as well, I'm reiterating my argument here for closing that bugzilla as notabug.
I completely agree with Steffan, this is a NAK. Such a feature would be a dreamscenario for The Great Firewall of China and similar national routing instances which implements complete network surveillance. It would make it extremely trivial for them to implement a MITM OpenVPN server which would affect users not being aware of this issue.
Quoted 4 lines
This feature would elude users configuring OpenVPN it is no problem using certificates from public CA issuers. This is a VERY BAD idea! We should help users configure OpenVPN in a secure way by default. Not the opposite.
Ack, I originally thought about this as tool to solve "packaging issue". We have corporate-wide authority, and people usually have it stored in bundle. But I got the point, and such a shame mistake -- there's too many trusted CAs.
Thanks for having a look!
Pavel
Quoted 5 lines
Quoted 31 lines · Pavel Raiskup
Quoted 25 lines · CET David Sommerseth
Quoted 9 lines · Pavel Raiskup
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
Quoted 5 lines
Signed-off-by Pavel Raiskup <[email protected]...>--- configure.ac | 5 +++++ src/openvpn/options.c | 9 +++++++++ 2 files changed, 14 insertions(+)As this was mentioned on a Red Hat Bugzilla (bz #1413343 [1]) as well, I'm reiterating my argument here for closing that bugzilla as notabug.
I completely agree with Steffan, this is a NAK. Such a feature would be a dreamscenario for The Great Firewall of China and similar national routing instances which implements complete network surveillance. It would make it extremely trivial for them to implement a MITM OpenVPN server which would affect users not being aware of this issue.
Quoted 4 lines
This feature would elude users configuring OpenVPN it is no problem using certificates from public CA issuers. This is a VERY BAD idea! We should help users configure OpenVPN in a secure way by default. Not the opposite.
Quoted 4 lines
Ack, I originally thought about this as tool to solve "packaging issue". We have corporate-wide authority, and people usually have it stored in bundle. But I got the point, and such a shame mistake -- there's too many trusted CAs.
I would recommend seeing the CA file being part of the configuration instead of a packaging detail. And you can embedd the CA inside the configuration file ... just do this in the config:
<ca>
-----BEGIN CERTIFICATE-----
....
....
....
-----END CERTIFICATE-----
</ca>
This replaces the 'ca /path/to/ca.pem' line in the configuration file.
Otherwise, for enterprises doing their own packaging ... it is also possible to install the OpenVPN CA file in /etc/pki/.... which is easily done with RPM files which again can be pushed out through internal repositories or Satellite. The distributed configurations would then just need to use 'ca /etc/pki/tls/cert/openvpn-ca.pem'.
It all depends on how often it is expected to distribute configuration files vs how often the CA certificate is renewed.
Signature · 4 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc
A User's Perspective:
We've been doing just this since ovpn began allowing inline certs. Works great! Recommend.
Marvin
Sent from my iPhone
Quoted 80 lines · David Sommerseth
Quoted 33 lines · Pavel Raiskup
Quoted 26 lines · CET David Sommerseth
Quoted 10 lines · Pavel Raiskup
Adding a new --with-ca-bundle configure option. It's argument is used as default CA file when no --ca option is specified at runtime.
This option is primarily designed for systems where users are allowed to manage trusted authorities for whole system (in one consolidated file; usually implemented in 'ca-certificates' package).
Quoted 5 lines
Signed-off-by Pavel Raiskup <[email protected]...>---
configure.ac | 5 +++++src/openvpn/options.c| 9 +++++++++2 files changed, 14 insertions(+)As this was mentioned on a Red Hat Bugzilla (bz #1413343 [1]) as well, I'm reiterating my argument here for closing that bugzilla as notabug.
I completely agree with Steffan, this is a NAK. Such a feature would be a dreamscenario for The Great Firewall of China and similar national routing instances which implements complete network surveillance. It would make it extremely trivial for them to implement a MITM OpenVPN server which would affect users not being aware of this issue.
Quoted 4 lines
This feature would elude users configuring OpenVPN it is no problem using certificates from public CA issuers. This is a VERY BAD idea! We should help users configure OpenVPN in a secure way by default. Not the opposite.
Quoted 4 lines
Ack, I originally thought about this as tool to solve "packaging issue". We have corporate-wide authority, and people usually have it stored in bundle. But I got the point, and such a shame mistake -- there's too many trusted CAs.
I would recommend seeing the CA file being part of the configuration instead of a packaging detail. And you can embedd the CA inside the configuration file ... just do this in the config:
<ca>
-----BEGIN CERTIFICATE-----
....
....
....
-----END CERTIFICATE-----
</ca>This replaces the 'ca /path/to/ca.pem' line in the configuration file.
Otherwise, for enterprises doing their own packaging ... it is also possible to install the OpenVPN CA file in
/etc/pki/.... which is easily done with RPM files which again can be pushed out through internal repositories or Satellite. The distributed configurations would then just need to use 'ca/etc/pki/tls/cert/openvpn-ca.pem'.It all depends on how often it is expected to distribute configuration files vs how often the CA certificate is renewed.
Signature · 16 lines
kind regards, David Sommerseth OpenVPN Technologies, Inc ------------------------------------------------------------------------------ Developer Access Program for Intel Xeon Phi Processors Access to Intel Xeon Phi processor-based developer platforms. With one year of Intel Parallel Studio XE. Training and support from Colfax. Order your platform today. http://sdm.link/xeonphi _______________________________________________ Openvpn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openvpn-devel