Re: [Openvpn-devel] wanted: mechanism to send text messages to client

2020-12-22 Thread Steffan Karger
Hi,

On 21-12-2020 21:25, Arne Schwabe wrote:
> Am 21.12.20 um 20:11 schrieb Gert Doering:
>> On Mon, Dec 21, 2020 at 06:24:36PM +, Greg Cox wrote:
>>> If the software were
>>> to contain a mechanism to make certain failure cases automatically more
>>> prominent, particularly for 'simple' users who have GUI clients, it'll be a
>>> big win for supportability on larger installs.
>>
>> This is indeed getting into philosophy... we do send different types of
>> AUTH_FAILED today (like, for token expired).  Maybe we could send an
>> "AUTH_FAILED,cert expired" and have the client display this?
>>
>> (I admit that I'm neither an expert on AUTH_FAILED message, nor on
>> "what is the client doing on variations of it", nor on "what *should*
>> be the expected outcome?".  Selva, Arne will know more).
> 
> It is easy to add that message, [...]

Uhm, I would say it's impossible to send that message. AUTH_FAILED
messages are sent over the control channel, while in case of certificate
errors the control channel will never be initialized.

We could however do something that has the same effect: don't prevent
TLS from sending it's "certificate_expired" alert. OpenVPN 2 (don't know
about 3) currently just doesn't respond at all if it detects a TLS error.

IIRC, this extra-paranoid behaviour has saved us from at least one of
the timing-based attacks on TLS from the past, but I can't recall which one.

At the same time, the TLS protocol and it's implementation have matured
a lot since heartbleed. Possibly beyond the point where usability
concerns now outweigh the security concerns. Before anyone suggests
making this optional: no. no. no. I strongly believer we should
carefully consider if we want to allow TLS to send alerts, or leave this
as-is.

David actually already brought this up in 2016, see this thread:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg12892.html

Note that any of this is separate from the initial discussion, where
Gert proposes to send notifications *before* the certificate expires.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix tls-auth mismatch OCC message when tls-cryptv2 is used.

2020-12-13 Thread Steffan Karger
Hi,

On 11-12-2020 13:59, Arne Schwabe wrote:
> A server with tls-cryptv2 and tls-auth produces the warning:
> 
>   WARNING: 'tls-auth' is present in local config but missing in remote 
> config, local='tls-auth'"
> 
> The tls-auth option has no argument so the strpefix with the space
> included does not match it.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/options.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index d824cbad..d9d492b2 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -4138,7 +4138,7 @@ options_warning_safe_scan2(const int msglevel,
>  if (strprefix(p1, "key-method ")
>  || strprefix(p1, "keydir ")
>  || strprefix(p1, "proto ")
> -|| strprefix(p1, "tls-auth ")
> +|| streq(p1, "tls-auth")
>      || strprefix(p1, "tun-ipv6")
>  || strprefix(p1, "cipher "))
>  {
> 

Thanks for fixing this.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH 1/2 v2] tls-crypt-v2: fix server memory leak

2020-12-03 Thread Steffan Karger
tls-crypt-v2 was developed in parallel with the changes that allowed to
use tls-auth/tls-crypt in connection blocks. The tls-crypt-v2 patch set
was never updated to the new reality after commit 5817b49b, causing a
memory leak of about 600 bytes for each connecting client.

It would be nicer to not reload the tls-crypt-v2 server key for each
connecting client, but that requires more refactoring (and thus more time
to get right). So for now just plug the leak by free'ing the memory when
we close a client connection.

To test this easily, compile openvpn with -fsanity=address, run a server
with tls-crypt-v2, connect a client, stop the server.

Signed-off-by: Steffan Karger 
---
v2: remove now-redundant free_key_ctx() from key_schedule_free()

 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 27a4170d..c3493c42 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2561,7 +2561,6 @@ key_schedule_free(struct key_schedule *ks, bool 
free_ssl_ctx)
 if (tls_ctx_initialised(>ssl_ctx) && free_ssl_ctx)
 {
 tls_ctx_free(>ssl_ctx);
-free_key_ctx(>tls_crypt_v2_server_key);
 }
 CLEAR(*ks);
 }
@@ -3619,6 +3618,7 @@ do_close_free_key_schedule(struct context *c, bool 
free_ssl_ctx)
  * always free the tls_auth/crypt key. If persist_key is true, the key will
  * be reloaded from memory (pre-cached)
  */
+free_key_ctx(>c1.ks.tls_crypt_v2_server_key);
 free_key_ctx_bi(>c1.ks.tls_wrap_key);
 CLEAR(c->c1.ks.tls_wrap_key);
 buf_clear(>c1.ks.tls_crypt_v2_wkc);
-- 
2.25.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH 2/2] tls-crypt-v2: also preload tls-crypt-v2 keys (if --persist-key)

2020-12-03 Thread Steffan Karger
This allows tls-crypt-v2 servers to drop privileges after reading the
keys. Without it, the server would try to read the key file for each
connecting client. (And clients for each reconnect.)

As with the previous patch, the pre-loading was developed in parallel
with tls-crypt-v2, and the tls-crypt-v2 patches were never amended to
implement the pre-loading.

Also as with the previous patch, it would be nicer if servers would not
reload the tls-crypt-v2 server key for each connecting client. But let's
first fix the issue, and see if we can improve later.

Signed-off-by: Steffan Karger 
---
 src/openvpn/options.c | 52 +--
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 21f8d494..599f534c 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -1980,6 +1980,23 @@ connection_entry_load_re(struct connection_entry *ce, 
const struct remote_entry
 }
 }
 
+static void
+connection_entry_preload_key(const char **key_file, bool *key_inline,
+ struct gc_arena *gc)
+{
+if (key_file && *key_file && !(*key_inline))
+{
+struct buffer in = buffer_read_from_file(*key_file, gc);
+if (!buf_valid())
+{
+msg(M_FATAL, "Cannot pre-load keyfile (%s)", *key_file);
+}
+
+*key_file = (const char *) in.data;
+*key_inline = true;
+}
+}
+
 static void
 options_postprocess_verify_ce(const struct options *options,
   const struct connection_entry *ce)
@@ -2931,36 +2948,17 @@ options_postprocess_mutate_ce(struct options *o, struct 
connection_entry *ce)
 ce->tls_crypt_v2_file_inline = o->tls_crypt_v2_file_inline;
 }
 
-/* pre-cache tls-auth/crypt key file if persist-key was specified and keys
- * were not already embedded in the config file
+/* Pre-cache tls-auth/crypt(-v2) key file if persist-key was specified and
+ * keys were not already embedded in the config file.
  */
 if (o->persist_key)
 {
-if (ce->tls_auth_file && !ce->tls_auth_file_inline)
-{
-struct buffer in = buffer_read_from_file(ce->tls_auth_file, 
>gc);
-if (!buf_valid())
-{
-msg(M_FATAL, "Cannot pre-load tls-auth keyfile (%s)",
-ce->tls_auth_file);
-}
-
-ce->tls_auth_file = (char *)in.data;
-ce->tls_auth_file_inline = true;
-}
-
-if (ce->tls_crypt_file && !ce->tls_crypt_file_inline)
-{
-struct buffer in = buffer_read_from_file(ce->tls_crypt_file, 
>gc);
-if (!buf_valid())
-{
-msg(M_FATAL, "Cannot pre-load tls-crypt keyfile (%s)",
-ce->tls_crypt_file);
-}
-
-ce->tls_crypt_file = (char *)in.data;
-ce->tls_crypt_file_inline = true;
-}
+connection_entry_preload_key(>tls_auth_file,
+ >tls_auth_file_inline, >gc);
+connection_entry_preload_key(>tls_crypt_file,
+ >tls_crypt_file_inline, >gc);
+connection_entry_preload_key(>tls_crypt_v2_file,
+ >tls_crypt_v2_file_inline, >gc);
 }
 }
 
-- 
2.25.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH 1/2] tls-crypt-v2: fix server memory leak

2020-12-03 Thread Steffan Karger
tls-crypt-v2 was developed in parallel with the changes that allowed to
use tls-auth/tls-crypt in connection blocks. The tls-crypt-v2 patch set
was never updated to the new reality after commit 5817b49b, causing a
memory leak of about 600 bytes for each connecting client.

It would be nicer to not reload the tls-crypt-v2 server key for each
connecting client, but that requires more refactoring (and thus more time
to get right). So for now just plug the leak by free'ing the memory when
we close a client connection.

To test this easily, compile openvpn with -fsanity=address, run a server
with tls-crypt-v2, connect a client, stop the server.

Signed-off-by: Steffan Karger 
---
 src/openvpn/init.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 27a4170d..5cde8a4b 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3619,6 +3619,7 @@ do_close_free_key_schedule(struct context *c, bool 
free_ssl_ctx)
  * always free the tls_auth/crypt key. If persist_key is true, the key will
  * be reloaded from memory (pre-cached)
  */
+free_key_ctx(>c1.ks.tls_crypt_v2_server_key);
 free_key_ctx_bi(>c1.ks.tls_wrap_key);
 CLEAR(c->c1.ks.tls_wrap_key);
 buf_clear(>c1.ks.tls_crypt_v2_wkc);
-- 
2.25.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Fix port-share option with TLS-Crypt v2

2020-12-03 Thread Steffan Karger
Hi,

On 30-11-2020 13:38, Arne Schwabe wrote:
> The port-share option assumed that all openvpn initial reset packets
> are between 14 and 255 bytes long. This is not true for tls-crypt-v2.
> 
> Patch V2: use correct length for TLS-Crypt v2, use length variable
>   non-tlscryptv2 test
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/ps.c | 34 +-
>  1 file changed, 29 insertions(+), 5 deletions(-)
> 
> diff --git a/src/openvpn/ps.c b/src/openvpn/ps.c
> index 2089e6b9..5d760782 100644
> --- a/src/openvpn/ps.c
> +++ b/src/openvpn/ps.c
> @@ -983,14 +983,38 @@ is_openvpn_protocol(const struct buffer *buf)
>  const int len = BLEN(buf);
>  if (len >= 3)
>  {
> -return p[0] == 0
> -   && p[1] >= 14
> -   && (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << P_OPCODE_SHIFT)
> -   || p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << 
> P_OPCODE_SHIFT));
> +int plen = (p[0] << 8) | p[1];
> +
> +if (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << P_OPCODE_SHIFT))
> +{
> +/* WKc is at least 290 byte (not including metadata):
> + *
> + * 16 bit len + 256 bit HMAC + 2048 bit Kc = 2320 bit
> + *
> + * This is increased by the normal length of client handshake +
> + * tls-crypt overhead (32)
> + *
> + * For metadata tls-crypt-v2.txt does not explicitly specify
> + * an upper limit but we also have TLS_CRYPT_V2_MAX_WKC_LEN
> + * as 1024 bytes. We err on the safe side with 255 extra overhead
> + *
> + * We don't do the 2 byte check for tls-crypt-v2 because it is 
> very
> + * unrealistic to have only 2 bytes available.
> + */
> +return  (plen >= 336 && plen < (1024 + 255));
> +}
> +else
> +{
> +/* For non tls-crypt2 we assume the packet length to valid 
> between
> + * 14 and 255 */
> +return plen >= 14 && plen <= 255
> +   && (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << 
> P_OPCODE_SHIFT));
> +}
>  }
>  else if (len >= 2)
>  {
> -return p[0] == 0 && p[1] >= 14;
> +int plen = (p[0] << 8) | p[1];
> +return plen >= 14 && plen <= 255;
>  }
>  else
>  {
> 

Thanks. This looks good to me now.

Ran some tests to check that this correctly resolves the issue when
using --tls-crypt-v2 in combination with --port-share.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix port-share option with TLS-Crypt v2

2020-11-22 Thread Steffan Karger
Hi,

On 20-11-2020 17:04, Arne Schwabe wrote:
> The port-share option assumed that all openvpn initial reset packets
> are between 14 and 255 bytes long. This is not true for tls-crypt-v2.

Good catch, I totally missed this in the tls-crypt-v2 patch set.

> ---
>  src/openvpn/ps.c | 34 ++
>  1 file changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/ps.c b/src/openvpn/ps.c
> index 2089e6b9..cd00bc23 100644
> --- a/src/openvpn/ps.c
> +++ b/src/openvpn/ps.c
> @@ -983,10 +983,36 @@ is_openvpn_protocol(const struct buffer *buf)
>  const int len = BLEN(buf);
>  if (len >= 3)
>  {
> -return p[0] == 0
> -   && p[1] >= 14
> -   && (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << P_OPCODE_SHIFT)
> -   || p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << 
> P_OPCODE_SHIFT));
> +if (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V3 << P_OPCODE_SHIFT))
> +{
> +/* WKc is at least 306 byte (not including metadata):
> + *
> + * 16 bit len + 256 bit HMAC + 128 bit IV + 2048 bit Kc = 2448 
> bit

The IV is part of the HMAC, so does not need to be counted here. So this
this be 2320 bits / 290 bytes.

> + *
> + * This is increased by the normal length of client handshake +
> + * tls-crypt overhead (32)
> + *
> + * For metadata tls-crypt-v2.txt does not explicitly specify
> + * an upper limit but we also have TLS_CRYPT_V2_MAX_WKC_LEN
> + * as 1024 bytes. We err on the safe side with 255 extra overhead
> + *
> + * We don't do the 2 byte check for tls-crypt-v2 because it is 
> very
> + * unrealistic to have only 2 bytes available.
> + */
> +int plen = (p[0] << 8) | p[1];
> +
> +return  (plen >= 352 && plen < (1024 + 255));
> +}
> +else
> +{
> +/* first two bytes are the size field. This is an openvpn packet
> + * between 14 bytes and 255 (otherwise p[1] would be 01 or 
> larger.
> + * on the hard reset packet key_id is zero, so only the opcode
> + * part is non-null */

Instead of explaining the length field in the comment, why not just move
the "int plen = (p[0] << 8) | p[1];" outside the if to have the code
explain that by itself?

> +return p[0] == 0
> +&& p[1] >= 14
> +&& (p[2] == (P_CONTROL_HARD_RESET_CLIENT_V2 << 
> P_OPCODE_SHIFT));
> +}
>  }
>  else if (len >= 2)
>  {
> 

Thanks,
-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Fix compilation on pre-EKM mbedTLS libraries.

2020-10-10 Thread Steffan Karger
Hi,

On 10-10-2020 10:14, Gert Doering wrote:
> commit f0734e49956217 simplified key_state_export_keying_material(),
> changing the function prototype.  For older mbedTLS versions, there
> is an "always fail" dummy function which was overlooked in that change.
> 
> Fix prototype.
> 
> v2: also adjust function return (NULL -> false)
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/ssl_mbedtls.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
> index bb5633b7..11fbeae4 100644
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> @@ -252,14 +252,13 @@ key_state_export_keying_material(struct tls_session 
> *session,
>  }
>  }
>  #else
> -unsigned char*
> +bool
>  key_state_export_keying_material(struct tls_session *session,
>   const char* label, size_t label_size,
> - size_t ekm_size,
> - struct gc_arena *gc)
> + void *ekm, size_t ekm_size)
>  {
>  /* Dummy function to avoid ifdefs in the common code */
> -return NULL;
> +return false;
>  }
>  #endif /* HAVE_EXPORT_KEYING_MATERIAL */
>  
> 

Sorry, totally missed this. Fix looks good.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Simplify key material exporter backend API

2020-10-09 Thread Steffan Karger
Just pass pointer and length, instead of a gc and return (possibly)
allocated memory. Saves us some gc instantiations and memcpy()s. Exact
same functionality, 19 lines less code.

(Didn't want to delay the TLS EKM reviews for this, so submitted as a
patch afterwards.)

Signed-off-by: Steffan Karger 
---
 src/openvpn/ssl.c | 26 --
 src/openvpn/ssl_backend.h | 14 +-
 src/openvpn/ssl_mbedtls.c | 12 +---
 src/openvpn/ssl_openssl.c | 11 ---
 4 files changed, 22 insertions(+), 41 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index b572b7b8..87b51d96 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -1786,23 +1786,14 @@ init_key_contexts(struct key_ctx_bi *key,
 static bool
 generate_key_expansion_tls_export(struct tls_session *session, struct key2 
*key2)
 {
-struct gc_arena gc = gc_new();
-unsigned char *key2data;
-
-key2data = key_state_export_keying_material(session,
-EXPORT_KEY_DATA_LABEL,
-strlen(EXPORT_KEY_DATA_LABEL),
-sizeof(key2->keys),
-);
-if (!key2data)
+if (!key_state_export_keying_material(session, EXPORT_KEY_DATA_LABEL,
+  strlen(EXPORT_KEY_DATA_LABEL),
+  key2->keys, sizeof(key2->keys)))
 {
 return false;
 }
-memcpy(key2->keys, key2data, sizeof(key2->keys));
-secure_memzero(key2data, sizeof(key2->keys));
 key2->n = 2;
 
-gc_free();
 return true;
 }
 
@@ -2499,12 +2490,11 @@ export_user_keying_material(struct key_state_ssl *ssl,
 unsigned int size = session->opt->ekm_size;
 struct gc_arena gc = gc_new();
 
-unsigned char *ekm;
-if ((ekm = key_state_export_keying_material(session,
-session->opt->ekm_label,
-
session->opt->ekm_label_size,
-session->opt->ekm_size,
-)))
+unsigned char *ekm = gc_malloc(session->opt->ekm_size, true, );
+if (key_state_export_keying_material(session,
+ session->opt->ekm_label,
+ session->opt->ekm_label_size,
+ ekm, session->opt->ekm_size))
 {
 unsigned int len = (size * 2) + 2;
 
diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index 4bcb3181..c3d12e5b 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -398,18 +398,14 @@ void backend_tls_ctx_reload_crl(struct tls_root_ctx 
*ssl_ctx,
  * @param session  The session associated with the given key_state
  * @param labelThe label to use when exporting the key
  * @param label_size   The size of the label to use when exporting the key
- * @param ekm_size THe size of the exported/returned key material
- * @param gc   gc_arena that might be used to allocate the string
- * returned
- * @returnsThe exported key material, the caller may zero the
- * string but should not free it
+ * @param ekm  Buffer to return the exported key material in
+ * @param ekm_size The size of ekm, in bytes
+ * @returnstrue if exporting succeeded, false otherwise
  */
-
-unsigned char*
+bool
 key_state_export_keying_material(struct tls_session *session,
  const char* label, size_t label_size,
- size_t ekm_size,
- struct gc_arena *gc) __attribute__((nonnull));
+ void *ekm, size_t ekm_size);
 
 /**/
 /** @addtogroup control_tls
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index f375e957..bb5633b7 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -219,11 +219,10 @@ mbedtls_ssl_export_keys_cb(void *p_expkey, const unsigned 
char *ms,
 return true;
 }
 
-unsigned char *
+bool
 key_state_export_keying_material(struct tls_session *session,
  const char* label, size_t label_size,
- size_t ekm_size,
- struct gc_arena *gc)
+ void *ekm, size_t ekm_size)
 {
 ASSERT(strlen(label) == label_size);
 
@@ -233,10 +232,9 @@ key_state_export_keying_material(struct tls_session 
*session,
  * there is no PRF, in both cases we cannot generate key material */
 if (cache-&

[Openvpn-devel] [PATCH] networking_iproute2: fix memory leak in net_iface_mtu_set()

2020-10-09 Thread Steffan Karger
ASAN yelled at me that someone forgot to call argv_free(). Fix that.

Signed-off-by: Steffan Karger 
---
 src/openvpn/networking_iproute2.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/src/openvpn/networking_iproute2.c 
b/src/openvpn/networking_iproute2.c
index f3b9c614..3b460527 100644
--- a/src/openvpn/networking_iproute2.c
+++ b/src/openvpn/networking_iproute2.c
@@ -88,6 +88,8 @@ net_iface_mtu_set(openvpn_net_ctx_t *ctx, const char *iface, 
uint32_t mtu)
 argv_msg(M_INFO, );
 openvpn_execve_check(, ctx->es, S_FATAL, "Linux ip link set failed");
 
+argv_free();
+
 return 0;
 }
 
-- 
2.25.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v5] Implement generating data channel keys via EKM/RFC 5705

2020-10-09 Thread Steffan Karger
),
> +sizeof(key2->keys),
> +);
> +if (!key2data)
> +{
> +return false;
> +}
> +memcpy(key2->keys, key2data, sizeof(key2->keys));
> +secure_memzero(key2data, sizeof(key2->keys));
> +key2->n = 2;
> +
> +gc_free();
> +return true;
> +}
> +
>  static struct key2
>  generate_key_expansion_openvpn_prf(const struct tls_session *session)
>  {
> @@ -1854,7 +1877,7 @@ generate_key_expansion_openvpn_prf(const struct 
> tls_session *session)
>   */
>  static bool
>  generate_key_expansion(struct key_ctx_bi *key,
> -   const struct tls_session *session)
> +   struct tls_session *session)
>  {
>  bool ret = false;
>  struct key2 key2;
> @@ -1865,10 +1888,20 @@ generate_key_expansion(struct key_ctx_bi *key,
>  goto exit;
>  }
>  
> -
>  bool server = session->opt->server;
>  
> -key2 = generate_key_expansion_openvpn_prf(session);
> +if (session->opt->crypto_flags & CO_USE_TLS_KEY_MATERIAL_EXPORT)
> +{
> +if (!generate_key_expansion_tls_export(session, ))
> +{
> +msg(D_TLS_ERRORS, "TLS Error: Keying material export failed");
> +goto exit;
> +}
> +}
> +else
> +{
> +key2 = generate_key_expansion_openvpn_prf(session);
> +}
>  
>  key2_print(, >opt->key_type,
> "Master Encrypt", "Master Decrypt");
> @@ -1967,6 +2000,11 @@ tls_session_update_crypto_params(struct tls_session 
> *session,
>  return false;
>  }
>  
> +if (options->data_channel_use_ekm)
> +{
> +session->opt->crypto_flags |= CO_USE_TLS_KEY_MATERIAL_EXPORT;
> +}
> +
>  if (strcmp(options->ciphername, session->opt->config_ciphername))
>  {
>  msg(D_HANDSHAKE, "Data Channel: using negotiated cipher '%s'",
> @@ -2251,13 +2289,11 @@ push_peer_info(struct buffer *buf, struct tls_session 
> *session)
>   * push request, also signal that the client wants
>   * to get push-reply messages without without requiring a round
>   * trip for a push request message*/
> -if(session->opt->pull)
> +if (session->opt->pull)
>  {
>  iv_proto |= IV_PROTO_REQUEST_PUSH;
>  }
>  
> -buf_printf(, "IV_PROTO=%d\n", iv_proto);
> -
>  /* support for Negotiable Crypto Parameters */
>  if (session->opt->ncp_enabled
>  && (session->opt->mode == MODE_SERVER || session->opt->pull))
> @@ -2269,8 +2305,14 @@ push_peer_info(struct buffer *buf, struct tls_session 
> *session)
>  buf_printf(, "IV_NCP=2\n");
>  }
>  buf_printf(, "IV_CIPHERS=%s\n", 
> session->opt->config_ncp_ciphers);
> +
> +#ifdef HAVE_EXPORT_KEYING_MATERIAL
> +iv_proto |= IV_PROTO_TLS_KEY_EXPORT;
> +#endif
>  }
>  
> +buf_printf(, "IV_PROTO=%d\n", iv_proto);
> +
>  /* push compression status */
>  #ifdef USE_COMP
>  comp_generate_peer_info_string(>opt->comp_options, );
> diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
> index 005628f6..f00f8abd 100644
> --- a/src/openvpn/ssl.h
> +++ b/src/openvpn/ssl.h
> @@ -116,6 +116,8 @@
>   * to wait for a push-request to send a push-reply */
>  #define IV_PROTO_REQUEST_PUSH   (1<<2)
>  
> +/** Supports key derivation via TLS key material exporter [RFC5705] */
> +#define IV_PROTO_TLS_KEY_EXPORT (1<<3)
>  
>  /* Default field in X509 to be username */
>  #define X509_USERNAME_FIELD_DEFAULT "CN"
> diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
> index cf9fba25..4bcb3181 100644
> --- a/src/openvpn/ssl_backend.h
> +++ b/src/openvpn/ssl_backend.h
> @@ -389,6 +389,7 @@ void key_state_ssl_free(struct key_state_ssl *ks_ssl);
>  void backend_tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
>  const char *crl_file, bool crl_inline);
>  
> +#define EXPORT_KEY_DATA_LABEL   "EXPORTER-OpenVPN-datakeys"
>  /**
>   * Keying Material Exporters [RFC 5705] allows additional keying material to 
> be
>   * derived from existing TLS channel. This exported keying material can then 
> be
> diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
> index 4ec355a9..f375e957 100644
> --- a/src/openvpn/ssl_mbedtls.c
> +++ b/src/openvpn/ssl_mbedtls.c
> @@ -1168,11 +1168,8 @@ key_state_ssl_init(struct key_state_ssl *ks_ssl,
>  
>  #ifdef HAVE_EXPORT_KEYING_MATERIAL
>  /* Initialize keying material exporter */
> -if (session->opt->ekm_size)
> -{
> -mbedtls_ssl_conf_export_keys_ext_cb(ks_ssl->ssl_config,
> -mbedtls_ssl_export_keys_cb, 
> session);
> -}
> +mbedtls_ssl_conf_export_keys_ext_cb(ks_ssl->ssl_config,
> +mbedtls_ssl_export_keys_cb, session);
>  #endif
>  
>  /* Initialise SSL context */
> 

If the above is fixed:

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v4 2/2] Implement generating data channel keys via EKM/RFC 5705

2020-10-09 Thread Steffan Karger
Hi,

On 25-08-2020 09:36, Arne Schwabe wrote:
> OpenVPN currently uses its own (based on TLS 1.0) key derivation
> mechanism to generate the 256 bytes key data in key2 struct that
> are then used used to generate encryption/hmac/iv vectors. While
> this mechanism is still secure, it is not state of the art.
> 
> Instead of modernising our own approach, this commit implements
> key derivation using the Keying Material Exporters API introduced
> by RFC 5705.

Thanks! I'm glad to see you're picking up the work I haven't been able
to find time for.

> We also use an opportunistic approach of negotiating the use of
> EKM (exported key material) through an IV_PROTO flag and prefer
> EKM to our own PRF if both client and server support it. The
> use of EKM is pushed to the client as part of NCP as
> key-derivation tls-ekm.
> 
> We still exchange the random data (112 bytes from client to server
> and 64 byte from server to client) for the OpenVPN PRF but
> do not use it. Removing that exchange would break the handshake
> and make a key-method 3 or similar necessary.
> 
> As a side effect, this makes a little bit easier to have a FIPS compatible
> version of OpenVPN since we do not rely on calling MD5 anymore.
> 
> Side note: this commit breaks the (not yet merged) WolfSSL support as it
> claims to support EKM in the OpenSSL compat API but always returns an error
> if you try to use it.
> 
> Signed-off-by: Arne Schwabe 

Signed off two times.

> Patch v2: rebase/change to V2 of EKM refactoring
> 
> Patch v3: add Changes.rst
> 
> Signed-off-by: Arne Schwabe 
> ---
>  Changes.rst  | 11 +++
>  doc/doxygen/doc_key_generation.h | 14 +++--
>  src/openvpn/crypto.h |  4 +++
>  src/openvpn/init.c   |  1 +
>  src/openvpn/multi.c  |  4 +++
>  src/openvpn/options.c| 14 +
>  src/openvpn/options.h|  3 ++
>  src/openvpn/push.c   |  5 ++-
>  src/openvpn/ssl.c| 54 
>  src/openvpn/ssl.h|  2 ++
>  src/openvpn/ssl_backend.h|  2 ++
>  src/openvpn/ssl_mbedtls.c|  7 ++---
>  12 files changed, 107 insertions(+), 14 deletions(-)
> 
> diff --git a/Changes.rst b/Changes.rst
> index f67e1d76..2a2829e7 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -1,3 +1,14 @@
> +Overview of changes in 2.6
> +==
> +
> +
> +New features
> +
> +Keying Material Exporters (RFC 5705) based key generation
> +As part of the cipher negotiation OpenVPN will automatically prefer
> +the RFC5705 based key material generation to the current custom
> +OpenVPN PRF. This feature requires OpenSSL or mbed TLS 2.18+.
> +
>  Overview of changes in 2.5
>  ==
>  
> diff --git a/doc/doxygen/doc_key_generation.h 
> b/doc/doxygen/doc_key_generation.h
> index 4bb9c708..cef773a9 100644
> --- a/doc/doxygen/doc_key_generation.h
> +++ b/doc/doxygen/doc_key_generation.h
> @@ -58,6 +58,12 @@
>   *
>   * @subsection key_generation_method_2 Key method 2
>   *
> + * There are two methods for generating key data when using key method 2
> + * the first is OpenVPN's traditional approach that exchanges random
> + * data and uses a PRF and the other is using the RFC5705 keying material
> + * exporter to generate the key material. For both methods the random
> + * data is exchange but only used in the traditional method.
> + *
>   * -# The client generates random material in the following amounts:
>   *- Pre-master secret: 48 bytes
>   *- Client's PRF seed for master secret: 32 bytes
> @@ -73,8 +79,12 @@
>   *server's random material.
>   *
>   * %Key method 2 %key expansion is performed by the \c
> - * generate_key_expansion() function.  Please refer to its source code for
> - * details of the %key expansion process.
> + * generate_key_expansion_openvpn_prf() function.  Please refer to its source
> + * code for details of the %key expansion process.
> + *
> + * When the client sends the IV_PROTO_TLS_KEY_EXPORT flag and the server 
> replies
> + * with `key-derivation tls-ekm` the RFC5705 key material exporter with the
> + * label EXPORTER-OpenVPN-datakeys is used for the key data.

Did you request this label with IANA?

Also, a user could now use --keying-material-exporter to export the data
channel keys to a plugin. I'm inclined to say we should prevent that, by
rejecting our internal label as a user label.

>   * @subsection key_generation_random Source of random material
>   *
> diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
> index 999f643e..ec935ca5 100644
> --- a/src/openvpn/crypto.h
> +++ b/src/openvpn/crypto.h
> @@ -254,6 +254,10 @@ struct crypto_options
>  #define CO_MUTE_REPLAY_WARNINGS (1<<2)
>  /**< Bit-flag indicating not to display
>   *   replay warnings. */
> +#define CO_USE_TLS_KEY_MATERIAL_EXPORT  (1<<3)
> +/**< Bit-flag indicating that key derivation

Sugestion: "data channel key 

Re: [Openvpn-devel] Introducing the OpenVPN Data Channel Offload Linux kernel module (ovpn-dco)

2020-10-06 Thread Steffan Karger
Hi Antonio,

On 22-09-2020 16:17, Antonio Quartulli wrote:
> Dear all,
> 
> OpenVPN Inc.[1] and me are happy to announce that today we have released
> to the public our work-in-progress project called "ovpn-dco".
> 
> [...] 
> 
> The idea of implementing an OpenVPN kernel module has been around for
> years; finally what were once words have become lines of code.
> I hope more enthusiasts will join the project and help pushing the
> development forward.

Congrats! Very cool that the first version of the code is out. I'm very
much looking forward to this progressing towards stable and
feature-complete code.

I can't make any promises on involvement right now, but you most
certainly triggered my interest :)

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v4 1/2] Move openvpn specific key expansion into its own function

2020-10-04 Thread Steffan Karger
ssion->opt->server;
> +
> +key2 = generate_key_expansion_openvpn_prf(session);
> +
> +key2_print(, >opt->key_type,
> +   "Master Encrypt", "Master Decrypt");
>  
>  /* check for weak keys */
>  for (int i = 0; i < 2; ++i)
>  {
> -fixup_key([i], key_type);
> -if (!check_key([i], key_type))
> +if (!check_key([i], >opt->key_type))
>  {
>  msg(D_TLS_ERRORS, "TLS Error: Bad dynamic key generated");
>  goto exit;
>  }
>  }
> -
> -/* Initialize OpenSSL key contexts */
> -int key_direction = server ? KEY_DIRECTION_INVERSE : 
> KEY_DIRECTION_NORMAL;
> -init_key_ctx_bi(key, , key_direction, key_type, "Data Channel");
> -
> -/* Initialize implicit IVs */
> -key_ctx_update_implicit_iv(>encrypt, key2.keys[(int)server].hmac,
> -   MAX_HMAC_KEY_LENGTH);
> -key_ctx_update_implicit_iv(>decrypt, key2.keys[1-(int)server].hmac,
> -   MAX_HMAC_KEY_LENGTH);
> -
> +init_key_contexts(key, >opt->key_type, server, );
>  ret = true;
>  
>  exit:
> -secure_memzero(, sizeof(master));
>  secure_memzero(, sizeof(key2));
>  
>  return ret;
>  }
>  
> +

Stray newline.

