date:20170224

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

2017-02-24 Thread James Yonan

On 24/02/2017 16:10, Steffan Karger wrote:

> Hi,
>
> On 24-02-17 22:28, James Yonan wrote:
>> On 24/02/2017 02:40, Steffan Karger wrote:
>>> On 23-02-17 22:41, James Yonan wrote:
 On 23/02/2017 01:22, Steffan Karger wrote:
> On 22-02-17 19:48, James Yonan wrote:
>> mbedTLS 2 has a new feature that allows rejection of certificates if the
>> key size is too small or the signing hash is weak.
>>
>> The feature is controlled via struct mbedtls_x509_crt_profile.
>>
>> For example, you could specify that certificates must be at least 2048
>> bits and use a SHA-2 signing alg.
>>
>> Wondering if we should enable this via an option, or tie it into the
>> existing tls-version-min.
>>
>> The granular approach would be to have specific options for each limit,
>> such as ssl-min-key-size, ssl-require-sha2
>>
>> The bundled approach would be to take an existing option such as
>> tls-version-min and add additional constraints onto it.  For example, if
>> tls-version-min is 1.2 or higher, then also require minimum key size to
>> be 2048 and certificate signing hash to be SHA-2.
> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
> function (SHA1+) if that causes trouble.
>
> If we are going to make this configurable, I think we should separate it
> from tls-version-min.  The main use case I see for using a lower
> security setting would be an out-of-the-admins-control CA, or something
> like (old) smart cards that don't support RSA-2048.  I wouldn't want to
> block people from enforcing TLS 1.2, because their smart card is crappy.
>
> So I think we'll have to add the relevant --tls-rsa-key-size-min,
> --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
> we want to make it configurable, that is.
 I think it needs to be configurable to allow for transitions to stronger
 keys.

 For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?
>>> Adding 'cert' in the option name is very good, it removes confusion
>>> between the TLS transcript digest and the cert digest.
>>>
>>> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature
>>> algorithm, but 'SHAx' is the certificates message digest algorithm.
>>>
>>> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).
>>>
 For --tls-cert-sign-min, the choices could be "none" (anything allowed
 by the underlying SSL lib) or "sha2" (requiring sha256 or higher).
>>> This makes sense for the SHA family, but 'or higher' becomes tricky when
>>> e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
>>> about that.
>> I'm still somewhat on the fence about making these options granular vs.
>> bundled.
> Yeah, I too find it hard to decide what the best approach is here.
> Being involved in OpenVPN the past few years has definitely learned me
> the importance of choosing the options right...
>
>> If we do granular, then we need to deal with every option, i.e. rsa key
>> size, cert digests, curves, etc. and we need to establish defaults and a
>> notion of "minimum" which is problematic as you mention above when new
>> algs (such as BLAKE2 as you mention above) enter the mix and its not
>> clear where to place them on the continuum.  Or avoid minimums by simple
>> enumerating the whole whitelist.  But this can become unwieldy with so
>> many options.
>>
>> Using the bundled approach would be more like the mbedTLS cert profiles
>> approach where you have a default that allows everything reasonable, and
>> a somewhat stricter profile that requires RSA key sizes >= 2048 and
>> disallows SHA1.  If we use this approach with OpenVPN, then we could
>> have an option --tls-cert-profile .  We would of course
>> need to define named profiles for this to work.
> Something like --tls-cert-profile sounds good, I think.  It's decoupled
> from --tls-version-min (which I think is good), but still doesn't offer
> a gazillion combinations of configurations.  We good go for e.g.
> 'legacy', 'default', 'suiteb' and perhaps something like 'paranoid'?
> We'd have to keep actively monitoring cryptographic advances, and kick
> out algs when they become deprecated and/or broken though.
>

That sounds good.  So how about legacy allows 1024-bit RSA keys and 
sha1, default requires 2048-bit keys and sha256 or higher?

James


--
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] cleanup: Remove faulty env processing functions

2017-02-24 Thread David Sommerseth

The env_set_add_to_environmenti() and env_set_remove_from_environment()
functions where not used in the code at all and they would cause an
ASSERT() in setenv_str_ex() later on, as it would not allow the
struct env_set *es pointer to be NULL (misc.c:807).

Signed-off-by: David Sommerseth 
---
 src/openvpn/misc.c | 51 ---
 src/openvpn/misc.h |  4 
 2 files changed, 55 deletions(-)

diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index a2f45b6..68d0687 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -701,57 +701,6 @@ env_set_inherit(struct env_set *es, const struct env_set 
*src)
 }
 }
 
-void
-env_set_add_to_environment(const struct env_set *es)
-{
-if (es)
-{
-struct gc_arena gc = gc_new();
-const struct env_item *e;
-
-e = es->list;
-
-while (e)
-{
-const char *name;
-const char *value;
-
-if (deconstruct_name_value(e->string, , , ))
-{
-setenv_str(NULL, name, value);
-}
-
-e = e->next;
-}
-gc_free();
-}
-}
-
-void
-env_set_remove_from_environment(const struct env_set *es)
-{
-if (es)
-{
-struct gc_arena gc = gc_new();
-const struct env_item *e;
-
-e = es->list;
-
-while (e)
-{
-const char *name;
-const char *value;
-
-if (deconstruct_name_value(e->string, , , ))
-{
-setenv_del(NULL, name);
-}
-
-e = e->next;
-}
-gc_free();
-}
-}
 
 /* add/modify/delete environmental strings */
 
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index 16be621..009767f 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -161,10 +161,6 @@ void env_set_print(int msglevel, const struct env_set *es);
 
 void env_set_inherit(struct env_set *es, const struct env_set *src);
 
-void env_set_add_to_environment(const struct env_set *es);
-
-void env_set_remove_from_environment(const struct env_set *es);
-
 /* Make arrays of strings */
 
 const char **make_env_array(const struct env_set *es,
-- 
2.11.0


--
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] Ignore auth-nocache for auth-user-pass if auth-token is pushed

2017-02-24 Thread Antonio Quartulli

When the auth-token option is pushed from the server to the client,
the latter has to ignore the auth-nocache directive (if specified).

The password will now be substituted by the unique token, therefore
it can't be wiped out, otherwise the next renegotiation will fail.

Trac: #840
Cc: David Sommerseth 
Signed-off-by: Antonio Quartulli 
---
 src/openvpn/init.c | 12 
 src/openvpn/misc.c |  7 ++-
 src/openvpn/misc.h |  2 ++
 src/openvpn/ssl.c  | 33 -
 src/openvpn/ssl.h  |  2 ++
 5 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index ff1551ea..3c0bb32b 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1383,6 +1383,18 @@ initialization_sequence_completed(struct context *c, 
const unsigned int flags)
 /* If we delayed UID/GID downgrade or chroot, do it now */
 do_uid_gid_chroot(c, true);
 
+/*
+ * In some cases (i.e. when receiving auth-token via
+ * push-reply) the auth-nocache option configured on the
+ * client is overridden; for this reason we have to wait
+ * for the push-reply message before attempting to wipe
+ * the user/pass entered by the user
+ */
+if (c->options.mode == MODE_POINT_TO_POINT)
+{
+delayed_auth_pass_purge();
+}
+
 /* Test if errors */
 if (flags & ISC_ERRORS)
 {
diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index a2f45b61..e6678ec8 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -1480,7 +1480,11 @@ purge_user_pass(struct user_pass *up, const bool force)
 secure_memzero(up, sizeof(*up));
 up->nocache = nocache;
 }