>  static void
>  key_ctx_update_implicit_iv(struct key_ctx *ctx, uint8_t *key, size_t key_len)
>  {
> @@ -1879,10 +1922,7 @@ tls_session_generate_data_channel_keys(struct 
> tls_session *session)
>  {
>  bool ret = false;
>  struct key_state *ks = >key[KS_PRIMARY];   /* primary key */
> -const struct session_id *client_sid = session->opt->server ?
> -  >session_id_remote : 
> >session_id;
> -const struct session_id *server_sid = !session->opt->server ?
> -  >session_id_remote : 
> >session_id;
> +
>  
>  if (ks->authenticated == KS_AUTH_FALSE)
>  {
> @@ -1891,9 +1931,8 @@ tls_session_generate_data_channel_keys(struct 
> tls_session *session)
>  }
>  
>  ks->crypto_options.flags = session->opt->crypto_flags;
> -if (!generate_key_expansion(>crypto_options.key_ctx_bi,
> ->opt->key_type, ks->key_src, 
> client_sid, server_sid,
> -session->opt->server))
> +
> +if (!generate_key_expansion(>crypto_options.key_ctx_bi, session))

Since you're passing session now, shouldn't you remove the key_ctx_bi
argument too? That's also part of session: (struct key_state) *ks =
>key[KS_PRIMARY].

>  {
>  msg(D_TLS_ERRORS, "TLS Error: generate_key_expansion failed");
>  goto cleanup;
> 

Otherwise this looks good. I can also live with leaving key_ctx_bi in
for now. The current version of the patch is a clear improvement (and
paving the way for 2/2, ofc.)

So, as long as at least the whitespace is fixed:

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix client's poor man NCP fallback

2020-08-22 Thread Steffan Karger
Hi,

On 14-08-2020 10:06, Arne Schwabe wrote:
> OpenVPN 2.5 clients do not correctly do a fallback to the server server.
> This commit fixes that logic and also fixes --data-ciphers-fallback to
> be used in situations other than no OCC cipher.
> 
> To reproduce the error use a client with only --data-ciphers set against
> a server without NCP.
> 
> OPTIONS ERROR: failed to negotiate cipher with server.
> Add the server's cipher  ('AES-256-CBC') to --data-ciphers
> (currently 'AES-256-CBC') if you want to connect to this server.
> 
> Reported by: Richard Bonhomme 
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/ssl_ncp.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index f522b8f0..c9ab85ce 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -296,13 +296,14 @@ check_pull_client_ncp(struct context *c, const int 
> found)
>  }
>  /* If the server did not push a --cipher, we will switch to the
>   * remote cipher if it is in our ncp-ciphers list */
> -bool useremotecipher = tls_poor_mans_ncp(>options,
> - 
> c->c2.tls_multi->remote_ciphername);
> -
> +if(tls_poor_mans_ncp(>options, c->c2.tls_multi->remote_ciphername))
> +{
> +return true;
> +}
>  
>  /* We could not figure out the peer's cipher but we have fallback
>   * enabled */
> -if (!useremotecipher && c->options.enable_ncp_fallback)
> +if (!c->c2.tls_multi->remote_ciphername && 
> c->options.enable_ncp_fallback)
>  {
>  return true;
>  }
> 

This makes sense. Given that the commit message is fixed as suggested by
Richard:

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 2/3] Move openvpn specific key expansion into its own function

2020-08-21 Thread Steffan Karger
Hi,

On 12-08-2020 16:01, Arne Schwabe wrote:
> This moves the OpenVPN specific PRF into its own function also
> simplifies the code a bit by passing tls_session directly instead of
> 5 of its fields.

Moves in the right direction. Some comments though:

> Signed-off-by: Arne Schwabe 
> 
> Patch V2: Rebase
> ---
>  src/openvpn/ssl.c | 109 +-
>  1 file changed, 69 insertions(+), 40 deletions(-)
> 
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 3fcaa25f..06cc4c0b 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -1765,27 +1765,38 @@ openvpn_PRF(const uint8_t *secret,
>  VALGRIND_MAKE_READABLE((void *)output, output_len);
>  }
>  
> -/*
> - * Using source entropy from local and remote hosts, mix into
> - * master key.
> - */
> -static bool
> -generate_key_expansion(struct key_ctx_bi *key,
> -   const struct key_type *key_type,
> -   const struct key_source2 *key_src,
> -   const struct session_id *client_sid,
> -   const struct session_id *server_sid,
> -   bool server)
> +static void
> +init_key_contexts(struct key_ctx_bi *key,
> +  const struct key_type *key_type,
> +  bool server,
> +  struct key2 *key2)
> +{
> +/* Initialize OpenSSL key contexts */

Since you're touching this, can you remove "OpenSSL" from this comment.
It's a lie! Sometimes.

> +int key_direction = server ? KEY_DIRECTION_INVERSE : 
> KEY_DIRECTION_NORMAL;
> +init_key_ctx_bi(key, key2, key_direction, key_type, "Data Channel");
> +
> +/* Initialize implicit IVs */
> +key_ctx_update_implicit_iv(>encrypt, (*key2).keys[(int)server].hmac,
> +   MAX_HMAC_KEY_LENGTH);
> +key_ctx_update_implicit_iv(>decrypt, 
> (*key2).keys[1-(int)server].hmac,
> +   MAX_HMAC_KEY_LENGTH);
> +
> +}
> +
> +
> +static struct key2
> +generate_key_expansion_oepnvpn_prf(const struct tls_session *session)

What is this oepnvpn you're talking about?

>  {
> +

Unneeded newline.

>  uint8_t master[48] = { 0 };
> -struct key2 key2 = { 0 };
> -bool ret = false;
>  
> -if (key->initialized)
> -{
> -msg(D_TLS_ERRORS, "TLS Error: key already initialized");
> -goto exit;
> -}
> +const struct key_state *ks = >key[KS_PRIMARY];
> +const struct key_source2 *key_src = ks->key_src;
> +
> +const struct session_id *client_sid = session->opt->server ?
> +  >session_id_remote : 
> >session_id;
> +const struct session_id *server_sid = !session->opt->server ?
> +  >session_id_remote : 
> >session_id;
>  
>  /* debugging print of source key material */
>  key_source2_print(key_src);
> @@ -1803,6 +1814,7 @@ generate_key_expansion(struct key_ctx_bi *key,
>  master,
>  sizeof(master));
>  
> +struct key2 key2;
>  /* compute key expansion */
>  openvpn_PRF(master,
>  sizeof(master),
> @@ -1815,41 +1827,62 @@ generate_key_expansion(struct key_ctx_bi *key,
>  server_sid,
>  (uint8_t *)key2.keys,
>  sizeof(key2.keys));
> +secure_memzero(, sizeof(master));
>  
> +/* We use the DES fixup here so we can drop it once we
> + * drop DES support and non RFC5705 key derivation */
> +for (int i = 0; i < 2; ++i)
> +{
> +fixup_key([i], >opt->key_type);
> +}

Very nice that we can finally get rid of this. But I'm wondering now:
should we forbid DES (or maybe even any small block cipher) when using EKM?

Even if we remove small block cipher support completely from 2.6, I'd
still really like to backport EKM to 2.5 ("long-term compat"). At that
will still allow persistent users to force it to use DES.

>  key2.n = 2;
>  
> -key2_print(, key_type, "Master Encrypt", "Master Decrypt");
> +return key2;
> +}
> +
> +/*
> + * Using source entropy from local and remote hosts, mix into
> + * master key.
> + */
> +static bool
> +generate_key_expansion(struct key_ctx_bi *key,
> +   const struct tls_session *session)
> +{
> +bool ret = false;
> +
> +if (key->initialized)
> +{
> +msg(D_TLS_ERRORS, "TLS Error: key already initialized");
> +goto exit;
> +}
> +
> +
> +bool server = session->opt->server;
> +
> +struct key2 key2 = generate_key_expansion_oepnvpn_prf(session);

Possible use-before-initialization/declaration here (undefined behavior).

key2 is used in the exit: label, so it should not be declared after the
"goto exit" above. This is type of mistake is the reason I don't like
late-declaration of any variable in functions that use a goto-error
flow. Next to not-too-smart static analyzers complaining about this
construct even if not used behind the label.

> +
> +

Re: [Openvpn-devel] [PATCH v3 1/3] Refactor key_state_export_keying_material functions

2020-08-21 Thread Steffan Karger
uct to cache TLS secrets for keying material exporter (RFC 5705).
> + * The constants (64 and 48) are inherent to TLS version and
> + * the whole keying material export will likely change when they change */
> +struct tls_key_cache {
> +unsigned char client_server_random[64];
> +mbedtls_tls_prf_types tls_prf_type;
> +unsigned char master_secret[48];
> +};
> +
>  /**
>   * Structure that wraps the TLS context. Contents differ depending on the
>   * SSL library used.
> @@ -114,8 +123,7 @@ struct key_state_ssl {
>  mbedtls_ssl_context *ctx;   /**< mbedTLS connection context */
>  bio_ctx *bio_ctx;
>  
> -/** Keying material exporter cache (RFC 5705). */
> -uint8_t *exported_key_material;
> +struct tls_key_cache tls_key_cache;
>  
>  };
>  
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 5ba74402..f52c7c39 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -158,35 +158,26 @@ tls_ctx_initialised(struct tls_root_ctx *ctx)
>  return NULL != ctx->ctx;
>  }
>  
> -void
> -key_state_export_keying_material(struct key_state_ssl *ssl,
> - struct tls_session *session)
> -{
> -if (session->opt->ekm_size > 0)
> -{
> -unsigned int size = session->opt->ekm_size;
> -struct gc_arena gc = gc_new();
> -unsigned char *ekm = (unsigned char *) gc_malloc(size, true, );
> +unsigned char*
> +key_state_export_keying_material(struct tls_session *session,
> + const char* label, size_t label_size,
> + size_t ekm_size,
> + struct gc_arena *gc)
>  
> -if (SSL_export_keying_material(ssl->ssl, ekm, size,
> -   session->opt->ekm_label,
> -   session->opt->ekm_label_size,
> -   NULL, 0, 0))
> -{
> -unsigned int len = (size * 2) + 2;
> +{
> +unsigned char *ekm = (unsigned char *) gc_malloc(ekm_size, true, gc);
>  
> -const char *key = format_hex_ex(ekm, size, len, 0, NULL, );
> -setenv_str(session->opt->es, "exported_keying_material", key);
> +SSL* ssl = session->key[KS_PRIMARY].ks_ssl.ssl;
>  
> -dmsg(D_TLS_DEBUG_MED, "%s: exported keying material: %s",
> - __func__, key);
> -}
> -else
> -{
> -msg(M_WARN, "WARNING: Export keying material failed!");
> -setenv_del(session->opt->es, "exported_keying_material");
> -}
> -gc_free();
> +if (SSL_export_keying_material(ssl, ekm, ekm_size, label,
> +   label_size, NULL, 0, 0) == 1)
> +{
> +return ekm;
> +}
> +else
> +{
> +secure_memzero(ekm, ekm_size);
> +return NULL;
>  }
>  }
>  
> 

Thanks, looks good to me now. Changes wrt v2 in comments and whitespace
only, so didn't re-test.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 1/3] Refactor key_state_export_keying_material functions

2020-08-12 Thread Steffan Karger
Hi,

On 12-08-2020 16:01, Arne Schwabe wrote:
> This refactors the common code between mbed SSL and OpenSSL into
> export_user_keying_material and also prepares the backend functions
> to export more than one key.
> 
> Also fix checking the return value of SSL_export_keying_material
> only 1 is a sucess, -1 is also an error.
> 
> Signed-off-by: Arne Schwabe 
> 
> Patch V2: Cache secrets for mbed TLS instead generating all ekms
>   in the call back function
> 
> Signed-off-by: Arne Schwabe 
> ---
>
>  [...]
> 
> --- a/src/openvpn/ssl_backend.h
> +++ b/src/openvpn/ssl_backend.h
> @@ -394,13 +394,23 @@ void backend_tls_ctx_reload_crl(struct tls_root_ctx 
> *ssl_ctx,
>   * derived from existing TLS channel. This exported keying material can then 
> be
>   * used for a variety of purposes.
>   *
> + *

This extra newline seems unneeded.

>   * @param ks_ssl   The SSL channel's state info
>   * @param session  The session associated with the given key_state
> + * @param labelThe label to use when exporting the key
> + * @param label_size   The size of the label to use when exporting the key
> + *
> + * @param gc   gc_arena that might be used to allocate the string
> + * returned
> + * @returnsThe exported key material, the caller may zero the
> + * string but should not free it
>   */
>  
> -void
> -key_state_export_keying_material(struct key_state_ssl *ks_ssl,
> - struct tls_session *session) 
> __attribute__((nonnull));
> +unsigned char*
> +key_state_export_keying_material(struct tls_session *session,
> + const char* label, size_t label_size,
> + size_t ekm_size,
> + struct gc_arena *gc) 
> __attribute__((nonnull));

(Quoting a former colleague:) comment is a lie! It does not match the
actual function prototype.

All the code itself looks good to me. I *think* it could be made
slightly better even, but these changes make sense for the intended
goal, and look correct.

Tested both openssl and mbedtls builds (with -fsanitize=address), and
verified that this indeed produces the same exported values for both
builds and a build without this patch.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/3] Refactor key_state_export_keying_material functions

2020-08-12 Thread Steffan Karger
Hi,

Couldn't resist giving this a quick look.

Feature-ACK on the patch set, but some comments on the approach:

On 12-08-2020 10:55, Arne Schwabe wrote:
> This refactors the common code between mbed SSL and OpenSSL into
> export_user_keying_material and also prepares the backend functions
> to export more than one key.
> 
> Also fix checking the return value of SSL_export_keying_material
> only 1 is a sucess, -1 is also an error.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/ssl.c | 33 -
>  src/openvpn/ssl_backend.h | 18 --
>  src/openvpn/ssl_mbedtls.c | 22 ++---
>  src/openvpn/ssl_openssl.c | 51 +--
>  4 files changed, 83 insertions(+), 41 deletions(-)
> 
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index f16114c2..390114e1 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2412,6 +2412,37 @@ error:
>  return false;
>  }
>  
> +static void
> +export_user_keying_material(struct key_state_ssl *ssl,
> +struct tls_session *session)
> +{
> +if (session->opt->ekm_size > 0)
> +{
> +unsigned int size = session->opt->ekm_size;
> +struct gc_arena gc = gc_new();
> +
> +unsigned char *ekm;
> +if ((ekm = key_state_export_keying_material(ssl, session,
> +EXPORT_KEY_USER, )))
> +{

Hmm, I don't think these abstractions are right. I would argue that the
crypto backends should know as few about OpenVPN specifics as possible.
So things like "EXPORT_KEY_USER" should probably not be passed to the
backend, and instead be handled in ssl.c.

Why not give the backend a prototype like

  key_state_export_keying_material(label, label_len, ekm, ekm_len)

I understand that this would mean an extra memcpy() for the mbedtls
code, but this is not performance-critical at all, right?

(In the follow-up patch, just cache the master secret and client/server
random, instead of the derived key material in the mbedtls backend, so
you can generate the export at will. For OpenSSL, this API should be
trivial.)

> +unsigned int len = (size * 2) + 2;
> +
> +const char *key = format_hex_ex(ekm, size, len, 0, NULL, );
> +setenv_str(session->opt->es, "exported_keying_material", key);
> +
> +dmsg(D_TLS_DEBUG_MED, "%s: exported keying material: %s",
> + __func__, key);
> +secure_memzero(ekm, size);
> +}
> +else
> +{
> +msg(M_WARN, "WARNING: Export keying material failed!");
> +setenv_del(session->opt->es, "exported_keying_material");
> +}
> +gc_free();
> +}
> +}
> +
>  /**
>   * Handle reading key data, peer-info, username/password, OCC
>   * from the TLS control channel (cleartext).
> @@ -2541,7 +2572,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
> *multi, struct tls_sessio
>  if ((ks->authenticated > KS_AUTH_FALSE)
>  && plugin_defined(session->opt->plugins, OPENVPN_PLUGIN_TLS_FINAL))
>  {
> -key_state_export_keying_material(>ks_ssl, session);
> +export_user_keying_material(>ks_ssl, session);
>  
>  if (plugin_call(session->opt->plugins, OPENVPN_PLUGIN_TLS_FINAL, 
> NULL, NULL, session->opt->es) != OPENVPN_PLUGIN_FUNC_SUCCESS)
>  {
> diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
> index 7f52ab1e..8faaefd5 100644
> --- a/src/openvpn/ssl_backend.h
> +++ b/src/openvpn/ssl_backend.h
> @@ -389,18 +389,32 @@ void key_state_ssl_free(struct key_state_ssl *ks_ssl);
>  void backend_tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx,
>  const char *crl_file, bool crl_inline);
>  
> +
> +/* defines the different RFC5705 that are used in OpenVPN */

Make this /** to have it turn up nicely in the doxygen.

> +enum export_key_identifier {
> +EXPORT_KEY_USER
> +};
> +
>  /**
>   * Keying Material Exporters [RFC 5705] allows additional keying material to 
> be
>   * derived from existing TLS channel. This exported keying material can then 
> be
>   * used for a variety of purposes.
>   *
> + * Note
> + *

Note ... what?

>   * @param ks_ssl   The SSL channel's state info
>   * @param session  The session associated with the given key_state
> + * @param key  The key to export.
> + * @param gc   gc_arena that might be used to allocate a string

Where "a string" is "the keying material", right? Maybe just say that :)

> + * @returnsThe exported key material, the caller may zero the
> + * string but should not free it
>   */
>  
> -void
> +unsigned char*
>  key_state_export_keying_material(struct key_state_ssl *ks_ssl,
> - struct tls_session *session) 
> __attribute__((nonnull));
> + struct tls_session *session,
> +

Re: [Openvpn-devel] [PATCH applied] Re: Remove S_OP_NORMAL key state.

2020-08-11 Thread Steffan Karger
On 11-08-2020 10:45, Gert Doering wrote:
> Acked-by: Gert Doering 
> 
> Server-side and client-side tested.
> 
> Not sure if I understand all possible implications of S_NORMAL_OP,
> but indeed it is not *used* anywere, except in ">= S_ACTIVE".
> 
> The flow of "at which point in time we set must_negotiate = 0"
> changes a bit - the old code would do it "when it expired AND
> we're in >= S_ACTIVE", while the new code would do it "right
> when setting S_ACTIVE" - which is the only place where S_ACTIVE
> is set, so it would always catch said condition.  This should be 
> totally fine.
> 
> Your patch has been applied to the master branch.

FWIW: I agree, I don't think we need S_NORMAL_OP.

Less code, more better.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Rework NCP compability logic and drop BF-CBC support by default

2020-08-05 Thread Steffan Karger
Hi,

No full review yet, but this version does seem to address my previous
comments. Some minor nits I noticed on my first run through v2:

On 29-07-2020 13:38, Arne Schwabe wrote:
> This reworks the NCP logic to be more strict about what is
> considered an acceptable result of an NCP negotiation. It also
> us to finally drop BF-CBC support by default.
> 
> All new behaviour is currently limited to server/client
> mode with pull enabled. P2p mode without pull does not change.
> 
> New Server behaviour:
> - when a client announces its supported ciphers through either
>   OCC or IV_CIPHER/IV_NCP we reject the client with a
>   AUTH_FAILED message if we have no common cipher.
> 
> - When a client does not announce any cipher in either
>   OCC or NCP we by reject it unless fallback-cipher is
>   specified in either ccd or config.
> 
> New client behaviour:
> - When no cipher is pushed (or a cipher we refused to support)
>   and we also cannot support the server's server announced in
>   OCC we fail the connection and log why
> 
> - If fallback-cipher is specified we will in the case that
>   cipher is missing from occ use the fallback cipher instead
>   of failing the connection
> 
> Both client and server behaviour:
> - We only announce --cipher xyz in occ if we are willing
>   to support that cipher.
> 
>   It means that we only announce the fallback-cipher if
>   it is also contained in --data-ciphers
> 
> Compatiblity behaviour:
> 
> In 2.5 both client and server will automatically set
> fallback-cipher xyz if --cipher xyz is in the config and
> also add append the cipher to the end of data-ciphers.
> 
> We log a warn user about this and point to --data-ciphers and
> --fallback-cipher. This also happens if the configuration
> contains an explicit --cipher BF-CBC.
> 
> If --cipher is not set, we only warn that previous versions
> allowed BF-CBC and point how to reenable BF-CBC. This might
> break very few config where someone connects a very old
> client to a 2.5 server but at some point we need to drop
> the BF-CBC and those affected use will already have a the
> scary SWEET32 warning in their logs.
> 
> In short: If --cipher is explicitly set 2.6 will work the same as
> 2.4 did. When --cipher is not set, BF-CBC support is dropped and
> we warn about it.
> 
> Examples how breaking the default BF-CBC will be logged:
> 
> Client side:
>  - Client connecting to server that does not push cipher but
>has --cipher in OCC
> 
> OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's 
> cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if 
> you want to connect to this server.
> 
>  - Client connecting to a server that does not support OCC:
> 
>OPTIONS ERROR: failed to negotioate cipher with server. Configure 
> --fallback-cipher if you want connect to this server.
> 
> Server Side:
> 
> - Server has a client only supporting BF-CBC connecting:
> 
>   styx/IP PUSH: No common cipher between server and client. Server 
> data-ciphers: 
> 'CHACHA20-POLY1305:AES-128-GCM:AES-256-GCM:AES-256-CBC:AES-128-CBC', client 
> supports cipher 'BF-CBC'.
> 
>  - Client without OCC:
> 
>styx/IP PUSH:No NCP or OCC cipher data received from peer.
>styx/IP Use --fallback-cipher with the cipher the client is using if you 
> want to allow the client to connect
> 
> In all reject cases on the client:
> 
>AUTH: Received control message: AUTH_FAILED,Data channel cipher 
> negotiation failed (no shared cipher)
> 
> Signed-off-by: Arne Schwabe 
> 
> Patch V2: rename fallback-cipher to data-ciphers-fallback
>   add all corrections from Steffan
>   Ignore occ cipher for clients sending IV_CIPHERS
>   move client side ncp in its own function
>   do not print INSECURE cipher warning if BF-CBC is not allowed
> 
> Signed-off-by: Arne Schwabe 
> ---
>  doc/man-sections/protocol-options.rst |  22 -
>  src/openvpn/crypto.c  |   4 +-
>  src/openvpn/init.c|  18 ++--
>  src/openvpn/multi.c   | 135 --
>  src/openvpn/options.c | 117 +-
>  src/openvpn/options.h |   2 +
>  src/openvpn/ssl.c |  17 ++--
>  src/openvpn/ssl_ncp.c |  82 +---
>  src/openvpn/ssl_ncp.h |  18 ++--
>  tests/unit_tests/openvpn/test_ncp.c   |  26 +++--
>  10 files changed, 311 insertions(+), 130 deletions(-)
> 
> diff --git a/doc/man-sections/protocol-options.rst 
> b/doc/man-sections/protocol-options.rst
> index 051f1d32..69d3bc67 100644
> --- a/doc/man-sections/protocol-options.rst
> +++ b/doc/man-sections/protocol-options.rst
> @@ -57,6 +57,9 @@ configured in a compatible way between both the local and 
> remote side.
>http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
>  
>  --cipher alg
> +  This option is deprecated for server-client mode and ``--data-ciphers``
> +  or rarely 

Re: [Openvpn-devel] [PATCH 9/9] Rework NCP compability logic and drop BF-CBC support by default

2020-07-28 Thread Steffan Karger
Hi,

This is awesome in many ways. Better behaviour, better code and a nice
way forward to really get rid of the BF-CBC default cipher.

It's also somewhat tricky, so here goes for a review purely based on
stare-at-code:

On 17-07-2020 15:47, Arne Schwabe wrote:
> This reworks the NCP logic to be more strict about what is
> considered an acceptable result of an NCP negotiation. It also
> us to finally drop BF-CBC support by default.
> 
> All new behaviour is currently limited to server/client
> mode with pull enabled. P2p mode without pull does not change.
> 
> New Server behaviour:
> - when a client announces its supported ciphers through either
>   OCC or IV_CIPHER/IV_NCP we reject the client with a
>   AUTH_FAILED message if we have no common cipher.
> 
> - When a client does not announce any cipher in either
>   OCC or NCP we by reject it unless fallback-cipher is
>   specified in either ccd or config.
> 
> New client behaviour:
> - When no cipher is pushed (or a cipher we refused to support)
>   and we also cannot support the server's server announced in
>   OCC we fail the connection and log why
> 
> - If fallback-cipher is specified we will in the case that
>   cipher is missing from occ use the fallback cipher instead
>   of failing the connection
> 
> Both client and server behaviour:
> - We only announce --cipher xyz in occ if we are willing
>   to support that cipher.
> 
>   It means that we only announce the fallback-cipher if
>   it is also contained in --data-ciphers
> 
> Compatiblity behaviour:
> 
> In 2.5 both client and server will automatically set
> fallback-cipher xyz if --cipher xyz is in the config and
> also add append the cipher to the end of data-ciphers.
> 
> We log a warn user about this and point to --data-ciphers and
> --fallback-cipher. This also happens if the configuration
> contains an explicit --cipher BF-CBC.
> 
> If --cipher is not set, we only warn that previous versions
> allowed BF-CBC and point how to reenable BF-CBC. This might
> break very few config where someone connects a very old
> client to a 2.5 server but at some point we need to drop
> the BF-CBC and those affected use will already have a the
> scary SWEET32 warning in their logs.
> 
> In short: If --cipher is explicitly set 2.6 will work the same as
> 2.4 did. When --cipher is not set, BF-CBC support is dropped and
> we warn about it.
> 
> Examples how breaking the default BF-CBC will be logged:
> 
> Client side:
>  - Client connecting to server that does not push cipher but
>has --cipher in OCC
> 
> OPTIONS ERROR: failed to negotiate cipher with server.  Add the server's 
> cipher ('BF-CBC') to --data-ciphers (currently 'AES-256-GCM:AES-128-CBC') if 
> you want to connect to this server.
> 
>  - Client connecting to a server that does not support OCC:
> 
>OPTIONS ERROR: failed to negotioate cipher with server. Configure 
> --fallback-cipher if you want connect to this server.
> 
> Server Side:
> 
> - Server has a client only supporting BF-CBC connecting:> diff --git 
> a/doc/man-sections/protocol-options.rst
b/doc/man-sections/protocol-options.rst

[ Used the output of "git diff -w" to review, so pasting that here is
"original" too. ]

> diff --git a/doc/man-sections/protocol-options.rst 
> b/doc/man-sections/protocol-options.rst
> index 051f1d32..ab22b415 100644
> --- a/doc/man-sections/protocol-options.rst
> +++ b/doc/man-sections/protocol-options.rst
> @@ -57,6 +57,9 @@ configured in a compatible way between both the local and 
> remote side.
>http://www.cs.ucsd.edu/users/mihir/papers/hmac.html
>  
>  --cipher alg
> +  This option is deprecated for server-client mode and ``--data-ciphers``
> +  or rarely `--data-ciphers-fallback`` should be used instead.
> +
>Encrypt data channel packets with cipher algorithm ``alg``.
>  
>The default is :code:`BF-CBC`, an abbreviation for Blowfish in Cipher
> @@ -183,8 +186,9 @@ configured in a compatible way between both the local and 
> remote side.
>``--server`` ), or if ``--pull`` is specified (client-side, implied by
>setting --client).
>  
> -  If both peers support and do not disable NCP, the negotiated cipher will
> -  override the cipher specified by ``--cipher``.
> +  If no common cipher is found is found during cipher negotiation, the

Duplicate "is found".

> +  connection is terminated. To support old clients/server that do not
> +  provide any cipher support see ``data-ciphers-fallback``.
>  
>Additionally, to allow for more smooth transition, if NCP is enabled,
>OpenVPN will inherit the cipher of the peer if that cipher is different
> @@ -201,8 +205,18 @@ configured in a compatible way between both the local 
> and remote side.
>This list is restricted to be 127 chars long after conversion to OpenVPN
>ciphers.
>  
> -  This option was called ``ncp-ciphers`` in OpenVPN 2.4 but has been renamed
> -  to ``data-ciphers`` in OpenVPN 2.5 to more accurately reflect its meaning.
> +  This option was called 

[Openvpn-devel] [PATCH] Gently push users towards --data-ciphers in --show-ciphers output

2020-07-27 Thread Steffan Karger
Also:
 * fix a typo in the openssl output ("may be use*d*")
 * mention GCM before CBC (we prefer AEAD modes)

Signed-off-by: Steffan Karger 
---
 src/openvpn/crypto_mbedtls.c |  5 +++--
 src/openvpn/crypto_openssl.c | 10 +-
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/src/openvpn/crypto_mbedtls.c b/src/openvpn/crypto_mbedtls.c
index 19a87eb4..fbb1f120 100644
--- a/src/openvpn/crypto_mbedtls.c
+++ b/src/openvpn/crypto_mbedtls.c
@@ -149,8 +149,9 @@ show_available_ciphers(void)
 #ifndef ENABLE_SMALL
 printf("The following ciphers and cipher modes are available for use\n"
"with " PACKAGE_NAME ".  Each cipher shown below may be used as a\n"
-   "parameter to the --cipher option.  Using a CBC or GCM mode is\n"
-   "recommended.  In static key mode only CBC mode is allowed.\n\n");
+   "parameter to the --data-ciphers (or --cipher) option.  Using a\n"
+   "GCM or CBC mode is recommended.  In static key mode only CBC\n"
+   "mode is allowed.\n\n");
 #endif
 
 while (*ciphers != 0)
diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index c47c2f3c..c60d4a54 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -287,11 +287,11 @@ show_available_ciphers(void)
 size_t num_ciphers = 0;
 #ifndef ENABLE_SMALL
 printf("The following ciphers and cipher modes are available for use\n"
-   "with " PACKAGE_NAME ".  Each cipher shown below may be use as a\n"
-   "parameter to the --cipher option.  The default key size is\n"
-   "shown as well as whether or not it can be changed with the\n"
-   "--keysize directive.  Using a CBC or GCM mode is recommended.\n"
-   "In static key mode only CBC mode is allowed.\n\n");
+   "with " PACKAGE_NAME ".  Each cipher shown below may be used as a\n"
+   "parameter to the --data-ciphers (or --cipher) option.  The\n"
+   "default key size is shown as well as whether or not it can be\n"
+   "changed with the --keysize directive.  Using a GCM or CBC mode\n"
+   "is recommended.  In static key mode only CBC mode is 
allowed.\n\n");
 #endif
 
 for (nid = 0; nid < 1; ++nid)
-- 
2.25.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-24 Thread Steffan Karger
tion.
> diff --git a/doc/man-sections/server-options.rst 
> b/doc/man-sections/server-options.rst
> index c24aec0b..74ad5e18 100644
> --- a/doc/man-sections/server-options.rst
> +++ b/doc/man-sections/server-options.rst
> @@ -473,8 +473,8 @@ fast hardware. SSL/TLS authentication must be used in 
> this mode.
>  *AES-GCM-128* and *AES-GCM-256*.
>  
>:code:`IV_CIPHERS=`
> -The client pushes the list of configured ciphers with the
> -``--ciphers`` option to the server.
> +The client announces the list of supported ciphers configured with 
> the
> +``--data-ciphers`` option to the server.
>  
>:code:`IV_GUI_VER= `
>  The UI version of a UI if one is running, for example
> diff --git a/sample/sample-config-files/client.conf 
> b/sample/sample-config-files/client.conf
> index 7f2f30a3..47ca4099 100644
> --- a/sample/sample-config-files/client.conf
> +++ b/sample/sample-config-files/client.conf
> @@ -112,7 +112,7 @@ tls-auth ta.key 1
>  # then you must also specify it here.
>  # Note that v2.4 client/server will automatically
>  # negotiate AES-256-GCM in TLS mode.
> -# See also the ncp-cipher option in the manpage
> +# See also the data-ciphers option in the manpage
>  cipher AES-256-CBC
>  
>  # Enable compression on the VPN link.
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 88ba9db2..d2549bca 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -1827,7 +1827,7 @@ multi_client_set_protocol_options(struct context *c)
>  else
>  {
>  /*
> - * Push the first cipher from --ncp-ciphers to the client that
> + * Push the first cipher from --data-ciphers to the client that
>   * the client announces to be supporting.
>   */
>  char *push_cipher = ncp_get_best_cipher(o->ncp_ciphers, 
> o->ciphername,
> @@ -1847,7 +1847,7 @@ multi_client_set_protocol_options(struct context *c)
>  {
>  msg(M_INFO, "PUSH: No common cipher between server and "
>  "client. Expect this connection not to work. Server "
> -"ncp-ciphers: '%s', client supported ciphers '%s'",
> +"data-ciphers: '%s', client supported ciphers '%s'",
>  o->ncp_ciphers, peer_ciphers);
>  }
>  else
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 31e33ae3..896abcde 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -536,7 +536,7 @@ static const char usage_message[] =
>  "--cipher alg: Encrypt packets with cipher algorithm alg\n"
>  "  (default=%s).\n"
>  "  Set alg=none to disable encryption.\n"
> -"--ncp-ciphers list : List of ciphers that are allowed to be 
> negotiated.\n"
> +"--data-ciphers list : List of ciphers that are allowed to be 
> negotiated.\n"
>  "--ncp-disable   : (DEPRECATED) Disable cipher negotiation.\n"
>  "--prng alg [nsl] : For PRNG, use digest algorithm alg, and\n"
>  "   nonce_secret_len=nsl.  Set alg=none to disable 
> PRNG.\n"
> @@ -7866,7 +7866,8 @@ add_option(struct options *options,
>  VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
>  options->ciphername = p[1];
>  }
> -else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
> +else if ((streq(p[0], "data-ciphers") || streq(p[0], "ncp-ciphers"))
> +&& p[1] && !p[2])
>  {
>  VERIFY_PERMISSION(OPT_P_GENERAL|OPT_P_INSTANCE);
>  options->ncp_ciphers = p[1];
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index e057a40b..6760884e 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -111,7 +111,7 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena 
> *gc)
>  const cipher_kt_t *ktc = cipher_kt_get(token);
>  if (!ktc)
>  {
> -msg(M_WARN, "Unsupported cipher in --ncp-ciphers: %s", token);
> +msg(M_WARN, "Unsupported cipher in --data-ciphers: %s", token);
>  error_found = true;
>  }
>  else
> @@ -130,7 +130,7 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena 
> *gc)
>  if (!(buf_forward_capacity(_list) >
>strlen(ovpn_cipher_name) + 2))
>  {
> -msg(M_WARN, "Length of --ncp-ciphers is over the "
> +msg(M_WARN, "Length of --data-ciphers is over the "
>  "limit of 127 chars");
>  error_found = true;
>  }
> 

Thanks. Patch looks good, and passes manual tests.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 8/9] Rename ncp-ciphers to data-ciphers

2020-07-24 Thread Steffan Karger
Hi,

On 23-07-2020 18:09, David Sommerseth wrote:
>> This was a deliberate decision. We really want to people to move towards
>> ncp and putting another hurdle with having an option that works better
>> on but gives a warning and a option that does not work on 2.4 does not
>> help here. If we decide that really aliases are a no-go in OpenVPN then
>> I would rather drop data-ciphers and stay with ncp-ciphers forever for
>> this reason.
> 
> Lets take a few steps back try to see a broader picture.
> 
> [..snip..]
> 
> We really need a proper and sane processes to allow the development of OpenVPN
> to have a chance to move on and leave things behind when appropriate, to be
> able to evolve and grow with the future - without being strangled by what
> existed in the far past (meaning: no longer community supported releases).
> Otherwise I do fear for the future of OpenVPN 2.x.
> 
> By having a clear strategy and adhering to a process of feature/option
> management in OpenVPN, we give clearly defined time-window for stability and
> functionality for our users.  This predictability is, in my experience, much
> more important to users than if a specifically named option is supported or 
> not.

Yes, you've made these points clear earlier on IRC. I (and with me Arne
and Gert) just don't agree with you on some of the details, resulting in
a different verdict on this patch.

None of us has trouble with deprecating options. We appreciate the work
you've put into the DeprecatedOptions page, and all of us have sent
and/or acked patched to remove dangerous or obsolete options.

This difference is in how we weigh the pros and cons per option. So I'll
leave the broader picture for now, and summarize why I'm going to ACK
Arne's patch exactly because is *doesn't* print a warning when the old
name is used.

Option name aliases add negligible code complexity and are trivial to
maintain. (Just look at --udp-mtu.) Keeping them in allows users to
write configs that work well and do not produce any warnings on both
older and newer versions. (Printing warnings for harmless things reduces
the value of the other warnings we print.)

Let's focus our time and effort on reducing actual complexity.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] Require AEAD support in the crypto library

2020-07-20 Thread Steffan Karger
x, uint8_t *tag_buf, int tag_size)
>  {
> -#ifdef HAVE_AEAD_CIPHER_MODES
>  return EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, tag_size, tag_buf);
> -#else
> -ASSERT(0);
> -#endif
>  }
>  
>  int
> @@ -841,16 +827,12 @@ cipher_ctx_reset(EVP_CIPHER_CTX *ctx, const uint8_t 
> *iv_buf)
>  int
>  cipher_ctx_update_ad(EVP_CIPHER_CTX *ctx, const uint8_t *src, int src_len)
>  {
> -#ifdef HAVE_AEAD_CIPHER_MODES
>  int len;
>  if (!EVP_CipherUpdate(ctx, NULL, , src, src_len))
>  {
>  crypto_msg(M_FATAL, "%s: EVP_CipherUpdate() failed", __func__);
>  }
>  return 1;
> -#else  /* ifdef HAVE_AEAD_CIPHER_MODES */
> -ASSERT(0);
> -#endif
>  }
>  
>  int
> @@ -874,7 +856,6 @@ int
>  cipher_ctx_final_check_tag(EVP_CIPHER_CTX *ctx, uint8_t *dst, int *dst_len,
> uint8_t *tag, size_t tag_len)
>  {
> -#ifdef HAVE_AEAD_CIPHER_MODES
>  ASSERT(tag_len < SIZE_MAX);
>  if (!EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, tag_len, tag))
>  {
> @@ -882,9 +863,6 @@ cipher_ctx_final_check_tag(EVP_CIPHER_CTX *ctx, uint8_t 
> *dst, int *dst_len,
>  }
>  
>  return cipher_ctx_final(ctx, dst, dst_len);
> -#else  /* ifdef HAVE_AEAD_CIPHER_MODES */
> -ASSERT(0);
> -#endif
>  }
>  
>  void
> diff --git a/src/openvpn/crypto_openssl.h b/src/openvpn/crypto_openssl.h
> index 4694ee08..e6f8f537 100644
> --- a/src/openvpn/crypto_openssl.h
> +++ b/src/openvpn/crypto_openssl.h
> @@ -61,13 +61,9 @@ typedef HMAC_CTX hmac_ctx_t;
>  /** Cipher is in CFB mode */
>  #define OPENVPN_MODE_CFBEVP_CIPH_CFB_MODE
>  
> -#ifdef HAVE_AEAD_CIPHER_MODES
> -
>  /** Cipher is in GCM mode */
>  #define OPENVPN_MODE_GCMEVP_CIPH_GCM_MODE
>  
> -#endif /* HAVE_AEAD_CIPHER_MODES */
> -
>  /** Cipher should encrypt */
>  #define OPENVPN_OP_ENCRYPT  1
>  
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 04518bf5..94308a8e 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -104,9 +104,7 @@ const char title_string[] =
>  " [MH/RECVDA]"
>  #endif
>  #endif
> -#ifdef HAVE_AEAD_CIPHER_MODES
>  " [AEAD]"
> -#endif
>  " built on " __DATE__
>  ;
>  
> @@ -871,11 +869,7 @@ init_options(struct options *o, const bool init_gc)
>  o->scheduled_exit_interval = 5;
>  #endif
>  o->ciphername = "BF-CBC";
> -#ifdef HAVE_AEAD_CIPHER_MODES /* IV_NCP=2 requires GCM support */
>  o->ncp_enabled = true;
> -#else
> -o->ncp_enabled = false;
> -#endif
>  o->ncp_ciphers = "AES-256-GCM:AES-128-GCM";
>  o->authname = "SHA1";
>  o->prng_hash = "SHA1";
> 

Thanks. This looks good to me now, and passes travis and basic local tests.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 3/9] Require AEAD support in the crypto library

2020-07-20 Thread Steffan Karger
Hi,

On 17-07-2020 15:47, Arne Schwabe wrote:
> All supported crypto libraries have AEAD support and with our
> ncp/de facto default cipher AES-256-GCM we do not want to support
> the obscure corner case of a library with disabled AEAD.

Again: feature-ACK, but some comments.

config-msvc.h still has a

  #define HAVE_AEAD_CIPHER_MODES 1

and ssl_openssl.c has two occurances of

  #ifdef EVP_CIPH_FLAG_AEAD_CIPHER

which I think can go too now.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 2/9] Drop support for OpenSSL 1.0.1

2020-07-20 Thread Steffan Karger
t;  struct gc_arena gc = gc_new();
>  unsigned char *ekm = (unsigned char *) gc_malloc(size, true, );
> @@ -188,7 +187,6 @@ key_state_export_keying_material(struct key_state_ssl 
> *ssl,
>  setenv_del(session->opt->es, "exported_keying_material");
>  }
>  gc_free();
> -#endif /* if (OPENSSL_VERSION_NUMBER >= 0x10001000) */
>  }
>  }
>  
> @@ -559,7 +557,7 @@ tls_ctx_set_cert_profile(struct tls_root_ctx *ctx, const 
> char *profile)
>  #else  /* ifdef HAVE_SSL_CTX_SET_SECURITY_LEVEL */
>  if (profile)
>  {
> -msg(M_WARN, "WARNING: OpenSSL 1.0.1 does not support 
> --tls-cert-profile"
> +msg(M_WARN, "WARNING: OpenSSL 1.0.2 does not support 
> --tls-cert-profile"
>  ", ignoring user-set profile: '%s'", profile);
>  }
>  #endif /* ifdef HAVE_SSL_CTX_SET_SECURITY_LEVEL */
> @@ -573,19 +571,11 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
>  
>  ASSERT(ctx);
>  
> -#if (OPENSSL_VERSION_NUMBER >= 0x10002000L && 
> !defined(LIBRESSL_VERSION_NUMBER)) \
> -|| LIBRESSL_VERSION_NUMBER >= 0x207fL
> -/* OpenSSL 1.0.2 and up */
>  cert = SSL_CTX_get0_certificate(ctx->ctx);
> -#else
> -/* OpenSSL 1.0.1 and earlier need an SSL object to get at the 
> certificate */
> -SSL *ssl = SSL_new(ctx->ctx);
> -cert = SSL_get_certificate(ssl);
> -#endif
>  
>  if (cert == NULL)
>  {
> -goto cleanup; /* Nothing to check if there is no certificate */
> +return; /* Nothing to check if there is no certificate */
>  }
>  
>  ret = X509_cmp_time(X509_get0_notBefore(cert), NULL);
> @@ -607,13 +597,6 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
>  {
>  msg(M_WARN, "WARNING: Your certificate has expired!");
>  }
> -
> -cleanup:
> -#if OPENSSL_VERSION_NUMBER < 0x10002000L \
> -|| (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x207fL)
> -SSL_free(ssl);
> -#endif
> -return;
>  }
>  
>  void
> @@ -680,7 +663,6 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const 
> char *curve_name
>  }
>  else
>  {
> -#if OPENSSL_VERSION_NUMBER >= 0x10002000L
>  #if (OPENSSL_VERSION_NUMBER < 0x1010L && 
> !defined(LIBRESSL_VERSION_NUMBER))
>  
>  /* OpenSSL 1.0.2 and newer can automatically handle ECDH parameter
> @@ -691,29 +673,6 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, const 
> char *curve_name
>   * so do nothing */
>  #endif
>  return;
> -#else  /* if OPENSSL_VERSION_NUMBER >= 0x10002000L */
> -/* For older OpenSSL we have to extract the curve from key on our 
> own */
> -EC_KEY *eckey = NULL;
> -const EC_GROUP *ecgrp = NULL;
> -EVP_PKEY *pkey = NULL;
> -
> -/* Little hack to get private key ref from SSL_CTX, yay OpenSSL... */
> -SSL *ssl = SSL_new(ctx->ctx);
> -if (!ssl)
> -{
> -crypto_msg(M_FATAL, "SSL_new failed");
> -}
> -pkey = SSL_get_privatekey(ssl);
> -SSL_free(ssl);
> -
> -msg(D_TLS_DEBUG, "Extracting ECDH curve from private key");
> -
> -if (pkey != NULL && (eckey = EVP_PKEY_get1_EC_KEY(pkey)) != NULL
> -&& (ecgrp = EC_KEY_get0_group(eckey)) != NULL)
> -{
> -nid = EC_GROUP_get_curve_name(ecgrp);
> -}
> -#endif /* if OPENSSL_VERSION_NUMBER >= 0x10002000L */
>  }
>  
>  /* Translate NID back to name , just for kicks */
> @@ -1462,15 +1421,7 @@ tls_ctx_use_management_external_key(struct 
> tls_root_ctx *ctx)
>  
>  ASSERT(NULL != ctx);
>  
> -#if (OPENSSL_VERSION_NUMBER >= 0x10002000L && 
> !defined(LIBRESSL_VERSION_NUMBER)) \
> -|| LIBRESSL_VERSION_NUMBER >= 0x207fL
> -/* OpenSSL 1.0.2 and up */
>  X509 *cert = SSL_CTX_get0_certificate(ctx->ctx);
> -#else
> -/* OpenSSL 1.0.1 and earlier need an SSL object to get at the 
> certificate */
> -SSL *ssl = SSL_new(ctx->ctx);
> -X509 *cert = SSL_get_certificate(ssl);
> -#endif
>  
>  ASSERT(NULL != cert);
>  
> @@ -1510,13 +1461,6 @@ tls_ctx_use_management_external_key(struct 
> tls_root_ctx *ctx)
>  
>  ret = 0;
>  cleanup:
> -#if OPENSSL_VERSION_NUMBER < 0x10002000L \
> -|| (defined(LIBRESSL_VERSION_NUMBER) && LIBRESSL_VERSION_NUMBER < 
> 0x207fL)
> -if (ssl)
> -{
> -SSL_free(ssl);
> -}
> -#endif
>  if (ret)
>  {
>  crypto_msg(M_FATAL, "Cannot enable SSL external private key 
> capability");
> 

Otherwise this now looks good to me. So if the whitespace can fixed when
committing:

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/9] Indicate that a client is in pull mode in IV_PROTO

2020-07-20 Thread Steffan Karger
Hi,

On 17-07-2020 15:47, Arne Schwabe wrote:
> This allows us to skip waiting for the first PUSH_REQUEST message from
> the client to send the response.

Feature-ACK, clever use of existing infra. Some comments though:

This commit message could use a bit more information. In particular, it
would be good to explain how the various OpenVPN versions currently
interpret IV_PROTO values, and why the change from a version-like
interpretation to a bitfield will not cause issues.

> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/multi.c | 12 ++--
>  src/openvpn/ssl.c   | 15 +--
>  src/openvpn/ssl.h   |  7 +++
>  3 files changed, 30 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 0095c871..88ba9db2 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -1795,10 +1795,18 @@ multi_client_set_protocol_options(struct context *c)
>  {
>  int proto = 0;
>  int r = sscanf(optstr, "IV_PROTO=%d", );
> -if ((r == 1) && (proto >= 2))
> +if (r == 1)
>  {
> -tls_multi->use_peer_id = true;
> +if (proto >= 2)
> +{
> +tls_multi->use_peer_id = true;
> +}

Wouldn't checking for proto & IV_PROTO_REQUEST_PUSH suffice? Any 2.3/2.4
client will only ever send "2", and newer clients will know this is a
bitfield now.

This works fine, but - in particular without an explaining comment -
first checking for a value, then continue as a bitfield is somewhat
surprising.

> +if (proto & IV_PROTO_REQUEST_PUSH)
> +{
> +c->c2.push_request_received = true;
> +}
>  }
> +
>  }
>  
>  /* Select cipher if client supports Negotiable Crypto Parameters */
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 54a23011..04d78a81 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2299,8 +2299,19 @@ push_peer_info(struct buffer *buf, struct tls_session 
> *session)
>  buf_printf(, "IV_PLAT=win\n");
>  #endif
>  
> -/* support for P_DATA_V2 */
> -buf_printf(, "IV_PROTO=2\n");
> +/* support for P_DATA_V2*/
> +int iv_proto = IV_PROTO_DATA_V2;
> +
> +/* support for receiving push_reply before sending
> + * push request, also signal that the client wants
> + * to get push-reply messages without without requiring a round
> + * trip for a push request message*/
> +if(session->opt->pull)

This needs a space behind the if.

> +{
> +iv_proto |= IV_PROTO_REQUEST_PUSH;
> +}
> +
> +buf_printf(, "IV_PROTO=%d\n", iv_proto);
>  
>  /* support for Negotiable Crypto Parameters */
>  if (session->opt->ncp_enabled
> diff --git a/src/openvpn/ssl.h b/src/openvpn/ssl.h
> index 58a9b0d4..86fb6853 100644
> --- a/src/openvpn/ssl.h
> +++ b/src/openvpn/ssl.h
> @@ -99,6 +99,13 @@
>  /* Maximum length of OCC options string passed as part of auth handshake */
>  #define TLS_OPTIONS_LEN 512
>  
> +/* Definitions of the bits in the IV_PROTO bitfield */
> +#define IV_PROTO_DATA_V2(1<<1)  /**< Support P_DATA_V2 */
> +#define IV_PROTO_REQUEST_PUSH   (1<<2)  /**< Assume client will send a push
> +  * request and server does not need
> +  * to wait for a push-request to 
> send
> +  * a push-reply */
> +

Style nit: would this not be more readable if you place the (rather
long) comment above the value, instead of behind?

Also: any particular reason to no use 1<<0 ? If we should not use that
for some reason, let's mark it as reserved. Otherwise: maybe just use it?

-Steffan



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 3/3] Remove key-method 1

2020-07-15 Thread Steffan Karger
Hi

On 13-07-2020 11:46, Arne Schwabe wrote:
> @@ -1100,7 +1100,7 @@ process_incoming_link_part1(struct context *c, struct 
> link_socket_info *lsi, boo
>  floated, _start))
>  {
>  /* Restore pre-NCP frame parameters */
> -if (is_hard_reset(opcode, c->options.key_method))
> +if (is_hard_reset(opcode, KEY_METHOD_2))
>  {

Can't we just remove the key_method parameter from is_hard_reset()?


> @@ -3817,10 +3803,9 @@ options_string(const struct options *o,
>   * tls-auth/tls-crypt does not match.  Removing tls-auth here 
> would
>   * break stuff, so leaving that in place. */
>  
> -if (o->key_method > 1)
> -{
> -buf_printf(, ",key-method %d", o->key_method);
> -}
> +
> +
> +buf_printf(, ",key-method %d", 2);

This could do with one less newline.

> @@ -2404,7 +2348,7 @@ key_method_2_write(struct buffer *buf, struct 
> tls_session *session)
>  }
>  
>  /* write key_method + flags */
> -if (!buf_write_u8(buf, (session->opt->key_method & KEY_METHOD_MASK)))
> +if (!buf_write_u8(buf, (KEY_METHOD_2 & KEY_METHOD_MASK)))
>  {
>  goto error;
>  }

The masking looks a bit silly now. Maybe replace with a static_assert()
if you want to be sure that no "wrong" bits are set?

>  static bool
>  key_method_2_read(struct buffer *buf, struct tls_multi *multi, struct 
> tls_session *session)
>  {
>  struct key_state *ks = >key[KS_PRIMARY];  /* primary key */
>  
> -int key_method_flags;
>  bool username_status, password_status;
>  
>  struct gc_arena gc = gc_new();
> @@ -2582,8 +2464,6 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
> *multi, struct tls_sessio
>  /* allocate temporary objects */
>  ALLOC_ARRAY_CLEAR_GC(options, char, TLS_OPTIONS_LEN, );
>  
> -ASSERT(session->opt->key_method == 2);
> -
>  /* discard leading uint32 */
>  if (!buf_advance(buf, 4))
>  {
> @@ -2593,7 +2473,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
> *multi, struct tls_sessio
>  }
>  
>  /* get key method */
> -key_method_flags = buf_read_u8(buf);
> +int key_method_flags = buf_read_u8(buf);

This variable declaration is now *after* a "goto error" jump. Currently
not harmful, because the variable isn't used after the error label, but
static analyzers might complain about "jump past initialization".

Otherwise this looks good based on stare-at-code. Didn't have time to
test yet.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/3] Drop support for OpenSSL 1.0.1

2020-07-14 Thread Steffan Karger
Hi,

Feature-ACK for sure. Some comments below.

On 13-07-2020 11:46, Arne Schwabe wrote:
> OpenSSL 1.0.1 was supported until 2016-12-31. Rhel6/Centos6 still
> use this version but considering that RHEL7 and RHEL8 are already
> out, these versions can also stay with OpenVPN 2.4.
> 
> All the supported Debian based distributions also come with at
> least 1.0.2
> 
> This also allows the tls groups commit to be applied without
> adding ifdefs to disable that functionality on OpenSSL 1.0.1
> 
> Signed-off-by: Arne Schwabe 
> ---
>  .travis.yml  |  8 
>  Changes.rst  |  5 -
>  configure.ac |  3 +--
>  src/openvpn/crypto.c |  7 ---
>  src/openvpn/openssl_compat.h | 14 --
>  src/openvpn/ssl_openssl.c| 32 +---
>  6 files changed, 6 insertions(+), 63 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 925d09ea..101ff096 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -35,10 +35,6 @@ jobs:
>env: SSLLIB="openssl" RUN_COVERITY="1"
>os: linux
>compiler: gcc
> -- name: gcc | openssl-1.0.1u
> -  env: SSLLIB="openssl" OPENSSL_VERSION="1.0.1u"
> -  os: linux
> -  compiler: gcc
>  - name: gcc | openssl-1.1.1d
>env: SSLLIB="openssl" OPENSSL_VERSION="1.1.1d"
>os: linux
> @@ -87,10 +83,6 @@ jobs:
>env: SSLLIB="mbedtls"
>os: osx
>compiler: clang
> -- name: mingw64 | openssl-1.0.1u
> -  env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32 OPENSSL_VERSION="1.0.1u"
> -  os: linux
> -  compiler: ": Win64 build only"
>  - name: mingw64 | openssl-1.1.1d
>env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32 OPENSSL_VERSION="1.1.1d"
>os: linux
> diff --git a/Changes.rst b/Changes.rst
> index 42f0d190..d45dc900 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -31,7 +31,10 @@ 
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions
>  With the improved and matured data channel cipher negotiation, the use
>  of ``ncp-disable`` should not be necessary anymore.
>  
> -
> +- Support for building with OpenSSL 1.0.1 has been removed. The minimum
> +  supported OpenSSL version is now 1.0.2.
> +  
> +

This adds some trailing whitespace.

>  Overview of changes in 2.4
>  ==
>  
> diff --git a/configure.ac b/configure.ac
> index 53b7a967..8194d8c2 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -839,7 +839,7 @@ if test "${with_crypto_library}" = "openssl"; then
>   # if the user did not explicitly specify flags, try to 
> autodetect
>   PKG_CHECK_MODULES(
>   [OPENSSL],
> - [openssl >= 1.0.1],
> + [openssl >= 1.0.2],
>   [have_openssl="yes"],
>   [] # If this fails, we will do another test next
>   )

There's a similar check for the no-pkgconfig fallback case. That should
be updated too:

# If pkgconfig check failed or OPENSSL_CFLAGS/OPENSSL_LIBS env vars
# are used, check the version directly in the OpenSSL include file
if test "${have_openssl}" != "yes"; then
AC_MSG_CHECKING([additionally if OpenSSL is available and
version >= 1.0.1])
AC_COMPILE_IFELSE(
[AC_LANG_PROGRAM(
[[
#include 
]],
[[
/*   Version encoding: MNNFFPPS - see opensslv.h for details */
#if OPENSSL_VERSION_NUMBER < 0x10001000L
#error OpenSSL too old
#endif
]]
)],
[AC_MSG_RESULT([ok])],
[AC_MSG_ERROR([OpenSSL version too old])]
)
fi

AC_CHECK_FUNCS([SSL_CTX_new EVP_CIPHER_CTX_set_key_length],
   ,
   [AC_MSG_ERROR([openssl check failed])]
)


> @@ -931,7 +931,6 @@ if test "${with_crypto_library}" = "openssl"; then
>   X509_STORE_get0_objects \
>   X509_OBJECT_free \
>   X509_OBJECT_get_type \
> - EVP_PKEY_id \
>   EVP_PKEY_get0_RSA \
>   EVP_PKEY_get0_DSA \
>   EVP_PKEY_get0_EC_KEY \
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 1ce98184..bbf47ef7 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -428,13 +428,6 @@ openvpn_decrypt_aead(struct buffer *buf, struct buffer 
> work,
>  tag_ptr = BPTR(buf);
>  ASSERT(buf_advance(buf, tag_size));
>  dmsg(D_PACKET_CONTENT, "DECRYPT MAC: %s", format_hex(tag_ptr, tag_size, 
> 0, ));
> -#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER < 0x10001040L
> -/* OpenSSL <= 1.0.1c bug requires set tag before processing ciphertext */
> -if (!EVP_CIPHER_CTX_ctrl(ctx->cipher, EVP_CTRL_GCM_SET_TAG, tag_size, 
> tag_ptr))
> -{
> -CRYPT_ERROR("setting tag failed");
> -}
> -#endif
>  
>  if (buf->len < 1)
>  {

Re: [Openvpn-devel] [PATCH 2/3] Cleanup: Remove unused code of old poor man's NCP.

2020-07-08 Thread Steffan Karger
Hi,

As discusses in #openvpn-devel on IRC, this patch breaks interop with
clients that don't pull, but that will be restored in a follow-up
refactoring (before 2.5 rc1). I can live with that, but I think this
should be mentioned in the commit message.

On 07-07-2020 14:16, Arne Schwabe wrote:
> Ever since the NCPv2 the ncp_get_best_cipher uses the global
> options->ncp_enabled option and ignore the tls_session->ncp_enabled
> option.
> 
> The server side's poor man's NCP is implemented as seeing the list
> of supported ciphers from the peer as just one cipher so this special
> handling for poor man's NCP of the older NCP here is not needed anymore.
> 
> Theoretically we can now get rid of tls_session->ncp_enabled but doing
> so requires more refactoring since options is not available in the
> methods that still use it. And when we remove ncp-disable the variable
> will be removed anyway.
> 
> Also document the remaining usage of tls_poor_mans_ncp better.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/init.c |  2 ++
>  src/openvpn/ssl.c  | 15 +--
>  2 files changed, 3 insertions(+), 14 deletions(-)
> 
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 91b919d5..e9c01629 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -2376,6 +2376,8 @@ do_deferred_options(struct context *c, const unsigned 
> int found)
>  }
>  else if (c->options.ncp_enabled)
>  {
> +/* If the server did not push a --cipher, we will switch to the
> + * remote cipher if it is in our ncp-ciphers list */
>  tls_poor_mans_ncp(>options, 
> c->c2.tls_multi->remote_ciphername);
>  }
>  struct frame *frame_fragment = NULL;
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 9df7552d..71565dd3 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2463,8 +2463,7 @@ key_method_2_write(struct buffer *buf, struct 
> tls_session *session)
>   * generation is postponed until after the pull/push, so we can process 
> pushed
>   * cipher directives.
>   */
> -if (session->opt->server && !(session->opt->ncp_enabled
> -  && session->opt->mode == MODE_SERVER && 
> ks->key_id <= 0))
> +if (session->opt->server && !(session->opt->mode == MODE_SERVER && 
> ks->key_id <= 0))
>  {
>  if (ks->authenticated != KS_AUTH_FALSE)
>  {
> @@ -2616,18 +2615,6 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
> *multi, struct tls_sessio
>  multi->remote_ciphername =
>  options_string_extract_option(options, "cipher", NULL);
>  
> -if (!tls_peer_supports_ncp(multi->peer_info))
> -{
> -/* Peer does not support NCP, but leave NCP enabled if the local and
> - * remote cipher do not match to attempt 'poor-man's NCP'.
> - */
> -if (multi->remote_ciphername == NULL
> -|| 0 == strcmp(multi->remote_ciphername, 
> multi->opt.config_ciphername))
> -{
> -session->opt->ncp_enabled = false;
> -}
> -}
> -

This removes the last user of tls_peer_supports_ncp(), should that be
removed too?

Other than this I think this looks good and moves in the right
direction. I haven't tested this thoroughly. Since much of the logic
will be changing soon anyway, I think it's okay to move forward
nevertheless. But we do need some aggressive testing when all the
changes are in.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 3/3] Make key_state->authenticated more state machine like

2020-07-08 Thread Steffan Karger
Hi,

On 07-07-2020 18:20, Antonio Quartulli wrote:
> On 07/07/2020 14:16, Arne Schwabe wrote:
>> This order the states from unauthenticated to authenticated and also
>> changes the comparison for KS_AUTH_FALSE from != to >
>>
>> Also remove a now obsolete comment and two obsolete ifdefs. While
>> keeping the ifdef in ssl_verify would save a few bytes of code,
>> this is too minor to justify keeping the ifdef
>>
>> Signed-off-by: Arne Schwabe 
>> ---
>>  src/openvpn/ssl.c|  6 +++---
>>  src/openvpn/ssl_common.h |  7 ++-
>>  src/openvpn/ssl_verify.c | 15 ---
>>  3 files changed, 9 insertions(+), 19 deletions(-)
>>
>> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
>> index 71565dd3..c73b51c3 100644
>> --- a/src/openvpn/ssl.c
>> +++ b/src/openvpn/ssl.c
>> @@ -2465,7 +2465,7 @@ key_method_2_write(struct buffer *buf, struct 
>> tls_session *session)
>>   */
>>  if (session->opt->server && !(session->opt->mode == MODE_SERVER && 
>> ks->key_id <= 0))
>>  {
>> -if (ks->authenticated != KS_AUTH_FALSE)
>> +if (ks->authenticated > KS_AUTH_FALSE)
>>  {
>>  if (!tls_session_generate_data_channel_keys(session))
>>  {
>> @@ -2646,7 +2646,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
>> *multi, struct tls_sessio
>>  secure_memzero(up, sizeof(*up));
>>  
>>  /* Perform final authentication checks */
>> -if (ks->authenticated != KS_AUTH_FALSE)
>> +if (ks->authenticated > KS_AUTH_FALSE)
>>  {
>>  verify_final_auth_checks(multi, session);
>>  }
>> @@ -2671,7 +2671,7 @@ key_method_2_read(struct buffer *buf, struct tls_multi 
>> *multi, struct tls_sessio
>>   * Call OPENVPN_PLUGIN_TLS_FINAL plugin if defined, for final
>>   * veto opportunity over authentication decision.
>>   */
>> -if ((ks->authenticated != KS_AUTH_FALSE)
>> +if ((ks->authenticated > KS_AUTH_FALSE)
>>  && plugin_defined(session->opt->plugins, OPENVPN_PLUGIN_TLS_FINAL))
>>  {
>>  key_state_export_keying_material(>ks_ssl, session);
>> diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
>> index fdf589b5..7d841ffb 100644
>> --- a/src/openvpn/ssl_common.h
>> +++ b/src/openvpn/ssl_common.h
>> @@ -129,8 +129,8 @@ struct key_source2 {
>>  
>>  enum ks_auth_state {
>>KS_AUTH_FALSE,
> 
> I suggest to add comments here describing how states work and how new
> states should be added.
> 
> I.e. something like: "any state before or equal to KS_AUTH_FALSE is
> considered unauthorized". Not sure the terminology is right, but
> something like this would help introducing new states, like Steffan
> reported before.

+1

Don't care much about the terminology. As long as the intention from the
quote from Antonio is immediately obvious from the code.

> Maybe he has additional comments too.

Nope, otherwise I think this looks good.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Make openvpn --version exit with exit code 0

2020-07-07 Thread Steffan Karger
For some reason, openvpn --version has since the beginning of time
returned exit code 1. A quick sample among common unix utilities confirms
that the rest of the world agrees with me that 0 makes more sense. Let's
make openvpn --version exit with exit code 0 too.

Signed-off-by: Steffan Karger 
---
 src/openvpn/options.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 2073b4a6..a72b677a 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -4326,7 +4326,7 @@ usage_version(void)
 msg(M_INFO|M_NOPREFIX, "special build: %s", CONFIGURE_SPECIAL_BUILD);
 #endif
 #endif
-openvpn_exit(OPENVPN_EXIT_STATUS_USAGE); /* exit point */
+openvpn_exit(OPENVPN_EXIT_STATUS_GOOD);
 }
 
 void
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/2] merge key_state->authenticated and key_state->auth_deferred

2020-07-07 Thread Steffan Karger
Hi,

Didn't find time to fully review, but I think this is moving into the
right direction. I did notice something I'd like you to consider:

On 06-07-2020 18:35, Arne Schwabe wrote:

> @@ -2466,7 +2466,7 @@ key_method_2_write(struct buffer *buf, struct 
> tls_session *session)
>  if (session->opt->server && !(session->opt->ncp_enabled
>&& session->opt->mode == MODE_SERVER && 
> ks->key_id <= 0))
>  {
> -if (ks->authenticated)
> +if (ks->authenticated != KS_AUTH_FALSE)
>  {

Statements like these can be risky. I'm not sure how likely enum
ks_auth_state is to grow another state, but I could imagine someone
adding an explicit KS_AUTH_FAILED or so.

I think this patch should at least document the enum better, and clearly
state assumptions like "KS_AUTH_FALSE is the only state that represents
auth failure".

Or perhaps we can make is less fragile by modeling the enum like a state
machine and documenting allowed state transitions. That would allow you
to write things like "if (ks->authenticated < KS_AUTH_TRUE)" to express
"any state before authentication succeeded".

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

2020-06-30 Thread Steffan Karger
On 22-06-2020 19:59, David Sommerseth wrote:
> On 22/06/2020 14:43, Steffan Karger wrote:
>> On 22-06-2020 14:29, David Sommerseth wrote:
>>> On 22/06/2020 14:21, Arne Schwabe wrote:
>>>>
>>>>>  PrivateTmp=true
>>>>>  WorkingDirectory=/etc/openvpn/server
>>>>> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log 
>>>>> --status-version 2 --suppress-timestamps --config %i.conf
>>>>> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log 
>>>>> --status-version 2 --suppress-timestamps --cipher AES-256-GCM 
>>>>> --ncp-ciphers AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC 
>>>>> --config %i.conf
>>>>>  CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
>>>>> CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE 
>>>>> CAP_AUDIT_WRITE
>>>>>  LimitNPROC=10
>>>>>  DeviceAllow=/dev/null rw
>>>>>
>>>>
>>>> NACK.
>>>>
>>>> Setting ncp-cipher to include BF-CBC by default allows BF-CBC in configs
>>>> that did not allow it before. Basically any config that had something
>>>> other than cipher BF-CBC and no ncp-ciphers in it will now allow clients
>>>> with BF-CBC to connect. I don't want force users to set ncp-cipher to a
>>>> sane value since the systemd unit file doesn't.
>>>
>>> That will break existing configs on the next upgrade.  Do we want do do 
>>> that?
>>>
>>> I'm fine with removing BF-CBC, but it is scheduled for removal in OpenVPN 
>>> 2.6.
>>
>> I think Arne has a very good point that it's kinda weird to "degrade"
>> the NCP defaults.
>>
>> Making AES-256-GCM the default cipher for TLS-based connections (GCM
>> won't work with static key configs) does not imply *removing* BF-CBC
>> support. Maybe these should be the steps:
>>
>> 2.4: Use to AES-256-GCM when available (basically what NCP did)
>> 2.5: Switch to AES-256-GCM as the default cipher (but allow overriding)
>> 2.6: Remove support for small block ciphers all together
>>
>> Yes, this will probably break some (less secure) setups and make some
>> people angry. But at some point people need to move on. We've been
>> throwing warnings at them for a while now.
> 
> Yes, I agree that Arne got a point.  But I'm not completely convinced breaking
> configs in OpenVPN 2.5 without a prior note that it will stop working.  Our
> warning only screams "you shouldn't use ciphers with block sizes < 128 bits",
> it doesn't say "this will stop working in a future release".
> 
> OpenVPN 2.4.9 gives this warning:
> 
> WARNING: INSECURE cipher with block size less than 128 bit (64 bit).  This
> allows attacks like SWEET32.  Mitigate by using a --cipher with a larger
> block size (e.g. AES-256-CBC).
> 
> The community has been informed it will stop working in 2.6, not before this
> release.
> 
> This must be documented properly and log warnings updated to indicate
> short-term workarounds.
> 
> I could be willing to consider breaking configs for ciphers in a later 2.5.x
> release as long as users are properly warned *when* it will stop working - and
> that users gets a real chance to fix configs before we do break their configs
> - where a workaround approach could be considered and available from v2.5.0
> (on the other hand, if they change their configs, they should swap ciphers
> instead of applying a workaround for a dying cipher - but for some it might be
> a bit more complicated to do such a swap).
> 
> We need to find a good middle-way for OpenVPN 2.5, where we clearly signal
> "weak ciphers will be removed" and when we will do that.  While also moving
> forward and break as few configs as possible and not make configs weaker than
> before.

I agree the warning we log should be made even more scary.

The DeprecatedOptions wiki however already says:

Removal of insecure ciphers: Ciphers with cipher block-size less than
128 bits (most commonly BF, DES, CAST5, IDEA and RC2)

Deprecated in: OpenVPN v2.4
To be removed in: OpenVPN v2.6

What I'm proposing is a step in between for something that is long
overdue: update the *defaults* to no longer use insecure ciphers. But to
cater for those that are unprepared, allow them to explicitly re-enable
BF-CBC during a transition period. They've been ignoring our advice to
migrate for a long time now, and even the wiki page says that these
ciphers are already deprecated in 2.4.

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

2020-06-30 Thread Steffan Karger
Hi,

On 22-06-2020 16:01, Arne Schwabe wrote:
> Am 22.06.20 um 14:43 schrieb Steffan Karger:
>> Maybe these should be the steps:
>>
>> 2.4: Use to AES-256-GCM when available (basically what NCP did)
>> 2.5: Switch to AES-256-GCM as the default cipher (but allow overriding)
>> 2.6: Remove support for small block ciphers all together
>>
>> Yes, this will probably break some (less secure) setups and make some
>> people angry. But at some point people need to move on. We've been
>> throwing warnings at them for a while now.
> 
> I had a different suggestion in the channel:
> 
> - Deprecate ncp-disable. Reason: Was a good debug switch when introduced
> should not be necessary anymore.

Deprecate in 2.5, remove in 2.6 makes sense to me.

Should we do the same for --cipher in P2MP configs?

> - Introduce ncp-fallback-cipher for compatibility with ncp-disable/old
> versions
> - needs to be a cipher from ncp-ciphers list
> - Eventually default the first cipher from ncp-ciphers list
> - in 2.5 default to --cipher if --cipher is set and automatically
> add cipher to ncp-ciphers and set ncp-fallback-cipher.
> 
> - If cipher is not set
>   a) warn about that cipher will be ignored in p2mp mode and if BF-CBC is
> still needed (e.g. peer 2.3 or older) that ncp-fallback-cipher should be set
> b) same a) but do it automatically for the user+warn
> 
> This allows us to eventually get rid of --cipher while providing still a
> smooth transaction.

That does sounds more friendly than my proposal.

But do we really need an extra option? Does is really differ so much
from changing the default cipher to AES-256-CBC? Both proposals require
config changes to keep old clients working with 2.5+ if --cipher wasn't
set explicitly.

We already have a lot of things in place to cater for a smooth transition:
 - 2.4+ does NCP by default.
 - Any 2.4+ client always sends OCC strings, which makes "poor man's
NCP" work for --ncp-disable clients as long as their cipher is in the
server's --ncp-ciphers list.
 - pre-2.4 clients almost always send OCC strings too, except for
ENABLE_SMALL builds.
 - If NCP and poor-man's NCP fail, 2.5 can (if --cipher is explicitly
set) fall back to whatever is in --cipher and print a big fat warning
that this connection will break in 2.6.
 - If someone *really* wants to have 2.3 ENABLE_SMALL clients connect to
a 2.6 server, they can run a separate server for those clients with only
the cipher of their choice in --ncp-ciphers ("Fall back to the first
cipher", as you proposed).

Basically: if we can agree to no longer guarantee interoperability
between 2.6+ and 2.3- ("mostly just works, but special cases - in
particular ENABLE_SMALL builds - might break"), I don't think we need to
add yet another option.

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] systemd: Change the default cipher to AES-256-GCM for server configs

2020-06-22 Thread Steffan Karger
Hi,

On 22-06-2020 14:29, David Sommerseth wrote:
> On 22/06/2020 14:21, Arne Schwabe wrote:
>>
>>>  PrivateTmp=true
>>>  WorkingDirectory=/etc/openvpn/server
>>> -ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log 
>>> --status-version 2 --suppress-timestamps --config %i.conf
>>> +ExecStart=@sbindir@/openvpn --status %t/openvpn-server/status-%i.log 
>>> --status-version 2 --suppress-timestamps --cipher AES-256-GCM --ncp-ciphers 
>>> AES-256-GCM:AES-128-GCM:AES-256-CBC:AES-128-CBC:BF-CBC --config %i.conf
>>>  CapabilityBoundingSet=CAP_IPC_LOCK CAP_NET_ADMIN CAP_NET_BIND_SERVICE 
>>> CAP_NET_RAW CAP_SETGID CAP_SETUID CAP_SYS_CHROOT CAP_DAC_OVERRIDE 
>>> CAP_AUDIT_WRITE
>>>  LimitNPROC=10
>>>  DeviceAllow=/dev/null rw
>>>
>>
>> NACK.
>>
>> Setting ncp-cipher to include BF-CBC by default allows BF-CBC in configs
>> that did not allow it before. Basically any config that had something
>> other than cipher BF-CBC and no ncp-ciphers in it will now allow clients
>> with BF-CBC to connect. I don't want force users to set ncp-cipher to a
>> sane value since the systemd unit file doesn't.
> 
> That will break existing configs on the next upgrade.  Do we want do do that?
> 
> I'm fine with removing BF-CBC, but it is scheduled for removal in OpenVPN 2.6.

I think Arne has a very good point that it's kinda weird to "degrade"
the NCP defaults.

Making AES-256-GCM the default cipher for TLS-based connections (GCM
won't work with static key configs) does not imply *removing* BF-CBC
support. Maybe these should be the steps:

2.4: Use to AES-256-GCM when available (basically what NCP did)
2.5: Switch to AES-256-GCM as the default cipher (but allow overriding)
2.6: Remove support for small block ciphers all together

Yes, this will probably break some (less secure) setups and make some
people angry. But at some point people need to move on. We've been
throwing warnings at them for a while now.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/3] Make cipher_kt_name always return normalised cipher name

2020-06-11 Thread Steffan Karger
 a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index 9ed6ff5f..042b0ce0 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -116,8 +116,7 @@ mutate_ncp_cipher_list(const char *list, struct gc_arena 
> *gc)
>  }
>  else
>  {
> -const char *ovpn_cipher_name =
> -translate_cipher_name_to_openvpn(cipher_kt_name(ktc));
> +const char *ovpn_cipher_name = cipher_kt_name(ktc);
>  
>  if (buf_len(_list)> 0)
>  {
> 

Makes sense, changes look good and passes my tests.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/3] Make cipher_kt_get also accept OpenVPN config cipher name

2020-06-11 Thread Steffan Karger
Hi,

On 05-06-2020 13:25, Arne Schwabe wrote:
> Basically calls to cipher_kt_get were calling
> translate_cipher_name_from_openvpn. The only two exception were the
> (broken) unit test and tls-crypt that uses cipher_kt_get("AES-256-CTR")
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/crypto.c | 2 +-
>  src/openvpn/crypto_backend.h | 3 ++-
>  src/openvpn/crypto_mbedtls.c | 1 +
>  src/openvpn/crypto_openssl.c | 1 +
>  src/openvpn/ssl_ncp.c| 8 
>  5 files changed, 9 insertions(+), 6 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index ba1fc095..1ce98184 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -763,7 +763,7 @@ init_key_type(struct key_type *kt, const char *ciphername,
>  CLEAR(*kt);
>  if (strcmp(ciphername, "none") != 0)
>  {
> -kt->cipher = 
> cipher_kt_get(translate_cipher_name_from_openvpn(ciphername));
> +kt->cipher = cipher_kt_get(ciphername);
>  if (!kt->cipher)
>  {
>  msg(M_FATAL, "Cipher %s not supported", ciphername);
> diff --git a/src/openvpn/crypto_backend.h b/src/openvpn/crypto_backend.h
> index d46cb63f..85cb084a 100644
> --- a/src/openvpn/crypto_backend.h
> +++ b/src/openvpn/crypto_backend.h
> @@ -227,7 +227,8 @@ void cipher_des_encrypt_ecb(const unsigned char 
> key[DES_KEY_LENGTH],
>   * initialise encryption/decryption.
>   *
>   * @param ciphernameName of the cipher to retrieve parameters for (e.g.
> - *  \c AES-128-CBC).
> + *  \c AES-128-CBC). Will be translated to the library 
> name
> + *  from the openvpn config name if needed.
>   *
>   * @return  A statically allocated structure containing 
> parameters
>   *  for the given cipher, or NULL if no matching 
> parameters
> diff --git a/src/openvpn/crypto_mbedtls.c b/src/openvpn/crypto_mbedtls.c
> index c8dcddc8..bb752557 100644
> --- a/src/openvpn/crypto_mbedtls.c
> +++ b/src/openvpn/crypto_mbedtls.c
> @@ -465,6 +465,7 @@ cipher_kt_get(const char *ciphername)
>  
>  ASSERT(ciphername);
>  
> +ciphername = translate_cipher_name_from_openvpn(ciphername);
>  cipher = mbedtls_cipher_info_from_string(ciphername);
>  
>  if (NULL == cipher)
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index 13ab4859..bbaa5742 100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -580,6 +580,7 @@ cipher_kt_get(const char *ciphername)
>  
>  ASSERT(ciphername);
>  
> +ciphername = translate_cipher_name_from_openvpn(ciphername);
>  cipher = EVP_get_cipherbyname(ciphername);
>  
>  if (NULL == cipher)
> diff --git a/src/openvpn/ssl_ncp.c b/src/openvpn/ssl_ncp.c
> index 042b0ce0..ea1dc960 100644
> --- a/src/openvpn/ssl_ncp.c
> +++ b/src/openvpn/ssl_ncp.c
> @@ -103,12 +103,12 @@ mutate_ncp_cipher_list(const char *list, struct 
> gc_arena *gc)
>  while (token)
>  {
>  /*
> - * Going through a roundtrip by using 
> translate_cipher_name_from_openvpn
> - * and translate_cipher_name_to_openvpn also normalises the cipher 
> name,
> + * Going through a roundtrip by using cipher_kt_get/cipher_kt_name
> + * (and translate_cipher_name_from_openvpn/
> + * translate_cipher_name_to_openvpn) also normalises the cipher name,
>   * e.g. replacing AeS-128-gCm with AES-128-GCM
>   */
> -const char *cipher_name = translate_cipher_name_from_openvpn(token);
> -const cipher_kt_t *ktc = cipher_kt_get(cipher_name);
> +    const cipher_kt_t *ktc = cipher_kt_get(token);
>  if (!ktc)
>  {
>  msg(M_WARN, "Unsupported cipher in --ncp-ciphers: %s", token);
> 

This makes the cipher_kt_name and cipher_kt_get abstractions nicely
consistent. Code looks good, and passes my tests.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [BUG] test_ncp.c failing

2020-05-29 Thread Steffan Karger
On 29-05-2020 01:46, James Bottomley wrote:
> The problem seems to be openssl uses a mixed case name for the cipher
> and EVP_CIPHER_name() is case sensitive.  Applying the patch below
> fixes this for openssl and gets make check to pass all tests, but I
> rather wonder why this isn't part of cipher_kt_name() to prevent this
> type of problem?

This was my first thought when looking at the patch too.

Probably because I wrote the cipher name translation code as one of my
very first OpenVPN contributions, and didn't get the abstractions right
at the time. Would be good to see if this can be refactored.

Slightly annoying to test if that won't break corner cases though,
because I think this part is not sufficiently covered by automated tests.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Switch assertion failure to returning false

2020-05-27 Thread Steffan Karger
Hi,

Thanks for the clear report, patch and follow-up.

On 20-05-2020 23:31, Jeremy Evans wrote:
> On 05/20 09:33, Gert Doering wrote:
>> On Wed, May 20, 2020 at 11:34:04AM -0700, Jeremy Evans wrote:
>>> To give some background, we hit this assertion failure, with the
>>> following log output:
>>
>> This should not happen, asserting out in "normal server use" is bad.  
>>
>> (Neither should it ever reach that point without ks->authenticated being 
>> true)

Agreed. I think it makes sense to first fix the urgent part (ie, not
kill the server), then figure out how de code ends up at this ASSERT.

Jeremy, can you determine from your logs whether this always
happenedwhen --auth-user-pass-verify returns zero or non-zero? Ie,
should the connections that trigger this succeed or fail?

>>> @@ -1930,7 +1930,10 @@ tls_session_generate_data_channel_keys(struct 
>>> tls_session *session)
>>>>session_id_remote : 
>>> >session_id;
>>>  
>>> -ASSERT(ks->authenticated);
>>> +if (!ks->authenticated) {
>>> +msg(D_TLS_ERRORS, "TLS Error: key_state not authenticated");
>>> +goto cleanup;
>>> +}
>>>  
>>>  ks->crypto_options.flags = session->opt->crypto_flags;
>>>  if (!generate_key_expansion(>crypto_options.key_ctx_bi,
>>
>> I'm not sure if that code is correct, though - it will erase key
>> material (in cleanup) without actually having generated a session
>> key.  So "bad things might happen later".
>  
> The same behavior would happen if generate_key_expansion fails a few
> lines below, so my assumption was it was safe to do so.  However, that's
> just an assumption and not even an educated guess.

This change correctly turns "kill the server" into "reject the
connection", which I agree is a good thing.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v4] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-05-15 Thread Steffan Karger
>  }
>  
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index a81dcfd8..4fa65ba8 100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -400,9 +400,8 @@ crypto_pem_encode(const char *name, struct buffer *dst,
>  BUF_MEM *bptr;
>  BIO_get_mem_ptr(bio, );
>  
> -*dst = alloc_buf_gc(bptr->length + 1, gc);
> +*dst = alloc_buf_gc(bptr->length, gc);
>  ASSERT(buf_write(dst, bptr->data, bptr->length));
> -buf_null_terminate(dst);
>  
>  ret = true;
>  cleanup:
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index e9f9cc2a..3018c18e 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -702,7 +702,7 @@ tls_crypt_v2_write_client_key_file(const char *filename,
>  
>  if (!filename || streq(filename, ""))
>  {
> -printf("%s\n", BPTR(_key_pem));
> +printf("%.*s\n", BLEN(_key_pem), BPTR(_key_pem));
>  client_filename = INLINE_FILE_TAG;
>  client_inline = (const char *)BPTR(_key_pem);
>  }
> diff --git a/tests/unit_tests/openvpn/test_tls_crypt.c 
> b/tests/unit_tests/openvpn/test_tls_crypt.c
> index 8406d89d..28bebb6e 100644
> --- a/tests/unit_tests/openvpn/test_tls_crypt.c
> +++ b/tests/unit_tests/openvpn/test_tls_crypt.c
> @@ -548,7 +548,8 @@ test_tls_crypt_v2_write_server_key_file(void **state)
>  const char *filename = "testfilename.key";
>  
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_server_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_server_key,
> +  strlen(test_server_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  tls_crypt_v2_write_server_key_file(filename);
> @@ -561,7 +562,8 @@ test_tls_crypt_v2_write_client_key_file(void **state)
>  
>  /* Test writing the client key */
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_client_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_client_key,
> +  strlen(test_client_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  /* Key generation re-reads the created file as a sanity check */
> @@ -580,7 +582,8 @@ test_tls_crypt_v2_write_client_key_file_metadata(void 
> **state)
>  
>  /* Test writing the client key */
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_client_key_metadata);
> +expect_memory(__wrap_buffer_write_file, pem, test_client_key_metadata,
> +strlen(test_client_key_metadata));
>  will_return(__wrap_buffer_write_file, true);
>  
>  /* Key generation re-reads the created file as a sanity check */
> 

Thanks, this looks good to me now.

The patch has a small merge conflict with the inline-refactoring-fixups,
but that should be easy enough to resolve when applying.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-05-03 Thread Steffan Karger
Hi,

On 27-04-2020 03:26, Arne Schwabe wrote:
> Change crypto_pem_encode to not put a nul-terminated terminated
> string into the buffer. This was  useful for printf but should
> not be written into the file.
> 
> Instead do not assume that the buffer is null terminated and
> print only the number of bytes in the buffer. Also fix a
> similar case in printing static key where the 0 byte was
> never added to the buffer
> 
> Patch V2: make pem_encode behave more like other similar functions in OpenVPN
>   and do not null terminate.
> 
> Patch V3: also make the mbed TLS variant of pem_decode behave like other
>   similar functions in OpeNVPN and accept a not null-terminated
>   buffer.

Thanks, this looks better. Two more things:

> @@ -273,9 +270,25 @@ crypto_pem_decode(const char *name, struct buffer *dst,
>  return false;
>  }
>  
> +/* mbed TLS requires the src to be null-terminated */
> +struct gc_arena gc = gc_new();
> +struct buffer input;
> +
> +if (*(BLAST(src)) == '\0')
> +{
> +input = *src;
> +}
> +else
> +{
> +/* allocate a new buffer to avoid modifying the src buffer */
> +input = alloc_buf_gc(BLEN(src) + 1, );
> +buf_copy(, src);
> +buf_null_terminate();
> +}
> +
>  size_t use_len = 0;
>  mbedtls_pem_context ctx = { 0 };
> -bool ret = mbed_ok(mbedtls_pem_read_buffer(, header, footer, 
> BPTR(src),
> +bool ret = mbed_ok(mbedtls_pem_read_buffer(, header, footer, 
> BPTR(),
> NULL, 0, _len));
>  if (ret && !buf_write(dst, ctx.buf, ctx.buflen))
>  {

Maybe a matter of taste, but why not always alloc the buffer? That
simplifies the code, and performance nor memory footprint is relevant
here. Just a suggestion. I'm also fine with keeping it like this.

> diff --git a/tests/unit_tests/openvpn/test_tls_crypt.c 
> b/tests/unit_tests/openvpn/test_tls_crypt.c
> index 366b48d5..f4b1f860 100644
> --- a/tests/unit_tests/openvpn/test_tls_crypt.c
> +++ b/tests/unit_tests/openvpn/test_tls_crypt.c
> @@ -530,7 +530,8 @@ test_tls_crypt_v2_write_server_key_file(void **state) {
>  const char *filename = "testfilename.key";
>  
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_server_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_server_key,
> +  strlen(test_server_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  tls_crypt_v2_write_server_key_file(filename);
> @@ -542,7 +543,8 @@ test_tls_crypt_v2_write_client_key_file(void **state) {
>  
>  /* Test writing the client key */
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_client_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_client_key,
> +  strlen(test_client_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  /* Key generation re-reads the created file as a sanity check */
> 

ASAN tells me you're missing another one:

==26863==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x618023d6 at pc 0x004310c8 bp 0x7fffbae53b90 sp 0x7fffbae53338
READ of size 847 at 0x618023d6 thread T0
#0 0x4310c7 in strcmp
(tests/unit_tests/openvpn/tls_crypt_testdriver+0x4310c7)
#1 0x7f9234541c6e  (/lib/x86_64-linux-gnu/libcmocka.so.0+0x2c6e)
#2 0x7f92345446f9 in _check_expected
(/lib/x86_64-linux-gnu/libcmocka.so.0+0x56f9)
#3 0x4cd414 in __wrap_buffer_write_file
tests/unit_tests/openvpn/../../.././../openvpn/tests/unit_tests/openvpn/test_tls_crypt.c:108:5
#4 0x4cc23b in tls_crypt_v2_write_client_key_file
tests/unit_tests/openvpn/../../.././../openvpn/src/openvpn/tls_crypt.c:709:15
#5 0x4d0f15 in test_tls_crypt_v2_write_client_key_file_metadata
tests/unit_tests/openvpn/../../.././../openvpn/tests/unit_tests/openvpn/test_tls_crypt.c:592:5
#6 0x7f92345444e0  (/lib/x86_64-linux-gnu/libcmocka.so.0+0x54e0)
#7 0x7f9234544ec4 in _cmocka_run_group_tests
(/lib/x86_64-linux-gnu/libcmocka.so.0+0x5ec4)
#8 0x4cd75a in main
tests/unit_tests/openvpn/../../.././../openvpn/tests/unit_tests/openvpn/test_tls_crypt.c:645:15
#9 0x7f92341fd0b2 in __libc_start_main
/build/glibc-YYA7BZ/glibc-2.31/csu/../csu/libc-start.c:308:16
#10 0x41d92d in _start
(tests/unit_tests/openvpn/tls_crypt_testdriver+0x41d92d)

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Uncrustify the tests/unit_tests/ part of our tree.

2020-04-26 Thread Steffan Karger
Hi,

On 26-04-2020 11:54, Gert Doering wrote:
> Apply uncrustify 0.70.1 (FreeBSD port) with our rules to that part
> of the tree, which followed a more compact coding style so far.
> ---
> 
> @@ -155,20 +157,21 @@ test_packet_id_write_long_wrap(void **state)
>  }
>  
>  int
> -main(void) {
> +main(void)
> +{
>  const struct CMUnitTest tests[] = {
> -cmocka_unit_test_setup_teardown(test_packet_id_write_short,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> -cmocka_unit_test_setup_teardown(test_packet_id_write_long,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> -
> cmocka_unit_test_setup_teardown(test_packet_id_write_short_prepend,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> -
> cmocka_unit_test_setup_teardown(test_packet_id_write_long_prepend,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> -cmocka_unit_test_setup_teardown(test_packet_id_write_short_wrap,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> -cmocka_unit_test_setup_teardown(test_packet_id_write_long_wrap,
> -test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_short,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_long,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_short_prepend,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_long_prepend,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_short_wrap,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
> +cmocka_unit_test_setup_teardown(test_packet_id_write_long_wrap,
> +test_packet_id_write_setup, 
> test_packet_id_write_teardown),
>  };

This now exceeds 80 chars by a fair amount. Perhaps rewrap?

Otherwise this looks good to me. I think having consistent style over
the code base, including tests, would be good.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 1/3] Use crypto library functions for const time memcmp when possible

2020-04-26 Thread Steffan Karger
Hi,

On 26-04-2020 11:34, Gert Doering wrote:
> On Sun, Apr 26, 2020 at 11:25:49AM +0200, Steffan Karger wrote:
>>>> well, sometimes to adhere to the codestyle, you have to re-arrange code :)
>>>
>>> "rearrange" and "rewrite in a not easy to understand way" (which looks
>>> a bit overthought to me, TBH - unlike "secure memzero" I cannot see an
>>> obvious reason why all that volatile would be relevant).
>>
>> This secure memcmp is relevant to avoid timing side channels in e.g.
>> authentication tag compare. Think about the HMAC in our tls-auth/crypt
>> and the HMAC of (non-AEAD) data channel packets.
> 
> I do understand why it has to be constant *time*, in regards to "do the
> compared buffers differ or not".
> 
> I do not see how all this "volatile" and "copy from pointer to variables
> to other stuff" handwaving is going to make any difference wrt constant
> time comparison.
> 
> And it hurts my eyes.

Pretty it is not. But "let's not try to outsmart the crypto library
folks" makes sense to me.

The copying stuff is probably just about making some annoying compiler
happy. We could probably leave that out, but that makes it harder to see
that we follow the mbed internal implementation.

When inlining this without volatile keywords, a compiler might at some
point become smart enough to realize "hey, this caller only cares about
zero/nonzero, not the actual value. And this code will only return zero
if *all* bytes are equal, so I can stop comparing as soon as soon as
I've found a difference".

Up to now, it seems compilers have not gotten this smart. But it's not
like we're keeping a close eye on that. So I would love to get rid of
the responsibility :-)

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] new openssl = new OpenVPN release ?

2020-04-26 Thread Steffan Karger


On 22-04-2020 10:27, Jan Just Keijser wrote:
> On 22/04/20 10:13, Arne Schwabe wrote:
 SSL_check_chain() function".

 Which we don't, I just grepped through our source tree.

 So, unless I misunderstand something about OpenSSL intricacies, I think
 we're safe - no new installers needed, and OpenVPN is not in risk.


>>> the advisory applies only to application that use the SSL_check_chain()
>>> function as part of a TLS 1.3 handshake. AFAIK, iIn OpenVPN 2.4 we don't
>>> do anything with TLS 1.3 just yet, so this security advisory does not
>>> apply to OpenVPN. Also note that this bug appears only in OpenSSL 1.1.1
>>> [d-f] , so anything older is fine as well.
>> Hu? OpenVPN 2.4 supports TLS 1.3 just fine. We have support for it in
>> tls-version-min and also tls-ciphersuites which is TLS 1.3 specific.
>>
>>
> what I meant was that OpenVPN 2.4 does not do any *specific* with any of
> the new features of TLS 1.3, like the new psk callbacks etc. If the
> control session is negotiated using TLS 1.3 then sure, OpenVPN will use
> that, but other that OpenVPN does not make use of any of the new
> features or crypto algorithms that come with OpenSSL 1.1.1 or TLS 1.3
> (chacha20 anyone ;) ? )

Arne has been working on some of the TLS 1.3-specific features, such as
using CHACHA20-POLY1305 for the control channel:

$ openvpn --show-tls
Available TLS Ciphers, listed in order of preference:

For TLS 1.3 and newer (--tls-ciphersuites):

TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256

For TLS 1.2 and older (--tls-cipher):

TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384

(This is with OpenVPN 2.4.7 from the Ubuntu 20.04 package.)

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 1/3] Use crypto library functions for const time memcmp when possible

2020-04-26 Thread Steffan Karger
Hi,

On 17-04-2020 17:36, Gert Doering wrote:
> On Fri, Apr 17, 2020 at 03:42:49PM +0200, Antonio Quartulli wrote:
 -static inline int
 -memcmp_constant_time(const void *a, const void *b, size_t size)
 -{
>>>
>>> Not sure I understand the motivation for this change.  "Just so uncrustify
>>> stops trying to change this" is not really strong.
>>
>> well, sometimes to adhere to the codestyle, you have to re-arrange code :)
> 
> "rearrange" and "rewrite in a not easy to understand way" (which looks
> a bit overthought to me, TBH - unlike "secure memzero" I cannot see an
> obvious reason why all that volatile would be relevant).

This secure memcmp is relevant to avoid timing side channels in e.g.
authentication tag compare. Think about the HMAC in our tls-auth/crypt
and the HMAC of (non-AEAD) data channel packets.

>> On top of that, this is basically allowing us to re-use an existing
>> openssl API when possible.
> 
> True, but if that turns out to be a code complication and reduces
> efficiency, I'm not convinced it's the right way to spend our cycles.
> 
>>> Also, keeping the "inline" part would be good...  this is in the per-packet
>>> path.
>>
>> I am not sure it would work in this case, because the function is
>> defined in a .c file now - it's not inlineable anymore outside of the
>> mbedtls code.
> 
> This is why I'm not exactly happy with the change.
> 
> We could do it "openvpn style" all in header files, or we could just
> leave the function alone.

This kind of code is a tricky balance between "prevent the compiler from
optimizing it to a not-constant-time implementation" and "as much
performance as we can get". Moving this responsibility to the crypto
library seems like a good idea to me.

And because our recommended data channel ciphers are AEAD ciphers for
which the auth tag compare is handled internally by the crypto library,
I don't care so much for the performance aspect. Want best security? Use
AEAD! Want best performance? Use AEAD!

You get the point. Use AEAD ;-)

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Add tls-crypt-v2 test writing metadata

2020-04-26 Thread Steffan Karger
Hi,

On 20-04-2020 12:44, Arne Schwabe wrote:
> ---
>  tests/unit_tests/openvpn/test_tls_crypt.c | 44 +--
>  1 file changed, 41 insertions(+), 3 deletions(-)
> 
> diff --git a/tests/unit_tests/openvpn/test_tls_crypt.c 
> b/tests/unit_tests/openvpn/test_tls_crypt.c
> index b9e3a7a6..91a4d209 100644
> --- a/tests/unit_tests/openvpn/test_tls_crypt.c
> +++ b/tests/unit_tests/openvpn/test_tls_crypt.c
> @@ -72,6 +72,24 @@ static const char *test_client_key = \
>  "/Z5wtPCAZ0tOzj4ItTI77fBOYRTfEayzHgEr\n"
>  "-END OpenVPN tls-crypt-v2 client key-\n";
>  
> +
> +/* Has custom metadata of AABBCCDD (base64) */
> +static const char *test_client_key_metadata= \
> +"-BEGIN OpenVPN tls-crypt-v2 client key-\n"
> +"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4v\n"
> +"MDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5f\n"
> +"YGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6P\n"
> +"kJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/\n"
> +"wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v\n"
> +"8PHy8/T19vf4+fr7/P3+/2ntp1WCqhcLjJQY/igkjNt3Yb6i0neqFkfrOp2UCDcz\n"
> +"6RSJtPLZbvOOKUHk2qwxPYUsFCnz/IWV6/ZiLRrabzUpS8oSN1HS6P7qqAdrHKgf\n"
> +"hVTHasdSf2UdMTPC7HBgnP9Ll0FhKN0h7vSzbbt7QM7wH9mr1ecc/Mt0SYW2lpwA\n"
> +"aJObYGTyk6hTgWm0g/MLrworLrezTqUHBZzVsu+LDyqLWK1lzJNd66MuNOsGA4YF\n"
> +"fbCsDh8n3H+Cw1k5YNBZDYYJOtVUgBWXheO6vgoOmqDdI0dAQ3hVo9DE+SkCFjgf\n"
> +"l4FY2yLEh9ZVZZrl1eD1Owh/X178CkHrBJYl9LNQSyQEKlDGWwBLQ/pY3qtjctr3\n"
> +"pV62MPQdBo+1lcsjDCJVQA6XUyltas4BKQ==\n"
> +"-END OpenVPN tls-crypt-v2 client key-\n";
> +
>  int
>  __wrap_parse_line(const char *line, char **p, const int n, const char *file,
>const int line_num, int msglevel, struct gc_arena *gc)
> @@ -520,21 +538,40 @@ test_tls_crypt_v2_write_server_key_file(void **state) {
>  
>  static void
>  test_tls_crypt_v2_write_client_key_file(void **state) {
> +  const char *filename = "testfilename.key";
> +
> +  /* Test writing the client key */
> +  expect_string(__wrap_buffer_write_file, filename, filename);
> +  expect_string(__wrap_buffer_write_file, pem, test_client_key);
> +  will_return(__wrap_buffer_write_file, true);
> +
> +  /* Key generation re-reads the created file as a sanity check */
> +  expect_string(__wrap_buffer_read_from_file, filename, filename);
> +  will_return(__wrap_buffer_read_from_file, test_client_key);
> +
> +  tls_crypt_v2_write_client_key_file(filename, NULL, INLINE_FILE_TAG,
> + test_server_key);
> +}
> +

The indenting of this block is wrong: 2 instead of 4 spaces. This also
makes the changes in this patch harder to see.

> +static void
> +test_tls_crypt_v2_write_client_key_file_metadata(void **state) {
>  const char *filename = "testfilename.key";
> +const char *b64metadata = "AABBCCDD";
>  
>  /* Test writing the client key */
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_client_key);
> +expect_string(__wrap_buffer_write_file, pem, test_client_key_metadata);
>  will_return(__wrap_buffer_write_file, true);
>  
>  /* Key generation re-reads the created file as a sanity check */
>  expect_string(__wrap_buffer_read_from_file, filename, filename);
> -will_return(__wrap_buffer_read_from_file, test_client_key);
> +will_return(__wrap_buffer_read_from_file, test_client_key_metadata);
>  
> -tls_crypt_v2_write_client_key_file(filename, NULL, INLINE_FILE_TAG,
> +tls_crypt_v2_write_client_key_file(filename, b64metadata, 
> INLINE_FILE_TAG,
> test_server_key);
>  }
>  
> +
>  int
>  main(void) {
>  const struct CMUnitTest tests[] = {
> @@ -576,6 +613,7 @@ main(void) {
>  test_tls_crypt_v2_teardown),
>  cmocka_unit_test(test_tls_crypt_v2_write_server_key_file),
>  cmocka_unit_test(test_tls_crypt_v2_write_client_key_file),
> +cmocka_unit_test(test_tls_crypt_v2_write_client_key_file_metadata),
>  };
>  
>  #if defined(ENABLE_CRYPTO_OPENSSL)
> 

Otherwise this looks good. So ACK-if-whitespace-is-fixed :)

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-04-25 Thread Steffan Karger
Hi,

On 20-04-2020 14:06, Arne Schwabe wrote:
> Change crypto_pem_encode to not put a nul-terminated terminated
> string into the buffer. This was  useful for printf but should
> not be written into the file.
> 
> Instead do not assume that the buffer is null terminated and
> print only the number of bytes in the buffer. Also fix a
> similar case in printing static key where the 0 byte was
> never added to the buffer
> 
> Patch V2: make pem_encode behave more like other similar functions in OpenVPN
>   and do not null terminate.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/crypto.c  | 4 ++--
>  src/openvpn/crypto_mbedtls.c  | 4 +++-
>  src/openvpn/crypto_openssl.c  | 3 +--
>  src/openvpn/tls_crypt.c   | 2 +-
>  tests/unit_tests/openvpn/test_tls_crypt.c | 6 --
>  5 files changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 1678cba8..b05262e1 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -1478,7 +1478,7 @@ write_key_file(const int nkeys, const char *filename)
>  /* write key file to stdout if no filename given */
>  if (!filename || strcmp(filename, "")==0)
>  {
> -printf("%s\n", BPTR());
> +printf("%.*s\n", BLEN(), BPTR());
>  }
>  /* write key file, now formatted in out, to file */
>  else if (!buffer_write_file(filename, ))
> @@ -1887,7 +1887,7 @@ write_pem_key_file(const char *filename, const char 
> *pem_name)
>  
>  if (!filename || strcmp(filename, "")==0)
>  {
> -printf("%s\n", BPTR(_key_pem));
> +printf("%.*s", BLEN(_key_pem), BPTR(_key_pem));
>  }
>  else if (!buffer_write_file(filename, _key_pem))
>  {
> diff --git a/src/openvpn/crypto_mbedtls.c b/src/openvpn/crypto_mbedtls.c
> index 3e77fa9e..14a528af 100644
> --- a/src/openvpn/crypto_mbedtls.c
> +++ b/src/openvpn/crypto_mbedtls.c
> @@ -239,10 +239,12 @@ crypto_pem_encode(const char *name, struct buffer *dst,
>  return false;
>  }
>  
> +/* We set the size buf to out_len-1 to NOT include the 0 byte that
> + * mbedtls_pem_write_buffer in its length calculation */
>  *dst = alloc_buf_gc(out_len, gc);
>  if (!mbed_ok(mbedtls_pem_write_buffer(header, footer, BPTR(src), 
> BLEN(src),
>BPTR(dst), BCAP(dst), _len))
> -|| !buf_inc_len(dst, out_len))
> +|| !buf_inc_len(dst, out_len-1))
>  {
>  CLEAR(*dst);
>  return false;
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index a81dcfd8..4fa65ba8 100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -400,9 +400,8 @@ crypto_pem_encode(const char *name, struct buffer *dst,
>  BUF_MEM *bptr;
>  BIO_get_mem_ptr(bio, );
>  
> -*dst = alloc_buf_gc(bptr->length + 1, gc);
> +*dst = alloc_buf_gc(bptr->length, gc);
>  ASSERT(buf_write(dst, bptr->data, bptr->length));
> -buf_null_terminate(dst);
>  
>  ret = true;
>  cleanup:
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index e9f9cc2a..3018c18e 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -702,7 +702,7 @@ tls_crypt_v2_write_client_key_file(const char *filename,
>  
>  if (!filename || streq(filename, ""))
>  {
> -printf("%s\n", BPTR(_key_pem));
> +printf("%.*s\n", BLEN(_key_pem), BPTR(_key_pem));
>  client_filename = INLINE_FILE_TAG;
>  client_inline = (const char *)BPTR(_key_pem);
>  }
> diff --git a/tests/unit_tests/openvpn/test_tls_crypt.c 
> b/tests/unit_tests/openvpn/test_tls_crypt.c
> index b9e3a7a6..54fc917d 100644
> --- a/tests/unit_tests/openvpn/test_tls_crypt.c
> +++ b/tests/unit_tests/openvpn/test_tls_crypt.c
> @@ -512,7 +512,8 @@ test_tls_crypt_v2_write_server_key_file(void **state) {
>  const char *filename = "testfilename.key";
>  
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_server_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_server_key,
> +  strlen(test_server_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  tls_crypt_v2_write_server_key_file(filename);
> @@ -524,7 +525,8 @@ test_tls_crypt_v2_write_client_key_file(void **state) {
>  
>  /* Test writing the client key */
>  expect_string(__wrap_buffer_write_file, filename, filename);
> -expect_string(__wrap_buffer_write_file, pem, test_client_key);
> +expect_memory(__wrap_buffer_write_file, pem, test_client_key,
> +  strlen(test_client_key));
>  will_return(__wrap_buffer_write_file, true);
>  
>  /* Key generation re-reads the created file as a sanity check */
> 

Didn't review in detail yet, but this patch now fails "make check" with
mbedtls:

[==] Running 1 test(s).
[ RUN  ] 

Re: [Openvpn-devel] [PATCH] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-04-06 Thread Steffan Karger
On 06-04-2020 18:00, Arne Schwabe wrote:
> Am 06.04.20 um 17:44 schrieb Steffan Karger:
>> Hi,
>>
>> On 06-04-2020 15:00, Arne Schwabe wrote:
>>> crypto_pem_encode put a nul-terminated terminated string into the
>>> buffer. This is useful for printf but should not be written into
>>> the file.
>>>
>>> Also for static keys, we were missing the nul termination when priting
>>> it to stadout but since the buffer was cleared before, there was always
>>> a NULL byte in the right place. Make it explicit instead.
>>>
>>> Signed-off-by: Arne Schwabe 
>>> ---
>>>  src/openvpn/crypto.c| 11 +--
>>>  src/openvpn/tls_crypt.c | 10 --
>>>  2 files changed, 17 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
>>> index 453cb20a..7af48df0 100644
>>> --- a/src/openvpn/crypto.c
>>> +++ b/src/openvpn/crypto.c
>>> @@ -1477,6 +1477,7 @@ write_key_file(const int nkeys, const char *filename)
>>>  /* write key file to stdout if no filename given */
>>>  if (!filename || strcmp(filename, "")==0)
>>>  {
>>> +buf_null_terminate();
>>>  printf("%s\n", BPTR());
>>>  }
>>>  /* write key file, now formatted in out, to file */
>>> @@ -1888,9 +1889,15 @@ write_pem_key_file(const char *filename, const char 
>>> *pem_name)
>>>  {
>>>  printf("%s\n", BPTR(_key_pem));
>>>  }
>>> -else if (!buffer_write_file(filename, _key_pem))
>>> +else
>>>  {
>>> -msg(M_ERR, "ERROR: could not write key file");
>>> +/* crypto_pem_encode null terminates the buffer, do
>>> + * not write this to the file */
>>> +buf_inc_len(_key_pem, -1);
>>> +if (!buffer_write_file(filename, _key_pem))
>>> +{
>>> +msg(M_ERR, "ERROR: could not write key file");
>>> +}
>>>  goto cleanup;
>>>  }
>>>  
>>> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
>>> index e9f9cc2a..85f2862b 100644
>>> --- a/src/openvpn/tls_crypt.c
>>> +++ b/src/openvpn/tls_crypt.c
>>> @@ -706,9 +706,15 @@ tls_crypt_v2_write_client_key_file(const char 
>>> *filename,
>>>  client_filename = INLINE_FILE_TAG;
>>>  client_inline = (const char *)BPTR(_key_pem);
>>>  }
>>> -else if (!buffer_write_file(filename, _key_pem))
>>> +else
>>>  {
>>> -msg(M_FATAL, "ERROR: could not write client key file");
>>> +/* crypto_pem_encode null terminates the buffer, do
>>> + * not write this to the file */
>>> +buf_inc_len(_key_pem, -1);
>>> +if (!buffer_write_file(filename, _key_pem))
>>> +{
>>> +msg(M_FATAL, "ERROR: could not write client key file");
>>> +}
>>>  goto cleanup;
>>>  }
>>>  
>>>
>>
>> Fix is correct, but I'm not too happy with changing the buffer from
>> being null-terminated to not-null-terminated. This change itself is
>> correct, but it feels like a recipe for mistakes in the future.
>>
>> What would you think about adding a length parameter to
>> buffer_write_file() instead, so that the API there changes to "write len
>> bytes of data to file"?
> 
> So there are three alternatives how to things:
> 
> a) make pem_encode behave more like other similar functions in OepnVPN
> and do not null terminate. Then we would need to call buf_null_terminate
> like in the static key path
> 
> b) do what this patch does
> 
> c) have buffer_write_file take a length argument.
> 
> I considered c) but it felt wrong because the function currently just
> does a very simple job.

I felt that too, but slightly less so than having buffers that are
sometimes null-terminated and sometimes not. Slight different preference
I guess.

> I did not do a) because that would make printing the buffer etc more
> complicated since either pem_encode needs to allocate a bigger buffer
> than it needs to or we need to copy the buffer into one that allows an
> extra null byte.

I originally discarded this idea, but thinking a bit more about it, I
think it makes sense. You don't have to allocate extra bytes, I think
the "%.*s" format specifier should work just fine:

   printf("%.*s", BLEN(buf), BPTR(buf));

> That being said I don't feel stronlgy about this and can send an updated
> patch that is a) or c)

Same here. Hence the fuzzy wording. Does my suggestion make you like c)
more? If you still like b) most, I'm okay with sticking to it. Neither
option excels in beauty :(

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Do not write extra 0 byte for --gen-key with auth-token/tls-crypt-v2

2020-04-06 Thread Steffan Karger
Hi,

On 06-04-2020 15:00, Arne Schwabe wrote:
> crypto_pem_encode put a nul-terminated terminated string into the
> buffer. This is useful for printf but should not be written into
> the file.
> 
> Also for static keys, we were missing the nul termination when priting
> it to stadout but since the buffer was cleared before, there was always
> a NULL byte in the right place. Make it explicit instead.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/crypto.c| 11 +--
>  src/openvpn/tls_crypt.c | 10 --
>  2 files changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 453cb20a..7af48df0 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -1477,6 +1477,7 @@ write_key_file(const int nkeys, const char *filename)
>  /* write key file to stdout if no filename given */
>  if (!filename || strcmp(filename, "")==0)
>  {
> +buf_null_terminate();
>  printf("%s\n", BPTR());
>  }
>  /* write key file, now formatted in out, to file */
> @@ -1888,9 +1889,15 @@ write_pem_key_file(const char *filename, const char 
> *pem_name)
>  {
>  printf("%s\n", BPTR(_key_pem));
>  }
> -else if (!buffer_write_file(filename, _key_pem))
> +else
>  {
> -msg(M_ERR, "ERROR: could not write key file");
> +/* crypto_pem_encode null terminates the buffer, do
> + * not write this to the file */
> +buf_inc_len(_key_pem, -1);
> +if (!buffer_write_file(filename, _key_pem))
> +{
> +msg(M_ERR, "ERROR: could not write key file");
> +}
>  goto cleanup;
>  }
>  
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index e9f9cc2a..85f2862b 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -706,9 +706,15 @@ tls_crypt_v2_write_client_key_file(const char *filename,
>  client_filename = INLINE_FILE_TAG;
>  client_inline = (const char *)BPTR(_key_pem);
>  }
> -else if (!buffer_write_file(filename, _key_pem))
> +else
>  {
> -msg(M_FATAL, "ERROR: could not write client key file");
> +/* crypto_pem_encode null terminates the buffer, do
> + * not write this to the file */
> +buf_inc_len(_key_pem, -1);
> +if (!buffer_write_file(filename, _key_pem))
> +{
> +msg(M_FATAL, "ERROR: could not write client key file");
> +}
>  goto cleanup;
>  }
>  
> 

Fix is correct, but I'm not too happy with changing the buffer from
being null-terminated to not-null-terminated. This change itself is
correct, but it feels like a recipe for mistakes in the future.

What would you think about adding a length parameter to
buffer_write_file() instead, so that the API there changes to "write len
bytes of data to file"?

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix off-by-one in tls-crypt-v2 client wrapping with custom metadata

2020-04-06 Thread Steffan Karger
Hi,

On 03-04-2020 11:09, Arne Schwabe wrote:
> Instead of writing at the end of the metadata buffer, the decoded
> base64 data overwrites the opcode as BPTR points to the beginning
> of the buffer and not the current position. Replace with BEND to
> fix this off-by-one
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/tls_crypt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index 37df2ce7..e9f9cc2a 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -664,7 +664,7 @@ tls_crypt_v2_write_client_key_file(const char *filename,
>  (int)strlen(b64_metadata), 
> TLS_CRYPT_V2_MAX_B64_METADATA_LEN);
>  }
>  ASSERT(buf_write(, _CRYPT_METADATA_TYPE_USER, 1));
> -int decoded_len = openvpn_base64_decode(b64_metadata, 
> BPTR(),
> +int decoded_len = openvpn_base64_decode(b64_metadata, 
> BEND(),
>  BCAP());
>  if (decoded_len < 0)
>  {
> 

Good catch. And apologies for the silly bug. Patch looks good, but it
would have been nice to add a regression (unit) test. Are you willing to
write one? Otherwise I will.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix OpenSSL private key passphrase notices

2020-02-27 Thread Steffan Karger
Hi,

On 21-10-2019 13:35, Santtu Lakkala wrote:
> Clear error stack on successful certificate loading in
> tls_ctx_load_cert_file_and_copy() and handle errors also for
> PEM_read_bio_PrivateKey() call in tls_ctx_load_priv_file().
> 
> Due to certificate loading possibly leaking non-fatal errors on OpenSSL
> error stack, and some slight oversights in error handling, the
> 
>> PASSWORD:Verification Failed: 'Private Key'
> 
> line was never produced on the management channel for PEM formatted keys.
> 
> Signed-off-by: Santtu Lakkala 
> ---
>  src/openvpn/ssl_openssl.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 07916c3c..74c8fa65 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -921,6 +921,10 @@ end:
>  crypto_msg(M_FATAL, "Cannot load certificate file %s", 
> cert_file);
>  }
>  }
> +else
> +{
> +crypto_print_openssl_errors(M_DEBUG);
> +}
>  
>  if (in != NULL)
>  {
> @@ -963,12 +967,7 @@ tls_ctx_load_priv_file(struct tls_root_ctx *ctx, const 
> char *priv_key_file,
>  pkey = PEM_read_bio_PrivateKey(in, NULL,
> SSL_CTX_get_default_passwd_cb(ctx->ctx),
> 
> SSL_CTX_get_default_passwd_cb_userdata(ctx->ctx));
> -if (!pkey)
> -{
> -goto end;
> -}
> -
> -if (!SSL_CTX_use_PrivateKey(ssl_ctx, pkey))
> +if (!pkey || !SSL_CTX_use_PrivateKey(ssl_ctx, pkey))
>  {
>  #ifdef ENABLE_MANAGEMENT
>  if (management && (ERR_GET_REASON(ERR_peek_error()) == 
> EVP_R_BAD_DECRYPT))
> 

Thanks, and apologies for the late repsonse. This patch does was it
says, and looks good to me. I think this one should go into both master
and release/2.4.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Warn about insecure ciphers also in init_key_type

2020-02-19 Thread Steffan Karger
On 19-02-2020 12:21, Arne Schwabe wrote:
> With modern Clients and server initialising the crypto cipher later
> and not when reading in the config, most users never the warning when
> having selected BF-CBC in the configuration.
> 
> This patch adds the logic to print out warning to init_key_type.
> 
> Main reason for this patch is a personal experience with someone who was
> strictly against putting 'cipher' into a config file because he did not
> like hardcoding a cipher and "OpenVPN will do AES-GCM anyway" and thinks
> that it is better to not have it in configuration even after told by me
> that 15 year defaults might not be good anymore.
> 
> Patch V2: rebase on master, fix minor style issues
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/crypto.c | 26 ++
>  1 file changed, 18 insertions(+), 8 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index 65e789ed..453cb20a 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -736,6 +736,17 @@ crypto_max_overhead(void)
> +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
>  }
>  
> +static void warn_insecure_key_type(const char* ciphername, const cipher_kt_t 
> *cipher)
> +{
> +if (cipher_kt_insecure(cipher))
> +{
> +msg(M_WARN, "WARNING: INSECURE cipher (%s) with block size less than 
> 128"
> +" bit (%d bit).  This allows attacks like SWEET32.  
> Mitigate by "
> +"using a --cipher with a larger block size (e.g. 
> AES-256-CBC).",
> +ciphername, cipher_kt_block_size(cipher)*8);
> +}
> +}
> +
>  /*
>   * Build a struct key_type.
>   */
> @@ -779,6 +790,10 @@ init_key_type(struct key_type *kt, const char 
> *ciphername,
>  {
>  msg(M_FATAL, "Cipher '%s' not allowed: block size too big.", 
> ciphername);
>  }
> +if (warn)
> +{
> +warn_insecure_key_type(ciphername, kt->cipher);
> +}
>  }
>  else
>  {
> @@ -831,9 +846,10 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
>  cipher_ctx_init(ctx->cipher, key->cipher, kt->cipher_length,
>  kt->cipher, enc);
>  
> +const char* ciphername = 
> translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher));
>  msg(D_HANDSHAKE, "%s: Cipher '%s' initialized with %d bit key",
>  prefix,
> -translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher)),
> +ciphername,
>  kt->cipher_length *8);
>  
>  dmsg(D_SHOW_KEYS, "%s: CIPHER KEY: %s", prefix,
> @@ -841,13 +857,7 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
>  dmsg(D_CRYPTO_DEBUG, "%s: CIPHER block_size=%d iv_size=%d",
>   prefix, cipher_kt_block_size(kt->cipher),
>   cipher_kt_iv_size(kt->cipher));
> -if (cipher_kt_insecure(kt->cipher))
> -{
> -msg(M_WARN, "WARNING: INSECURE cipher with block size less than 
> 128"
> -" bit (%d bit).  This allows attacks like SWEET32.  Mitigate 
> by "
> -"using a --cipher with a larger block size (e.g. 
> AES-256-CBC).",
> -cipher_kt_block_size(kt->cipher)*8);
> -}
> +warn_insecure_key_type(ciphername, kt->cipher);
>  }
>  if (kt->digest && kt->hmac_length > 0)
>  {
> 

Tested, works as advertised.

Acked-by: Steffan Karger 

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Warn about insecure ciphers also in init_key_type

2020-02-19 Thread Steffan Karger
Hi,

On 29-03-2019 13:27, Arne Schwabe wrote:
> With modern Clients and server initialising the crypto cipher later
> and not when reading in the config, most users never the warning when
> having selected BF-CBC in the configuration.
> 
> This patch adds the logic to print out warning to init_key_type.
> 
> Main reason for this patch is a personal experience with someone who was
> strictly against putting 'cipher' into a config file because he did not
> like hardcoding a cipher and "OpenVPN will do AES-GCM anyway" and thinks
> that it is better to not have it in configuration even after told by me
> that 15 year defaults might not be good anymore.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/crypto.c | 27 +++
>  1 file changed, 19 insertions(+), 8 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index ff9dbfdc..8a92a8c1 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -736,6 +736,17 @@ crypto_max_overhead(void)
> +max_int(OPENVPN_MAX_HMAC_SIZE, OPENVPN_AEAD_TAG_LENGTH);
>  }
>  
> +static void warn_insecure_key_type(const char* ciphername, const cipher_kt_t 
> *cipher)
> +{
> +if (cipher_kt_insecure(cipher))
> +{
> +msg(M_WARN, "WARNING: INSECURE cipher (%s) with block size less than 
> 128"
> +" bit (%d bit).  This allows attacks like SWEET32.  
> Mitigate by "
> +"using a --cipher with a larger block size (e.g. 
> AES-256-CBC).",
> +ciphername, cipher_kt_block_size(cipher)*8);
> +}
> +}
> +
>  /*
>   * Build a struct key_type.
>   */
> @@ -763,6 +774,7 @@ init_key_type(struct key_type *kt, const char *ciphername,
>  kt->cipher_length = keysize;
>  }
>  
> +

Spurious newline, should be removed from patch.

>  /* check legal cipher mode */
>  aead_cipher = cipher_kt_mode_aead(kt->cipher);
>  if (!(cipher_kt_mode_cbc(kt->cipher)
> @@ -779,6 +791,10 @@ init_key_type(struct key_type *kt, const char 
> *ciphername,
>  {
>  msg(M_FATAL, "Cipher '%s' not allowed: block size too big.", 
> ciphername);
>  }
> +if(warn)

Space after if missing: if (warn)

> +{
> +warn_insecure_key_type(ciphername, kt->cipher);
> +}
>  }
>  else
>  {
> @@ -831,9 +847,10 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
>  cipher_ctx_init(ctx->cipher, key->cipher, kt->cipher_length,
>  kt->cipher, enc);
>  
> +const char* ciphername = 
> translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher));
>  msg(D_HANDSHAKE, "%s: Cipher '%s' initialized with %d bit key",
>  prefix,
> -translate_cipher_name_to_openvpn(cipher_kt_name(kt->cipher)),
> +ciphername,
>  kt->cipher_length *8);
>  
>  dmsg(D_SHOW_KEYS, "%s: CIPHER KEY: %s", prefix,
> @@ -841,13 +858,7 @@ init_key_ctx(struct key_ctx *ctx, const struct key *key,
>  dmsg(D_CRYPTO_DEBUG, "%s: CIPHER block_size=%d iv_size=%d",
>   prefix, cipher_kt_block_size(kt->cipher),
>   cipher_kt_iv_size(kt->cipher));
> -if (cipher_kt_insecure(kt->cipher))
> -{
> -msg(M_WARN, "WARNING: INSECURE cipher with block size less than 
> 128"
> -" bit (%d bit).  This allows attacks like SWEET32.  Mitigate 
> by "
> -"using a --cipher with a larger block size (e.g. 
> AES-256-CBC).",
> -cipher_kt_block_size(kt->cipher)*8);
> -}
> +warn_insecure_key_type(ciphername, kt->cipher);
>  }
>  if (kt->digest && kt->hmac_length > 0)
>  {
> 

Otherwise this looks good. Maybe send a rebased version with the above
nits resolved?

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] travis-ci: add arm64, s390x builds.

2020-02-03 Thread Steffan Karger
On 03-02-2020 09:04, Илья Шипицин wrote:
> also, ARM64 builds are flaky. maybe we should add them as allow_failures.

What is flaky about the ARM64 builds? Is it our build? Is it the travis
infra?

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] linux arm64 tests fail

2020-02-01 Thread Steffan Karger
Hi,

On 01-02-2020 13:43, Илья Шипицин wrote:
> https://travis-ci.org/chipitsine/openvpn/jobs/644745481?utm_medium=notification_source=github_status
> 
> it indicates "ERROR" when running tests, however tests are ok after all.
> 
> [ RUN ] tls_crypt_v2_wrap_too_long_metadata
> 
> ERROR: could not crypt: insufficient space in dst
> 
> [ OK ] tls_crypt_v2_wrap_too_long_metadata
> 
> [ RUN ] tls_crypt_v2_wrap_unwrap_wrong_key
> 
> [ OK ] tls_crypt_v2_wrap_unwrap_wrong_key
> 
> [ RUN ] tls_crypt_v2_wrap_unwrap_dst_too_small
> 
> [ OK ] tls_crypt_v2_wrap_unwrap_dst_too_small
> 
> [ RUN ] test_tls_crypt_v2_write_server_key_file
> 
> [ OK ] test_tls_crypt_v2_write_server_key_file
> 
> [ RUN ] test_tls_crypt_v2_write_client_key_file
> 
> [ OK ] test_tls_crypt_v2_write_client_key_file
> 
> [==] 14 test(s) run.
> 
> [ PASSED ] 14 test(s).
> 
> PASS: tls_crypt_testdriver

This is expected behaviour. And unrelated to arm64. Just check the amd64
build, exact same message.

We test the "too much input data" case here, which prints an error.
Looks odd, I admit. But printing warnings/errors even in tests helps
speed up diagnosis.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Move keying material exporter check from syshead.h to configure.ac

2020-01-20 Thread Steffan Karger
On 20-01-2020 13:42, Lev Stipakov wrote:
> +       have_export_keying_material="yes"
> +       AC_CHECK_FUNCS(
> +               [SSL_export_keying_material],
> +               ,
> +               [have_export_keying_material="no"; break]
> +       )
> 
> 
> Just wondering why not AC_CHECK_FUNC? In this case we could get rid of
> "break".
> 
> _FUNCS also defines HAVE_function macro, which we don't use in this
> particular case.
> 
> Noticed that we have similar code above:
> 
>     have_crypto_aead_modes="yes"
>     AC_CHECK_FUNCS(
>         [EVP_aes_256_gcm],
>         ,
>         [have_crypto_aead_modes="no"; break]
>     )
> 
> so maybe that's why.

This. It's too long ago that I fully remember, but I recall we changed
to FUNCS for some reason in the past. Autoconf is full of surprises. So
if we have something that works, and I want something similar, let's do
it in the exact same way.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Move keying material exporter check from syshead.h to configure.ac

2020-01-20 Thread Steffan Karger
Commit ab27c9f7 added a compile-time check for availablitity of
keying-material-export functionality to syshead.h. It turns out that
openvpnserv also includes syshead.h, and has ENABLE_CRYPTO_* defined in
it's config.h, but doesn't have the necessary CFLAGS / LIBS to actually
compile and link against the crypto libraries. That of course breaks
openvpnserv builds.

To fix this, change the compile-time check in syshead.h into a
configure-time check in configure.ac. That's more consistent with how we
do other feature checks anyway.

Signed-off-by: Steffan Karger 
---
 configure.ac  | 20 
 src/openvpn/init.c|  4 ++--
 src/openvpn/options.c |  4 ++--
 src/openvpn/options.h |  2 +-
 src/openvpn/ssl_mbedtls.c |  6 +++---
 src/openvpn/syshead.h | 13 -
 6 files changed, 28 insertions(+), 21 deletions(-)

diff --git a/configure.ac b/configure.ac
index a47e0a06..98fd39ce 100644
--- a/configure.ac
+++ b/configure.ac
@@ -912,6 +912,13 @@ if test "${with_crypto_library}" = "openssl"; then
[have_crypto_aead_modes="no"; break]
)
 
+   have_export_keying_material="yes"
+   AC_CHECK_FUNCS(
+   [SSL_export_keying_material],
+   ,
+   [have_export_keying_material="no"; break]
+   )
+
AC_CHECK_FUNCS(
[ \
HMAC_CTX_new \
@@ -1010,6 +1017,13 @@ elif test "${with_crypto_library}" = "mbedtls"; then
[have_crypto_aead_modes="no"; break]
)
 
+   have_export_keying_material="yes"
+   AC_CHECK_FUNCS(
+   [mbedtls_ssl_conf_export_keys_ext_cb],
+   ,
+   [have_export_keying_material="no"; break]
+   )
+
CFLAGS="${saved_CFLAGS}"
LIBS="${saved_LIBS}"
AC_DEFINE([ENABLE_CRYPTO_MBEDTLS], [1], [Use mbed TLS library])
@@ -1217,6 +1231,12 @@ test "${enable_strict_options}" = "yes" && 
AC_DEFINE([ENABLE_STRICT_OPTIONS_CHEC
 
 test "${enable_crypto_ofb_cfb}" = "yes" && AC_DEFINE([ENABLE_OFB_CFB_MODE], 
[1], [Enable OFB and CFB cipher modes])
 test "${have_crypto_aead_modes}" = "yes" && 
AC_DEFINE([HAVE_AEAD_CIPHER_MODES], [1], [Use crypto library])
+if test "${have_export_keying_material}" = "yes"; then
+   AC_DEFINE(
+   [HAVE_EXPORT_KEYING_MATERIAL], [1],
+   [Crypto library supports keying material exporter]
+   )
+fi
 OPTIONAL_CRYPTO_CFLAGS="${OPTIONAL_CRYPTO_CFLAGS} ${CRYPTO_CFLAGS}"
 OPTIONAL_CRYPTO_LIBS="${OPTIONAL_CRYPTO_LIBS} ${CRYPTO_LIBS}"
 
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index ce417df0..04207b61 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2931,7 +2931,7 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 to.comp_options = options->comp;
 #endif
 
-#ifdef HAVE_EKM
+#ifdef HAVE_EXPORT_KEYING_MATERIAL
 if (options->keying_material_exporter_label)
 {
 to.ekm_size = options->keying_material_exporter_length;
@@ -2947,7 +2947,7 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 {
 to.ekm_size = 0;
 }
-#endif /* HAVE_EKM */
+#endif /* HAVE_EXPORT_KEYING_MATERIAL */
 
 /* TLS handshake authentication (--tls-auth) */
 if (options->ce.tls_auth_file)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 173a1eea..c459b260 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -662,7 +662,7 @@ static const char usage_message[] =
 "  an explicit nsCertType designation t = 'client' | 
'server'.\n"
 "--x509-track x  : Save peer X509 attribute x in environment for use by\n"
 "  plugins and management interface.\n"
-#ifdef HAVE_EKM
+#ifdef HAVE_EXPORT_KEYING_MATERIAL
 "--keying-material-exporter label len : Save Exported Keying Material 
(RFC5705)\n"
 "  of len bytes (min. 16 bytes) using label in environment 
for use by plugins.\n"
 #endif
@@ -8506,7 +8506,7 @@ add_option(struct options *options,
 options->use_peer_id = true;
 options->peer_id = atoi(p[1]);
 }
-#ifdef HAVE_EKM
+#ifdef HAVE_EXPORT_KEYING_MATERIAL
 else if (streq(p[0], "keying-material-exporter") && p[1] && p[2])
 {
 int ekm_length = positive_atoi(p[2]);
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index 3c6b1965..2f1f6faf 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -640,7 +640,7 @@ struct options
 bool use_peer_id;
 uint32_t peer_id;
 
-#ifdef HAVE_EKM
+#ifdef HAVE_EXPORT_KEYING_MATERIAL
 /* Keying Material Exporters [RFC 5705] */
 const char *keying_

Re: [Openvpn-devel] [PATCH 1/4] Only announce IV_NCP=2 when we are willing to support these ciphers

2020-01-06 Thread Steffan Karger
Hi,

Finally found some time to start looking at this patch set.

On 17-11-2019 19:12, Arne Schwabe wrote:
> We currently always announce IV_NCP=2 when we support these ciphers even
> when we do not accept them. This lead to a server pushing a AES-GCM-128
> cipher to clients and the client then rejecting it.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  doc/openvpn.8| 2 ++
>  src/openvpn/init.c   | 4 
>  src/openvpn/openvpn.h| 1 +
>  src/openvpn/ssl.c| 4 +++-
>  src/openvpn/ssl_common.h | 1 +
>  5 files changed, 11 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index 457c2667..ae24b6c0 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -4392,6 +4392,8 @@ NCP server (v2.4+) with "\-\-cipher BF\-CBC" and 
> "\-\-ncp\-ciphers
>  AES\-256\-GCM:AES\-256\-CBC" set can either specify "\-\-cipher BF\-CBC" or
>  "\-\-cipher AES\-256\-CBC" and both will work.
>  
> +Note, for using NCP with a OpenVPN 2.4 server this list must include
> +the AES\-256\-GCM and AES\-128\-GCM ciphers.
>  .\"*
>  .TP
>  .B \-\-ncp\-disable
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 0bdb0a9c..8f142311 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -623,6 +623,7 @@ save_ncp_options(struct context *c)
>  c->c1.ciphername = c->options.ciphername;
>  c->c1.authname = c->options.authname;
>  c->c1.keysize = c->options.keysize;
> +c->c1.ncp_ciphers = c->options.ncp_ciphers;
>  }
>  
>  /* Restores NCP-negotiable options to original values */
> @@ -632,6 +633,7 @@ restore_ncp_options(struct context *c)
>  c->options.ciphername = c->c1.ciphername;
>  c->options.authname = c->c1.authname;
>  c->options.keysize = c->c1.keysize;
> +c->options.ncp_ciphers = c->c1.ncp_ciphers;
>  }

options->ncp_ciphers itself is not negotiable, and thus does not need
restoring, I would think.

>  void
> @@ -2827,6 +2829,7 @@ do_init_crypto_tls(struct context *c, const unsigned 
> int flags)
>  to.tcp_mode = link_socket_proto_connection_oriented(options->ce.proto);
>  to.config_ciphername = c->c1.ciphername;
>  to.config_authname = c->c1.authname;
> +to.config_ncp_ciphers = c->c1.ncp_ciphers;
>  to.ncp_enabled = options->ncp_enabled;
>  to.transition_window = options->transition_window;
>  to.handshake_window = options->handshake_window;
> @@ -4532,6 +4535,7 @@ inherit_context_child(struct context *dest,
>  dest->c1.ciphername = src->c1.ciphername;
>  dest->c1.authname = src->c1.authname;
>  dest->c1.keysize = src->c1.keysize;
> +dest->c1.ncp_ciphers = src->c1.ncp_ciphers;
>  
>  /* inherit auth-token */
>  dest->c1.ks.auth_token_key = src->c1.ks.auth_token_key;
> diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
> index 900db7e1..9e46ad6c 100644
> --- a/src/openvpn/openvpn.h
> +++ b/src/openvpn/openvpn.h
> @@ -209,6 +209,7 @@ struct context_1
>  
>  const char *ciphername; /**< Data channel cipher from config file */
>  const char *authname;   /**< Data channel auth from config file */
> +const char *ncp_ciphers;/**< NCP Ciphers */
>  int keysize;/**< Data channel keysize from config file */
>  #endif
>  };
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 4455ebb8..6ca5c79a 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2322,7 +2322,9 @@ push_peer_info(struct buffer *buf, struct tls_session 
> *session)
>  
>  /* support for Negotiable Crypto Parameters */
>  if (session->opt->ncp_enabled
> -&& (session->opt->mode == MODE_SERVER || session->opt->pull))
> +&& (session->opt->mode == MODE_SERVER || session->opt->pull)
> +&& tls_item_in_cipher_list("AES-128-GCM", 
> session->opt->config_ncp_ciphers)
> +&& tls_item_in_cipher_list("AES-256-GCM", 
> session->opt->config_ncp_ciphers))
>  {
>  buf_printf(, "IV_NCP=2\n");
>  }
> diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
> index 8dd08862..fb82f610 100644
> --- a/src/openvpn/ssl_common.h
> +++ b/src/openvpn/ssl_common.h
> @@ -290,6 +290,7 @@ struct tls_options
>  
>  const char *config_ciphername;
>  const char *config_authname;
> +const char *config_ncp_ciphers;
>  bool ncp_enabled;
>  
>  bool tls_crypt_v2;
> 

Otherwise this makes sense and looks good.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v6 4/7] wintun: ring buffers based I/O

2019-12-15 Thread Steffan Karger
Hi Lev,

Thanks for the update. Even with the latest added fixes and sanity
checks, the resulting code is now 30 lines shorter *and* more readable.

Some last questions / comments inline:

On 13-12-2019 20:19, Lev Stipakov wrote:
> @@ -2099,6 +2115,13 @@ io_wait_dowork(struct context *c, const unsigned int 
> flags)
>  tuntap |= EVENT_READ;
>  }
>  
> +#ifdef _WIN32
> +if (tuntap_is_wintun(c->c1.tuntap))
> +{
> +tuntap = EVENT_READ;
> +}
> +#endif

Now that the code is refactored, it is clear that for the tuntap case
the code will ignore any of the earlier set flags. Can you maybe add a
comment explaining why the other flags are being ignored?

> +/* there is a data in wintun ring buffer, read it immediately */

Grammar nit: "there is data" (remove 'a').

Otherwise, as far as stare-at-code goes, I'm fine with this patch now. I
haven't tested it, nor have I reviewed Windows-specific interaction. So
this needs at least one other review from someone able to review those
parts.

Regarding the integration into OpenVPN:

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] fix clang warning about missing braces

2019-11-28 Thread Steffan Karger
On 28-11-2019 09:06, Lev Stipakov wrote:
> A struct with subobjects should be initialized
> with double braces.

This is not true. {0} is a valid initializer for structs in C. Both
clang and gcc used to have a bug where they incorrectly warned about
this. GCC fixed this a while ago[0]. I thought clang had fixed it too
recently, but apparently not?

-Steffan

[0] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53119


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] mbedtls: add RFC 5705 keying material exporter support

2019-11-10 Thread Steffan Karger
Since mbed TLS 2.18, mbed TLS can also implement RFC 5705. As a first
step towards using the keying material exporter as a method to generate
key material for the data channel, implement the
--keying-material-exporter function we already have for OpenSSL also for
mbed TLS builds.

Implementing RFC 5705 for mbed TLS is a bit more cumbersome, because the
library itself only provides a callback that is called during connection
setup, which enables us to implement RFC 5705 ourselves. To protect
ourselves against mistakes, we immediately perform the required key
derivation to generate the exporterd keying material, and only cache the
derived key material until we can actually export it to the environment
(similar to the OpenSSL builds).

To test this, I found it easiest to temporarily move the call to
key_state_export_keying_material outside the if statement, and use a
script that runs after connection setup (e.g. --ipchange) that prints
the environment. E.g.

  #!/bin/sh
  env | sort

This should show the same value for the exported_keying_material env
variable for both mbed TLS and OpenSSL builds. Of course you can also
use the code as-is, and write a plugin to verify the same thing.

Signed-off-by: Steffan Karger 
---
 src/openvpn/init.c|  4 +--
 src/openvpn/options.c |  4 +--
 src/openvpn/options.h |  2 +-
 src/openvpn/ssl_mbedtls.c | 64 ++-
 src/openvpn/ssl_mbedtls.h |  5 +++
 src/openvpn/ssl_openssl.c |  4 ++-
 src/openvpn/syshead.h | 14 -
 7 files changed, 89 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 0bdb0a9c..1ed6ae11 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2931,7 +2931,7 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 to.comp_options = options->comp;
 #endif
 
-#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x10001000
+#ifdef HAVE_EKM
 if (options->keying_material_exporter_label)
 {
 to.ekm_size = options->keying_material_exporter_length;
@@ -2947,7 +2947,7 @@ do_init_crypto_tls(struct context *c, const unsigned int 
flags)
 {
 to.ekm_size = 0;
 }
-#endif
+#endif /* HAVE_EKM */
 
 /* TLS handshake authentication (--tls-auth) */
 if (options->ce.tls_auth_file)
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index c282b582..98d94b86 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -661,7 +661,7 @@ static const char usage_message[] =
 "  an explicit nsCertType designation t = 'client' | 
'server'.\n"
 "--x509-track x  : Save peer X509 attribute x in environment for use by\n"
 "  plugins and management interface.\n"
-#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x10001000
+#ifdef HAVE_EKM
 "--keying-material-exporter label len : Save Exported Keying Material 
(RFC5705)\n"
 "  of len bytes (min. 16 bytes) using label in environment 
for use by plugins.\n"
 #endif
@@ -8468,7 +8468,7 @@ add_option(struct options *options,
 options->use_peer_id = true;
 options->peer_id = atoi(p[1]);
 }
-#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x10001000
+#ifdef HAVE_EKM
 else if (streq(p[0], "keying-material-exporter") && p[1] && p[2])
 {
 int ekm_length = positive_atoi(p[2]);
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index 7fd2c00f..7f3b3b20 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -640,7 +640,7 @@ struct options
 bool use_peer_id;
 uint32_t peer_id;
 
-#if defined(ENABLE_CRYPTO_OPENSSL) && OPENSSL_VERSION_NUMBER >= 0x10001000
+#ifdef HAVE_EKM
 /* Keying Material Exporters [RFC 5705] */
 const char *keying_material_exporter_label;
 int keying_material_exporter_length;
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index a4197cba..54f692e0 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -190,12 +190,62 @@ tls_ctx_initialised(struct tls_root_ctx *ctx)
 return ctx->initialised;
 }
 
+#ifdef HAVE_EKM
+int mbedtls_ssl_export_keys_cb(void *p_expkey, const unsigned char *ms,
+   const unsigned char *kb, size_t maclen,
+   size_t keylen, size_t ivlen,
+   const unsigned char client_random[32],
+   const unsigned char server_random[32],
+   mbedtls_tls_prf_types tls_prf_type)
+{
+struct tls_session *session = p_expkey;
+struct key_state_ssl *ks_ssl = >key[KS_PRIMARY].ks_ssl;
+unsigned char client_server_random[64];
+
+ks_ssl->exported_key_material = gc_malloc(session->opt->ekm_size,
+  t

[Openvpn-devel] [PATCH] Update sample configs to use modern cipher, remove static key examples

2019-11-09 Thread Steffan Karger
Since these are examples, people might use them as a basis for their own
configs. In the non-push/pull configs, we should specify a decent cipher.

Further, I don't think we should recommend anyone to still use a static key
configuration, so remove the static key config examples.

Signed-off-by: Steffan Karger 
---
 sample/sample-config-files/loopback-client|  1 +
 sample/sample-config-files/loopback-server|  1 +
 sample/sample-config-files/static-home.conf   | 75 ---
 sample/sample-config-files/static-office.conf | 72 --
 sample/sample-config-files/tls-home.conf  | 12 +--
 sample/sample-config-files/tls-office.conf|  3 +
 6 files changed, 11 insertions(+), 153 deletions(-)
 delete mode 100644 sample/sample-config-files/static-home.conf
 delete mode 100644 sample/sample-config-files/static-office.conf

diff --git a/sample/sample-config-files/loopback-client 
b/sample/sample-config-files/loopback-client
index 7117307d..1734aa8b 100644
--- a/sample/sample-config-files/loopback-client
+++ b/sample/sample-config-files/loopback-client
@@ -22,5 +22,6 @@ ca sample-keys/ca.crt
 key sample-keys/client.key
 cert sample-keys/client.crt
 tls-auth sample-keys/ta.key 1
+cipher AES-256-GCM
 ping 1
 inactive 120 1000
diff --git a/sample/sample-config-files/loopback-server 
b/sample/sample-config-files/loopback-server
index 8e1f39cd..58daeb56 100644
--- a/sample/sample-config-files/loopback-server
+++ b/sample/sample-config-files/loopback-server
@@ -22,5 +22,6 @@ ca sample-keys/ca.crt
 key sample-keys/server.key
 cert sample-keys/server.crt
 tls-auth sample-keys/ta.key 0
+cipher AES-256-GCM
 ping 1
 inactive 120 1000
diff --git a/sample/sample-config-files/static-home.conf 
b/sample/sample-config-files/static-home.conf
deleted file mode 100644
index ed0c6726..
--- a/sample/sample-config-files/static-home.conf
+++ /dev/null
@@ -1,75 +0,0 @@
-#
-# Sample OpenVPN configuration file for
-# home using a pre-shared static key.
-#
-# '#' or ';' may be used to delimit comments.
-
-# Use a dynamic tun device.
-# For Linux 2.2 or non-Linux OSes,
-# you may want to use an explicit
-# unit number such as "tun1".
-# OpenVPN also supports virtual
-# ethernet "tap" devices.
-dev tun
-
-# Our OpenVPN peer is the office gateway.
-remote 1.2.3.4
-
-# 10.1.0.2 is our local VPN endpoint (home).
-# 10.1.0.1 is our remote VPN endpoint (office).
-ifconfig 10.1.0.2 10.1.0.1
-
-# Our up script will establish routes
-# once the VPN is alive.
-up ./home.up
-
-# Our pre-shared static key
-secret static.key
-
-# Cipher to use
-cipher AES-256-CBC
-
-# OpenVPN 2.0 uses UDP port 1194 by default
-# (official port assignment by iana.org 11/04).
-# OpenVPN 1.x uses UDP port 5000 by default.
-# Each OpenVPN tunnel must use
-# a different port number.
-# lport or rport can be used
-# to denote different ports
-# for local and remote.
-; port 1194
-
-# Downgrade UID and GID to
-# "nobody" after initialization
-# for extra security.
-; user nobody
-; group nobody
-
-# If you built OpenVPN with
-# LZO compression, uncomment
-# out the following line.
-; comp-lzo
-
-# Send a UDP ping to remote once
-# every 15 seconds to keep
-# stateful firewall connection
-# alive.  Uncomment this
-# out if you are using a stateful
-# firewall.
-; ping 15
-
-# Uncomment this section for a more reliable detection when a system
-# loses its connection.  For example, dial-ups or laptops that
-# travel to other locations.
-; ping 15
-; ping-restart 45
-; ping-timer-rem
-; persist-tun
-; persist-key
-
-# Verbosity level.
-# 0 -- quiet except for fatal errors.
-# 1 -- mostly quiet, but display non-fatal network errors.
-# 3 -- medium output, good for normal operation.
-# 9 -- verbose, good for troubleshooting
-verb 3
diff --git a/sample/sample-config-files/static-office.conf 
b/sample/sample-config-files/static-office.conf
deleted file mode 100644
index 609ddd02..
--- a/sample/sample-config-files/static-office.conf
+++ /dev/null
@@ -1,72 +0,0 @@
-#
-# Sample OpenVPN configuration file for
-# office using a pre-shared static key.
-#
-# '#' or ';' may be used to delimit comments.
-
-# Use a dynamic tun device.
-# For Linux 2.2 or non-Linux OSes,
-# you may want to use an explicit
-# unit number such as "tun1".
-# OpenVPN also supports virtual
-# ethernet "tap" devices.
-dev tun
-
-# 10.1.0.1 is our local VPN endpoint (office).
-# 10.1.0.2 is our remote VPN endpoint (home).
-ifconfig 10.1.0.1 10.1.0.2
-
-# Our up script will establish routes
-# once the VPN is alive.
-up ./office.up
-
-# Our pre-shared static key
-secret static.key
-
-# Cipher to use
-cipher AES-256-CBC
-
-# OpenVPN 2.0 uses UDP port 1194 by default
-# (official port assignment by iana.org 11/04).
-# OpenVPN 1.x uses UDP port 5000 by default.
-# Each OpenVPN tunnel must use
-# a different port number.
-# lport or rport can be used
-# to denote different ports
-# for local and remote.
-; port 11

Re: [Openvpn-devel] [PATCH v3] Make compression asymmetric by default and add warnings

2019-11-09 Thread Steffan Karger
Hi,

Feature-ack, and overall looks good. But some nits to tackle.

On 24-10-2018 12:06, Arne Schwabe wrote:
> This commit introduces the allow-compression option that allow
> changing the new default to the previous default or to a stricter
> version.
> 
> Warning are not generated in the post option check
> (options_postprocess_mutate) since these warnings should also be shown
> on pushed options.
> 
> Patch V2: fix spelling and grammer (thanks tincantech), also fix
>uncompressiable to incompressible in three other instances in the
>source code
> 
> Patch V3: fix overlong lines. Do not allow compression to be pushed
> ---
>  doc/openvpn.8  |  44 ++
>  src/openvpn/comp-lz4.c |   3 +-
>  src/openvpn/comp.c |   2 +-
>  src/openvpn/comp.h |  16 +--
>  src/openvpn/lzo.c  |   2 +-
>  src/openvpn/mtu.h  |   2 +-
>  src/openvpn/options.c  | 101 -
>  7 files changed, 143 insertions(+), 27 deletions(-)
> 
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index d40dcf43..ac923f51 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -2545,26 +2545,54 @@ Enable a compression algorithm.
>  
>  The
>  .B algorithm
> -parameter may be "lzo", "lz4", or empty.  LZO and LZ4
> -are different compression algorithms, with LZ4 generally
> +parameter may be "lzo", "lz4", "lz4\-v2", "stub", "stub\-v2" or empty.
> +LZO and LZ4 are different compression algorithms, with LZ4 generally
>  offering the best performance with least CPU usage.
>  For backwards compatibility with OpenVPN versions before v2.4, use "lzo"
>  (which is identical to the older option "\-\-comp\-lzo yes").
>  
> +The "lz4\-v2" and "stub\-v2" variants implement a better framing that does 
> not add
> +overhead when packets cannot be compressed. All other variants always add 
> one extra
> +framing byte compared to no compression framing.
> +
>  If the
>  .B algorithm
> -parameter is empty, compression will be turned off, but the packet
> -framing for compression will still be enabled, allowing a different
> -setting to be pushed later.
> +parameter is "stub", "stub\-v2", or empty, compression will be turned off, 
> but
> +the packet framing for compression will still be enabled, allowing a 
> different
> +setting to be pushed later. Additionally, "stub" and "stub\-v2" will disable
> +announcing lzo and lz4 compression support via "IV_" variables to the server.
> +
>  
>  .B Security Considerations
>  
>  Compression and encryption is a tricky combination.  If an attacker knows or 
> is
>  able to control (parts of) the plaintext of packets that contain secrets, the
>  attacker might be able to extract the secret if compression is enabled.  See
> -e.g. the CRIME and BREACH attacks on TLS which also leverage compression to
> -break encryption.  If you are not entirely sure that the above does not apply
> -to your traffic, you are advised to *not* enable compression.
> +e.g. the CRIME and BREACH attacks on TLS and VORACLE on VPNs which also 
> leverage
> +compression to break encryption.  If you are not entirely sure that the 
> above does
> +not apply to your traffic, you are advised to *not* enable compression.
> +
> +.\"*
> +.TP
> +.B \-\-allow\-compression [mode]
> +As described in
> +\.B \-\-compress
> +option, compression is potentially dangerous option. This option allows
> +controlling the behaviour of OpenVPN when compression is used and allowed.
> +.B mode
> +may be "yes", "no", or "asym" (default).
> +
> +With allow\-compression set to "no", OpenVPN will refuse any non stub
> +compression. With "yes" OpenVPN will send and receive compressed packets.
> +With "asym", the default, OpenVPN will only decompress (downlink) packets but
> +not compress (uplink) packets. This also allows migrating to disable 
> compression
> +when changing both server and client configurations to remove compression at 
> the
> +same time is not a feasible option.
> +
> +The default of asym has been chosen to maximise compatibility with existing
> +configuration while at the same time phasing out compression in existing
> +deployment by disabling compression on the uplink, effectively completely 
> disabling
> +compression if both client and server are upgraded.
>  
>  .\"*
>  .TP
> diff --git a/src/openvpn/comp-lz4.c b/src/openvpn/comp-lz4.c
> index f52fdbfb..fa23e5a5 100644
> --- a/src/openvpn/comp-lz4.c
> +++ b/src/openvpn/comp-lz4.c
> @@ -70,8 +70,9 @@ do_lz4_compress(struct buffer *buf,
>  {
>  /*
>   * In order to attempt compression, length must be at least 
> COMPRESS_THRESHOLD.
> + * and asymmetric compression must be disabled
>   */
> -if (buf->len >= COMPRESS_THRESHOLD)
> +if (buf->len >= COMPRESS_THRESHOLD && (compctx->flags & COMP_F_NO_ASYM))
>  {
>  const size_t ps = PAYLOAD_SIZE(frame);
>  int zlen_max = ps + 

Re: [Openvpn-devel] [PATCH v6 1/2] Make tls_version_max return the actual maximum version

2019-11-09 Thread Steffan Karger
Hi,

On 09-11-2019 13:03, Arne Schwabe wrote:
> Before OpenSSL 1.1.1 there could be no mismatch between
> compiled and actual OpenSSL version. With OpenSSL 1.1.1 we need
> runtime detection to detect the actual best TLS version supported.
> 
> Allowing this runtime detection also allows removing some of the
> TLS 1.3/OpenSSL 1.1.1 #ifdefs
> 
> Without this patch tls-min-version 1.3 or-highest will actually
> downgrade to TLS 1.3 in the "compiled with 1.1.0 and linked against
> 1.1.1" scenario.
> 
> Signed-off-by: Arne Schwabe 
> ---
>  src/openvpn/ssl.c | 11 +--
>  src/openvpn/ssl_openssl.c | 31 ---
>  2 files changed, 33 insertions(+), 9 deletions(-)
> 
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 4455ebb8..e708fc93 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -4194,12 +4194,11 @@ show_available_tls_ciphers(const char *cipher_list,
>  {
>  printf("Available TLS Ciphers, listed in order of preference:\n");
>  
> -#if (ENABLE_CRYPTO_OPENSSL && OPENSSL_VERSION_NUMBER >= 0x1010100fL)
> -printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
> -show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile, 
> true);
> -#else
> -(void) cipher_list_tls13;  /* Avoid unused warning */
> -#endif
> +if (tls_version_max() >= TLS_VER_1_3)
> +{
> +printf("\nFor TLS 1.3 and newer (--tls-ciphersuites):\n\n");
> +show_available_tls_ciphers_list(cipher_list_tls13, tls_cert_profile, 
> true);
> +}
>  
>  printf("\nFor TLS 1.2 and older (--tls-cipher):\n\n");
>  show_available_tls_ciphers_list(cipher_list, tls_cert_profile, false);
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 07916c3c..e07d6e74 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -215,7 +215,23 @@ int
>  tls_version_max(void)
>  {
>  #if defined(TLS1_3_VERSION)
> +/* If this is defined we can safely assume TLS 1.3 support */
>  return TLS_VER_1_3;

This clause is no longer needed, right?

> +#elif OPENSSL_VERSION_NUMBER >= 0x1010L
> +/*
> + * The library we are *linked* against is OpenSSL 1.1.1

s/is/might be/ ?

> + * and therefore supports TLS 1.3. This needs to be checked at runtime
> + * since we can be compiled against 1.1.0 and then the library can be
> + * upgraded to 1.1.1
> + */
> +if (OpenSSL_version_num() >= 0x1010100fL)
> +{
> +return TLS_VER_1_3;
> +}
> +else
> +{
> +return TLS_VER_1_2;
> +}
>  #elif defined(TLS1_2_VERSION) || defined(SSL_OP_NO_TLSv1_2)
>  return TLS_VER_1_2;
>  #elif defined(TLS1_1_VERSION) || defined(SSL_OP_NO_TLSv1_1)
> @@ -241,12 +257,20 @@ openssl_tls_version(int ver)
>  {
>  return TLS1_2_VERSION;
>  }
> -#if defined(TLS1_3_VERSION)
>  else if (ver == TLS_VER_1_3)
>  {
> +/*
> + * Supporting the library upgraded to TLS1.3 without recompile
> + * is enough to support here with a simple constant that the same
> + * as in the TLS 1.3, so spec it is very unlikely that OpenSSL
> + * will change this constant
> + */
> +#ifndef TLS1_3_VERSION
> +return 0x0304;
> +#else

Why not do this outside the function as

  #ifndef TLS1_3_VERSION
  #define TLS1_3_VERSION 0x0304
  #endif

>  return TLS1_3_VERSION;
> -}
>  #endif
> +}
>  return 0;
>  }
>  
> @@ -2015,7 +2039,8 @@ show_available_tls_ciphers_list(const char *cipher_list,
>  #if defined(TLS1_3_VERSION)
>  if (tls13)
>  {
> -SSL_CTX_set_min_proto_version(tls_ctx.ctx, TLS1_3_VERSION);
> +SSL_CTX_set_min_proto_version(tls_ctx.ctx,
> +  openssl_tls_version(TLS_VER_1_3));
>  tls_ctx_restrict_ciphers_tls13(_ctx, cipher_list);
>  }
>  else
> 

Otherwise looks good.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 4/7] wintun: ring buffers based I/O

2019-11-09 Thread Steffan Karger
Hi,

Some first-round review comments. I still need to fully grasp the event
mechanism intricacies for a real in-depth review.

As a general remark: could you try to stick to the 80 char line length
limit?

On 07-11-2019 18:45, Lev Stipakov wrote:
> From: Lev Stipakov 
> 
> Implemented according to Wintun documentation
> and reference client code.
> 
> Wintun uses ring buffers to communicate between
> kernel driver and user process. Client allocates
> send and receive ring buffers, creates events
> and passes it to kernel driver under LocalSystem
> privileges.
> 
> When data is available for read, wintun modifies
> "tail" pointer of send ring and signals via event.
> User process reads data from "head" to "tail" and
> updates "head" pointer.
> 
> When user process is ready to write, it writes
> to receive ring, updates "tail" pointer and signals
> to kernel via event.
> 
> In openvpn code we add send ring's event to event loop.
> Before performing io wait, we compare "head" and "tail"
> pointers of send ring and if they're different, we skip
> io wait and perform read.
> 
> This also adds ring buffers support to tcp and udp
> server code.
> 
> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpn/forward.c |  42 +++---
>  src/openvpn/forward.h |  47 +++-
>  src/openvpn/mtcp.c|  28 +++-
>  src/openvpn/mudp.c|  14 ++
>  src/openvpn/options.c |   4 +-
>  src/openvpn/syshead.h |   1 +
>  src/openvpn/tun.c |  45 +++
>  src/openvpn/tun.h | 121 
> +-
>  src/openvpn/win32.c   | 120 +
>  src/openvpn/win32.h   |  47 
>  10 files changed, 458 insertions(+), 11 deletions(-)
> 
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index 8451706..0be8b6d 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1256,12 +1256,30 @@ read_incoming_tun(struct context *c)
>  perf_push(PERF_READ_IN_TUN);
>  
>  c->c2.buf = c->c2.buffers->read_tun_buf;
> +
>  #ifdef _WIN32
> -read_tun_buffered(c->c1.tuntap, >c2.buf);
> +if (c->c1.tuntap->wintun)
> +{
> +read_wintun(c->c1.tuntap, >c2.buf);
> +if (c->c2.buf.len == -1)
> +{
> +register_signal(c, SIGHUP, "tun-abort");
> +c->persist.restart_sleep_seconds = 1;
> +msg(M_INFO, "Wintun read error, restarting");
> +perf_pop();
> +return;
> +}
> +}
> +else
> +{
> +read_tun_buffered(c->c1.tuntap, >c2.buf);
>  #else
> -ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> -ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> -c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf), 
> MAX_RW_SIZE_TUN(>c2.frame));
> +ASSERT(buf_init(>c2.buf, FRAME_HEADROOM(>c2.frame)));
> +ASSERT(buf_safe(>c2.buf, MAX_RW_SIZE_TUN(>c2.frame)));
> +c->c2.buf.len = read_tun(c->c1.tuntap, BPTR(>c2.buf), 
> MAX_RW_SIZE_TUN(>c2.frame));
> +#endif
> +#ifdef _WIN32
> +}
>  #endif

As Simon mentioned too, this code is getting more and more hard to read.
Can we maybe do this in some cleaner way? Maybe add some helper function(s)?

>  
>  #ifdef PACKET_TRUNCATION_CHECK
> @@ -2103,7 +2121,21 @@ io_wait_dowork(struct context *c, const unsigned int 
> flags)
>   * Configure event wait based on socket, tuntap flags.
>   */
>  socket_set(c->c2.link_socket, c->c2.event_set, socket, (void 
> *)_shift, NULL);
> -tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift, NULL);
> +
> +#ifdef _WIN32
> +if (c->c1.tuntap && c->c1.tuntap->wintun)
> +{
> +/* add ring buffer event */
> +struct rw_handle rw = {.read = c->c1.tuntap->send_tail_moved };
> +event_ctl(c->c2.event_set, , EVENT_READ, (void *)_shift);
> +}
> +else
> +{
> +#endif
> +tun_set(c->c1.tuntap, c->c2.event_set, tuntap, (void *)_shift, 
> NULL);
> +#ifdef _WIN32
> +}
> +#endif

As above :)

>  
>  #ifdef ENABLE_MANAGEMENT
>  if (management)
> diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
> index 48202c0..6096fa8 100644
> --- a/src/openvpn/forward.h
> +++ b/src/openvpn/forward.h
> @@ -375,6 +375,19 @@ p2p_iow_flags(const struct context *c)
>  {
>  flags |= IOW_TO_TUN;
>  }
> +#ifdef _WIN32
> +{
> +struct tuntap *tt = c->c1.tuntap;
> +if (tt && tt->wintun)
> +{
> +if (tt->send_ring->head == tt->send_ring->tail)
> +{
> +/* nothing to read from tun -> remove tun read flag set by 
> IOW_READ */
> +flags &= ~IOW_READ_TUN;
> +}
> +}
> +}
> +#endif

Looks like this should be a helper function (with a good name that helps
understand what this does).

>  return flags;
>  }
>  
> @@ -403,8 +416,38 @@ io_wait(struct context *c, const unsigned int flags)
>  }
>  else
>  {
> 

Re: [Openvpn-devel] [PATCH v3] wintun: add --windows-driver config option

2019-11-09 Thread Steffan Karger
opology coding
>   */
> @@ -5281,6 +5316,13 @@ add_option(struct options *options,
>  VERIFY_PERMISSION(OPT_P_GENERAL);
>  options->dev_type = p[1];
>  }
> +#ifdef _WIN32
> +else if (streq(p[0], "windows-driver") && p[1] && !p[2])
> +{
> +VERIFY_PERMISSION(OPT_P_GENERAL);
> +options->wintun = parse_windows_driver(p[1], M_FATAL);
> +}
> +#endif
>  else if (streq(p[0], "dev-node") && p[1] && !p[2])
>  {
>  VERIFY_PERMISSION(OPT_P_GENERAL);
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index ff7a5bb..0a24e5e 100644
> --- a/src/openvpn/options.h
> +++ b/src/openvpn/options.h
> @@ -632,6 +632,7 @@ struct options
>  bool show_net_up;
>  int route_method;
>  bool block_outside_dns;
> +bool wintun;
>  #endif
>  
>  bool use_peer_id;
> diff --git a/src/openvpn/tun.h b/src/openvpn/tun.h
> index 5a0a933..df935f6 100644
> --- a/src/openvpn/tun.h
> +++ b/src/openvpn/tun.h
> @@ -175,6 +175,7 @@ struct tuntap
>   * ~0 if undefined */
>  DWORD adapter_index;
>  
> +bool wintun; /* true if wintun is used instead of tap-windows6 */
>  int standby_iter;
>  #else  /* ifdef _WIN32 */
>  int fd; /* file descriptor for TUN/TAP dev */
> 

Thanks, this looks good to me now.

I don't have a working Windows test setup available, so only did
stare-at-code and verified that building with mingw still works for me.
So, as far as this goes without real testing:

Acked-by: Steffan Karger 

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2 2/7] wintun: add --windows-driver config option

2019-11-08 Thread Steffan Karger
Hi,

Thanks for looking into wintun support. Definitely feature-ack.

On 07-11-2019 18:45, Lev Stipakov wrote:
> From: Lev Stipakov 
> 
> This allows to specify which tun driver openvpn should use,
> tap-windows6 (default) or wintun.
> 
> Note than wintun support will be added in follow-up patches.
> 
> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpn/init.c|  7 +++
>  src/openvpn/options.c | 37 +
>  src/openvpn/options.h |  1 +
>  src/openvpn/tun.h |  1 +
>  4 files changed, 46 insertions(+)

Should there not be a manpage entry in this commit too?

> 
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index ae7bd63..c6d4953 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -1733,6 +1733,10 @@ do_init_tun(struct context *c)
>  c->c2.es,
>  >net_ctx);
>  
> +#ifdef _WIN32
> +c->c1.tuntap->wintun = c->options.wintun;
> +#endif
> +
>  init_tun_post(c->c1.tuntap,
>>c2.frame,
>>options.tuntap_options);
> @@ -1775,6 +1779,9 @@ do_open_tun(struct context *c)
>  /* store (hide) interactive service handle in tuntap_options */
>  c->c1.tuntap->options.msg_channel = c->options.msg_channel;
>  msg(D_ROUTE, "interactive service msg_channel=%u", (unsigned int) 
> c->options.msg_channel);
> +
> +c->c1.tuntap->wintun = c->options.wintun;
> +

Why do we have to set c->c2.tuntap->wintun in both do_init_tun and
do_open_tun? Should one of them not suffice?

>  #endif
>  
>  /* allocate route list structure */
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index 1838a69..5c5033e 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -747,6 +747,9 @@ static const char usage_message[] =
>  "   optional parameter controls the initial state of 
> ex.\n"
>  "--show-net-up   : Show " PACKAGE_NAME "'s view of routing table and net 
> adapter list\n"
>  "  after TAP adapter is up and routes have been added.\n"
> +"--windows-driver   : Which tun driver to use?\n"
> +" tap-windows6 (default)\n"
> +" wintun\n"
>  #ifdef _WIN32

Should this --windows-driver option not be inside the #ifdef _WIN32 ?

>  "--block-outside-dns   : Block DNS on other network adapters to prevent 
> DNS leaks\n"
>  #endif
> @@ -851,6 +854,7 @@ init_options(struct options *o, const bool init_gc)
>  o->tuntap_options.dhcp_masq_offset = 0; /* use network address as 
> internal DHCP server address */
>  o->route_method = ROUTE_METHOD_ADAPTIVE;
>  o->block_outside_dns = false;
> +o->wintun = false;
>  #endif
>  o->vlan_accept = VLAN_ONLY_UNTAGGED_OR_PRIORITY;
>  o->vlan_pvid = 1;
> @@ -2994,6 +2998,12 @@ options_postprocess_mutate_invariant(struct options 
> *options)
>  options->ifconfig_noexec = false;
>  }
>  
> +/* for wintun kernel doesn't send DHCP requests, so use ipapi to set IP 
> address and netmask */
> +if (options->wintun)
> +{
> +options->tuntap_options.ip_win32_type = IPW32_SET_IPAPI;
> +}
> +
>  remap_redirect_gateway_flags(options);
>  #endif
>  
> @@ -4039,6 +4049,26 @@ foreign_option(struct options *o, char *argv[], int 
> len, struct env_set *es)
>  }
>  }
>  
> +#ifdef _WIN32
> +bool
> +parse_windows_driver(const char *str, const int msglevel)

I think this should be a static function. Also a short (doxygen) comment
explaining what the return value means would be nice.

> +{
> +if (streq(str, "tap-windows6"))
> +{
> +return false;
> +}
> +else if (streq(str, "wintun"))
> +{
> +return true;
> +}
> +else
> +{
> +msg(msglevel, "--windows-driver must be tap-windows6 or wintun");
> +return false;
> +}
> +}
> +#endif
> +
>  /*
>   * parse/print topology coding
>   */
> @@ -5281,6 +5311,13 @@ add_option(struct options *options,
>  VERIFY_PERMISSION(OPT_P_GENERAL);
>  options->dev_type = p[1];
>  }
> +#ifdef _WIN32
> +else if (streq(p[0], "windows-driver") && p[1] && !p[2])
> +{
> +VERIFY_PERMISSION(OPT_P_GENERAL);
> +options->wintun = parse_windows_driver(p[1], M_FATAL);
> +}
> +#endif
>  else if (streq(p[0], "dev-node") && p[1] && !p[2])
>  {
>  VERIFY_PERMISSION(OPT_P_GENERAL);
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index ff7a5bb..0a24e5e 100644
> --- a/src/openvpn/options.h
> +++ b/src/openvpn/options.h
> @@ -632,6 +632,7 @@ struct options
>  bool show_net_up;
>  int route_method;
>  bool block_outside_dns;
> +bool wintun;

Did you consider using an enum instead? I think it would make the code
easier to read. E.g. with

typedef enum { WINDRV_TAP6, WINDRV_WINTUN } windrv_t;

in tun.h or so, we'd get

options->windrv = WINDRV_TAP6

instead of

options->wintun = false.

>  

Re: [Openvpn-devel] [PATCH 1/7] Visual Studio: upgrade project files to VS2019

2019-09-20 Thread Steffan Karger
Hi,

On Fri, Sep 20, 2019, 15:47 Lev Stipakov  wrote:

> Wintun driver is now signed for Windows 10,
>
> https://staging.openvpn.net/openvpn2/wintun-0.6-signed.zip
>
> So if you want to try out super fast openvpn2, no need to meddle anymore
> with test mode / disabling signature checks.
>

Out of curiosity: does the (signed) driver from wintun.net not work? Of so,
why?

-Steffan

>
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] t_net.sh: wait for NO-CARRIER bit to settle before starting test

2019-09-19 Thread Steffan Karger
Hi,

On 19-09-19 09:28, Antonio Quartulli wrote:
> Interfaces of type tun are marked as NO-CARRIER when no process is
> attached to them. However, this bit gets set with some delay after
> creation.
> 
> For this reason, it is better to wait for the bit to settle before
> starting any test, otherwise any timing influence on the test may lead
> to inconsistencies due to the NO-CARRIER bit randomly being or not in
> the snapshot output taken by t_net.sh.
> 
> This patch add a 'sleep 1' command right after creation of the
> interface, to give the NO-CARRIER bit a chance to settle.
> 
> This issue has been witnessed on a buildbot that is
> apparently slowler than average to run the unit tests.
> 
> Signed-off-by: Antonio Quartulli 
> ---
>  tests/t_net.sh | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/tests/t_net.sh b/tests/t_net.sh
> index 18799d12..97e947ab 100755
> --- a/tests/t_net.sh
> +++ b/tests/t_net.sh
> @@ -34,6 +34,13 @@ reload_dummy()
>  {
>  $RUN_SUDO $openvpn --dev $IFACE --dev-type tun --rmtun >/dev/null
>  $RUN_SUDO $openvpn --dev $IFACE --dev-type tun --mktun >/dev/null
> +
> +# it seems that tun devices will settle on NO-CARRIER while not 
> connected to
> +# any process, but this won't happen immediately. To avoid having the
> +# NO-CARRIER bit appear in the middle of the tests - which would 
> compromise
> +# the results - let's wait 1 sec here for it to settle.
> +sleep 1
> +
>  if [ $? -ne 0 ]; then
>  echo "can't create interface $IFACE"
>  exit 1
> 

This return value check now checks that sleep succeeded instead of the
openvpn --mktun command. I don't think that is what you intended.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Adding support for wolfSSL backend

2019-08-24 Thread Steffan Karger
Hi,

On 24-08-19 21:40, Gert Doering wrote:
> On Sat, Aug 24, 2019 at 06:04:21PM +0200, Arne Schwabe wrote:
>> I want to give you an honest opionion of mine to merging WolfSSL in
>> OpenVPN. Please note, that this is my personal opinion and not to be
>> confused to be an official OpenVPN community project or OpenVPN Inc
>> position.
> 
> Arne summarized things quite well.  New and large additions need to
> balance "what *our* users want/need", "what the core team finds 
> interesting enough to spend time on" and "how expensive in terms of 
> maintainer lifetime will it be to maintain that stuff".
> 
> Since we're currently short on contributors that can review crypto
> related code changes, and we do not have anyone in the team today
> that can review WolfSSL interface code at all, this isn't likely 
> going to happen in the near future.

Just like Arne and Gert, I believe we're currently not in the position
to take on the maintenance burden of adding another crypto backend. I'd
rather spend our time on fixing bugs and improving openvpn performance
(the crypto libs are not the bottleneck).

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/1] Start TLS after connection established without waiting.

2019-08-21 Thread Steffan Karger
Hi,

On 24-07-19 13:41, Daniel Kaldor wrote:
> There is a ~1s delay between establishing connection with remote
> server and starting TLS handshake.
> This change removes delay and improves connection time.

While this sounds like something we'd like to have (i.e, feature-ACK),
this doesn't really explain why this change resolves the issue, nor why
this is the right fix.

Can you please clarify what it changes in the connection sequence and
why you believe this is the right way to get rid of the 1s second delay?

Also, how did you test this patch? (TCP, UDP, with or without
management, on fast/slow links, even running in production maybe? Etc.)

Thanks,
-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/2] Fix check if iface name is set

2019-08-13 Thread Steffan Karger
Hi,

On 13-08-19 23:31, Antonio Quartulli wrote:
> On 13/08/2019 23:26, David Sommerseth wrote:
>> wouldn't it be better to
>> do 'if (rgi6->iface[0])' instead?  Since the buffer should be NULL terminated
>> and has to be NULL terminted for strlen() to function anyhow.  But the
>> compiled code would be a bit more efficient (even though, this isn't
>> necessarily a performance critical code section).
> 
> In my opinion strlen() is more readable for the casual developer
> checking this code. Behind iface[0] we may hide other ambiguous
> assumptions (even though this is not the case here, but we won't
> remember in some months from now).

Antionio's answer is of course the real reason to use strlen(), but you
nerd-sniped me by saying "compiled code would be a bit more efficient".
As you said, that wouldn't matter here, but still: compilers nowadays do
optimize calls to strlen, memset, memcpy, etc.

The following code

#include 

int test(const char *buf) {
return (strlen(buf) > 0);
}

for example compiles with -O3 on my GCC 8.3 to

 :
   0:   31 c0   xor%eax,%eax
   2:   80 3f 00cmpb   $0x0,(%rdi)
   5:   0f 95 c0setne  %al
   8:   c3  retq

which indeed just compares the first byte of the buffer against zero.

So, unless there are important performance constraints, let's optimize
code for readability, rather than performance :)

FM [0]

-Steffan

[0] https://xkcd.com/356/


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH for 2.4] Correct the return value of cryptoapi RSA signature callbacks

2019-07-28 Thread Steffan Karger



On 27-07-19 05:12, selva.n...@gmail.com wrote:
> From: Selva Nair 
> 
> Fixes the wrong check on siglen instead of *siglen for
> signing failures.
> 
> Bug reported by: lilulo 
> 
> Signed-off-by: Selva Nair 
> ---
>  src/openvpn/cryptoapi.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/cryptoapi.c b/src/openvpn/cryptoapi.c
> index 720fce09..35a9ebc4 100644
> --- a/src/openvpn/cryptoapi.c
> +++ b/src/openvpn/cryptoapi.c
> @@ -393,7 +393,7 @@ rsa_sign_CNG(int type, const unsigned char *m, unsigned 
> int m_len,
>  }
>  
>  *siglen = priv_enc_CNG(cd, alg, m, (int)m_len, sig, RSA_size(rsa), 
> padding);
> -return (siglen == 0) ? 0 : 1;
> +    return (*siglen == 0) ? 0 : 1;
>  }
>  
>  /* decrypt */
> 

Acked-by: Steffan Karger 


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Correct the return value of cryptoapi RSA signature callbacks

2019-07-28 Thread Steffan Karger



On 26-07-19 22:39, selva.n...@gmail.com wrote:
> From: Selva Nair 
> 
> Fixes the wrong check on siglen instead of *siglen for
> signing failures.
> 
> Bug reported by: lilulo 
> 
> Signed-off-by: Selva Nair 
> ---
> 
> 2.4 will need a separate patch
> 
>  src/openvpn/cryptoapi.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/openvpn/cryptoapi.c b/src/openvpn/cryptoapi.c
> index 0c11712e..2f2eee77 100644
> --- a/src/openvpn/cryptoapi.c
> +++ b/src/openvpn/cryptoapi.c
> @@ -499,7 +499,7 @@ rsa_sign_CNG(int type, const unsigned char *m, unsigned 
> int m_len,
>  *siglen = priv_enc_CNG(cd, alg, m, (int)m_len, sig, RSA_size(rsa),
> cng_padding_type(padding), 0);
>  
> -return (siglen == 0) ? 0 : 1;
> +return (*siglen == 0) ? 0 : 1;
>  }
>  
>  /* decrypt */
> @@ -973,7 +973,7 @@ pkey_rsa_sign(EVP_PKEY_CTX *ctx, unsigned char *sig, 
> size_t *siglen,
>  *siglen = priv_enc_CNG(cd, alg, tbs, (int)tbslen, sig, *siglen,
> cng_padding_type(padding), (DWORD)saltlen);
>  
> -return (siglen == 0) ? 0 : 1;
> +return (*siglen == 0) ? 0 : 1;
>  }
>  
>  #endif /* OPENSSL_VERSION >= 1.1.0 */
> 

Acked-by: Steffan Karger 


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] openssl: Fix compilation without deprecated OpenSSL 1.1 APIs

2019-07-25 Thread Steffan Karger
}
>  
> -void
> -cipher_ctx_cleanup(EVP_CIPHER_CTX *ctx)
> -{
> -EVP_CIPHER_CTX_cleanup(ctx);
> -}
> -
>  int
>  cipher_ctx_iv_length(const EVP_CIPHER_CTX *ctx)
>  {
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index a4072b9a..4ac8f24d 100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -89,6 +89,18 @@ EVP_MD_CTX_new(void)
>  }
>  #endif
>  
> +#if !defined(HAVE_EVP_CIPHER_CTX_RESET)
> +#define EVP_CIPHER_CTX_reset EVP_CIPHER_CTX_init
> +#endif
> +
> +#if !defined(HAVE_X509_GET0_NOTBEFORE)
> +#define X509_get0_notBefore X509_get_notBefore
> +#endif
> +
> +#if !defined(HAVE_X509_GET0_NOTAFTER)
> +#define X509_get0_notAfter X509_get_notAfter
> +#endif
> +
>  #if !defined(HAVE_HMAC_CTX_RESET)
>  /**
>   * Reset a HMAC context
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 05ca4113..c029d0f2 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -76,12 +76,13 @@ int mydata_index; /* GLOBAL */
>  void
>  tls_init_lib(void)
>  {
> +#if (OPENSSL_VERSION_NUMBER < 0x1010L && 
> !defined(LIBRESSL_VERSION_NUMBER))
>  SSL_library_init();
> -#ifndef ENABLE_SMALL
> +# ifndef ENABLE_SMALL
>  SSL_load_error_strings();
> -#endif
> +# endif
>  OpenSSL_add_all_algorithms();
> -
> +#endif
>  mydata_index = SSL_get_ex_new_index(0, "struct session *", NULL, NULL, 
> NULL);
>  ASSERT(mydata_index >= 0);
>  }
> @@ -89,9 +90,11 @@ tls_init_lib(void)
>  void
>  tls_free_lib(void)
>  {
> +#if (OPENSSL_VERSION_NUMBER < 0x1010L && 
> !defined(LIBRESSL_VERSION_NUMBER))
>  EVP_cleanup();
> -#ifndef ENABLE_SMALL
> +# ifndef ENABLE_SMALL
>  ERR_free_strings();
> +# endif
>  #endif
>  }
>  
> @@ -567,7 +570,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
>  goto cleanup; /* Nothing to check if there is no certificate */
>  }
>  
> -ret = X509_cmp_time(X509_get_notBefore(cert), NULL);
> +ret = X509_cmp_time(X509_get0_notBefore(cert), NULL);
>  if (ret == 0)
>  {
>  msg(D_TLS_DEBUG_MED, "Failed to read certificate notBefore field.");
> @@ -577,7 +580,7 @@ tls_ctx_check_cert_time(const struct tls_root_ctx *ctx)
>  msg(M_WARN, "WARNING: Your certificate is not yet valid!");
>  }
>  
> -ret = X509_cmp_time(X509_get_notAfter(cert), NULL);
> +ret = X509_cmp_time(X509_get0_notAfter(cert), NULL);
>  if (ret == 0)
>  {
>  msg(D_TLS_DEBUG_MED, "Failed to read certificate notAfter field.");
> @@ -660,10 +663,13 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, 
> const char *curve_name
>  else
>  {
>  #if OPENSSL_VERSION_NUMBER >= 0x10002000L
> +#if (OPENSSL_VERSION_NUMBER < 0x1010L && 
> !defined(LIBRESSL_VERSION_NUMBER))
> +
>  /* OpenSSL 1.0.2 and newer can automatically handle ECDH parameter
>   * loading */
>  SSL_CTX_set_ecdh_auto(ctx->ctx, 1);
>  return;
> +#endif
>  #else
>  /* For older OpenSSL we have to extract the curve from key on our 
> own */
>  EC_KEY *eckey = NULL;
> 

Code looks good, verified that TLS connections still works with mbedtls
and openssl builds.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCHv2] openssl: Fix compilation without deprecated OpenSSL 1.1 APIs

2019-07-24 Thread Steffan Karger
Hi all,

On 14-06-19 12:38, Arne Schwabe wrote:
>> +#if !defined(HAVE_EVP_CIPHER_CTX_INIT)
>> +#define EVP_CIPHER_CTX_init EVP_CIPHER_CTX_reset
>> +#endif
>> +
>> +#if !defined(HAVE_EVP_CIPHER_CTX_CLEANUP)
>> +#define EVP_CIPHER_CTX_cleanup EVP_CIPHER_CTX_reset
>> +#endif
> 
> These two keep the older API instead of switching to the new one, from
> OpenSSL.
> 
> # if OPENSSL_API_COMPAT < 0x1010L
> #  define EVP_CIPHER_CTX_init(c)  EVP_CIPHER_CTX_reset(c)
> #  define EVP_CIPHER_CTX_cleanup(c)   EVP_CIPHER_CTX_reset(c)
> # endif
> 
> Since just using only the new API in this case does not really work I
> think in case it would be better to rather always use
> EVP_CIPHER_CTX_reset isntead of init and  have ifdefs in the 2-3 places
> where we actually use EVP_CIPHER_CTX_cleanup so we can remove the old
> API when we bump our minimum OpenSSL version (and find this thing easy
> since it is an ifdef depending on the openssl version).

Why wouldn't using the new API work? _reset() is basically the new name
for _cleanup(), which some some actual cleanup + init.

As far as I can see it would work perfectly fine to use _reset() instead
of the _init/_cleanup calls everywhere. We never call _init on
uninitialized memory (which is the only case where _init() would work
while _cleanup() would fail).

All we'd have to do than is add something like

#ifndef HAVE_EVP_CIPHER_CTX_RESET
#define EVP_CIPHER_CTX_reset EVP_CIPHER_CTX_cleanup
#endif

to openssl_compat.h.

That way we would just use the new API everywhere, and can get rid of
the lines in the compat file once we drop support for OpenSSL 1.0.

Or am I missing something here?

-Steffan



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v2] Fix broken fragment/mssfix with NCP

2019-07-20 Thread Steffan Karger

On 08-05-19 16:19, Arne Schwabe wrote:
> Am 21.01.19 um 21:04 schrieb Lev Stipakov:
>> From: Lev Stipakov 
>>
>> NCP negotiation replaces worst cast crypto overhead
>> with actual one in data channel frame. That frame
>> params are used by mssfix.
>>
>> Fragment frame still contains worst case overhead.
>> Because of that TCP packets are fragmented, since
>> MSS value exceeds max fragment size.
>>
>> Fix by replacing worst case crypto overhead with
>> actual one for fragment frame, as it is done for data
>> channel frame.
> 
> The change looks good and is tested.
> 
> Acked-By: Arne Schwabe 

Since Arne agrees, I'm completely convinced now too:

Acked-by: Steffan Karger 



signature.asc
Description: OpenPGP digital signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Do not set pkcs11-helper "safe fork mode"

2019-07-20 Thread Steffan Karger
On 28-04-19 11:23, Steffan Karger wrote:
> Together with the pkcs11-helper fixes, I do think this is the right fix.
> I'll try to experiment a bit with it myself too.

Finally got to some testing and staring at code. The patch resolves the
issue for me, and I didn't find any other issues. Our code seems to be
in good shape to disable safe fork mode as far as I can tell.

I replied to the github thread on
https://github.com/OpenVPN/openvpn/pull/121 with my conclusions:

"The initialization order has been changed around 2015. Since then,
OpenVPN initializes the crypto - including pkcs11 - always after
daemonizing. Any PIN / password is always queried before that point.
Since this patch will only be applied to release/2.4 and master, we're
good in that aspect.

With respect to slot events, I believe we're good too. If I understand
the code correctly (@alonbl, please correct me if I'm wrong), slot
events are only used if someone calls pkcs11h_setSlotEventHook(), which
OpenVPN doesn't do.

Summarizing, unless @alonbl tells me I'm wrong I think this patch is
good and should be merged."

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Rate-limit incoming P_CONTROL_HARD_RESET_* packets.

2019-07-14 Thread Steffan Karger
Hi,

On 06-12-18 18:10, Gert Doering wrote:
> Creation of new instances (= new incoming reset packets with different
> source IP addresses / source ports) can be rate-limited in the current
> code by use of the "--connect-freq" option.
> 
> For packets sent with the same source port, OpenVPN would dilligently
> reply to every single packet, causing route reflection issues (plus
> using somewhat more server cycles).  This patch introduces a timestamp
> in the tls_multi context which records when the last "reset" packet
> was seen, and ignores all further "reset" packets coming in in the
> next 10 second interval.

This makes sense, but why 10s? Our default connect-retry value is 5
seconds. Wouldn't 5 (or 4?) be a better value in that regard?

> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/ssl.c| 14 ++
>  src/openvpn/ssl_common.h |  1 +
>  2 files changed, 15 insertions(+)
> 
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 74b88ce6..3078d76c 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -3468,6 +3468,20 @@ tls_pre_decrypt(struct tls_multi *multi,
>  print_link_socket_actual(from, ));
>  goto error;
>  }
> +
> +/* only permit one is_hard_reset() packet per 10 seconds,
> + * ignore more frequent packets
> + */
> +time_t now = time(NULL);
> +if ( now - multi->last_hard_reset_seen < 10 )

I think we use the "if (now - multi->last_hard_reset_seen < 10)" style
in the vast majority of the code base.

> +{
> +msg(D_MULTI_ERRORS, "TLS: tls_pre_decrypt: ignore 
> incoming"
> +" '%s' (only %ds since last RESET)",
> +packet_opcode_name(op),
> +(int)(now - multi->last_hard_reset_seen) );

Here too, no space before ).

> +goto error;
> +}
> +multi->last_hard_reset_seen = now;
>  }
>  
>  /*
> diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
> index 7bf82b3a..e71696b5 100644
> --- a/src/openvpn/ssl_common.h
> +++ b/src/openvpn/ssl_common.h
> @@ -515,6 +515,7 @@ struct tls_multi
>   */
>  int n_hard_errors; /* errors due to TLS negotiation failure */
>  int n_soft_errors; /* errors due to unrecognized or 
> failed-to-authenticate incoming packets */
> +time_t last_hard_reset_seen; /* rate-limit incoming hard reset */
>  
>  /*
>   * Our locked common name, username, and cert hashes (cannot change 
> during the life of this tls_multi object)
> 

Otherwise this looks good to me. I'll ACK once I understand your pick
for the timeout value.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH v3] Stop state-exhaustion attacks from a single source address.

2019-07-14 Thread Steffan Karger
Hi,

Sorry for the terrible response time, but here goes for initial review:

On 07-12-18 21:28, Gert Doering wrote:
> If an attacker sends lots of RESET packets from different source
> ports (but the same source address), every packet will create a
> new multi_instance, leading to resource waste on the server, and
> to lots of reply packets while OpenVPN tries to establish a
> TLS handshake.
> 
> This can be rate-limited with "connect-freq", but if this is set
> too tightly, an attacker can drown out legitimate users of the
> same OpenVPN server.
> 
> So, when deciding whether or not to create a new instance, iterate
> over all existing instances, counting all from the same source IP
> (ignoring source port info) that are "in TLS negotiation" state -
> if more than  instances are already active, refuse new instance.
> 
> The cutoff parameter can be configured by a newly introduced 3rd
> argument to "connect-freq".  So something like this might be
> reasonable for a medium-sized server:
> 
>connect-freq 20 20 3
> 
> ("permit 20 new connections per 20 seconds, but only 3 from the same
> source IP address")
> 
> Drawback: if many users are sitting behind a shared NAT ip address
> and they all reconnect at the same time, session setup will take
> longer for some of the users while the server is still handshaking
> with others.

This seems a very reasonable way - on top of tls-auth/tls-crypt - to
mitigate floods from a single IP. I'm not very familiar with this code
paths, what happens when a cient gets rejected? Does it get told "try
next server", or do we give it a silence treatment?

Also, I think it would be nice to have separate log messages in the
server log for "generic limit reached" and "per-ip limit reached".

Finally, aside from removing the debug prints, this will need some
whitespace polishing. The patch mixes tabs/spaces and styles surrounding
the parentheses in ifs.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] configure.ac: add lzo CFLAGS/LIBS to the test flags

2019-06-02 Thread Steffan Karger
This fixes "make check" builds on systems with lzo on a non-standard
location.

Signed-off-by: Steffan Karger 
---
 configure.ac | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/configure.ac b/configure.ac
index 59673e049..56598217f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -1353,8 +1353,13 @@ AC_SUBST([sampledir])
 AC_SUBST([systemdunitdir])
 AC_SUBST([tmpfilesdir])
 
-TEST_LDFLAGS="${OPTIONAL_CRYPTO_LIBS} ${OPTIONAL_PKCS11_HELPER_LIBS} -lcmocka 
-L\$(top_builddir)/vendor/dist/lib -Wl,-rpath,\$(top_builddir)/vendor/dist/lib"
-TEST_CFLAGS="${OPTIONAL_CRYPTO_CFLAGS} ${OPTIONAL_PKCS11_HELPER_CFLAGS} 
-I\$(top_srcdir)/include -I\$(top_builddir)/vendor/dist/include"
+TEST_LDFLAGS="${OPTIONAL_CRYPTO_LIBS} ${OPTIONAL_PKCS11_HELPER_LIBS}"
+TEST_LDFLAGS="${TEST_LDFLAGS} ${OPTIONAL_LZO_LIBS}"
+TEST_LDFLAGS="${TEST_LDFLAGS} -lcmocka -L\$(top_builddir)/vendor/dist/lib"
+TEST_LDFLAGS="${TEST_LDFLAGS} -Wl,-rpath,\$(top_builddir)/vendor/dist/lib"
+TEST_CFLAGS="${OPTIONAL_CRYPTO_CFLAGS} ${OPTIONAL_PKCS11_HELPER_CFLAGS}"
+TEST_CFLAGS="${TEST_CFLAGS} ${OPTIONAL_LZO_CFLAGS}"
+TEST_CFLAGS="${TEST_CFLAGS} -I\$(top_srcdir)/include 
-I\$(top_builddir)/vendor/dist/include"
 
 AC_SUBST([TEST_LDFLAGS])
 AC_SUBST([TEST_CFLAGS])
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH v2] tests: remove dependency on base64

2019-05-08 Thread Steffan Karger
From: Steffan Karger 

Triggered by the report from Ilya, that if base64 is missing, the tests
would still report success:

  Testing tls-crypt-v2 key generation (max length metadata)/t_lpback.sh: 
base64: not found
  OK
  PASS: t_lpback.sh

The easiest way to fix that, is to remove the dependency on base64 (which
is it's current form wouldn't work on OSX anyway, because their base64
doesn't understand "-w0").

Signed-off-by: Steffan Karger 
---
v2: build loop using 'expr' instead of 'seq', which should also work on
OpenBSD.

 tests/t_lpback.sh | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/tests/t_lpback.sh b/tests/t_lpback.sh
index fb43211d..3b1e73a8 100755
--- a/tests/t_lpback.sh
+++ b/tests/t_lpback.sh
@@ -77,10 +77,17 @@ else
 echo "OK"
 fi
 
+# Generate max-length base64 metadata ('A' is 0b00 in base64)
+METADATA=""
+i=0
+while [ $i -lt 732 ]; do
+METADATA="${METADATA}A"
+i=$(expr $i + 1)
+done
 echo -n "Testing tls-crypt-v2 key generation (max length metadata)..."
 "${top_builddir}/src/openvpn/openvpn" --tls-crypt-v2 tc-server-key.$$ \
---tls-crypt-v2-genkey client tc-client-key.$$ \
-$(head -c732 /dev/zero | base64 -w0) >log.$$ 2>&1
+--tls-crypt-v2-genkey client tc-client-key.$$ "${METADATA}" \
+>log.$$ 2>&1
 if [ $? != 0 ] ; then
 echo "FAILED"
 cat log.$$
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] build: Package missing mock_msg.h

2019-05-02 Thread Steffan Karger
On 17-04-19 22:30, David Sommerseth wrote:
> The mock_msg.h file was not enlisted in the _SOURCES lists in
> Makefile.am for the unit tests.  This caused the mock_msg.h file to not
> be present in the .tar.gz file created by 'make dist'.
> 
> This was not noticed earlier as we haven't really tried much to run git
> clone of the cmocka project manually in vendor/ from an unpacked
> tarball.
> 
> With this fix the cmocka unit tests can also run from tarballs, with
> manually extracting/fetching the cmocka source code in vendor/cmocka.
> 
> Signed-off-by: David Sommerseth 
> 
> 8<8<8<8<8<8<8<8<8<8<8<
> 
> How to test:
> 
> - Create a tarball: make distcheck (or just 'dist')
> - Extract openvpn-2.5_git.tar.gz in a clean directory
> - cd openvpn-2.5_git/vendor
> - git clone https://git.cryptomilk.org/projects/cmocka.git
> - ./configure
> - make check
> - Observe that the cmocka unit tests ran as expected
> 
> Depending on the CMake version, you might want to check out cmocka git
> commit b2732b52202ae48f; which is the one we use in the git submodule.
> ---
>  tests/unit_tests/openvpn/Makefile.am | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/tests/unit_tests/openvpn/Makefile.am 
> b/tests/unit_tests/openvpn/Makefile.am
> index 4f137b2b..657957e5 100644
> --- a/tests/unit_tests/openvpn/Makefile.am
> +++ b/tests/unit_tests/openvpn/Makefile.am
> @@ -19,7 +19,7 @@ compat_srcdir = $(top_srcdir)/src/compat
>  
>  argv_testdriver_CFLAGS  = @TEST_CFLAGS@ -I$(openvpn_srcdir) 
> -I$(compat_srcdir)
>  argv_testdriver_LDFLAGS = @TEST_LDFLAGS@ -L$(openvpn_srcdir) 
> -Wl,--wrap=parse_line
> -argv_testdriver_SOURCES = test_argv.c mock_msg.c \
> +argv_testdriver_SOURCES = test_argv.c mock_msg.c mock_msg.h \
>   mock_get_random.c \
>   $(openvpn_srcdir)/platform.c \
>   $(openvpn_srcdir)/buffer.c \
> @@ -27,14 +27,14 @@ argv_testdriver_SOURCES = test_argv.c mock_msg.c \
>  
>  buffer_testdriver_CFLAGS  = @TEST_CFLAGS@ -I$(openvpn_srcdir) 
> -I$(compat_srcdir)
>  buffer_testdriver_LDFLAGS = @TEST_LDFLAGS@ -L$(openvpn_srcdir) 
> -Wl,--wrap=parse_line
> -buffer_testdriver_SOURCES = test_buffer.c mock_msg.c \
> +buffer_testdriver_SOURCES = test_buffer.c mock_msg.c mock_msg.h \
>   mock_get_random.c \
>   $(openvpn_srcdir)/platform.c
>  
>  crypto_testdriver_CFLAGS  = @TEST_CFLAGS@ \
>   -I$(openvpn_includedir) -I$(compat_srcdir) -I$(openvpn_srcdir)
>  crypto_testdriver_LDFLAGS = @TEST_LDFLAGS@
> -crypto_testdriver_SOURCES = test_crypto.c mock_msg.c \
> +crypto_testdriver_SOURCES = test_crypto.c mock_msg.c mock_msg.h \
>   $(openvpn_srcdir)/buffer.c \
>   $(openvpn_srcdir)/crypto.c \
>   $(openvpn_srcdir)/crypto_mbedtls.c \
> @@ -46,7 +46,7 @@ crypto_testdriver_SOURCES = test_crypto.c mock_msg.c \
>  packet_id_testdriver_CFLAGS  = @TEST_CFLAGS@ \
>   -I$(openvpn_includedir) -I$(compat_srcdir) -I$(openvpn_srcdir)
>  packet_id_testdriver_LDFLAGS = @TEST_LDFLAGS@
> -packet_id_testdriver_SOURCES = test_packet_id.c mock_msg.c \
> +packet_id_testdriver_SOURCES = test_packet_id.c mock_msg.c mock_msg.h \
>   mock_get_random.c \
>   $(openvpn_srcdir)/buffer.c \
>   $(openvpn_srcdir)/otime.c \
> @@ -60,7 +60,7 @@ tls_crypt_testdriver_LDFLAGS = @TEST_LDFLAGS@ \
>   -Wl,--wrap=buffer_write_file \
>   -Wl,--wrap=parse_line \
>   -Wl,--wrap=rand_bytes
> -tls_crypt_testdriver_SOURCES = test_tls_crypt.c mock_msg.c \
> +tls_crypt_testdriver_SOURCES = test_tls_crypt.c mock_msg.c mock_msg.h \
>   $(openvpn_srcdir)/argv.c \
>   $(openvpn_srcdir)/base64.c \
>   $(openvpn_srcdir)/buffer.c \
> 

Makes sense. Apologies for the omission.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Do not set pkcs11-helper "safe fork mode"

2019-04-28 Thread Steffan Karger
Hi David, Hilko,

On 07-03-19 20:14, David Sommerseth wrote:
> On 18/02/2019 16:31, Hilko Bengen wrote:
>> From the pkcs11-helper API documentation about pkcs11h_setForkMode():
>>
>>> This funciton is releavant if PKCS11H_FEATURE_MASK_THREADING is
>>> set. If safe mode is on, the child process can use the loaded
>>> PKCS#11 providers but it cannot use fork(), while it is in one of
>>> the hooks functions, since locked mutexes cannot be released.
>>
>> As far as I can tell, pkcs11-helper functionality is not used in a
>> child process that is created after initialization. Even if OpenVPN is
>> turned into a daemon, the pkcs11-helper library is only initialized
>> after calling possibly_become_daemon(), i.e. in the child process. All
>> other uses of fork() are immediately followed by an exec()
>>
>> This simple change fixes the symptoms described in both
>>  (hang on password
>> prompt when systemd support is enabled) and
>>  (hang on
>> initialization with newer versions of pkcs11-helper).
>>
>> I have successfully tested that this makes the described symptoms go
>> away. For this, I used a YubiKey NEO on Debian/stable, a rebuild of
>> OpenVPN 2.4.6 and two versions of libpkcs11-helper:
>>
>> - libpkcs11-helper 1.21-1 from Debian/stretch
>> - a backport of libpkcs11-helper 1.25-1 from Debian/buster
> 
> Hi,
> 
> Sorry for the time it has take to have a look at this.  I've spent time trying
> to understand how the pkcs11-helper handles things ... and how the whole
> forking stuff happens.  And this approach does look promising.
> 
> But ... it doesn't really work on my RHEL 7.6 system (using
> pkcs11-helper-1.11-3.el7.x86_64).  I've tested this with a yubikey 4 token,
> with a RSA-2048 key.
> 
> The relevant log lines:
> 
> Thu Mar  7 19:37:54 2019 us=108092 VERIFY OK: depth=0, CN=devtest.example.org
> Enter test.user token Password: **
> Thu Mar  7 19:37:56 2019 us=5368 PKCS#11: Cannot perform signature
> 179:'CKR_SESSION_HANDLE_INVALID'
> Thu Mar  7 19:37:56 2019 us=5429 OpenSSL: error:14099006:SSL
> routines:ssl3_send_client_verify:EVP lib
> Thu Mar  7 19:37:56 2019 us=5438 TLS_ERROR: BIO read tls_read_plaintext error
> Thu Mar  7 19:37:56 2019 us=5448 TLS Error: TLS object -> incoming plaintext
> read error
> Thu Mar  7 19:37:56 2019 us=5454 TLS Error: TLS handshake failed
> Thu Mar  7 19:37:56 2019 us=5601 TCP/UDP: Closing socket
> 
> 
> When I compile *without* --enable-systemd, this works.  Which is odd.  I've
> checked that the input provided is identical.  Both builds with and without
> systemd support ends up with the same "pin" value.  But for some reason the
> systemd build fails when calling pkcs11h_openssl_session_getEVP() in
> pkcs11_init_tls_session() [pkcs11_openssl.c:65].
> 
> Based on the error message (CKR_SESSION_HANDLE_INVALID), it seems the locking
> being disabled with using pkcs11h_setForkMode(FALSE) still breaks something
> along the way.
> 
> On the positive side, the "hang" we experience without this patch is gone.
> But I can't claim this being a proper fix as it is currently :-/
> 


That is probably because you need the fork fixes from pkcs11-helper
1.25. Could you try again when linking against 1.25?

Together with the pkcs11-helper fixes, I do think this is the right fix.
I'll try to experiment a bit with it myself too.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] tests: remove dependency on base64

2019-04-17 Thread Steffan Karger
From: Steffan Karger 

Triggered by the report from Ilya, that if base64 is missing, the tests
would still report success:

  Testing tls-crypt-v2 key generation (max length metadata)/t_lpback.sh: 
base64: not found
  OK
  PASS: t_lpback.sh

The easiest way to fix that, is to remove the dependency on base64 (which
is it's current form wouldn't work on OSX anyway, because their base64
doesn't understand "-w0").

Signed-off-by: Steffan Karger 
---
 tests/t_lpback.sh | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/tests/t_lpback.sh b/tests/t_lpback.sh
index fb43211d..dd6c34e5 100755
--- a/tests/t_lpback.sh
+++ b/tests/t_lpback.sh
@@ -77,10 +77,15 @@ else
 echo "OK"
 fi
 
+# Generate max-length base64 metadata ('A' is 0b00 in base64)
+METADATA=""
+for i in $(seq 1 732); do
+METADATA="${METADATA}A"
+done
 echo -n "Testing tls-crypt-v2 key generation (max length metadata)..."
 "${top_builddir}/src/openvpn/openvpn" --tls-crypt-v2 tc-server-key.$$ \
---tls-crypt-v2-genkey client tc-client-key.$$ \
-$(head -c732 /dev/zero | base64 -w0) >log.$$ 2>&1
+--tls-crypt-v2-genkey client tc-client-key.$$ "${METADATA}" \
+>log.$$ 2>&1
 if [ $? != 0 ] ; then
 echo "FAILED"
 cat log.$$
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] cirrus-ci: freebsd builds ?

2019-04-17 Thread Steffan Karger
On Thu, 11 Apr 2019 at 00:54, Илья Шипицин  wrote:
> 1) error when built with mbedtls-2.16.0 (surprizingly, build does not fail)
>
> [   OK ] tls_crypt_v2_wrap_unwrap_no_metadata
> [ RUN  ] tls_crypt_v2_wrap_unwrap_max_metadata
> [   OK ] tls_crypt_v2_wrap_unwrap_max_metadata
> [ RUN  ] tls_crypt_v2_wrap_too_long_metadata
> ERROR: could not crypt: insufficient space in dst

This is not a test error, but an error message printed by the code
that is tested. See the test name, it feeds the code too much
metadata, and checks that the code errors out as expected.

> 2) base64 is missing --> build is ok (we have similar "failures" on travis-ci 
> osx builds)
>
> Testing tls-crypt-v2 key generation (max length metadata)/t_lpback.sh: 
> base64: not found
> OK
> PASS: t_lpback.sh

This is an error in t_lpback.sh, will check it out.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 3/3] travis-ci: update osx to xcode9.4 and modernize brew management

2019-03-17 Thread Steffan Karger
Hi,

On 11-03-19 14:36, chipits...@gmail.com wrote:
> From: Ilya Shipitsin 
> 
> osx image used for builds, i.e. xcode7.3 is outdated, we
> can switch to "default" xcode9.4 and use more fast brew
> travis-ci plugin
> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index bf46b14c..e61a8d38 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -50,11 +50,9 @@ matrix:
>compiler: clang
>  - env: SSLLIB="openssl"
>os: osx
> -  osx_image: xcode7.3
>compiler: clang
>  - env: SSLLIB="mbedtls"
>os: osx
> -  osx_image: xcode7.3
>compiler: clang
>  - env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32 OPENSSL_VERSION="1.0.1u"
>os: linux
> @@ -76,6 +74,8 @@ addons:
>apt:
>  update: true
>  packages: [ liblzo2-dev, libpam0g-dev, liblz4-dev, linux-libc-dev, 
> man2html, mingw-w64]
> +  homebrew:
> +packages: [ lzo ]
>  
>  cache:
>directories:
> @@ -83,10 +83,6 @@ cache:
>- ${HOME}/opt
>- ${HOME}/Library/Caches/Homebrew
>  
> -before_install:
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew update ; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
> -
>  install:
>- if [ ! -z "${CHOST}" ]; then unset CC; fi
>- .travis/build-deps.sh > build-deps.log 2>&1 || (cat build-deps.log && 
> exit 1)
> 

Nice. Thanks for the updates.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/3] travis-ci: change trusty image to xenial

2019-03-17 Thread Steffan Karger
Hi,

On 11-03-19 14:36, chipits...@gmail.com wrote:
> From: Ilya Shipitsin 
> 
> Ubuntu Trusty reaches End of Life on April 30, 2019
> Let us switch to xenial. Also, it simplifies mingw builds.
> We do not need to add xenial mingw manually anymore
> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml   | 9 ++---
>  .travis/build-deps.sh | 9 -
>  2 files changed, 2 insertions(+), 16 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 428131ec..bf46b14c 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -1,5 +1,5 @@
>  sudo: required
> -dist: trusty
> +dist: xenial
>  
>  os: linux
>  
> @@ -75,12 +75,7 @@ matrix:
>  addons:
>apt:
>  update: true
> -packages:
> -  - liblzo2-dev
> -  - libpam0g-dev
> -  - liblz4-dev
> -  - linux-libc-dev
> -  - man2html
> +packages: [ liblzo2-dev, libpam0g-dev, liblz4-dev, linux-libc-dev, 
> man2html, mingw-w64]
>  
>  cache:
>directories:
> diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> index 96a030cc..391b35ef 100755
> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -130,15 +130,6 @@ build_openssl () {
>  fi
>  }
>  
> -if [ ! -z ${CHOST+x} ]; then
> -  #
> -  # openvpn requires at least mingw-gcc-4.9, which is available at 
> xenial repo
> -  #
> -  sudo apt-add-repository "deb http://archive.ubuntu.com/ubuntu xenial 
> main universe"
> -  sudo apt-get update
> -  sudo apt-get -y install dpkg mingw-w64
> -fi
> -
>  # Download and build crypto lib
>  if [ "${SSLLIB}" = "openssl" ]; then
>  download_openssl
> 

Makes sense. (Too bad travis is so slow to roll out newer Ubuntu versions.)

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 1/3] travis-ci: add "linux-ppc64le" to build matrix

2019-03-17 Thread Steffan Karger
Hi,

On 11-03-19 14:36, chipits...@gmail.com wrote:
> From: Ilya Shipitsin 
> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index ede2aaa6..428131ec 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -33,6 +33,9 @@ matrix:
>  - env: SSLLIB="openssl" OPENSSL_VERSION="1.1.0h"
>os: linux
>compiler: gcc
> +- env: SSLLIB="openssl" OPENSSL_VERSION="1.1.0h" LABEL="linux-ppc64le"
> +  os: linux-ppc64le
> +  compiler: gcc
>  - env: SSLLIB="openssl" CFLAGS="-fsanitize=address"
>os: linux
>compiler: clang
> 

Looks good to me and passes tests on travis.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] Summary of the community meeting (Wed, 12th Mar 2019)

2019-03-17 Thread Steffan Karger
Hi Jan Just,

On 13-03-19 13:13, Jan Just Keijser wrote:
> On 13/03/19 13:00, Samuli Seppänen wrote:
>> Here's the summary of the IRC meeting.
>>
>> Talked about release OpenVPN 2.x Windows installers with OpenSSL 1.1.1.
>> Agreed that this makes sense as people (on forums for example) already
>> take 2.4.x and replace the OpenSSL libraries forcibly. Mattock tested
>> openvpn-build with OpenSSL 1.1.1b and there were no issues - a NSI
>> installer was produced. The next Windows installer release will thus
>> have latest OpenSSL 1.1.1 version. If serious issues are found we can
>> always have separate installer releases for OpenSSL 1.1.0 and 1.1.1
>> versions.
>>
> as always, thanks for the summary and chatlog; I really wanted to attend
> this morning but got stuck in a work meeting. There was something
> related to OpenSSL 1.1.1 support that I wanted to bring up:
> 
> OpenSSL 1.1.1 does TLS v1.3; does OpenVPN support TLS v1.3 (for the
> control channel) already?  If so, then it might be a good chance to
> change the internal key derivation stuff in OpenVPN:
> 
> TLS < 1.2   --> use the sha1+md5 routines (which is basically what TLS
> itself does for TSL < 1.1
> TLS >= 1.3 --> use the "export_keying_material" routines in OpenSSL,
> which will create (sha2) keys for you, based on the connection parameters.
> 
> That way, we can slowly migrate users away from the sha1+md5 stuff ,
> which will help with fips compliance as well.
> 
> Thought, anyone?

That would have been nice, except that older OpenVPN versions compiled
against newer OpenSSL sort-of can do TLS 1.3 already. So we can't really
couple the openvpn key derivation / PRF to the TLS version (without
breaking existing setups).

I've considered moving to using the key material exporter functionality
too, and it would be cleaner for us to use. As far as I know though,
mbed TLS doesn't support that extension. And that's tricky to work
around, because the extension needs access to TLS-internal key material.
In the end I think we might be better off by simply upgrading our
internal hash.

We discussed this two hackathons ago, but it didn't make it onto the 2.5
list. Mostly because for our usage, md5+sha1 is fine (all we need is
preimage resistance, not collision resistance). But as we already agreed
back then, even if it was for appearances only, we should migrate away
from it.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [Openvpn-users] Why is the authentication tag transmitted before the encrypted data?

2019-03-17 Thread Steffan Karger
Hi Pieter,

[ Adding in -devel, because this really is more of a devel topic. ]

On 15-03-19 15:29, Pieter Hulshoff wrote:
> I was wondering why the authentication tag is transmitted before the
> encrypted data in stead of after it (like in e.g. MACsec).

As far as I understand, mostly because the V1 data channel protocol put
the HMAC before the ciphertext. James might remember why the original
data channel protocol put the tag in front.

The current GCM wire spec was proposed by James in
<54648eac.70...@openvpn.net>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg09516.html).

I had a short (off-list) discussion with James in 2015 where I proposed
moving the tag to the end of the data frame, to facilitate hardware
implementations. But because (software) implementation of the proposed
protocol had already progressed, we ended up not adopting that proposal.

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix documentation of tls-verify script argument

2019-02-23 Thread Steffan Karger
Hi,

On 01-02-19 21:43, openvpn-devel=lists.sourceforge@thomas.quinot.org
wrote:
> From: Thomas Quinot 
> 
> The second argument is the entire subject DN, not just the CN.
> ---
>  doc/openvpn.8 | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index 7abcaf1e..f80393ee 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -5448,7 +5448,7 @@ is executed two arguments are appended after any 
> arguments specified in
>  .B cmd certificate_depth subject
>  
>  These arguments are, respectively, the current certificate depth and
> -the X509 common name (cn) of the peer.
> +the X509 subject distinguished name (dn) of the peer.
>  
>  This feature is useful if the peer you want to trust has a certificate
>  which was signed by a certificate authority who also signed many
> 

This is indeed what we do. Thanks for the fix.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH] Fix broken fragment/mssfix with NCP

2019-01-19 Thread Steffan Karger
Hi,

On 12-11-18 15:16, Lev Stipakov wrote:
> From: Lev Stipakov 
> 
> NCP negotiation replaces worst cast crypto overhead
> with actual one in data channel frame. That frame
> params are used by mssfix.
> 
> Fragment frame still contains worst case overhead.
> Because of that TCP packets are fragmented, since
> MSS value exceeds max fragment size.
> 
> Fix by replacing worst case crypto overhead with
> actual one for fragment frame, as it is done for data
> channel frame.
> 
> Trac #1140

Thanks for digging into this!

> Signed-off-by: Lev Stipakov 
> ---
>  src/openvpn/forward.c |  1 +
>  src/openvpn/init.c| 12 +++-
>  src/openvpn/openvpn.h |  1 +
>  src/openvpn/push.c|  9 -
>  src/openvpn/ssl.c | 19 ++-
>  src/openvpn/ssl.h | 13 -
>  6 files changed, 47 insertions(+), 8 deletions(-)
> 
> diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
> index f8faa81..773f5d7 100644
> --- a/src/openvpn/forward.c
> +++ b/src/openvpn/forward.c
> @@ -1090,6 +1090,7 @@ process_incoming_link_part1(struct context *c, struct 
> link_socket_info *lsi, boo
>  if (is_hard_reset(opcode, c->options.key_method))
>  {
>  c->c2.frame = c->c2.frame_initial;
> +c->c2.frame_fragment = c->c2.frame_fragment_initial;

This breaks --disable-fragment builds:

src/openvpn/forward.c:1096:27: error: no member named 'frame_fragment'
in 'struct context_2'
c->c2.frame_fragment = c->c2.frame_fragment_initial;
~ ^
src/openvpn/forward.c:1096:50: error: no member named
'frame_fragment_initial' in 'struct context_2'
c->c2.frame_fragment = c->c2.frame_fragment_initial;
   ~ ^
2 errors generated.
Makefile:676: recipe for target 'forward.o' failed


>  }
>  
>  interval_action(>c2.tmp_int);
> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
> index 39e8ca5..db96353 100644
> --- a/src/openvpn/init.c
> +++ b/src/openvpn/init.c
> @@ -2300,9 +2300,18 @@ do_deferred_options(struct context *c, const unsigned 
> int found)
>  {
>  tls_poor_mans_ncp(>options, 
> c->c2.tls_multi->remote_ciphername);
>  }
> +struct frame *frame_fragment = NULL;
> +#ifdef ENABLE_FRAGMENT
> +if (c->options.ce.fragment)
> +{
> +frame_fragment = >c2.frame_fragment;
> +}
> +#endif
> +
>  /* Do not regenerate keys if server sends an extra push reply */
>  if (!session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized
> -&& !tls_session_update_crypto_params(session, >options, 
> >c2.frame))
> +&& !tls_session_update_crypto_params(session, >options, 
> >c2.frame,
> + frame_fragment))
>  {
>  msg(D_TLS_ERRORS, "OPTIONS ERROR: failed to import crypto 
> options");
>  return false;
> @@ -3082,6 +3091,7 @@ do_init_frame(struct context *c)
>   */
>  c->c2.frame_fragment = c->c2.frame;
>  frame_subtract_extra(>c2.frame_fragment, >c2.frame_fragment_omit);
> +c->c2.frame_fragment_initial = c->c2.frame_fragment;
>  #endif
>  
>  #if defined(ENABLE_FRAGMENT) && defined(ENABLE_OCC)
> diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
> index d11f61d..a5d250f 100644
> --- a/src/openvpn/openvpn.h
> +++ b/src/openvpn/openvpn.h
> @@ -265,6 +265,7 @@ struct context_2
>  /* Object to handle advanced MTU negotiation and datagram fragmentation 
> */
>  struct fragment_master *fragment;
>  struct frame frame_fragment;
> +struct frame frame_fragment_initial;
>  struct frame frame_fragment_omit;
>  #endif
>  
> diff --git a/src/openvpn/push.c b/src/openvpn/push.c
> index 72f0996..a44646a 100644
> --- a/src/openvpn/push.c
> +++ b/src/openvpn/push.c
> @@ -274,11 +274,18 @@ incoming_push_message(struct context *c, const struct 
> buffer *buffer)
>  {
>  if (c->options.mode == MODE_SERVER)
>  {
> +struct frame *frame_fragment = NULL;
> +#ifdef ENABLE_FRAGMENT
> +if (c->options.ce.fragment)
> +{
> +frame_fragment = >c2.frame_fragment;
> +}
> +#endif
>  struct tls_session *session = 
> >c2.tls_multi->session[TM_ACTIVE];
>  /* Do not regenerate keys if client send a second push request */
>  if 
> (!session->key[KS_PRIMARY].crypto_options.key_ctx_bi.initialized
>  && !tls_session_update_crypto_params(session, >options,
> - >c2.frame))
> + >c2.frame, 
> frame_fragment))
>  {
>  msg(D_TLS_ERRORS, "TLS Error: initializing data channel 
> failed");
>  goto error;
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 

[Openvpn-devel] [PATCH v2] Fix tls-auth/crypt in connection blocks with --persist-key

2019-01-19 Thread Steffan Karger
If --persist-key was used, we would always try to pre-load the 'global'
tls-auth/crypt file. That would result in using the wrong key (leading
to a failed connection) or en error is there was to 'global' key:

  Sat Jan 19 11:09:01 2019 Cannot pre-load tls-auth keyfile ((null))
  Sat Jan 19 11:09:01 2019 Exiting due to fatal error

Fix that by loading loading the key from the current connection entry.

Signed-off-by: Steffan Karger 
---
v2: Also fix tls-crypt, not just tls-auth.

 src/openvpn/options.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 0cf8db767..bebd30059 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2863,11 +2863,11 @@ options_postprocess_mutate_ce(struct options *o, struct 
connection_entry *ce)
 {
 if (ce->tls_auth_file && !ce->tls_auth_file_inline)
 {
-struct buffer in = buffer_read_from_file(o->tls_auth_file, >gc);
+struct buffer in = buffer_read_from_file(ce->tls_auth_file, 
>gc);
 if (!buf_valid())
 {
 msg(M_FATAL, "Cannot pre-load tls-auth keyfile (%s)",
-o->tls_auth_file);
+ce->tls_auth_file);
 }
 
 ce->tls_auth_file = INLINE_FILE_TAG;
@@ -2876,11 +2876,11 @@ options_postprocess_mutate_ce(struct options *o, struct 
connection_entry *ce)
 
 if (ce->tls_crypt_file && !ce->tls_crypt_inline)
 {
-struct buffer in = buffer_read_from_file(o->tls_crypt_file, 
>gc);
+struct buffer in = buffer_read_from_file(ce->tls_crypt_file, 
>gc);
 if (!buf_valid())
 {
 msg(M_FATAL, "Cannot pre-load tls-crypt keyfile (%s)",
-o->tls_auth_file);
+ce->tls_crypt_file);
 }
 
 ce->tls_crypt_file = INLINE_FILE_TAG;
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Fix tls-auth/crypt in connection blocks with --persist-key

2019-01-19 Thread Steffan Karger
If --persist-key was used, we would always try to pre-load the 'global'
tls-auth/crypt file. That would result in using the wrong key (leading
to a failed connection) or en error is there was to 'global' key:

  Sat Jan 19 11:09:01 2019 Cannot pre-load tls-auth keyfile ((null))
  Sat Jan 19 11:09:01 2019 Exiting due to fatal error

Fix that by loading loading the key from the current connection entry.

Signed-off-by: Steffan Karger 
---
 src/openvpn/options.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 0cf8db767..3d4da38d9 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2863,11 +2863,11 @@ options_postprocess_mutate_ce(struct options *o, struct 
connection_entry *ce)
 {
 if (ce->tls_auth_file && !ce->tls_auth_file_inline)
 {
-struct buffer in = buffer_read_from_file(o->tls_auth_file, >gc);
+struct buffer in = buffer_read_from_file(ce->tls_auth_file, 
>gc);
 if (!buf_valid())
 {
 msg(M_FATAL, "Cannot pre-load tls-auth keyfile (%s)",
-o->tls_auth_file);
+ce->tls_auth_file);
 }
 
 ce->tls_auth_file = INLINE_FILE_TAG;
-- 
2.17.1



___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


Re: [Openvpn-devel] [PATCH 2/6] Refactor tls_crypt_v2_write_server_key_file into crypto.c

2019-01-16 Thread Steffan Karger
Hi,

On 14-01-19 16:48, Arne Schwabe wrote:
> From: Arne Schwabe 
> 
> This allows the method to be resued for generating other types of keys
> that should also not be reused as tls-crypt/tls-auth keys.
> ---
>  src/openvpn/crypto.c| 34 ++
>  src/openvpn/crypto.h| 10 ++
>  src/openvpn/tls_crypt.c | 30 +-
>  3 files changed, 45 insertions(+), 29 deletions(-)
> 
> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
> index df6f36ca..19136799 100644
> --- a/src/openvpn/crypto.c
> +++ b/src/openvpn/crypto.c
> @@ -1848,3 +1848,37 @@ translate_cipher_name_to_openvpn(const char 
> *cipher_name)
>  
>  return pair->openvpn_name;
>  }
> +
> +void
> +write_pem_key_file(const char *filename, const char *pem_name)
> +{
> +struct gc_arena gc = gc_new();
> +struct key server_key = { 0 };
> +struct buffer server_key_buf = clear_buf();
> +struct buffer server_key_pem = clear_buf();
> +
> +if (!rand_bytes((void *)_key, sizeof(server_key)))
> +{
> +msg(M_NONFATAL, "ERROR: could not generate random key");
> +goto cleanup;
> +}
> +buf_set_read(_key_buf, (void *)_key, sizeof(server_key));
> +if (!crypto_pem_encode(pem_name, _key_pem,
> +   _key_buf, ))
> +{
> +msg(M_WARN, "ERROR: could not PEM-encode key");
> +goto cleanup;
> +}
> +
> +if (!buffer_write_file(filename, _key_pem))
> +{
> +msg(M_ERR, "ERROR: could not write key file");
> +goto cleanup;
> +}
> +
> +cleanup:
> +secure_memzero(_key, sizeof(server_key));
> +buf_clear(_key_pem);
> +gc_free();
> +return;
> +}
> diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
> index 1edde2e3..c0574ff6 100644
> --- a/src/openvpn/crypto.h
> +++ b/src/openvpn/crypto.h
> @@ -420,6 +420,16 @@ void crypto_adjust_frame_parameters(struct frame *frame,
>  /** Return the worst-case OpenVPN crypto overhead (in bytes) */
>  unsigned int crypto_max_overhead(void);
>  
> +/**
> + * Generate a server key with enough randomness to fill a key struct
> + * and write to file.
> + *
> + * @param filename  Filename of the server key file to create.
> + * @param pem_name  The name to use in the PEM header/footer.
> + */
> +void
> +write_pem_key_file(const char *filename, const char *pem_name);
> +
>  /* Minimum length of the nonce used by the PRNG */
>  #define NONCE_SECRET_LEN_MIN 16
>  
> diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
> index 6bc2b7f8..eeac794b 100644
> --- a/src/openvpn/tls_crypt.c
> +++ b/src/openvpn/tls_crypt.c
> @@ -670,35 +670,7 @@ tls_crypt_v2_extract_client_key(struct buffer *buf,
>  void
>  tls_crypt_v2_write_server_key_file(const char *filename)
>  {
> -struct gc_arena gc = gc_new();
> -struct key server_key = { 0 };
> -struct buffer server_key_buf = clear_buf();
> -struct buffer server_key_pem = clear_buf();
> -
> -if (!rand_bytes((void *)_key, sizeof(server_key)))
> -{
> -msg(M_NONFATAL, "ERROR: could not generate random key");
> -goto cleanup;
> -}
> -buf_set_read(_key_buf, (void *)_key, sizeof(server_key));
> -if (!crypto_pem_encode(tls_crypt_v2_srv_pem_name, _key_pem,
> -   _key_buf, ))
> -{
> -msg(M_WARN, "ERROR: could not PEM-encode server key");
> -goto cleanup;
> -}
> -
> -if (!buffer_write_file(filename, _key_pem))
> -{
> -    msg(M_ERR, "ERROR: could not write server key file");
> -goto cleanup;
> -}
> -
> -cleanup:
> -secure_memzero(_key, sizeof(server_key));
> -buf_clear(_key_pem);
> -gc_free();
> -return;
> +write_pem_key_file(filename, tls_crypt_v2_srv_pem_name);
>  }
>  
>  void
> 

Makes sense, and does what it says on the tin.

Acked-by: Steffan Karger 

-Steffan


___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel


[Openvpn-devel] [PATCH] Extend tls-crypt-v2 unit tests

2019-01-16 Thread Steffan Karger
This commit adds two tests for tls-crypt-v2 to verify the client and
server key generation. These are introduced primarily as a regression
test for the off-by-one bug fixed by Arne in tls_crypt_v2_read_keyfile()
recently (no commit hash availble, patch has not been applied yet).

Signed-off-by: Steffan Karger 
---
 tests/unit_tests/openvpn/Makefile.am  |  6 +-
 tests/unit_tests/openvpn/test_tls_crypt.c | 89 ++-
 2 files changed, 93 insertions(+), 2 deletions(-)

diff --git a/tests/unit_tests/openvpn/Makefile.am 
b/tests/unit_tests/openvpn/Makefile.am
index b4304e35..4f137b2b 100644
--- a/tests/unit_tests/openvpn/Makefile.am
+++ b/tests/unit_tests/openvpn/Makefile.am
@@ -55,7 +55,11 @@ packet_id_testdriver_SOURCES = test_packet_id.c mock_msg.c \
 
 tls_crypt_testdriver_CFLAGS  = @TEST_CFLAGS@ \
-I$(openvpn_includedir) -I$(compat_srcdir) -I$(openvpn_srcdir)
-tls_crypt_testdriver_LDFLAGS = @TEST_LDFLAGS@ -Wl,--wrap=parse_line
+tls_crypt_testdriver_LDFLAGS = @TEST_LDFLAGS@ \
+   -Wl,--wrap=buffer_read_from_file \
+   -Wl,--wrap=buffer_write_file \
+   -Wl,--wrap=parse_line \
+   -Wl,--wrap=rand_bytes
 tls_crypt_testdriver_SOURCES = test_tls_crypt.c mock_msg.c \
$(openvpn_srcdir)/argv.c \
$(openvpn_srcdir)/base64.c \
diff --git a/tests/unit_tests/openvpn/test_tls_crypt.c 
b/tests/unit_tests/openvpn/test_tls_crypt.c
index 62721e82..b793a7a2 100644
--- a/tests/unit_tests/openvpn/test_tls_crypt.c
+++ b/tests/unit_tests/openvpn/test_tls_crypt.c
@@ -49,7 +49,30 @@
 #define PARAM1  "param1"
 #define PARAM2  "param two"
 
-const char plaintext_short[1];
+static const char *plaintext_short = "";
+
+static const char *test_server_key = \
+"-BEGIN OpenVPN tls-crypt-v2 server key-\n"
+"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4v\n"
+"MDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5f\n"
+"YGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn8=\n"
+"-END OpenVPN tls-crypt-v2 server key-\n";
+
+static const char *test_client_key = \
+"-BEGIN OpenVPN tls-crypt-v2 client key-\n"
+"AAECAwQFBgcICQoLDA0ODxAREhMUFRYXGBkaGxwdHh8gISIjJCUmJygpKissLS4v\n"
+"MDEyMzQ1Njc4OTo7PD0+P0BBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWltcXV5f\n"
+"YGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6e3x9fn+AgYKDhIWGh4iJiouMjY6P\n"
+"kJGSk5SVlpeYmZqbnJ2en6ChoqOkpaanqKmqq6ytrq+wsbKztLW2t7i5uru8vb6/\n"
+"wMHCw8TFxsfIycrLzM3Oz9DR0tPU1dbX2Nna29zd3t/g4eLj5OXm5+jp6uvs7e7v\n"
+"8PHy8/T19vf4+fr7/P3+/xd9pcB0qUYZsWvkrLcfGmzPJPM8a7r0mEWdXwbDadSV\n"
+"LHg5bv2TwlmPR3HgaMr8o9LTh9hxUTkrH3S0PfKRNwcso86ua/dBFTyXsM9tg4aw\n"
+"3dS6ogH9AkaT+kRRDgNcKWkQCbwmJK2JlfkXHBwbAtmn78AkNuho6QCFqCdqGab3\n"
+"zh2vheFqGMPdGpukbFrT3rcO3VLxUeG+RdzXiMTCpJSovFBP1lDkYwYJPnz6daEh\n"
+"j0TzJ3BVru9W3CpotdNt7u09knxAfpCxjtrP3semsDew/gTBtcfQ/OoTFyFHnN5k\n"
+"RZ+q17SC4nba3Pp8/Fs0+hSbv2tJozoD8SElFq7SIWJsciTYh8q8f5yQxjdt4Wxu\n"
+"/Z5wtPCAZ0tOzj4ItTI77fBOYRTfEayzHgEr\n"
+"-END OpenVPN tls-crypt-v2 client key-\n";
 
 int
 __wrap_parse_line(const char *line, char **p, const int n, const char *file,
@@ -61,6 +84,40 @@ __wrap_parse_line(const char *line, char **p, const int n, 
const char *file,
 return 3;
 }
 
+bool
+__wrap_buffer_write_file(const char *filename, const struct buffer *buf)
+{
+const char *pem = BSTR(buf);
+check_expected(filename);
+check_expected(pem);
+
+return mock();
+}
+
+struct buffer
+__wrap_buffer_read_from_file(const char *filename, struct gc_arena *gc)
+{
+check_expected(filename);
+
+const char *pem_str = (const char *) mock();
+struct buffer ret = alloc_buf_gc(strlen(pem_str) + 1, gc);
+buf_write(, pem_str, strlen(pem_str) + 1);
+
+return ret;
+}
+
+
+/** Predictable random for tests */
+int
+__wrap_rand_bytes(uint8_t *output, int len)
+{
+for (int i = 0; i < len; i++)
+{
+output[i] = i;
+}
+return true;
+}
+
 struct test_tls_crypt_context {
 struct crypto_options co;
 struct key_type kt;
@@ -450,6 +507,34 @@ tls_crypt_v2_wrap_unwrap_dst_too_small(void **state) {
 assert_true(0 == BLEN(>unwrapped_metadata));
 }
 
+static void
+test_tls_crypt_v2_write_server_key_file(void **state) {
+const char *filename = "testfilename.key";
+
+expect_string(__wrap_buffer_write_file, filename, filename);
+expect_string(__wrap_buffer_write_file, pem, test_server_key);
+will_return(__wrap_buffer_write_file, true);
+
+tls_crypt_v2_write_server_key_file(filename);
+}
+
+static void
+test_tls_crypt_v2_write_client_key_file(void **state) {
+const char *filename = "testfilename.key";
+
+/* Te

  1   2   3   4   5   6   7   8   9   10   >