-else if (!warn_shown)
+/*
+ * don't show warning if the pass has been replaced by a token: this is an
+ * artificial "auth-nocache"
+ */
+else if (!warn_shown && (!up->tokenized))
 {
 msg(M_WARN, "WARNING: this configuration may cache passwords in memory 
-- use the auth-nocache option to prevent this");
 warn_shown = true;
@@ -1494,6 +1498,7 @@ set_auth_token(struct user_pass *up, const char *token)
 {
 CLEAR(up->password);
 strncpynt(up->password, token, USER_PASS_LEN);
+up->tokenized = true;
 }
 }
 
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index 16be6219..201ebf62 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -206,6 +206,8 @@ struct user_pass
 {
 bool defined;
 bool nocache;
+bool tokenized; /* true if password has been substituted by a token */
+bool wait_for_push; /* true if this object is waiting for a push-reply */
 
 /* max length of username/password */
 #ifdef ENABLE_PKCS11
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 86450fe0..ce301560 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -452,6 +452,8 @@ ssl_set_auth_nocache(void)
 {
 passbuf.nocache = true;
 auth_user_pass.nocache = true;
+/* wait for push-reply, because auth-token may invert nocache */
+auth_user_pass.wait_for_push = true;
 }
 
 /*
@@ -460,6 +462,14 @@ ssl_set_auth_nocache(void)
 void
 ssl_set_auth_token(const char *token)
 {
+if (auth_user_pass.nocache)
+{
+msg(M_INFO,
+"auth-token received, disabling auth-nocache for the "
+"authentication token");
+auth_user_pass.nocache = false;
+}
+
 set_auth_token(_user_pass, token);
 }
 
@@ -2383,7 +2393,21 @@ key_method_2_write(struct buffer *buf, struct 
tls_session *session)
 {
 goto error;
 }
-purge_user_pass(_user_pass, false);
+/* if auth-nocache was specified, the auth_user_pass object reaches
+ * a "complete" state only after having received the push-reply
+ * message.
+ * This is the case because auth-token statement in a push-reply would
+ * invert its nocache.
+ *
+ * For this reason, skip the purge operation here if no push-reply
+ * message has been received yet.
+ *
+ * This normally happens upon first negotiation only.
+ */
+if (!auth_user_pass.wait_for_push)
+{
+purge_user_pass(_user_pass, false);
+}
 }
 else
 {
@@ -4214,6 +4238,13 @@ done:
 return BSTR();
 }
 
+void
+delayed_auth_pass_purge(void)
+{
+auth_user_pass.wait_for_push = false;
+purge_user_pass(_user_pass, false);
+}
+
 #else  /* if defined(ENABLE_CRYPTO) */
 static void
 dummy(void)
diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
index ed1344e7..33a02544 100644
--- a/src/openvpn/ssl.h
+++ b/src/openvpn/ssl.h
@@ -591,6 +591,8 @@ void show_tls_performance_stats(void);
 /*#define EXTRACT_X509_FIELD_TEST*/
 void extract_x509_field_test(void);
 
+void delayed_auth_pass_purge(void);
+
 #endif /* ENABLE_CRYPTO */
 
 #endif /* ifndef OPENVPN_SSL_H */
-- 
2.11.1

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

2017-02-24 Thread Steffan Karger

Hi,

On 24-02-17 22:28, James Yonan wrote:
> On 24/02/2017 02:40, Steffan Karger wrote:
>> On 23-02-17 22:41, James Yonan wrote:
>>> On 23/02/2017 01:22, Steffan Karger wrote:
 On 22-02-17 19:48, James Yonan wrote:
> mbedTLS 2 has a new feature that allows rejection of certificates if the
> key size is too small or the signing hash is weak.
>
> The feature is controlled via struct mbedtls_x509_crt_profile.
>
> For example, you could specify that certificates must be at least 2048
> bits and use a SHA-2 signing alg.
>
> Wondering if we should enable this via an option, or tie it into the
> existing tls-version-min.
>
> The granular approach would be to have specific options for each limit,
> such as ssl-min-key-size, ssl-require-sha2
>
> The bundled approach would be to take an existing option such as
> tls-version-min and add additional constraints onto it.  For example, if
> tls-version-min is 1.2 or higher, then also require minimum key size to
> be 2048 and certificate signing hash to be SHA-2.
 OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
 people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
 function (SHA1+) if that causes trouble.

 If we are going to make this configurable, I think we should separate it
 from tls-version-min.  The main use case I see for using a lower
 security setting would be an out-of-the-admins-control CA, or something
 like (old) smart cards that don't support RSA-2048.  I wouldn't want to
 block people from enforcing TLS 1.2, because their smart card is crappy.

 So I think we'll have to add the relevant --tls-rsa-key-size-min,
 --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
 we want to make it configurable, that is.
>>> I think it needs to be configurable to allow for transitions to stronger
>>> keys.
>>>
>>> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?
>> Adding 'cert' in the option name is very good, it removes confusion
>> between the TLS transcript digest and the cert digest.
>>
>> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature
>> algorithm, but 'SHAx' is the certificates message digest algorithm.
>>
>> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).
>>
>>> For --tls-cert-sign-min, the choices could be "none" (anything allowed
>>> by the underlying SSL lib) or "sha2" (requiring sha256 or higher).
>> This makes sense for the SHA family, but 'or higher' becomes tricky when
>> e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
>> about that.
> 
> I'm still somewhat on the fence about making these options granular vs. 
> bundled.

Yeah, I too find it hard to decide what the best approach is here.
Being involved in OpenVPN the past few years has definitely learned me
the importance of choosing the options right...

> If we do granular, then we need to deal with every option, i.e. rsa key 
> size, cert digests, curves, etc. and we need to establish defaults and a 
> notion of "minimum" which is problematic as you mention above when new 
> algs (such as BLAKE2 as you mention above) enter the mix and its not 
> clear where to place them on the continuum.  Or avoid minimums by simple 
> enumerating the whole whitelist.  But this can become unwieldy with so 
> many options.
> 
> Using the bundled approach would be more like the mbedTLS cert profiles 
> approach where you have a default that allows everything reasonable, and 
> a somewhat stricter profile that requires RSA key sizes >= 2048 and 
> disallows SHA1.  If we use this approach with OpenVPN, then we could 
> have an option --tls-cert-profile .  We would of course 
> need to define named profiles for this to work.

Something like --tls-cert-profile sounds good, I think.  It's decoupled
from --tls-version-min (which I think is good), but still doesn't offer
a gazillion combinations of configurations.  We good go for e.g.
'legacy', 'default', 'suiteb' and perhaps something like 'paranoid'?
We'd have to keep actively monitoring cryptographic advances, and kick
out algs when they become deprecated and/or broken though.

-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] [PATCH v3 00/15] Add support for OpenSSL 1.1.x

2017-02-24 Thread Christian Hesse

Christian Hesse  on Fri, 2017/02/24 13:13:
> Christian Hesse  on Thu, 2017/02/23 21:57:
> > Built v3 against openssl 1.0.2k without issues, tests succeed and two
> > instanced successfully established vpn connection (with server version
> > 2.3.12 and 2.4.0).  
> 
> Just tested a server instance with ancient client (version 2.1.4). Works as
> well.
> 
> I will try to restart another server instance later.

Just restarted the server. Here is the current client connect statistic:

  1  2.3.8
  4  2.3.12
  6  2.3.13
  7  2.3.11
 18  2.3.14
 70  2.4.0

So looks good for now. ;)
-- 
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);}


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

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

2017-02-24 Thread James Yonan

On 24/02/2017 02:40, Steffan Karger wrote:

> On 23-02-17 22:41, James Yonan wrote:
>> On 23/02/2017 01:22, Steffan Karger wrote:
>>> On 22-02-17 19:48, James Yonan wrote:
 mbedTLS 2 has a new feature that allows rejection of certificates if the
 key size is too small or the signing hash is weak.

 The feature is controlled via struct mbedtls_x509_crt_profile.

 For example, you could specify that certificates must be at least 2048
 bits and use a SHA-2 signing alg.

 Wondering if we should enable this via an option, or tie it into the
 existing tls-version-min.

 The granular approach would be to have specific options for each limit,
 such as ssl-min-key-size, ssl-require-sha2

 The bundled approach would be to take an existing option such as
 tls-version-min and add additional constraints onto it.  For example, if
 tls-version-min is 1.2 or higher, then also require minimum key size to
 be 2048 and certificate signing hash to be SHA-2.
>>> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
>>> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
>>> function (SHA1+) if that causes trouble.
>>>
>>> If we are going to make this configurable, I think we should separate it
>>> from tls-version-min.  The main use case I see for using a lower
>>> security setting would be an out-of-the-admins-control CA, or something
>>> like (old) smart cards that don't support RSA-2048.  I wouldn't want to
>>> block people from enforcing TLS 1.2, because their smart card is crappy.
>>>
>>> So I think we'll have to add the relevant --tls-rsa-key-size-min,
>>> --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
>>> we want to make it configurable, that is.
>> I think it needs to be configurable to allow for transitions to stronger
>> keys.
>>
>> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?
> Adding 'cert' in the option name is very good, it removes confusion
> between the TLS transcript digest and the cert digest.
>
> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature
> algorithm, but 'SHAx' is the certificates message digest algorithm.
>
> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).
>
>> For --tls-cert-sign-min, the choices could be "none" (anything allowed
>> by the underlying SSL lib) or "sha2" (requiring sha256 or higher).
> This makes sense for the SHA family, but 'or higher' becomes tricky when
> e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
> about that.

I'm still somewhat on the fence about making these options granular vs. 
bundled.

If we do granular, then we need to deal with every option, i.e. rsa key 
size, cert digests, curves, etc. and we need to establish defaults and a 
notion of "minimum" which is problematic as you mention above when new 
algs (such as BLAKE2 as you mention above) enter the mix and its not 
clear where to place them on the continuum.  Or avoid minimums by simple 
enumerating the whole whitelist.  But this can become unwieldy with so 
many options.

Using the bundled approach would be more like the mbedTLS cert profiles 
approach where you have a default that allows everything reasonable, and 
a somewhat stricter profile that requires RSA key sizes >= 2048 and 
disallows SHA1.  If we use this approach with OpenVPN, then we could 
have an option --tls-cert-profile .  We would of course 
need to define named profiles for this to work.

James

--
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: Fix '--dev null'

2017-02-24 Thread Gert Doering

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

As ordered, '||' have been moved to pos_arith=lead, and the tab 
has been extabinated.

commit 22c5381b71710ad0e1dbbccc1d5680fccb602311 (master)
commit 2085c1f3875b9c96ac739941712247b805677efa (release/2.4)
Author: Gert Doering
Date:   Fri Feb 24 14:52:22 2017 +0100

 Fix '--dev null'

 Signed-off-by: Gert Doering 
 Acked-by: Steffan Karger 
 Message-Id: <20170224135222.44640-1-g...@greenie.muc.de>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14186.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] [PATCH] Fix "--dev null"

2017-02-24 Thread Steffan Karger

Hi,

On 24-02-17 14:52, Gert Doering wrote:
> To test whether a server is reachable and all the key handling is
> right, openvpn can connect with "--dev null --ifconfig-noexec" to
> avoid needing to the client with elevated privileges.
> 
> This was erroring out for no good reason (because the "set environment
> variables appropriately" code didn't know if this is a tun or tap
> device...) - treat --dev null as "tap", done.
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/tun.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 31585b32..12ce99d5 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -560,7 +560,9 @@ is_tun_p2p(const struct tuntap *tt)
>  {
>  bool tun = false;
>  
> -if (tt->type == DEV_TYPE_TAP || (tt->type == DEV_TYPE_TUN && 
> tt->topology == TOP_SUBNET))
> +if (tt->type == DEV_TYPE_TAP ||
> +(tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) ||
> + tt->type == DEV_TYPE_NULL )
>  {
>  tun = false;
>  }
> 

Code makes sense.  Code-ACK.

Style-wise, we went for pos_arith=lead (Knuth style), so

x = first_condition
  && second_condition
  && third_condition

and this patch is trying to sneak a tab into the code! ;)

I'd be fine with you fixing the style on the fly when applying.

-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] [PATCH] Fix "--dev null"

2017-02-24 Thread Gert Doering

Hi,

On Fri, Feb 24, 2017 at 04:32:14PM +0200, Samuli Seppänen wrote:
> On 24/02/2017 15:52, Gert Doering wrote:
> > To test whether a server is reachable and all the key handling is
> > right, openvpn can connect with "--dev null --ifconfig-noexec" to
> > avoid needing to the client with elevated privileges.
> 
> There seems to be a typo here. Did you mean "to avoid needing to
> _connect to_ the client with elevated privileges"?

Actually "to _run_ the client" - indeed.

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] [PATCH] Fix "--dev null"

2017-02-24 Thread Samuli Seppänen

Hi,

On 24/02/2017 15:52, Gert Doering wrote:
> To test whether a server is reachable and all the key handling is
> right, openvpn can connect with "--dev null --ifconfig-noexec" to
> avoid needing to the client with elevated privileges.

There seems to be a typo here. Did you mean "to avoid needing to
_connect to_ the client with elevated privileges"?

> 
> This was erroring out for no good reason (because the "set environment
> variables appropriately" code didn't know if this is a tun or tap
> device...) - treat --dev null as "tap", done.
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/tun.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
> index 31585b32..12ce99d5 100644
> --- a/src/openvpn/tun.c
> +++ b/src/openvpn/tun.c
> @@ -560,7 +560,9 @@ is_tun_p2p(const struct tuntap *tt)
>  {
>  bool tun = false;
>  
> -if (tt->type == DEV_TYPE_TAP || (tt->type == DEV_TYPE_TUN && 
> tt->topology == TOP_SUBNET))
> +if (tt->type == DEV_TYPE_TAP ||
> +(tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) ||
> + tt->type == DEV_TYPE_NULL )
>  {
>  tun = false;
>  }
> 


-- 
Samuli Seppänen
Community Manager
OpenVPN Technologies, Inc

irc freenode net: mattock

--
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] Fix "--dev null"

2017-02-24 Thread Gert Doering

To test whether a server is reachable and all the key handling is
right, openvpn can connect with "--dev null --ifconfig-noexec" to
avoid needing to the client with elevated privileges.

This was erroring out for no good reason (because the "set environment
variables appropriately" code didn't know if this is a tun or tap
device...) - treat --dev null as "tap", done.

Signed-off-by: Gert Doering 
---
 src/openvpn/tun.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 31585b32..12ce99d5 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -560,7 +560,9 @@ is_tun_p2p(const struct tuntap *tt)
 {
 bool tun = false;
 
-if (tt->type == DEV_TYPE_TAP || (tt->type == DEV_TYPE_TUN && tt->topology 
== TOP_SUBNET))
+if (tt->type == DEV_TYPE_TAP ||
+(tt->type == DEV_TYPE_TUN && tt->topology == TOP_SUBNET) ||
+   tt->type == DEV_TYPE_NULL )
 {
 tun = false;
 }
-- 
2.11.1


--
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: fix typo in notification message

2017-02-24 Thread Gert Doering

ACK.  See, I'm totally pro-systemd (today)!!

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

commit b13bc6c9570e00d12e26bb3b8e5bf9bdb0b16eff (master)
commit 4c241acc67c1d6b42dbe1f6199c75d9f7f228ac2 (release/2.4)
Author: Christian Hesse
Date:   Fri Feb 24 13:22:52 2017 +0100

 fix typo in notification message

 Signed-off-by: Christian Hesse 
 Acked-by: Gert Doering 
 Message-Id: <20170224122252.15199-1-l...@eworm.de>
 URL: 
http://www.mail-archive.com/search?l=mid=20170224122252.15199-1-l...@eworm.de
 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

[Openvpn-devel] [PATCH 1/1] fix typo in notification message

2017-02-24 Thread Christian Hesse

From: Christian Hesse 

Signed-off-by: Christian Hesse 
---
 src/openvpn/init.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index ff1551e..7da0061 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -567,7 +567,7 @@ context_init_1(struct context *c)
  * do any fork due to daemon() a future call.
  * See possibly_become_daemon() [init.c] for more details.
  */
-sd_notifyf(0, "READY=1\nSTATUS=Pre-connection initialization 
succesfull\nMAINPID=%lu",
+sd_notifyf(0, "READY=1\nSTATUS=Pre-connection initialization 
successful\nMAINPID=%lu",
(unsigned long) getpid());
 #endif
 
-- 
2.11.1


--
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] [PATCH v3 00/15] Add support for OpenSSL 1.1.x

2017-02-24 Thread Christian Hesse

Christian Hesse  on Thu, 2017/02/23 21:57:
> Built v3 against openssl 1.0.2k without issues, tests succeed and two
> instanced successfully established vpn connection (with server version
> 2.3.12 and 2.4.0).

Just tested a server instance with ancient client (version 2.1.4). Works as
well.

I will try to restart another server instance later.
-- 
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);}


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

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

2017-02-24 Thread Steffan Karger

On 23-02-17 22:41, James Yonan wrote:
> On 23/02/2017 01:22, Steffan Karger wrote:
>> On 22-02-17 19:48, James Yonan wrote:
>>> mbedTLS 2 has a new feature that allows rejection of certificates if the
>>> key size is too small or the signing hash is weak.
>>>
>>> The feature is controlled via struct mbedtls_x509_crt_profile.
>>>
>>> For example, you could specify that certificates must be at least 2048
>>> bits and use a SHA-2 signing alg.
>>>
>>> Wondering if we should enable this via an option, or tie it into the
>>> existing tls-version-min.
>>>
>>> The granular approach would be to have specific options for each limit,
>>> such as ssl-min-key-size, ssl-require-sha2
>>>
>>> The bundled approach would be to take an existing option such as
>>> tls-version-min and add additional constraints onto it.  For example, if
>>> tls-version-min is 1.2 or higher, then also require minimum key size to
>>> be 2048 and certificate signing hash to be SHA-2.
>> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
>> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
>> function (SHA1+) if that causes trouble.
>>
>> If we are going to make this configurable, I think we should separate it
>> from tls-version-min.  The main use case I see for using a lower
>> security setting would be an out-of-the-admins-control CA, or something
>> like (old) smart cards that don't support RSA-2048.  I wouldn't want to
>> block people from enforcing TLS 1.2, because their smart card is crappy.
>>
>> So I think we'll have to add the relevant --tls-rsa-key-size-min,
>> --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
>> we want to make it configurable, that is.
> 
> I think it needs to be configurable to allow for transitions to stronger 
> keys.
> 
> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?

Adding 'cert' in the option name is very good, it removes confusion
between the TLS transcript digest and the cert digest.

'sign' reads like 'signature', while RSA (or ECDSA) is the signature
algorithm, but 'SHAx' is the certificates message digest algorithm.

So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).

> For --tls-cert-sign-min, the choices could be "none" (anything allowed 
> by the underlying SSL lib) or "sha2" (requiring sha256 or higher).

This makes sense for the SHA family, but 'or higher' becomes tricky when
e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
about that.

> Wondering what the defaults should be.

The mbed TLS x509 defaults look pretty sane to me:
 * Cert signatures: RSA2048+ or ECDSA with any curve
 * Cert digests: SHA1+

It might be nicer to bump the digest to SHA2+, if we are going to make
it configurable though.  Especially since Google and Stevens just gave
us another stick to slap people using SHA1 with[0].

-Steffan

[0] https://shattered.io/

--
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] Should we use mbedTLS certificate profiles?

[Openvpn-devel] [PATCH] cleanup: Remove faulty env processing functions

[Openvpn-devel] [PATCH] Ignore auth-nocache for auth-user-pass if auth-token is pushed

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

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

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

[Openvpn-devel] [PATCH applied] Re: Fix '--dev null'

Re: [Openvpn-devel] [PATCH] Fix "--dev null"

Re: [Openvpn-devel] [PATCH] Fix "--dev null"

Re: [Openvpn-devel] [PATCH] Fix "--dev null"

[Openvpn-devel] [PATCH] Fix "--dev null"

[Openvpn-devel] [PATCH applied] Re: fix typo in notification message

[Openvpn-devel] [PATCH 1/1] fix typo in notification message

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

Re: [Openvpn-devel] Should we use mbedTLS certificate profiles?

15 matches

Site Navigation

Mail list logo

Footer information