Re: [Openvpn-devel] [PATCH] Use SHA256 for the internal digest, instead of MD5

[Steffan Karger]

Hi,

On 20-01-17 23:01, David Sommerseth wrote:
> This actually tries to revert commit ec4dff3bbdcc9fedf7844 ... which is
> quite surprising.
> 
> [...snip...]
> 
> And this too is also a revert of the same commit as above.
> 
> Had it been just a simple rebase, I'd be willing to tackle that
> on-the-fly.  But as it tries to do some really unexpected reverts, there
> might be a few other issues I'm not able to spot instantly.

Ouch, that's one ugly rebase error.  I'll double-check the patch, and
resend a properly rebased one.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Use SHA256 for the internal digest, instead of MD5

[Steffan Karger]

Our internal options digest uses MD5 hashes to store the state, instead of
storing the full options string.  There's nothing wrong with that, but it
would still be better to use SHA256 because:
 * That makes it easier to make OpenVPN "FIPS-compliant" (forbids MD5)
 * We don't have to explain anymore that MD5 is fine too

The slightly less bytes for the digest (16 instead of 32) and operations
per connection setup are not worth sticking to MD5.

Note that might SHA256 not be available in de crypto lib, OpenVPN will
refuse to start and shout "Message hash algorithm 'SHA256' not found".

Signed-off-by: Steffan Karger 
---
v2: fix rebase error that erroneously reverted commit ec4dff3b

 src/openvpn/crypto.h |  6 +++---
 src/openvpn/crypto_mbedtls.h |  1 +
 src/openvpn/crypto_openssl.h |  1 +
 src/openvpn/init.c   | 10 +-
 src/openvpn/openvpn.h|  6 +++---
 src/openvpn/push.c   |  8 
 6 files changed, 17 insertions(+), 15 deletions(-)

diff --git a/src/openvpn/crypto.h b/src/openvpn/crypto.h
index 42a46d9..afd6fe5 100644
--- a/src/openvpn/crypto.h
+++ b/src/openvpn/crypto.h
@@ -131,9 +131,9 @@
 #include "packet_id.h"
 #include "mtu.h"
 
-/** Wrapper struct to pass around MD5 digests */
-struct md5_digest {
-uint8_t digest[MD5_DIGEST_LENGTH];
+/** Wrapper struct to pass around SHA256 digests */
+struct sha256_digest {
+uint8_t digest[SHA256_DIGEST_LENGTH];
 };
 
 /*
diff --git a/src/openvpn/crypto_mbedtls.h b/src/openvpn/crypto_mbedtls.h
index 525b256..da2db16 100644
--- a/src/openvpn/crypto_mbedtls.h
+++ b/src/openvpn/crypto_mbedtls.h
@@ -73,6 +73,7 @@ typedef mbedtls_md_context_t hmac_ctx_t;
 #define MD4_DIGEST_LENGTH   16
 #define MD5_DIGEST_LENGTH   16
 #define SHA_DIGEST_LENGTH   20
+#define SHA256_DIGEST_LENGTH32
 #define DES_KEY_LENGTH 8
 
 /**
diff --git a/src/openvpn/crypto_openssl.h b/src/openvpn/crypto_openssl.h
index 56ec6e1..f8ddbc8 100644
--- a/src/openvpn/crypto_openssl.h
+++ b/src/openvpn/crypto_openssl.h
@@ -33,6 +33,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /** Generic cipher key type %context. */
 typedef EVP_CIPHER cipher_kt_t;
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index f2e75c8..756bf36 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1919,12 +1919,12 @@ tun_abort()
  * equal, or either one is all-zeroes.
  */
 static bool
-options_hash_changed_or_zero(const struct md5_digest *a,
- const struct md5_digest *b)
+options_hash_changed_or_zero(const struct sha256_digest *a,
+ const struct sha256_digest *b)
 {
-const struct md5_digest zero = {{0}};
-return memcmp(a, b, sizeof(struct md5_digest))
-   || !memcmp(a, &zero, sizeof(struct md5_digest));
+const struct sha256_digest zero = {{0}};
+return memcmp(a, b, sizeof(struct sha256_digest))
+   || !memcmp(a, &zero, sizeof(struct sha256_digest));
 }
 #endif /* P2MP */
 
diff --git a/src/openvpn/openvpn.h b/src/openvpn/openvpn.h
index 37edec4..893296e 100644
--- a/src/openvpn/openvpn.h
+++ b/src/openvpn/openvpn.h
@@ -202,7 +202,7 @@ struct context_1
 #endif
 
 /* if client mode, hash of option strings we pulled from server */
-struct md5_digest pulled_options_digest_save;
+struct sha256_digest pulled_options_digest_save;
 /**< Hash of option strings received from the
  *   remote OpenVPN server.  Only used in
  *   client-mode. */
@@ -471,9 +471,9 @@ struct context_2
 bool did_pre_pull_restore;
 
 /* hash of pulled options, so we can compare when options change */
-bool pulled_options_md5_init_done;
+bool pulled_options_digest_init_done;
 md_ctx_t pulled_options_state;
-struct md5_digest pulled_options_digest;
+struct sha256_digest pulled_options_digest;
 
 struct event_timeout scheduled_exit;
 int scheduled_exit_signal;
diff --git a/src/openvpn/push.c b/src/openvpn/push.c
index c9c04a6..8c3104e 100644
--- a/src/openvpn/push.c
+++ b/src/openvpn/push.c
@@ -720,10 +720,10 @@ process_incoming_push_msg(struct context *c,
 if (ch == ',')
 {
 struct buffer buf_orig = buf;
-if (!c->c2.pulled_options_md5_init_done)
+if (!c->c2.pulled_options_digest_init_done)
 {
-md_ctx_init(&c->c2.pulled_options_state, md_kt_get("MD5"));
-c->c2.pulled_options_md5_init_done = true;
+md_ctx_init(&c->c2.pulled_options_state, md_kt_get("SHA256"));
+c->c2.pulled_options_digest_init_done = true;
 }
 if (!c->c2.did_pre_pull_restore)
 {
@@ -744,7 +744,7 @@ process_incoming_push_msg(struct context *c,
 case 1:
 md_ctx_final(&c->c2.pulled_options_state, 
c->c2.pulled_options_digest.digest

Re: [Openvpn-devel] [PATCH v5] convert *_inline attributes to bool

[Steffan Karger]

Hi,

One more real comment and two nitpicks:

On 15-01-17 15:43, Antonio Quartulli wrote:
> @@ -3233,39 +3258,63 @@ options_postprocess_filechecks(struct options 
> *options)
>
> [...]
>
> +errs |= check_file_access_inline(options->cert_file_inline, CHKACC_FILE,
> + options->cert_file, R_OK, "--cert");

This line has 1 indent too many.

> +errs |= check_file_access_inline(options->extra_certs_file, CHKACC_FILE,
> + options->extra_certs_file, R_OK,
> + "--extra-certs");

I think the second one should be options->extra_certs_file_inline?

> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -542,7 +542,7 @@ tls_version_parse(const char *vstr, const char *extra)
>   */
>  static void
>  tls_ctx_reload_crl(struct tls_root_ctx *ssl_ctx, const char *crl_file,
> -   const char *crl_file_inline)
> +   bool crl_file_inline)

The doxygen string of the crl_file_inline parameter needs to be updated
too (like you did in the header file for the non-static functions).

Apart from these I am ready to give this an ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] git: Merge .gitignore files into a single file

[Steffan Karger]

Hi,

On 20 January 2017 at 22:04, David Sommerseth  wrote:
> We already track a lot of files over the whole directory structure
> in the main .gitignore file.  But a few additional ones had been
> added into some of the subdirectories.
>
> This unifies all these files into a master file for the whole project,
> making it easier to know where to look at and edit if changes needs
> to be done.
>
> Signed-off-by: David Sommerseth 
> ---
>  .gitignore| 5 +
>  sample/sample-keys/.gitignore | 1 -
>  tests/unit_tests/.gitignore   | 1 -
>  vendor/.gitignore | 2 --
>  4 files changed, 5 insertions(+), 4 deletions(-)
>  delete mode 100644 sample/sample-keys/.gitignore
>  delete mode 100644 tests/unit_tests/.gitignore
>  delete mode 100644 vendor/.gitignore
>
> diff --git a/.gitignore b/.gitignore
> index fc1e223..72593cf 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -51,11 +51,16 @@ config-msvc-local.h
>  config-msvc-version.h
>  doc/openvpn.8.html
>  distro/rpm/openvpn.spec
> +sample/sample-keys/sample-ca/
> +vendor/.build
> +vendor/dist
>
>  tests/t_client.sh
>  tests/t_client-*-20??-??/
>  t_client.rc
>  t_client_ips.rc
> +tests/unit_tests/*/*_testdriver
> +tests/unit_tests/*/*/*_testdriver
>

What about tests/unit_tests/**/*_testdriver ?  As of git 1.8.2 that
should match all subfolders, which is old enough to be present on
almost all development machines, I think.

>  src/openvpn/openvpn
>  include/openvpn-plugin.h
> diff --git a/sample/sample-keys/.gitignore b/sample/sample-keys/.gitignore
> deleted file mode 100644
> index f148752..000
> --- a/sample/sample-keys/.gitignore
> +++ /dev/null
> @@ -1 +0,0 @@
> -sample-ca/
> diff --git a/tests/unit_tests/.gitignore b/tests/unit_tests/.gitignore
> deleted file mode 100644
> index 8655de8..000
> --- a/tests/unit_tests/.gitignore
> +++ /dev/null
> @@ -1 +0,0 @@
> -*_testdriver
> diff --git a/vendor/.gitignore b/vendor/.gitignore
> deleted file mode 100644
> index e11dfec..000
> --- a/vendor/.gitignore
> +++ /dev/null
> @@ -1,2 +0,0 @@
> -.build/
> -dist/
> --
> 2.11.0

ACK, whether you decide to follow my suggestion or not.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Allow changing cipher from a ccd file

[Steffan Karger]

As described in msg  <374a7eb7-f539-5231-623b-41f208ed8...@belkam.com> on
openvpn-devel@lists.sourceforge.net, clients that are compiled with
--disable-occ (included in --enable-small) won't send an options string.
Without the options string, the 2.4 server doesn't know which cipher to
use for poor man's NCP.

This patch allows working around that issue by allowing the 'cipher'
directive to be used in --client-config-dir files.  That way, a server
admin can add ccd files to specify per-client which cipher to use.

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

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 4b6d720..6f89616 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -7536,7 +7536,7 @@ add_option(struct options *options,
 }
 else if (streq(p[0], "cipher") && p[1] && !p[2])
 {
-VERIFY_PERMISSION(OPT_P_NCP);
+VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
 options->ciphername = p[1];
 }
 else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index a14f2ab..f4f0226 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -628,7 +628,7 @@ struct options
 #define OPT_P_MTU (1<<14) /* TODO */
 #define OPT_P_NICE(1<<15)
 #define OPT_P_PUSH(1<<16)
-#define OPT_P_INSTANCE(1<<17)
+#define OPT_P_INSTANCE(1<<17) /**< Allow usage in ccd file */
 #define OPT_P_CONFIG  (1<<18)
 #define OPT_P_EXPLICIT_NOTIFY (1<<19)
 #define OPT_P_ECHO(1<<20)
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix building with LibreSSL 2.5.1 by cleaning a hack.

[Steffan Karger]

Hi,

On 06-02-17 20:18, Olivier W wrote:
> Should be compatible with all versions of OpenSSL and LibreSSL.
> Similar to what is done in curl:
> https://github.com/curl/curl/blob/028391df5d84d9fae3433afdee9261d565900355/lib/vtls/openssl.c#L603-L619
> 
> Error while compiling was:
> "ssl_openssl.c:512:30: error: no member named 'cert' in 'struct ssl_ctx_st'
> ssl.cert = ctx->ctx->cert;
> ~ ^
> 1 error generated.
> *** Error code 1"
> ---
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 8266595..a889332 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -508,10 +508,13 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx
> *ctx, const char *curve_name
>  const EC_GROUP *ecgrp = NULL;
>  EVP_PKEY *pkey = NULL;
> 
> -/* Little hack to get private key ref from SSL_CTX, yay OpenSSL... */
> -SSL ssl;
> -ssl.cert = ctx->ctx->cert;
> -pkey = SSL_get_privatekey(&ssl);
> +SSL *ssl = SSL_new(ctx->ctx);
> +if (!ssl)
> +{
> +crypto_msg(M_FATAL, "SSL_new failed");
> +}
> +pkey = SSL_get_privatekey(ssl);
> +SSL_free(ssl);

The code change looks good, and passes my (manual) tests.  I'd like to
keep the comment though, because this still is a hack/workaround to get
the private key from the SSL_CTX object, it just does so a little nicer
at the cost of a number of malloc/free calls.

It might be even worth noting that the workaround is only needed for
OpenSSL <= 1.0.1, because later versions do have a function to get the
private key from a struct SSL_CTX directly.  By noting that explicitly,
we help ourselves remember to get rid of the hack as soon as we drop
support for these OpenSSL versions.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix building with LibreSSL 2.5.1 by cleaning a hack.

[Steffan Karger]

Hi,

On 07-02-17 09:45, Илья Шипицин wrote:
> I have a question (sorry if I couldn't check myself): did you check that
> SSL_get_privatekey() and SSL_free() won't crash when ssl is NULL ?
> 
> what if we involve clang static analyzer for such things ? can we count
> on it ?
> 
> it is capable of detecting "Argument with 'nonnull' attribute passed null"
> 
> and, as I can see, after applying patch it didn't find new issues
> 
> http://chipitsine.github.io/without-patch/
> http://chipitsine.github.io/with-patch/
> 
> 
> also, it might be even automated, run clang static analyzer before and
> after applying patch and compare the result

Static analyzers are useful, but do not and probably never will replace
review by someone who knows the code.  They complement each other;
neither will detect all mistakes.

In relation to that, please stop making statements like 'it passes
travis, so the patch must be okay'.  That's pertinently not true.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix building with LibreSSL 2.5.1 by cleaning a hack.

[Steffan Karger]

Hi,

On 09-02-17 21:04, Olivier W wrote:
> Hello,
> Please find the new version of the patch.
> 
> So, I added back the comment I had removed and new versions of OpenSSL
> will use SSL_CTX_get0_privatekey() instead of SSL_new() +
> SSL_get_privatekey() + SSL_free().
> 
> It successfully compile with LibreSSL 2.4.5, 2.5.1 and OpenSSL 1.0.2k.
> I've also pushed it to Github and Travis-CI is currently running:
> https://github.com/OpenVPN/openvpn/pull/82
> 
> Best Regards,
> Olivier
> 
> ---
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 8266595..abf69c9 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -508,10 +508,18 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx
> *ctx, const char *curve_name
>  const EC_GROUP *ecgrp = NULL;
>  EVP_PKEY *pkey = NULL;
> 
> +#if OPENSSL_VERSION_NUMBER >= 0x10002000L && 
> !defined(LIBRESSL_VERSION_NUMBER)
> +pkey = SSL_CTX_get0_privatekey(ctx->ctx);
> +#else
>  /* Little hack to get private key ref from SSL_CTX, yay OpenSSL... */
> -SSL ssl;
> -ssl.cert = ctx->ctx->cert;
> -pkey = SSL_get_privatekey(&ssl);
> +SSL *ssl = SSL_new(ctx->ctx);
> +if (!ssl)
> +{
> +crypto_msg(M_FATAL, "SSL_new failed");
> +}
> +pkey = SSL_get_privatekey(ssl);
> +SSL_free(ssl);
> +#endif
> 
>  msg(D_TLS_DEBUG, "Extracting ECDH curve from private key");
>

The code change looks good to me, so ACK to that.

The commit does need a better commit message though, and somewhere in
the process the newlines got mangled.  I think the commit message of
your initial patch is okay, it just missed the Signed-off-by line.  To
smoothen the patch application process, could you create a commit with
the above change, and send it to the list using git send-email?  The
command line would be something like:

git send-email --to=openvpn-devel@lists.sourceforge.net HEAD~1

Otherwise, Gert or David will have to wrestle a commit together from you
various messages, and that will likely take more time before it gets
applied.

Thanks,
-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix building with LibreSSL 2.5.1 by cleaning a hack. Similar to what is done in curl: https://github.com/curl/curl/blob/028391df5d84d9fae3433afdee9261d565900355/lib/vtls/op

[Steffan Karger]

Hi,

On 13-02-17 19:38, O2 Graphics wrote:
> Use SSL_CTX_get0_privatekey() for OpenSSL >= 1.0.2
> 
> Signed-off-by: Olivier Wahrenberger 
> ---
>  src/openvpn/ssl_openssl.c | 14 +++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 8266595..abf69c9 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -508,10 +508,18 @@ tls_ctx_load_ecdh_params(struct tls_root_ctx *ctx, 
> const char *curve_name
>  const EC_GROUP *ecgrp = NULL;
>  EVP_PKEY *pkey = NULL;
>  
> +#if OPENSSL_VERSION_NUMBER >= 0x10002000L && 
> !defined(LIBRESSL_VERSION_NUMBER)
> +pkey = SSL_CTX_get0_privatekey(ctx->ctx);
> +#else
>  /* Little hack to get private key ref from SSL_CTX, yay OpenSSL... */
> -SSL ssl;
> -ssl.cert = ctx->ctx->cert;
> -pkey = SSL_get_privatekey(&ssl);
> +SSL *ssl = SSL_new(ctx->ctx);
> +if (!ssl)
> +{
> +crypto_msg(M_FATAL, "SSL_new failed");
> +}
> +pkey = SSL_get_privatekey(ssl);
> +SSL_free(ssl);
> +#endif
>  
>  msg(D_TLS_DEBUG, "Extracting ECDH curve from private key");
>  
> 

Code still looks good, patch looks a lot better (applies cleanly now),
but could use an extra newline in the subject.  But that doesn't warrant
an extra patch iteration, so ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Feedback wanted: proof-of-concept recvmmsg() support

[Steffan Karger]

Hi David,

Thanks for the comments.

On 25-01-17 18:25, David Sommerseth wrote:
> First of all, not all kernels carry these system calls, I believe they
> were added in some of the 3.x kernels - but, IIRC, it has been
> backported to at least the RHEL6 2.6.32 kernels.  My memory is scarce
> about the 2.6.18 kernel base on RHEL5, but I believe only recvmmsg() is
> supported there.
>
> But kernel support isn't enough.  It needs to be supported in glibc as
> well, where recvmmsg() arrived in glibc-2.12 and sendmmsg() arrived in
> glibc-2.14.  And if glibc support is missing ... there's needed to so
> some tweaks here, having a wrapper which does the proper syscall() with
> SYS_recvmmsg and/or SYS_sendmmsg as the syscall number reference. (see
> /usr/include/bits/syscall.h and man syscall(2) for more info) ... but
> step carefully with such wrappers - as we need to consider
> cross-platforms (not saying we should support this feature on all
> platforms).
>
> So all this considered, configure.ac will need to do some probing if
> recvmmsg() and sendmmsg() are supported.

configure.ac has:

-AC_CHECK_FUNCS([sendmsg recvmsg])
+AC_CHECK_FUNCS([sendmsg recvmsg sendmmsg recvmmsg])

and the calls are inside

+#ifdef HAVE_RECVMMSG

Shouldn't that be enough?

> I know this patch covers recvmmsg() only.  But I think you can gain even
> more performance if looking into sendmmsg() as well.

Yes, but that's a little trickier, because it also need changing the
tun/tap side (we need to read multiple messages there to have some gain
from sendmmsg()).  I decided to do this one thing at a time :)

> I'll try to play a bit with this patch and see how things go on my side
> though.

Great, I am curious about your results.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Allow changing cipher from a ccd file

[Steffan Karger]

As described in msg  <374a7eb7-f539-5231-623b-41f208ed8...@belkam.com> on
openvpn-devel@lists.sourceforge.net, clients that are compiled with
--disable-occ (included in --enable-small) won't send an options string.
Without the options string, the 2.4 server doesn't know which cipher to
use for poor man's NCP.

This patch allows working around that issue by allowing the 'cipher'
directive to be used in --client-config-dir files.  That way, a server
admin can add ccd files to specify per-client which cipher to use.

Because the ccd files are read after where we would normally generate keys,
this patch delays key generation for non-NCP p2mp servers until after
reading the ccd file.

Trac: #845

Signed-off-by: Steffan Karger 
---
v2: postpone p2mp non-NCP key generation, such that setting cipher in
a ccd file for a non-NCP client actually works.

 src/openvpn/multi.c   | 14 ++
 src/openvpn/options.c |  2 +-
 src/openvpn/options.h |  2 +-
 src/openvpn/ssl.c |  9 -
 4 files changed, 20 insertions(+), 7 deletions(-)

diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 56009b7..4c81e9a 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -2086,6 +2086,20 @@ script_failed:
 mi->context.c2.context_auth = cc_succeeded_count ? CAS_PARTIAL : 
CAS_FAILED;
 }
 
+/* Generate tunnel keys, unless IV_NCP >= 2 is negotiated. The first 
key
+ * generation is then postponed until after the pull/push, so we can
+ * process pushed cipher directives.
+ */
+struct tls_session *session = 
&mi->context.c2.tls_multi->session[TM_ACTIVE];
+struct key_state *ks = &session->key[KS_PRIMARY];
+if (!session->opt->ncp_enabled && ks->authenticated
+&& !tls_session_update_crypto_params(session, &mi->context.options,
+ &mi->context.c2.frame))
+{
+msg(D_TLS_ERRORS, "TLS Error: server generate_key_expansion 
failed");
+cc_succeeded = false;
+}
+
 /* set flag so we don't get called again */
 mi->connection_established_flag = true;
 
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index dde1f48..0e6b393 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -7536,7 +7536,7 @@ add_option(struct options *options,
 }
 else if (streq(p[0], "cipher") && p[1] && !p[2])
 {
-VERIFY_PERMISSION(OPT_P_NCP);
+VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
 options->ciphername = p[1];
 }
 else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index a14f2ab..f4f0226 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -628,7 +628,7 @@ struct options
 #define OPT_P_MTU (1<<14) /* TODO */
 #define OPT_P_NICE(1<<15)
 #define OPT_P_PUSH(1<<16)
-#define OPT_P_INSTANCE(1<<17)
+#define OPT_P_INSTANCE(1<<17) /**< Allow usage in ccd file */
 #define OPT_P_CONFIG  (1<<18)
 #define OPT_P_EXPLICIT_NOTIFY (1<<19)
 #define OPT_P_ECHO(1<<20)
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 8c724cb..1479c77 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2401,12 +2401,11 @@ key_method_2_write(struct buffer *buf, struct 
tls_session *session)
 }
 
 /* Generate tunnel keys if we're a TLS server.
- * If we're a p2mp server and IV_NCP >= 2 is negotiated, the first key
- * generation is postponed until after the pull/push, so we can process 
pushed
- * cipher directives.
+ * If we're a p2mp server, the first key generation is postponed so we can
+ * switch cipher during the connection setup phase.
  */
-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)
 {
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

Hi Emmanuel,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> The purpose of this RFC series is to make the latest master of OpenVPN
> (2.5-git) linkable with OpenSSL v1.1.x. It may not be complete (I may
> have missed something due to my work environment, but any missing pieces
> will be added next week) so be a bit cautious with this. The 
> configuration I used (--without-systemd, --without-lzo) seems to work
> but I must confess I did not tested much. 
> 
> As you may know, the important information about the API of OpenSSL 1.1
> if that it no longer provide access to the content of its objects. The
> structure types are now opaque and various functions have been added to
> fetch information from these objects. 
> 
> Once theses patches have been applied, it is possible to compile 
> OpenSSL with the latest 1.0.1 and with the latest 1.1.0. I still have to
> check whether compilation with 1.0.0 and 0.9.8 works. I don't try to 
> get the OpenSSL version -- I instead decided to check for the presence
> of individual functions in the library and chose to reimplement the 
> missing ones. Then I changed caller code in order to use this new
> interface. The net result is that OpenVPN is now using the OpenSSL 1.1
> API -- regardless of the real version of OpenSSL. This might make futur
> changes simpler at the cost of adding more functions in the 
> openssl_compat.h file. 
> 
> Las but not least, because of the way I worked I introduced some strange 
> artefacts (I believe they are not really relevant but some of them are 
> weird enough to need some explaination). 
> 
> * I had to introduce a function of the 1.0 API in the 1.1 code. In the
>   1.0 API, HMAC_CTX is populated with HMAC_CTX_init() and cleaned with
>   HMAC_CTX_cleanup(). In 1.1 these two functions are gone and replaced
>   with HMAC_CTX_reset(). I decided to use _reset() to implement 
>   _cleanup() but since I then could not use it for _init() (that would
>   break an OpenVPN linked with 1.0) I created a small wrapper in 1.1
>   mode. So, in 1.1, HMAC_CTX_init() calls _reset() -- and everybody is
>   happy (well, maybe not everybody).  
>   
> * HMAC_CTX, EVP_MD_CTX and a few other objects cannot be allocated using
>   malloc() so I had to change the way these object are used and 
>   initialized. I introduces a few new functions in the crypto backend to
>   handle this.
> 
> * x509_verify_ns_cert_type() checks had to be changed. OpenSSL 1.1 does 
>   not provide any solution to access both X509::ex_flags and 
>   X509::ex_nscert so the check could not be implemented this way. The
>   only solution I found was to use X509_check_purpose() but I'm worried
>   that the implemented test is now far more strict. 
> 
> * weirdly enough, it's no longer possible to duplicate the n parameter
>   of a RSA public key into another RSA public key. If you do so, you
>   also need to duplicate the e parameter. The reason is that you cannot
>   have (n && !e) or (!n && e) (see RSA_set0_key[1]). I deciced to go
>   the same route in my implementation and thus I needed to change the
>   code in tls_ctx_use_external_private_key(). 
> 
> Thanks for your comprehension, 
> 
> [1] https://github.com/openssl/openssl/blob/master/crypto/rsa/rsa_lib.c#L191
> 
> -- Emmanuel Deloget

Thank you very much.  You approach looks good to me, and quite closely
matches what I had in mind for when I would find the time to tackle
this.  (Which might have taken me a while, so really happy to see these
patches!)

As discussed in other threads, we do want to support building on RHEL6,
which is why we would prefer to be compatible with (patched) OpenSSL
0.9.8.  I haven't tested anything yet, but looking at the patches this
might very well just work, or otherwise just needs some minor tweaking.

Also very good that this is split up into small and independently
reviewable patches.  I'll start review soon.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 14/15] OpenSSL: check for the SSL reason, not the full error

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 changed the SSLv3 API and removed many SSL_L_SSL3_*
> constants. Moreover, new code might use different function
> code for the same error.
> 
> Thus, we extract the error reason from the error code before
> we compare it instead of trying to rebuild an error code
> that might not be correct.
> 
> The new version is compatible with OpenSSL 1.0.x as well as
> with older versions (starting at 0.9.8).
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/crypto_openssl.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index 
> 2f77a9853ac484770dcd808efdf13671ade7e758..23de17542bf0f4a311825373ecf8d8261fd21c73
>  100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -194,8 +194,7 @@ crypto_print_openssl_errors(const unsigned int flags)
>  while ((err = ERR_get_error()))
>  {
>  /* Be more clear about frequently occurring "no shared cipher" error 
> */
> -if (err == ERR_PACK(ERR_LIB_SSL,SSL_F_SSL3_GET_CLIENT_HELLO,
> -SSL_R_NO_SHARED_CIPHER))
> +if (ERR_GET_REASON(err) == SSL_R_NO_SHARED_CIPHER)
>  {
>  msg(D_CRYPT_ERRORS, "TLS error: The server has no TLS 
> ciphersuites "
>  "in common with the client. Your --tls-cipher setting might 
> be "
> 

This patch is correct even outside the context of the transition to 1.1,
and can be applied immediately.  ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

On 19-02-17 15:58, David Sommerseth wrote:
> On 19/02/17 13:03, Steffan Karger wrote:
> 
>> As discussed in other threads, we do want to support building on RHEL6,
>> which is why we would prefer to be compatible with (patched) OpenSSL
>> 0.9.8.  I haven't tested anything yet, but looking at the patches this
>> might very well just work, or otherwise just needs some minor tweaking.
> 
> RHEL6 ships with OpenSSL 1.0.1e.  We don't need anything older for git
> master, and I would even argue release/2.4.
> 
> RHEL5 (which goes EOL by end of next month) ships with OpenSSL 0.9.8e.
> So I vote for ditching 0.9.8e now.

Oh, very good.  I messed up the versions again...

The other big long-term-support distro, SLES, does still ship and
support 0.9.8 in SELS11 until 2019 (2022 for extended support), but can
be updated to 1.0.1.

As far as I'm concerned, that is enough reason to only support OpenSSL
1.0.1+ for OpenVPN 2.4 (and newer).

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

[Steffan Karger]

Hi,

The attached patch from trac #825 fixes a silly bug in my --tls-crypt
code.  I already confirmed this in trac, but now also on the list:

ACK to the attached patch.

-Steffan
>From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
From: "Simon (simix)" 
Date: Tue, 21 Feb 2017 20:34:15 +0100
Subject: [PATCH] Fix segfault when using crypto lib without AES-256-CTR or
 SHA256

Openvpn segfaults on RHEL5/CentOS5 when using --tls-crypt, because it
doesn't have AES-256-CTR support:

openvpn[15330]: OpenVPN 2.4.0 x86_64-redhat-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] built on Jan 17 2017
openvpn[15330]: library versions: OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008, LZO 2.09, LZ4 1.7.5
openvpn[15331]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
kernel: openvpn[15331]: segfault at 0008 rip 0040ebe0 rsp 7fffdcfc5738 error 4

This patch fixes it so it shows:

openvpn[424]: ERROR: --tls-crypt requires AES-256-CTR support.
openvpn[424]: Exiting due to fatal error

Trac: #825
---
 src/openvpn/tls_crypt.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/src/openvpn/tls_crypt.c b/src/openvpn/tls_crypt.c
index a227379..bda14fd 100644
--- a/src/openvpn/tls_crypt.c
+++ b/src/openvpn/tls_crypt.c
@@ -51,9 +51,7 @@ tls_crypt_init_key(struct key_ctx_bi *key, const char *key_file,
 
 struct key_type kt;
 kt.cipher = cipher_kt_get("AES-256-CTR");
-kt.cipher_length = cipher_kt_key_size(kt.cipher);
 kt.digest = md_kt_get("SHA256");
-kt.hmac_length = md_kt_size(kt.digest);
 
 if (!kt.cipher)
 {
@@ -64,6 +62,9 @@ tls_crypt_init_key(struct key_ctx_bi *key, const char *key_file,
 msg(M_FATAL, "ERROR: --tls-crypt requires HMAC-SHA-256 support.");
 }
 
+kt.cipher_length = cipher_kt_key_size(kt.cipher);
+kt.hmac_length = md_kt_size(kt.digest);
+
 crypto_read_openvpn_key(&kt, key, key_file, key_inline, key_direction,
 "Control Channel Encryption", "tls-crypt");
 }
-- 
2.7.4

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including X509_STORE_CTX. We have to use the defined
> functions to do so.
> 
> Fortunately, these functions have existed since the dawn of time so
> we don't have any compatibility issue here.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/ssl_verify_openssl.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/src/openvpn/ssl_verify_openssl.c 
> b/src/openvpn/ssl_verify_openssl.c
> index 
> edc709b89eb05bca895639dde606b29f8e1f7024..5bdd1e3609c4a2693e16c0835a9e5c39babd5ff8
>  100644
> --- a/src/openvpn/ssl_verify_openssl.c
> +++ b/src/openvpn/ssl_verify_openssl.c
> @@ -62,14 +62,15 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  session = (struct tls_session *) SSL_get_ex_data(ssl, mydata_index);
>  ASSERT(session);
>  
> -struct buffer cert_hash = x509_get_sha256_fingerprint(ctx->current_cert, 
> &gc);
> -cert_hash_remember(session, ctx->error_depth, &cert_hash);
> +X509 *current_cert = X509_STORE_CTX_get_current_cert(ctx);
> +struct buffer cert_hash = x509_get_sha256_fingerprint(current_cert, &gc);
> +cert_hash_remember(session, X509_STORE_CTX_get_error_depth(ctx), 
> &cert_hash);
>  
>  /* did peer present cert which was signed by our root cert? */
>  if (!preverify_ok)
>  {
>  /* get the X509 name */
> -char *subject = x509_get_subject(ctx->current_cert, &gc);
> +char *subject = x509_get_subject(current_cert, &gc);
>  
>  if (!subject)
>  {
> @@ -77,11 +78,11 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  }
>  
>  /* Log and ignore missing CRL errors */
> -if (ctx->error == X509_V_ERR_UNABLE_TO_GET_CRL)
> +if (X509_STORE_CTX_get_error(ctx) == X509_V_ERR_UNABLE_TO_GET_CRL)
>  {
>  msg(D_TLS_DEBUG_LOW, "VERIFY WARNING: depth=%d, %s: %s",
> -ctx->error_depth,
> -X509_verify_cert_error_string(ctx->error),
> +X509_STORE_CTX_get_error_depth(ctx),
> +X509_verify_cert_error_string(X509_STORE_CTX_get_error(ctx)),
>  subject);
>  ret = 1;
>  goto cleanup;
> @@ -89,8 +90,8 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  
>  /* Remote site specified a certificate, but it's not correct */
>  msg(D_TLS_ERRORS, "VERIFY ERROR: depth=%d, error=%s: %s",
> -ctx->error_depth,
> -X509_verify_cert_error_string(ctx->error),
> +X509_STORE_CTX_get_error_depth(ctx),
> +X509_verify_cert_error_string(X509_STORE_CTX_get_error(ctx)),
>  subject);
>  
>  ERR_clear_error();
> @@ -99,7 +100,7 @@ verify_callback(int preverify_ok, X509_STORE_CTX *ctx)
>  goto cleanup;
>  }
>  
> -if (SUCCESS != verify_cert(session, ctx->current_cert, ctx->error_depth))
> +if (SUCCESS != verify_cert(session, current_cert, 
> X509_STORE_CTX_get_error_depth(ctx)))
>  {
>  goto cleanup;
>  }
> 

ACK.  Changes look good and tested against OpenSSL 0.9.8, 1.0.0, 1.0.1
and 1.0.2.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

[Steffan Karger]

Hi,

On 21-02-17 22:12, Gert Doering wrote:
> On Tue, Feb 21, 2017 at 08:42:57PM +0100, Steffan Karger wrote:
>> ACK to the attached patch.
> 
>> >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
>> From: "Simon (simix)" 
> 
> All previous commits (I'm aware of) carry a valid e-mail address, and
> most of them have a full name for the author.
> 
> Do we have a policy how to handle patches with missing author info?

I don't know, but thought this was more reasonable than claiming
authorship.  We could try to reach out on trac first, and see if Simon
is willing to provide a full name and email address.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix segfault when using crypto lib without AES-256-CTR or SHA256

[Steffan Karger]

On 22-02-17 08:39, Gert Doering wrote:
> On Wed, Feb 22, 2017 at 02:21:35AM +0100, David Sommerseth wrote:
 >From d97f526a2ddbf2abe60a64260601ebd742fc00cc Mon Sep 17 00:00:00 2001
 From: "Simon (simix)" 
>>>
>>> Do we have a policy how to handle patches with missing author info?
>>
>> I see no reason at all why we should not give proper credit with full
>> name.  
> 
> That was only half the question - of course I *want* to give full credits,
> but is "not having this information available & no SoB line" a reason
> for rejecting a patch?
> 
> The patch in question is quite obvious, so this is not something to bring
> in the lawyers - more a matter of general policy.

Same here.

For this specific patch:  I asked the reporter on trac for full name and
email last night.  We can wait for a bit to see if he replies.

In general: what do we do when we don't get a full name and email, but
do want to apply the patch?  Wait forever?  Claim authorship (but refer
to the trac ticket in the commit msg)?  Apply anyway?  ...?

(While typing this, I realize this sounds like a topic for the meeting
tonight.  I'll put it on the agenda.)

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 09/15] OpenSSL: don't use direct access to the internal of X509_STORE_CTX

[Steffan Karger]

On 22 February 2017 at 15:47, Christian Hesse  wrote:
> Steffan Karger  on Tue, 2017/02/21 22:30:
>> ACK.  Changes look good and tested against OpenSSL 0.9.8, 1.0.0, 1.0.1
>> and 1.0.2.
>
> You answered to a patch in the middle of a series. Does this ACK apply to the
> complete series or just this patch?

Just this one.  Not much brains left last night, so I only reviewed
this rather simple and independent patch out of the series :)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 01/15] OpenSSL: don't use direct access to the internal of SSL_CTX

[Steffan Karger]

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including SSL_CTX. We have to use the defined functions
> to do so.
> 
> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |  9 ++
>  src/openvpn/openssl_compat.h | 74 
> 
>  src/openvpn/ssl_openssl.c| 13 +---
>  3 files changed, 91 insertions(+), 5 deletions(-)
>  create mode 100644 src/openvpn/openssl_compat.h
> 
> diff --git a/configure.ac b/configure.ac
> index 
> b29f8b410dfb69bce1145c3bb4a1ba011f0636ec..5fe5d6046ceafa2b577296af772c347ac2ad8039
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -898,6 +898,15 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   [have_crypto_aead_modes="no"; break]
>   )
>  
> + AC_CHECK_FUNCS(
> + [ \
> + SSL_CTX_get_default_passwd_cb \
> + SSL_CTX_get_default_passwd_cb_userdata \
> + ],
> + ,
> + []
> + )
> +
>   CFLAGS="${saved_CFLAGS}"
>   LIBS="${saved_LIBS}"
>  
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> new file mode 100644
> index 
> ..59bad9ff24d10b358419d345181a0e2e52a0c662
> --- /dev/null
> +++ b/src/openvpn/openssl_compat.h
> @@ -0,0 +1,74 @@
> +/*
> + *  OpenVPN -- An application to securely tunnel IP networks
> + * over a single TCP/UDP port, with support for SSL/TLS-based
> + * session authentication and key exchange,
> + * packet encryption, packet authentication, and
> + * packet compression.
> + *
> + *  Copyright (C) 2002-2017 OpenVPN Technologies, Inc. 
> + *  Copyright (C) 2010-2017 Fox Crypto B.V. 
> + *
> + *  This program is free software; you can redistribute it and/or modify
> + *  it under the terms of the GNU General Public License version 2
> + *  as published by the Free Software Foundation.
> + *
> + *  This program is distributed in the hope that it will be useful,
> + *  but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *  GNU General Public License for more details.
> + *
> + *  You should have received a copy of the GNU General Public License
> + *  along with this program (see the file COPYING included with this
> + *  distribution); if not, write to the Free Software Foundation, Inc.,
> + *  59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
> + */
> +
> +/**
> + * @file OpenSSL compatibility stub
> + *
> + * This file provide compatibility stubs for the OpenSSL libraries
> + * prior to version 1.1. This version introduces many changes in the
> + * library interface, including the fact that various objects and
> + * structures are not fully opaque.
> + */
> +
> +#ifndef OPENSSL_COMPAT_H_
> +#define OPENSSL_COMPAT_H_
> +
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#elif defined(_MSC_VER)
> +#include "config-msvc.h"
> +#endif
> +
> +#include 
> +
> +#if !defined(HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB_USERDATA)
> +/**
> + * Fetch the default password callback user data from the SSL context
> + *
> + * @param ctxSSL context
> + * @return   The password callback user data
> + */
> +static inline void *
> +SSL_CTX_get_default_passwd_cb_userdata(SSL_CTX *ctx)
> +{
> +return ctx ? ctx->default_passwd_callback_userdata : NULL;
> +}
> +#endif
> +
> +#if !defined(HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB)
> +/**
> + * Fetch the default password callback from the SSL context
> + *
> + * @param ctxSSL context
> + * @return   The password callback
> + */
> +static inline pem_password_cb *
> +SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx)
> +{
> +return ctx ? ctx->default_passwd_callback : NULL;
> +}
> +#endif
> +
> +#endif /* OPENSSL_COMPAT_H_ */
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 
> abf69c91a60910e450ae6d2d49ea7e5b1cd3a535..39e92f8cdae52d54d0ad95a9362e4e0e1b2289f4
>  100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -45,6 +45,7 @@
>  #include "ssl_backend.h"
>  #include "ssl_common.h"
>  #include "base64.h"
> +#include "openssl_compat.h"
>  
>  #ifdef ENABLE_CRYPTOAPI
>  #include "cryptoapi.h"
> @@ -658,7 +659,8 @@ tls_ctx_load_pkcs12(struct tls_root_ctx *ctx, const char 
> *pkcs12_file,
>  {
>  for (i = 0; i < sk_X509_num(ca); i++)
>  {
> -if 
> (!X509_STORE_add_cert(ctx->ctx->cert_store,sk_X509_value(ca, i)))
> +X509_STORE *cert_store = SSL_CTX_get_cert_store(ctx->ctx);
> +if (!X509_STORE_add_cert(cert_store,sk

Re: [Openvpn-devel] [RFC PATCH v1 02/15] OpenSSL: don't use direct access to the internal of X509_STORE

[Steffan Karger]

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including X509_STORE. We have to use the defined functions
> to do so.
> 
> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |  1 +
>  src/openvpn/openssl_compat.h | 15 +++
>  src/openvpn/ssl_openssl.c|  7 ---
>  src/openvpn/ssl_verify_openssl.c |  6 --
>  4 files changed, 24 insertions(+), 5 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 
> 5fe5d6046ceafa2b577296af772c347ac2ad8039..415128c9f8687a53e4a73419f3048d07f66b70cc
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -902,6 +902,7 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   [ \
>   SSL_CTX_get_default_passwd_cb \
>   SSL_CTX_get_default_passwd_cb_userdata \
> + X509_STORE_get0_objects \
>   ],
>   ,
>   []
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> 59bad9ff24d10b358419d345181a0e2e52a0c662..016008bc1705a41ee0ee09fecfc0b16b282cede3
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -42,6 +42,7 @@
>  #endif
>  
>  #include 
> +#include 
>  
>  #if !defined(HAVE_SSL_CTX_GET_DEFAULT_PASSWD_CB_USERDATA)
>  /**
> @@ -71,4 +72,18 @@ SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx)
>  }
>  #endif
>  
> +#if !defined(HAVE_X509_STORE_GET0_OBJECTS)
> +/**
> + * Fetch the X509 object stack from the X509 store
> + *
> + * @param store  X509 object store
> + * @return   the X509 object stack
> + */
> +static inline STACK_OF(X509_OBJECT) *
> +X509_STORE_get0_objects(X509_STORE *store)
> +{
> +return store ? store->objs : NULL;
> +}
> +#endif
> +
>  #endif /* OPENSSL_COMPAT_H_ */
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 
> 39e92f8cdae52d54d0ad95a9362e4e0e1b2289f4..e57de43a748c89ff58ea00abade0b1c317013258
>  100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -900,13 +900,14 @@ backend_tls_ctx_reload_crl(struct tls_root_ctx 
> *ssl_ctx, const char *crl_file,
>  /* Always start with a cleared CRL list, for that we
>   * we need to manually find the CRL object from the stack
>   * and remove it */
> -for (int i = 0; i < sk_X509_OBJECT_num(store->objs); i++)
> +STACK_OF(X509_OBJECT) *objs = X509_STORE_get0_objects(store);
> +for (int i = 0; i < sk_X509_OBJECT_num(objs); i++)
>  {
> -X509_OBJECT *obj = sk_X509_OBJECT_value(store->objs, i);
> +X509_OBJECT *obj = sk_X509_OBJECT_value(objs, i);
>  ASSERT(obj);
>  if (obj->type == X509_LU_CRL)
>  {
> -sk_X509_OBJECT_delete(store->objs, i);
> +sk_X509_OBJECT_delete(objs, i);
>  X509_OBJECT_free_contents(obj);
>  OPENSSL_free(obj);
>  }
> diff --git a/src/openvpn/ssl_verify_openssl.c 
> b/src/openvpn/ssl_verify_openssl.c
> index 
> 274e2bbf96b6c943ce628eab143f8c76e1c47103..fabbb0c370b123f54ce4a1eaf5f9650b440f47f8
>  100644
> --- a/src/openvpn/ssl_verify_openssl.c
> +++ b/src/openvpn/ssl_verify_openssl.c
> @@ -43,6 +43,7 @@
>  #include "ssl_openssl.h"
>  #include "ssl_verify.h"
>  #include "ssl_verify_backend.h"
> +#include "openssl_compat.h"
>  
>  #include 
>  #include 
> @@ -715,9 +716,10 @@ tls_verify_crl_missing(const struct tls_options *opt)
>  crypto_msg(M_FATAL, "Cannot get certificate store");
>  }
>  
> -for (int i = 0; i < sk_X509_OBJECT_num(store->objs); i++)
> +STACK_OF(X509_OBJECT) *objs = X509_STORE_get0_objects(store);
> +for (int i = 0; i < sk_X509_OBJECT_num(objs); i++)
>  {
> -X509_OBJECT *obj = sk_X509_OBJECT_value(store->objs, i);
> +X509_OBJECT *obj = sk_X509_OBJECT_value(objs, i);
>  ASSERT(obj);
>  if (obj->type == X509_LU_CRL)
>  {
> 

ACK

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 03/15] OpenSSL: don't use direct access to the internal of X509_OBJECT

[Steffan Karger]

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including X509_OBJECT. We have to use the defined
> functions to do so.
> 
> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |  2 ++
>  src/openvpn/openssl_compat.h | 31 +++
>  src/openvpn/ssl_openssl.c|  5 ++---
>  src/openvpn/ssl_verify_openssl.c |  2 +-
>  4 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 
> 415128c9f8687a53e4a73419f3048d07f66b70cc..789ad08fbaa3b3fc4c95d2b7a22332c0a93aeab4
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -903,6 +903,8 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   SSL_CTX_get_default_passwd_cb \
>   SSL_CTX_get_default_passwd_cb_userdata \
>   X509_STORE_get0_objects \
> + X509_OBJECT_free \
> + X509_OBJECT_get_type \
>   ],
>   ,
>   []
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> 016008bc1705a41ee0ee09fecfc0b16b282cede3..458a6adbe2b3fcd5ea63dcea6596cc24315d463c
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -86,4 +86,35 @@ X509_STORE_get0_objects(X509_STORE *store)
>  }
>  #endif
>  
> +#if !defined(HAVE_X509_OBJECT_FREE)
> +/**
> + * Destroy a X509 object
> + *
> + * @param objX509 object
> + */
> +static inline void
> +X509_OBJECT_free(X509_OBJECT *obj)
> +{
> +if (obj)
> +{
> +X509_OBJECT_free_contents(obj);
> +OPENSSL_free(obj);
> +}
> +}
> +#endif
> +
> +#if !defined(HAVE_X509_OBJECT_GET_TYPE)
> +/**
> + * Get the type of an X509 object
> + *
> + * @param objX509 object
> + * @return   The underlying object type
> + */
> +static inline int
> +X509_OBJECT_get_type(const X509_OBJECT *obj)
> +{
> +return obj ? obj->type : X509_LU_FAIL;
> +}
> +#endif
> +
>  #endif /* OPENSSL_COMPAT_H_ */
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 
> e57de43a748c89ff58ea00abade0b1c317013258..bf0f643f25439f71cbfe71bf5a7e8eb834b0f012
>  100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -905,11 +905,10 @@ backend_tls_ctx_reload_crl(struct tls_root_ctx 
> *ssl_ctx, const char *crl_file,
>  {
>  X509_OBJECT *obj = sk_X509_OBJECT_value(objs, i);
>  ASSERT(obj);
> -if (obj->type == X509_LU_CRL)
> +if (X509_OBJECT_get_type(obj) == X509_LU_CRL)
>  {
>  sk_X509_OBJECT_delete(objs, i);
> -X509_OBJECT_free_contents(obj);
> -OPENSSL_free(obj);
> +X509_OBJECT_free(obj);
>  }
>  }
>  
> diff --git a/src/openvpn/ssl_verify_openssl.c 
> b/src/openvpn/ssl_verify_openssl.c
> index 
> fabbb0c370b123f54ce4a1eaf5f9650b440f47f8..07975248035b48121d1383b47f40a56042bc7380
>  100644
> --- a/src/openvpn/ssl_verify_openssl.c
> +++ b/src/openvpn/ssl_verify_openssl.c
> @@ -721,7 +721,7 @@ tls_verify_crl_missing(const struct tls_options *opt)
>  {
>  X509_OBJECT *obj = sk_X509_OBJECT_value(objs, i);
>  ASSERT(obj);
> -if (obj->type == X509_LU_CRL)
> +if (X509_OBJECT_get_type(obj) == X509_LU_CRL)
>  {
>  return false;
>  }
> 

ACK

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 04/15] OpenSSL: don't use direct access to the internal of RSA_METHOD

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including RSA_METHOD. We have to use the defined
> functions to do so.
> 
> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |   9 +++
>  src/openvpn/openssl_compat.h | 186 
> +++
>  src/openvpn/ssl_openssl.c|  22 ++---
>  3 files changed, 206 insertions(+), 11 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 
> 789ad08fbaa3b3fc4c95d2b7a22332c0a93aeab4..6f31609d0aeedd2c7841d271ecadd1aa6f3b11da
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -905,6 +905,15 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   X509_STORE_get0_objects \
>   X509_OBJECT_free \
>   X509_OBJECT_get_type \
> + RSA_meth_new \
> + RSA_meth_free \
> + RSA_meth_set_pub_enc \
> + RSA_meth_set_pub_dec \
> + RSA_meth_set_priv_enc \
> + RSA_meth_set_priv_dec \
> + RSA_meth_set_init \
> + RSA_meth_set_finish \
> + RSA_meth_set0_app_data \
>   ],
>   ,
>   []
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> 458a6adbe2b3fcd5ea63dcea6596cc24315d463c..b1748754f821f472cf9ed7083ade918336c9b075
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -41,6 +41,8 @@
>  #include "config-msvc.h"
>  #endif
>  
> +#include "buffer.h"
> +
>  #include 
>  #include 
>  
> @@ -117,4 +119,188 @@ X509_OBJECT_get_type(const X509_OBJECT *obj)
>  }
>  #endif
>  
> +#if !defined(HAVE_RSA_METH_NEW)
> +/**
> + * Allocate a new RSA method object
> + *
> + * @param name   The object name
> + * @param flags  Configuration flags
> + * @return   A new RSA method object
> + */
> +static inline RSA_METHOD *
> +RSA_meth_new(const char *name, int flags)
> +{
> +RSA_METHOD *rsa_meth = NULL;
> +ALLOC_OBJ_CLEAR(rsa_meth, RSA_METHOD);
> +rsa_meth->name = name;
> +rsa_meth->flags = flags;
> +return rsa_meth;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_FREE)
> +/**
> + * Free an existing RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + */
> +static inline void
> +RSA_meth_free(RSA_METHOD *meth)
> +{
> +free(meth);
> +}
> +#endif

I think it would be nicer to more closely mimic the 1.1 behaviour in
RSA_meth_{new,free}(), and copy the name string in new() and free it
again in free().  That could prevent a future use-after-free that would
occur for pre-1.1.0, but not 1.1.0+:

  char *mystring = calloc(50, 1);
  RSA_METHOD *meth = RSA_meth_new(mystring, 0);
  free(mystring);

  meth.smoke();
   ^^ might cause problems

(Hint: use string_alloc(x, NULL).)

> +
> +#if !defined(HAVE_RSA_METH_SET_PUB_ENC)
> +/**
> + * Set the public encoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param pub_encthe public encoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_pub_enc(RSA_METHOD *meth,
> + int (*pub_enc) (int flen, const unsigned char *from,
> + unsigned char *to, RSA *rsa,
> + int padding))
> +{
> +if (meth)
> +{
> +meth->rsa_pub_enc = pub_enc;
> +return 1;
> +}
> +return 0;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PUB_DEC)
> +/**
> + * Set the public decoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param pub_decthe public decoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_pub_dec(RSA_METHOD *meth,
> + int (*pub_dec) (int flen, const unsigned char *from,
> + unsigned char *to, RSA *rsa,
> + int padding))
> +{
> +if (meth)
> +{
> +meth->rsa_pub_dec = pub_dec;
> +return 1;
> +}
> +return 0;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PRIV_ENC)
> +/**
> + * Set the private encoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param priv_enc   the private encoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_priv_enc(RSA_METHOD *meth,
> +  int (*priv_enc) (int f

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

[Steffan Karger]

Hi James,

On 22-02-17 19:48, James Yonan wrote:
> mbedTLS 2 has a new feature that allows rejection of certificates if the 
> key size is too small or the signing hash is weak.
> 
> The feature is controlled via struct mbedtls_x509_crt_profile.
> 
> For example, you could specify that certificates must be at least 2048 
> bits and use a SHA-2 signing alg.
> 
> Wondering if we should enable this via an option, or tie it into the 
> existing tls-version-min.
> 
> The granular approach would be to have specific options for each limit, 
> such as ssl-min-key-size, ssl-require-sha2
> 
> The bundled approach would be to take an existing option such as 
> tls-version-min and add additional constraints onto it.  For example, if 
> tls-version-min is 1.2 or higher, then also require minimum key size to 
> be 2048 and certificate signing hash to be SHA-2.

OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
function (SHA1+) if that causes trouble.

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

So I think we'll have to add the relevant --tls-rsa-key-size-min,
--tls-curves (could replace --ecdh-curves), --tls-digests options.  If
we want to make it configurable, that is.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Add openssl_compat.h to openvpn_SOURCES

[Steffan Karger]

On 23-02-17 09:49, Gert Doering wrote:
> Commit b936ddfb63 introduced a new header file but forgot to include
> it in the list of openvpn_SOURCES, so it did not get bundled in the
> generated tarballs.
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/Makefile.am | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/src/openvpn/Makefile.am b/src/openvpn/Makefile.am
> index 3f978553..fcc22d68 100644
> --- a/src/openvpn/Makefile.am
> +++ b/src/openvpn/Makefile.am
> @@ -81,6 +81,7 @@ openvpn_SOURCES = \
>   multi.c multi.h \
>   ntlm.c ntlm.h \
>   occ.c occ.h occ-inline.h \
> + openssl_compat.h \
>   pkcs11.c pkcs11.h pkcs11_backend.h \
>   pkcs11_openssl.c \
>   pkcs11_mbedtls.c \
> 

ACK

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 01/15] OpenSSL: don't use direct access to the internal of SSL_CTX

[Steffan Karger]

On 23-02-17 10:31, Emmanuel Deloget wrote:
>>>  - configure.ac does something to CentOS 6 / RHEL 6 which makes configure
>>>explode:
>>>
>>> ...
>>> checking for linux/if_tun.h... yes
>>> checking tap-windows.h usability... no
>>> checking tap-windows.h presence... no
>>> checking for tap-windows.h... no
>>> checking whether TUNSETPERSIST is declared... yes
>>> checking for setcon in -lselinux... yes
>>> checking for pam_start in -lpam... yes
>>> checking for PKCS11_HELPER... no
>>> ./configure: line 21440: syntax error near unexpected token `fi'
>>> ./configure: line 21440: `fi'
>>
>> This still needs investigation.
> 
> I'm taking the time to install a CentOS 6 on a VM. I'll test this asap.

I have a fix ready, but am busy with testing it on various platforms.

-Steffan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] OpenSSL: 1.1 fallout - fix configure on old autoconf

[Steffan Karger]

Older versions of autoconf generate an empty "else fi" block for empty
fields in an AC_CHECK_FUNCS() macro.  This breaks on e.g. RHEL6.

Signed-off-by: Steffan Karger 
---
 configure.ac | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/configure.ac b/configure.ac
index 546a7d6..79ef52d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -912,9 +912,7 @@ if test "${enable_crypto}" = "yes" -a 
"${with_crypto_library}" = "openssl"; then
X509_STORE_get0_objects \
X509_OBJECT_free \
X509_OBJECT_get_type \
-   ],
-   ,
-   []
+   ]
)
 
CFLAGS="${saved_CFLAGS}"
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

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

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

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

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

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

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

> Wondering what the defaults should be.

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

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

-Steffan

[0] https://shattered.io/

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

Hi,

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

Code makes sense.  Code-ACK.

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

x = first_condition
  && second_condition
  && third_condition

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

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

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

Hi,

On 24-02-17 22:28, James Yonan wrote:
> On 24/02/2017 02:40, Steffan Karger wrote:
>> On 23-02-17 22:41, James Yonan wrote:
>>> On 23/02/2017 01:22, Steffan Karger wrote:
>>>> On 22-02-17 19:48, James Yonan wrote:
>>>>> mbedTLS 2 has a new feature that allows rejection of certificates if the
>>>>> key size is too small or the signing hash is weak.
>>>>>
>>>>> The feature is controlled via struct mbedtls_x509_crt_profile.
>>>>>
>>>>> For example, you could specify that certificates must be at least 2048
>>>>> bits and use a SHA-2 signing alg.
>>>>>
>>>>> Wondering if we should enable this via an option, or tie it into the
>>>>> existing tls-version-min.
>>>>>
>>>>> The granular approach would be to have specific options for each limit,
>>>>> such as ssl-min-key-size, ssl-require-sha2
>>>>>
>>>>> The bundled approach would be to take an existing option such as
>>>>> tls-version-min and add additional constraints onto it.  For example, if
>>>>> tls-version-min is 1.2 or higher, then also require minimum key size to
>>>>> be 2048 and certificate signing hash to be SHA-2.
>>>> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
>>>> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
>>>> function (SHA1+) if that causes trouble.
>>>>
>>>> If we are going to make this configurable, I think we should separate it
>>>> from tls-version-min.  The main use case I see for using a lower
>>>> security setting would be an out-of-the-admins-control CA, or something
>>>> like (old) smart cards that don't support RSA-2048.  I wouldn't want to
>>>> block people from enforcing TLS 1.2, because their smart card is crappy.
>>>>
>>>> So I think we'll have to add the relevant --tls-rsa-key-size-min,
>>>> --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
>>>> we want to make it configurable, that is.
>>> I think it needs to be configurable to allow for transitions to stronger
>>> keys.
>>>
>>> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?
>> Adding 'cert' in the option name is very good, it removes confusion
>> between the TLS transcript digest and the cert digest.
>>
>> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature
>> algorithm, but 'SHAx' is the certificates message digest algorithm.
>>
>> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).
>>
>>> For --tls-cert-sign-min, the choices could be "none" (anything allowed
>>> by the underlying SSL lib) or "sha2" (requiring sha256 or higher).
>> This makes sense for the SHA family, but 'or higher' becomes tricky when
>> e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
>> about that.
> 
> I'm still somewhat on the fence about making these options granular vs. 
> bundled.

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

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

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

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

On 25-02-17 07:04, James Yonan wrote:
> On 24/02/2017 16:10, Steffan Karger wrote:
>> On 24-02-17 22:28, James Yonan wrote:
>>> On 24/02/2017 02:40, Steffan Karger wrote:
>>>> On 23-02-17 22:41, James Yonan wrote:
>>>>> On 23/02/2017 01:22, Steffan Karger wrote:
>>>>>> On 22-02-17 19:48, James Yonan wrote:
>>>>>>> mbedTLS 2 has a new feature that allows rejection of certificates if the
>>>>>>> key size is too small or the signing hash is weak.
>>>>>>>
>>>>>>> The feature is controlled via struct mbedtls_x509_crt_profile.
>>>>>>>
>>>>>>> For example, you could specify that certificates must be at least 2048
>>>>>>> bits and use a SHA-2 signing alg.
>>>>>>>
>>>>>>> Wondering if we should enable this via an option, or tie it into the
>>>>>>> existing tls-version-min.
>>>>>>>
>>>>>>> The granular approach would be to have specific options for each limit,
>>>>>>> such as ssl-min-key-size, ssl-require-sha2
>>>>>>>
>>>>>>> The bundled approach would be to take an existing option such as
>>>>>>> tls-version-min and add additional constraints onto it.  For example, if
>>>>>>> tls-version-min is 1.2 or higher, then also require minimum key size to
>>>>>>> be 2048 and certificate signing hash to be SHA-2.
>>>>>> OpenVPN 2.4 currently just uses mbed TLS' default profile, and we tell
>>>>>> people to use stronger keys (RSA 2048+ / ECDSA) or a stronger hash
>>>>>> function (SHA1+) if that causes trouble.
>>>>>>
>>>>>> If we are going to make this configurable, I think we should separate it
>>>>>> from tls-version-min.  The main use case I see for using a lower
>>>>>> security setting would be an out-of-the-admins-control CA, or something
>>>>>> like (old) smart cards that don't support RSA-2048.  I wouldn't want to
>>>>>> block people from enforcing TLS 1.2, because their smart card is crappy.
>>>>>>
>>>>>> So I think we'll have to add the relevant --tls-rsa-key-size-min,
>>>>>> --tls-curves (could replace --ecdh-curves), --tls-digests options.  If
>>>>>> we want to make it configurable, that is.
>>>>> I think it needs to be configurable to allow for transitions to stronger
>>>>> keys.
>>>>>
>>>>> For naming, how about --tls-rsa-key-size-min and --tls-cert-sign-min?
>>>> Adding 'cert' in the option name is very good, it removes confusion
>>>> between the TLS transcript digest and the cert digest.
>>>>
>>>> 'sign' reads like 'signature', while RSA (or ECDSA) is the signature
>>>> algorithm, but 'SHAx' is the certificates message digest algorithm.
>>>>
>>>> So, I raise you '--tls-cert-digest-min' (or '--tls-cert-md-min'?).
>>>>
>>>>> For --tls-cert-sign-min, the choices could be "none" (anything allowed
>>>>> by the underlying SSL lib) or "sha2" (requiring sha256 or higher).
>>>> This makes sense for the SHA family, but 'or higher' becomes tricky when
>>>> e.g. BLAKE2 enters the arena.  I'm uncertain whether we should worry
>>>> about that.
>>> I'm still somewhat on the fence about making these options granular vs.
>>> bundled.
>> Yeah, I too find it hard to decide what the best approach is here.
>> Being involved in OpenVPN the past few years has definitely learned me
>> the importance of choosing the options right...
>>
>>> If we do granular, then we need to deal with every option, i.e. rsa key
>>> size, cert digests, curves, etc. and we need to establish defaults and a
>>> notion of "minimum" which is problematic as you mention above when new
>>> algs (such as BLAKE2 as you mention above) enter the mix and its not
>>> clear where to place them on the continuum.  Or avoid minimums by simple
>>> enumerating the whole whitelist.  But this can become unwieldy with so
>>> many options.
>>>
>>> Using the bundled approach would be more like the mbedTLS cert profiles
>>> approach where you have a default that allows everything reasonable, and
>>> a somewhat stricter profile tha

Re: [Openvpn-devel] [PATCH] travis-ci: add "make distcheck" to test scenario

[Steffan Karger]

Hi,

On 23-02-17 19:22, Ilya Shipitsin wrote:
> in rare cases openvpn is built from tarball, it happens during "installer 
> build"
> process. "make distcheck" helps to prevent problems during such builds.
> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/.travis.yml b/.travis.yml
> index a68374a..6ebfa39 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -79,6 +79,7 @@ script:
>- if [ "${TRAVIS_OS_NAME}" = "osx"   ]; then export 
> DYLD_LIBRARY_PATH="${PREFIX}/lib:${DYLD_LIBRARY_PATH}"; fi
>- autoreconf -vi
>- ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1)
> +  - make distcheck > build.log 2>&1 || (cat build.log && exit 1)
>- make -j$JOBS
>- src/openvpn/openvpn --version || true
>- if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
> 

Running 'make distcheck' from travis is a good idea.  But, I think it
should be done *after* 'make check'.  Futhermore, it would be nice to
only do this for one of the configurations, to keep our travis runs as
lightweight as possible (saves devs some waiting time, saves travis
energy/capacity).

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add "make distcheck" to test scenario, V2

[Steffan Karger]

On 25-02-17 19:00, Ilya Shipitsin wrote:
> in rare cases openvpn is built from tarball, it happens during "installer 
> build"
> process. "make distcheck" helps to prevent problems during such builds.
> 
> V2: limit "make distcheck" to one build configuration
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index a68374a..3c0aa7d 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -33,7 +33,7 @@ matrix:
>  - env: SSLLIB="mbedtls"
>os: linux
>compiler: clang
> -- env: SSLLIB="openssl" EXTRA_CONFIG="--disable-crypto"
> +- env: SSLLIB="openssl" EXTRA_CONFIG="--disable-crypto" 
> EXTRA_SCRIPT="make distcheck"
>os: linux
>compiler: clang
>  - env: SSLLIB="openssl" EXTRA_CONFIG="--disable-lzo"
> @@ -84,3 +84,4 @@ script:
>- if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
>- if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; fi
>- make check
> +  - $EXTRA_SCRIPT
> 

Thanks, this looks good.  ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

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

[Steffan Karger]

On 28-02-17 06:09, James Yonan wrote:
> On 27/02/2017 18:18, David Sommerseth wrote:
> 
>> On 27/02/17 23:06, James Yonan wrote:
>>> On 25/02/2017 08:40, Steffan Karger wrote:
>> [...snip...]
>>>> I'd say so.  Something like:
>>>>
>>>> legacy: RSA 1024+, SHA1+, all curves
>>>> default: RSA 2048+, SHA2+, all curves
>>>> suiteb: no RSA, SHA256/SHA384, P-256/P-384
>>>>
>>>> As long as we kick anything that's deprecated out of 'default', that
>>>> should probably suffice.
>>> That sounds good, but I'm thinking that we should probably name
>>> "default" something else, such as "standard", so there's no confusion
>>> between the cert profile name, and which cert profile is chosen by
>>> default which may vary according to app preferences/settings.
>>>
>>> For example in mobile clients, we would probably need an app-level
>>> setting to indicate whether "legacy" or "standard" should be the
>>> default, but that would be confusing if "default" was actually a profile
>>> name.
>> There's a narrow edge here before it becomes bike-shedding; I do try to
>> avoid that ... but what about:  legacy, preferred and suiteb ?
>>
>> "Standard" just sounds a bit too static to me, that is not something
>> which changes much.  So in 5 or 10 years from now, "standard" may just
>> as much be "legacy".  Hence my suggestion for "preferred"; this is what
>> we prefer now.  "legacy" is what we used and can even include what we
>> preferred earlier.
> 
> I'm okay with legacy, preferred and suiteb.

Me too.

-Steffan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3 04/15] OpenSSL: don't use direct access to the internal of RSA_METHOD

[Steffan Karger]

Hi,

On 23-02-17 15:35, Emmanuel Deloget wrote:
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including RSA_METHOD. We have to use the defined
> functions to do so.
> 
> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |   9 ++
>  src/openvpn/openssl_compat.h | 190 
> +++
>  src/openvpn/ssl_openssl.c|  22 ++---
>  3 files changed, 210 insertions(+), 11 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 
> 0c55d78327597a0690fa9625e06adb8b055852b1..2406ad8d6bf10f202d3fc1e9b971bc8ec135bd4f
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -905,6 +905,15 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   X509_STORE_get0_objects \
>   X509_OBJECT_free \
>   X509_OBJECT_get_type \
> + RSA_meth_new \
> + RSA_meth_free \
> + RSA_meth_set_pub_enc \
> + RSA_meth_set_pub_dec \
> + RSA_meth_set_priv_enc \
> + RSA_meth_set_priv_dec \
> + RSA_meth_set_init \
> + RSA_meth_set_finish \
> + RSA_meth_set0_app_data \
>   ]
>   )
>  
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> 458a6adbe2b3fcd5ea63dcea6596cc24315d463c..e98e8dffc5773d73684398ae28215d4fdccac3c4
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -41,6 +41,8 @@
>  #include "config-msvc.h"
>  #endif
>  
> +#include "buffer.h"
> +
>  #include 
>  #include 
>  
> @@ -117,4 +119,192 @@ X509_OBJECT_get_type(const X509_OBJECT *obj)
>  }
>  #endif
>  
> +#if !defined(HAVE_RSA_METH_NEW)
> +/**
> + * Allocate a new RSA method object
> + *
> + * @param name   The object name
> + * @param flags  Configuration flags
> + * @return   A new RSA method object
> + */
> +static inline RSA_METHOD *
> +RSA_meth_new(const char *name, int flags)
> +{
> +RSA_METHOD *rsa_meth = NULL;
> +ALLOC_OBJ_CLEAR(rsa_meth, RSA_METHOD);
> +rsa_meth->name = string_alloc(name, NULL);
> +rsa_meth->flags = flags;
> +return rsa_meth;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_FREE)
> +/**
> + * Free an existing RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + */
> +static inline void
> +RSA_meth_free(RSA_METHOD *meth)
> +{
> +if (meth)
> +{
> +free(meth->name);
> +free(meth);
> +}
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PUB_ENC)
> +/**
> + * Set the public encoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param pub_encthe public encoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_pub_enc(RSA_METHOD *meth,
> + int (*pub_enc) (int flen, const unsigned char *from,
> + unsigned char *to, RSA *rsa,
> + int padding))
> +{
> +if (meth)
> +{
> +meth->rsa_pub_enc = pub_enc;
> +return 1;
> +}
> +return 0;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PUB_DEC)
> +/**
> + * Set the public decoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param pub_decthe public decoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_pub_dec(RSA_METHOD *meth,
> + int (*pub_dec) (int flen, const unsigned char *from,
> + unsigned char *to, RSA *rsa,
> + int padding))
> +{
> +if (meth)
> +{
> +meth->rsa_pub_dec = pub_dec;
> +return 1;
> +}
> +return 0;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PRIV_ENC)
> +/**
> + * Set the private encoding function of an RSA_METHOD object
> + *
> + * @param meth   The RSA_METHOD object
> + * @param priv_enc   the private encoding function
> + * @return   1 on success, 0 on error
> + */
> +static inline int
> +RSA_meth_set_priv_enc(RSA_METHOD *meth,
> +  int (*priv_enc) (int flen, const unsigned char *from,
> +   unsigned char *to, RSA *rsa,
> +   int padding))
> +{
> +if (meth)
> +{
> +meth->rsa_priv_enc = priv_enc;
> +return 1;
> +}
> +return 0;
> +}
> +#endif
> +
> +#if !defined(HAVE_RSA_METH_SET_PRIV_DEC)
> +/**
> + * Set the private decoding function of an RSA

Re: [Openvpn-devel] [RFC PATCH v1 05/15] OpenSSL: don't use direct access to the internal of X509

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> OpenSSL 1.1 does not allow us to directly access the internal of
> any data type, including X509. We have to use the defined
> functions to do so.
> 
> In x509_verify_ns_cert_type() in particular, this means that we
> cannot directly check for the extended flags to find whether the
> certificate should be used as a client or as a server certificate.
> We need to leverage the X509_check_purpose() API yet this API is
> far stricter than the currently implemented check. So far, I have
> not been able to find a situation where this stricter test fails
> (although I must admit that I haven't tested that very well).

The nsCertType x509 extension is very old, and replaced by keyUsage and
extendedKeyUsage (supported by OpenVPN via --remote-cert-tls or
--remote-cert-ku and --remote-cert-eku).

Changing this to the stricter API without warning will probably break
some people's setups with certs that do have nsCertType set, but not
keyUsage and/or extendedKeyUsage, while leaving them guessing why.

So, what I propose instead is:
 * remove all the nsCertType code (except the option in add_option())
 * update the help strings and man page to indicate that --ns-cert-type
is no longer supported and --remote-cert-tls should be used instead
 * in add_option(), if the option is enabled in a config file, act as if
--remote-cert-tls was specified correspondingly, and print a clear
warning that --ns-cert-type is no longer supported and stricter checks
are enabled instead.

> Compatibility with OpenSSL 1.0 is kept by defining the corresponding
> functions when they are not found in the library.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  configure.ac |  1 +
>  src/openvpn/openssl_compat.h | 15 +++
>  src/openvpn/ssl_openssl.c|  3 ++-
>  src/openvpn/ssl_verify_openssl.c | 28 +++-
>  4 files changed, 37 insertions(+), 10 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 
> 6f31609d0aeedd2c7841d271ecadd1aa6f3b11da..c41db3effbb26318be4f44009a5055e808b89b56
>  100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -902,6 +902,7 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   [ \
>   SSL_CTX_get_default_passwd_cb \
>   SSL_CTX_get_default_passwd_cb_userdata \
> + X509_get0_pubkey \
>   X509_STORE_get0_objects \
>   X509_OBJECT_free \
>   X509_OBJECT_get_type \
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> b1748754f821f472cf9ed7083ade918336c9b075..6a89b91b05e0370a50ac5a1cae20ae659e6c7634
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -74,6 +74,21 @@ SSL_CTX_get_default_passwd_cb(SSL_CTX *ctx)
>  }
>  #endif
>  
> +#if !defined(HAVE_X509_GET0_PUBKEY)
> +/**
> + * Get the public key from a X509 certificate
> + *
> + * @param x  X509 certificate
> + * @return   The certificate public key
> + */
> +static inline EVP_PKEY *
> +X509_get0_pubkey(const X509 *x)
> +{
> +return (x && x->cert_info && x->cert_info->key) ?
> +   x->cert_info->key->pkey : NULL;
> +}
> +#endif
> +
>  #if !defined(HAVE_X509_STORE_GET0_OBJECTS)
>  /**
>   * Fetch the X509 object stack from the X509 store
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 
> f011e06702529ff34e91f6d0169d1adf8cc9d767..b683961d9e4e79b9ee04cfa7ecd1b377ade9651b
>  100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -1073,7 +1073,8 @@ tls_ctx_use_external_private_key(struct tls_root_ctx 
> *ctx,
>  }
>  
>  /* get the public key */
> -ASSERT(cert->cert_info->key->pkey); /* NULL before 
> SSL_CTX_use_certificate() is called */
> +EVP_PKEY *pkey = X509_get0_pubkey(cert);
> +ASSERT(pkey); /* NULL before SSL_CTX_use_certificate() is called */
>  pub_rsa = cert->cert_info->key->pkey->pkey.rsa;
>  
>  /* initialize RSA object */
> diff --git a/src/openvpn/ssl_verify_openssl.c 
> b/src/openvpn/ssl_verify_openssl.c
> index 
> 07975248035b48121d1383b47f40a56042bc7380..edc709b89eb05bca895639dde606b29f8e1f7024
>  100644
> --- a/src/openvpn/ssl_verify_openssl.c
> +++ b/src/openvpn/ssl_verify_openssl.c
> @@ -285,18 +285,20 @@ backend_x509_get_serial_hex(openvpn_x509_cert_t *cert, 
> struct gc_arena *gc)
>  struct buffer
>  x509_get_sha1_fingerprint(X509 *cert, struct gc_arena *gc)
>  {
> -struct buffer hash = alloc_buf_gc(sizeof(cert->sha1_hash), gc);
> -memcpy(BPTR(&hash), cert->sha1_hash, sizeof(cert->sha1_hash));
> -ASSERT(buf_inc_len(&hash, sizeof(cert->sha1_hash)));
> +const EVP_MD *sha1 = EVP_sha1();
> +struct buffer hash = alloc_buf_gc(EVP_MD_size(sha1), gc);
> +X509_digest(cert, EVP_sha1(), BPTR(&hash), NULL);
> +ASSERT(buf_inc_len

Re: [Openvpn-devel] [RFC PATCH v1 13/15] OpenSSL: SSLeay symbols are no longer available in OpenSSL 1.1

[Steffan Karger]

Hi,

On 17-02-17 23:00, log...@free.fr wrote:
> From: Emmanuel Deloget 
> 
> The old symbols do not exist anymore but the library gained new
> equivalent symbols (OSSL). Use them instead of the old ones
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/openssl_compat.h | 5 +
>  src/openvpn/ssl_openssl.c| 2 +-
>  2 files changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/src/openvpn/openssl_compat.h b/src/openvpn/openssl_compat.h
> index 
> f81ec59c134fb6da2b802e66339ecd0d67040928..054fd56cd1833bb5278eb5fd88a4c4d1908d6415
>  100644
> --- a/src/openvpn/openssl_compat.h
> +++ b/src/openvpn/openssl_compat.h
> @@ -601,4 +601,9 @@ RSA_meth_set0_app_data(RSA_METHOD *meth, void *app_data)
>  }
>  #endif
>  
> +/* SSLeay symbols have been renamed in OpenSSL 1.1 */
> +#if !defined(RSA_F_RSA_OSSL_PRIVATE_ENCRYPT)
> +#define RSA_F_RSA_OSSL_PRIVATE_ENCRYPT   RSA_F_RSA_EAY_PRIVATE_ENCRYPT
> +#endif
> +
>  #endif /* OPENSSL_COMPAT_H_ */
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index 
> a9ae20f45fe60d35af97e7d14bfd2332f9360c30..2ff3e12b93d6f829e4b27aefc2622d52e41ce589
>  100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -996,7 +996,7 @@ rsa_priv_enc(int flen, const unsigned char *from, 
> unsigned char *to, RSA *rsa, i
>  
>  if (padding != RSA_PKCS1_PADDING)
>  {
> -RSAerr(RSA_F_RSA_EAY_PRIVATE_ENCRYPT, RSA_R_UNKNOWN_PADDING_TYPE);
> +RSAerr(RSA_F_RSA_OSSL_PRIVATE_ENCRYPT, RSA_R_UNKNOWN_PADDING_TYPE);
>  goto done;
>  }
>  
> 

ACK

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v2 15/15] OpenSSL: use EVP_CipherInit_ex() instead of EVP_CipherInit()

[Steffan Karger]

Hi,

On 20-02-17 15:32, Emmanuel Deloget wrote:
> The behavior of EVP_CipherInit() changed in OpenSSL 1.1 -- instead
> of clearing the context when the cipher parameter was !NULL, it now
> clears the context unconditionnaly. As a result, subsequent calls
> to the function with additional information now fails.
> 
> The bulk work is done by EVP_CipherInit_ex() which has been part of the
> OpenSSL interface since the dawn of time (0.9.8 already has it). Thus,
> the change allows us to get the old behavior back instead of relying
> on dirty tricks.
> 
> Signed-off-by: Emmanuel Deloget 
> ---
>  src/openvpn/crypto_openssl.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
> index 23de175..2bca88b 100644
> --- a/src/openvpn/crypto_openssl.c
> +++ b/src/openvpn/crypto_openssl.c
> @@ -683,7 +683,7 @@ cipher_ctx_init(EVP_CIPHER_CTX *ctx, uint8_t *key, int 
> key_len,
>  crypto_msg(M_FATAL, "EVP set key size");
>  }
>  #endif
> -if (!EVP_CipherInit(ctx, NULL, key, NULL, enc))
> +if (!EVP_CipherInit_ex(ctx, NULL, NULL, key, NULL, enc))
>  {
>  crypto_msg(M_FATAL, "EVP cipher init #2");
>  }
> @@ -736,7 +736,7 @@ cipher_ctx_get_cipher_kt(const cipher_ctx_t *ctx)
>  int
>  cipher_ctx_reset(EVP_CIPHER_CTX *ctx, uint8_t *iv_buf)
>  {
> -return EVP_CipherInit(ctx, NULL, NULL, iv_buf, -1);
> +return EVP_CipherInit_ex(ctx, NULL, NULL, NULL, iv_buf, -1);
>  }
>  
>  int
> 

ACK

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [RFC PATCH v1 05/15] OpenSSL: don't use direct access to the internal of X509

[Steffan Karger]

Hi,

On 02-03-17 22:26, Gert Doering wrote:
> On Thu, Mar 02, 2017 at 09:36:32PM +0100, Steffan Karger wrote:
>> So, what I propose instead is:
>>  * remove all the nsCertType code (except the option in add_option())
>>  * update the help strings and man page to indicate that --ns-cert-type
>> is no longer supported and --remote-cert-tls should be used instead
>>  * in add_option(), if the option is enabled in a config file, act as if
>> --remote-cert-tls was specified correspondingly, and print a clear
>> warning that --ns-cert-type is no longer supported and stricter checks
>> are enabled instead.
> 
> Mmmmh.  Is there a way to get the old behaviour with OpenSSL 1.1?
> 
> We decided that we do want 1.1 compatibility in release/2.4, but what
> you propose might break people's working config when upgrading from 2.4.1
> to 2.4.2 - bad enough if we make mistakes, but if there is an alternative
> to consciously changing cert validation behaviour in the middle of a
> release train, we should look again...

So I looked again, and there really seems to be no way to get the old
behaviour with OpenSSL 1.1.  However, the exact behaviour of
X509_check_purpose() is not as strict as I initially thought.  The
current patch basically adds the following checks:
 * if the cert has key usage set, it must be correct
 * if the cert has extended key usage set, it must be correct
 * if the cert has the CA flag set, it must be done correctly

These are fairly low-risk.  I'd expect quite some issues if we would
reject certs *without* (extended) key usage set, but if (e)ku is set,
this will most likely be done correctly.  Or in other words, we might
reject weird certificates, but not proper certificates.

All in all, I think the original patch (after fixing const correctness)
is fine.

As a last resort, we could consider keeping the old code inside #if
OSSL_VER < 1.1.0 in release/2.4, but that might just create more
confusion...

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Deprecate --ns-cert-type

[Steffan Karger]

The nsCertType x509 extension is very old, and barely used.  We already
have had an alternative for a long time: --remote-cert-tls uses the far
more common keyUsage and extendedKeyUsage extensions instead.

OpenSSL 1.1 longer exposes an API to (separately) check the nsCertType x509
extension.  Since we want be able to migrate to OpenSSL 1.1, we should
deprecate this option immediately.

Signed-off-by: Steffan Karger 
---
 Changes.rst  | 13 +++--
 doc/openvpn.8|  8 ++--
 src/openvpn/init.c   |  4 
 src/openvpn/options.c|  4 ++--
 tests/t_client.rc-sample |  2 +-
 5 files changed, 24 insertions(+), 7 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 7ffd89e..0af29e3 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -1,5 +1,5 @@
-Version 2.4.0
-=
+Overview of changes in 2.4
+==
 
 
 New features
@@ -302,3 +302,12 @@ Maintainer-visible changes
   header combinations.  In most of these situations it is recommended to
   use -std=gnu99 in CFLAGS.  This is known to be needed when doing
   i386/i686 builds on RHEL5.
+
+
+Version 2.4.1
+=
+ - ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
+   The nsCertType x509 extension is very old, and barely used.
+   ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
+   extension instead.  Make sure your certificates carry these to be able to
+   use ``--remote-cert-tls``.
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index e3d603e..f6822ec 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -327,7 +327,7 @@ http\-proxy 192.168.0.8 8080
 persist\-key
 persist\-tun
 pkcs12 client.p12
-ns\-cert\-type server
+remote\-cert\-tls server
 verb 3
 .in -4
 .ft
@@ -5313,7 +5313,11 @@ as X509__=.  Multiple
 options can be defined to track multiple attributes.
 .\"*
 .TP
-.B \-\-ns\-cert\-type client|server
+.B \-\-ns\-cert\-type client|server (DEPRECATED)
+This option is deprecated.  Use the more modern equivalent
+.B \-\-remote\-cert\-tls
+instead.  This option will be removed in OpenVPN 2.5.
+
 Require that peer certificate was signed with an explicit
 .B nsCertType
 designation of "client" or "server".
diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 975700b..5c34cda 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -2979,6 +2979,10 @@ do_option_warnings(struct context *c)
 {
 msg(M_WARN, "WARNING: No server certificate verification method has 
been enabled.  See http://openvpn.net/howto.html#mitm for more info.");
 }
+if (o->ns_cert_type)
+{
+msg(M_WARN, "WARNING: --ns-cert-type is DEPRECATED.  Use 
--remote-cert-tls instead.");
+}
 #endif /* ifdef ENABLE_CRYPTO */
 
 /* If a script is used, print appropiate warnings */
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 0e6b393..1243db0 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -635,8 +635,8 @@ static const char usage_message[] =
 "--verify-x509-name name: Accept connections only from a host with X509 
subject\n"
 "  DN name. The remote host must also pass all other 
tests\n"
 "  of verification.\n"
-"--ns-cert-type t: Require that peer certificate was signed with an 
explicit\n"
-"  nsCertType designation t = 'client' | 'server'.\n"
+"--ns-cert-type t: (DEPRECATED) Require that peer certificate was signed 
with \n"
+"  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
diff --git a/tests/t_client.rc-sample b/tests/t_client.rc-sample
index 4fdea48..355e8bb 100644
--- a/tests/t_client.rc-sample
+++ b/tests/t_client.rc-sample
@@ -40,7 +40,7 @@ TEST_RUN_LIST="1 2"
 #
 OPENVPN_BASE_P2MP="--client --ca $CA_CERT \
--cert $CLIENT_CERT --key $CLIENT_KEY \
-   --ns-cert-type server --nobind --comp-lzo --verb 3"
+   --remote-cert-tls server --nobind --comp-lzo --verb 3"
 
 # base config for p2p tests
 #
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH applied] Re: OpenSSL: don't use direct access to the internal of RSA_METHOD

[Steffan Karger]

On 05-03-17 10:53, Gert Doering wrote:
> Small side note: I assume that RSA_meth_new() can fail and return NULL
> in OpenSSL 1.1?  Because for 1.0, the "check_malloc_return(rsa_meth)" call 
> isn't necessary, as ALLOC_OBJ_CLEAR() would call ALLOC_OBJ() and that
> already checks...  (mentioning this here in case someone wonders and goes
> to the list archives).

For the archives: yes, RSA_meth_new() indeed returns NULL if it's
internal malloc() call fails.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] could be gitlab-ci an alternative to buildbot cloud?

[Steffan Karger]

Hi,

On 05-03-17 15:25, Илья Шипицин wrote:
> there was some buzz related to improvement of testing system, like
> patchwork.
> we tried gitlab-ci on our internal project, it looks very promising.
> 
> since openvpn is already hosted on gitlab.com ,
> there's a possibility of
> 
> 1) users can add their own gitlab-ci agents to the repo
> 2) it might be even windows agents
> 3) build results are publicly available (not easy to get from buildbot)
> 
> it looks like a big step, and it is hard to predict its result. but, I
> think we can try and have a look at it.
> thoughts?

Does this mean that gitlab (as in, the company) controls the build
slaves?  Or should we host our own gitlab-ci-master to control the slaves?

I currently don't contribute any slaves to the buildbot setup, but I for
one would never want to give gitlab root on my machines.  Quite some
OpenVPN functionality requires root, which makes it more tricky to test.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Remove duplicate X509 env variables

[Steffan Karger]

Commit 13b585e8 added support for multiple X509 env variables with the
same name, but as a side effect caused these variables to pile up for
each renegotiation.  The old code would simply overwrite the old variables
(as long as an equally-long chain was used for the new session).

To stop the variables from piling up, this commit removes any old X509
env variables if we start negotiating a new TLS session.

Trac: #854

Signed-off-by: Steffan Karger 
---
 src/openvpn/ssl.c|  3 +++
 src/openvpn/ssl_verify.c | 17 +
 src/openvpn/ssl_verify.h |  3 +++
 3 files changed, 23 insertions(+)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 401b8fd..1189f56 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -2821,6 +2821,9 @@ tls_process(struct tls_multi *multi,
session->opt->crl_file, 
session->opt->crl_file_inline);
 }
 
+/* New connection, remove any old X509 env variables */
+tls_x509_clear_env(session->opt->es);
+
 dmsg(D_TLS_DEBUG_MED, "STATE S_START");
 }
 
diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index 9f12ab8..a6e9be3 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -1486,4 +1486,21 @@ verify_final_auth_checks(struct tls_multi *multi, struct 
tls_session *session)
 gc_free(&gc);
 }
 }
+
+void
+tls_x509_clear_env(struct env_set *es)
+{
+struct env_item *item = es->list;
+while (item)
+{
+struct env_item *next = item->next;
+if (item->string
+&& 0 == strncmp("X509_", item->string, strlen("X509_")))
+{
+env_set_del(es, item->string);
+}
+item = next;
+}
+}
+
 #endif /* ENABLE_CRYPTO */
diff --git a/src/openvpn/ssl_verify.h b/src/openvpn/ssl_verify.h
index ffab218..d91799e 100644
--- a/src/openvpn/ssl_verify.h
+++ b/src/openvpn/ssl_verify.h
@@ -238,6 +238,9 @@ tls_client_reason(struct tls_multi *multi)
 #endif
 }
 
+/** Remove any X509_ env variables from env_set es */
+void tls_x509_clear_env(struct env_set *es);
+
 #endif /* ENABLE_CRYPTO */
 
 #endif /* SSL_VERIFY_H_ */
-- 
2.7.4


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix types in WIN32 socket_listen_accept()

[Steffan Karger]

SOCKET_UNDEFINED is of type socket_descriptor_t (or SOCKET, in MS types),
so new_sd should be too.  Also, the return value of this function is
always stored in a socket_descriptor_t variable, so it should return that
type (which makes sense now, because it returns new_sd) instead of an int.

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

diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 6aa2e6d..672634a 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1146,7 +1146,7 @@ tcp_connection_established(const struct 
link_socket_actual *act)
 gc_free(&gc);
 }
 
-static int
+static socket_descriptor_t
 socket_listen_accept(socket_descriptor_t sd,
  struct link_socket_actual *act,
  const char *remote_dynamic,
@@ -1158,7 +1158,7 @@ socket_listen_accept(socket_descriptor_t sd,
 struct gc_arena gc = gc_new();
 /* struct openvpn_sockaddr *remote = &act->dest; */
 struct openvpn_sockaddr remote_verify = act->dest;
-int new_sd = SOCKET_UNDEFINED;
+socket_descriptor_t new_sd = SOCKET_UNDEFINED;
 
 CLEAR(*act);
 socket_do_listen(sd, local, do_listen, true);
-- 
2.7.4


--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix windows-specific format specifiers

[Steffan Karger]

A number of printf-like functions in windows-specific code used incorrect
format specifiers, which could potentially lead to incorrect values being
printed.

Signed-off-by: Steffan Karger 
---
 src/openvpn/route.c  | 12 ++--
 src/openvpn/socket.c |  6 +++---
 src/openvpn/tun.c|  4 ++--
 3 files changed, 11 insertions(+), 11 deletions(-)

diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index fec1c25..25b5fce 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1967,12 +1967,12 @@ add_route_ipv6(struct route_ipv6 *r6, const struct 
tuntap *tt, unsigned int flag
 struct buffer out = alloc_buf_gc(64, &gc);
 if (r6->adapter_index)  /* vpn server special route */
 {
-buf_printf(&out, "interface=%d", r6->adapter_index );
+buf_printf(&out, "interface=%lu", r6->adapter_index );
 gateway_needed = true;
 }
 else
 {
-buf_printf(&out, "interface=%d", tt->adapter_index );
+buf_printf(&out, "interface=%lu", tt->adapter_index );
 }
 device = buf_bptr(&out);
 
@@ -2406,12 +2406,12 @@ delete_route_ipv6(const struct route_ipv6 *r6, const 
struct tuntap *tt, unsigned
 struct buffer out = alloc_buf_gc(64, &gc);
 if (r6->adapter_index)  /* vpn server special route */
 {
-buf_printf(&out, "interface=%d", r6->adapter_index );
+buf_printf(&out, "interface=%lu", r6->adapter_index );
 gateway_needed = true;
 }
 else
 {
-buf_printf(&out, "interface=%d", tt->adapter_index );
+buf_printf(&out, "interface=%lu", tt->adapter_index );
 }
 device = buf_bptr(&out);
 
@@ -2832,7 +2832,7 @@ get_default_gateway_ipv6(struct route_ipv6_gateway_info 
*rgi6,
 goto done;
 }
 
-msg( D_ROUTE, "GDG6: II=%d DP=%s/%d NH=%s",
+msg( D_ROUTE, "GDG6: II=%lu DP=%s/%u NH=%s",
  BestRoute.InterfaceIndex,
  print_in6_addr( BestRoute.DestinationPrefix.Prefix.Ipv6.sin6_addr, 0, 
&gc),
  BestRoute.DestinationPrefix.PrefixLength,
@@ -2993,7 +2993,7 @@ do_route_service(const bool add, const route_message_t 
*rt, const size_t size, H
 
 if (ack.error_number != NO_ERROR)
 {
-msg(M_WARN, "ROUTE: route %s failed using service: %s [status=%u 
if_index=%lu]",
+msg(M_WARN, "ROUTE: route %s failed using service: %s [status=%u 
if_index=%d]",
 (add ? "addition" : "deletion"), strerror_win32(ack.error_number, 
&gc),
 ack.error_number, rt->iface.index);
 goto out;
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index c1c0eaa..12085e6 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1119,7 +1119,7 @@ socket_do_accept(socket_descriptor_t sd,
 
 if (!socket_defined(new_sd))
 {
-msg(D_LINK_ERRORS | M_ERRNO, "TCP: accept(%d) failed", sd);
+msg(D_LINK_ERRORS | M_ERRNO, "TCP: accept(%"PRIuPTR") failed", sd);
 }
 /* only valid if we have remote_len_af!=0 */
 else if (remote_len_af && remote_len != remote_len_af)
@@ -1872,13 +1872,13 @@ phase2_inetd(struct link_socket *sock, const struct 
frame *frame,
 if (getsockname(sock->sd, &local_addr.addr.sa, &addrlen) == 0)
 {
 sock->info.lsa->actual.dest.addr.sa.sa_family = 
local_addr.addr.sa.sa_family;
-dmsg(D_SOCKET_DEBUG, "inetd(%s): using sa_family=%d from 
getsockname(%d)",
+dmsg(D_SOCKET_DEBUG, "inetd(%s): using sa_family=%d from 
getsockname(%"PRIuPTR")",
  proto2ascii(sock->info.proto, sock->info.af, false),
  local_addr.addr.sa.sa_family, sock->sd);
 }
 else
 {
-msg(M_WARN, "inetd(%s): getsockname(%d) failed, using AF_INET",
+msg(M_WARN, "inetd(%s): getsockname(%"PRIuPTR") failed, using 
AF_INET",
 proto2ascii(sock->info.proto, sock->info.af, false), 
sock->sd);
 }
 }
diff --git a/src/openvpn/tun.c b/src/openvpn/tun.c
index 3504fbf..0b13310 100644
--- a/src/openvpn/tun.c
+++ b/src/openvpn/tun.c
@@ -125,7 +125,7 @@ do_address_service(const bool add, const short family, 
const struct tuntap *tt)
 
 if (ack.error_number != NO_ERROR)
 {
-msg(M_WARN, "TUN: %s address failed using service: %s [status=%u 
if_index=%lu]",
+msg(M_WARN, "TUN: %s address failed using service: %s [status=%u 
if_index=%d]",
 (add ? "adding" : "deleting&quo

Re: [Openvpn-devel] [PATCH] Fix windows-specific format specifiers

[Steffan Karger]

On 09-03-17 13:23, Steffan Karger wrote:
> A number of printf-like functions in windows-specific code used incorrect
> format specifiers, which could potentially lead to incorrect values being
> printed.

Hm, some of these are not windows-specific, and cause problems for
non-windows builds.  Please hold your breath for a V2.

-Steffan



--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Fix windows-build format specifiers

[Steffan Karger]

A number of printf-like functions used incorrect format specifiers for
Windows builds, which could potentially lead to incorrect values being
printed / used when calling executables.

Signed-off-by: Steffan Karger 
---
v2: add OVPN_PRI_SKT define to print socket type across platforms

 src/openvpn/init.c|  2 +-
 src/openvpn/route.c   | 12 ++--
 src/openvpn/socket.c  |  7 ---
 src/openvpn/syshead.h |  2 ++
 src/openvpn/tun.c |  4 ++--
 5 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 033318d..2a9a398 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -1585,7 +1585,7 @@ do_open_tun(struct context *c)
 #ifdef _WIN32
 /* 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);
+msg(D_ROUTE, "interactive service msg_channel=%"PRIuPTR, (uintptr_t) 
c->options.msg_channel);
 #endif
 
 /* allocate route list structure */
diff --git a/src/openvpn/route.c b/src/openvpn/route.c
index fec1c25..25b5fce 100644
--- a/src/openvpn/route.c
+++ b/src/openvpn/route.c
@@ -1967,12 +1967,12 @@ add_route_ipv6(struct route_ipv6 *r6, const struct 
tuntap *tt, unsigned int flag
 struct buffer out = alloc_buf_gc(64, &gc);
 if (r6->adapter_index)  /* vpn server special route */
 {
-buf_printf(&out, "interface=%d", r6->adapter_index );
+buf_printf(&out, "interface=%lu", r6->adapter_index );
 gateway_needed = true;
 }
 else
 {
-buf_printf(&out, "interface=%d", tt->adapter_index );
+buf_printf(&out, "interface=%lu", tt->adapter_index );
 }
 device = buf_bptr(&out);
 
@@ -2406,12 +2406,12 @@ delete_route_ipv6(const struct route_ipv6 *r6, const 
struct tuntap *tt, unsigned
 struct buffer out = alloc_buf_gc(64, &gc);
 if (r6->adapter_index)  /* vpn server special route */
 {
-buf_printf(&out, "interface=%d", r6->adapter_index );
+buf_printf(&out, "interface=%lu", r6->adapter_index );
 gateway_needed = true;
 }
 else
 {
-buf_printf(&out, "interface=%d", tt->adapter_index );
+buf_printf(&out, "interface=%lu", tt->adapter_index );
 }
 device = buf_bptr(&out);
 
@@ -2832,7 +2832,7 @@ get_default_gateway_ipv6(struct route_ipv6_gateway_info 
*rgi6,
 goto done;
 }
 
-msg( D_ROUTE, "GDG6: II=%d DP=%s/%d NH=%s",
+msg( D_ROUTE, "GDG6: II=%lu DP=%s/%u NH=%s",
  BestRoute.InterfaceIndex,
  print_in6_addr( BestRoute.DestinationPrefix.Prefix.Ipv6.sin6_addr, 0, 
&gc),
  BestRoute.DestinationPrefix.PrefixLength,
@@ -2993,7 +2993,7 @@ do_route_service(const bool add, const route_message_t 
*rt, const size_t size, H
 
 if (ack.error_number != NO_ERROR)
 {
-msg(M_WARN, "ROUTE: route %s failed using service: %s [status=%u 
if_index=%lu]",
+msg(M_WARN, "ROUTE: route %s failed using service: %s [status=%u 
if_index=%d]",
 (add ? "addition" : "deletion"), strerror_win32(ack.error_number, 
&gc),
 ack.error_number, rt->iface.index);
 goto out;
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index c1c0eaa..c854f90 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1119,7 +1119,7 @@ socket_do_accept(socket_descriptor_t sd,
 
 if (!socket_defined(new_sd))
 {
-msg(D_LINK_ERRORS | M_ERRNO, "TCP: accept(%d) failed", sd);
+msg(D_LINK_ERRORS | M_ERRNO, "TCP: accept(%"PRI_OVPN_SKT") failed", 
sd);
 }
 /* only valid if we have remote_len_af!=0 */
 else if (remote_len_af && remote_len != remote_len_af)
@@ -1872,13 +1872,14 @@ phase2_inetd(struct link_socket *sock, const struct 
frame *frame,
 if (getsockname(sock->sd, &local_addr.addr.sa, &addrlen) == 0)
 {
 sock->info.lsa->actual.dest.addr.sa.sa_family = 
local_addr.addr.sa.sa_family;
-dmsg(D_SOCKET_DEBUG, "inetd(%s): using sa_family=%d from 
getsockname(%d)",
+dmsg(D_SOCKET_DEBUG,
+ "inetd(%s): using sa_family=%d from 
getsockname(%"PRI_OVPN_SKT")",
  proto2ascii(sock->info.proto, sock->info.af, false),
  local_addr.addr.sa.sa_family, sock->sd);
 }
 else
 {
-msg(M_WARN, "inetd(%s): getsockname(%d) fa

Re: [Openvpn-devel] [PATCH v2] Fix windows-build format specifiers

[Steffan Karger]

On 09-03-17 15:20, Antonio Quartulli wrote:
> On Thu, Mar 09, 2017 at 03:00:43PM +0100, Steffan Karger wrote:
>> A number of printf-like functions used incorrect format specifiers for
>> Windows builds, which could potentially lead to incorrect values being
>> printed / used when calling executables.
>>
>> Signed-off-by: Steffan Karger 
>> ---
>> v2: add OVPN_PRI_SKT define to print socket type across platforms
>>
>>  src/openvpn/init.c|  2 +-
>>  src/openvpn/route.c   | 12 ++--
>>  src/openvpn/socket.c  |  7 ---
>>  src/openvpn/syshead.h |  2 ++
>>  src/openvpn/tun.c |  4 ++--
>>  5 files changed, 15 insertions(+), 12 deletions(-)
>>
>> diff --git a/src/openvpn/init.c b/src/openvpn/init.c
>> index 033318d..2a9a398 100644
>> --- a/src/openvpn/init.c
>> +++ b/src/openvpn/init.c
>> @@ -1585,7 +1585,7 @@ do_open_tun(struct context *c)
>>  #ifdef _WIN32
>>  /* 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);
>> +msg(D_ROUTE, "interactive service msg_channel=%"PRIuPTR, (uintptr_t) 
>> c->options.msg_channel);
> 
> A little comment about the style (codestyle maniac here!).
> Should this:
> 
> msg_channel=%"PRIuPTR
> 
> be:
> 
> msg_channel=%" PRIuPTR
> 
> ?
> 
> the " is closing the const char and therefore a space would be needed between 
> it and the
> next constant.
> 
> This appears several times in the patch and therefore I thought it was worth
> mentioning it.

I don't have a strong preference about this.  I tend to not add spaces
for these preprocessor-format-specifiers, because I view them as part of
the string.  But I get your view too.  So I'd be perfectly fine with
adding spaces if that's the general preference.

-Steffan




signature.asc
Description: OpenPGP digital signature
--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: remove unused files

[Steffan Karger]

On 05-03-17 18:21, Ilya Shipitsin wrote:
> Those files were commited by mistake. I implemented building
> dependencies in 4 separate scripts, later Steffan Karger combined
> all 4 scripts into "build-deps.sh".
> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis/build-mbedtls-linux.sh |  9 -
>  .travis/build-mbedtls-osx.sh   |  9 -
>  .travis/build-openssl-linux.sh | 12 
>  .travis/build-openssl-osx.sh   | 11 ---
>  4 files changed, 41 deletions(-)
>  delete mode 100755 .travis/build-mbedtls-linux.sh
>  delete mode 100755 .travis/build-mbedtls-osx.sh
>  delete mode 100755 .travis/build-openssl-linux.sh
>  delete mode 100755 .travis/build-openssl-osx.sh
> 
> diff --git a/.travis/build-mbedtls-linux.sh b/.travis/build-mbedtls-linux.sh
> deleted file mode 100755
> index dc92aaf..000
> --- a/.travis/build-mbedtls-linux.sh
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#!/bin/sh
> -
> -if [ ! -f download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz ]; then
> - wget -O download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz 
> https://tls.mbed.org/download/mbedtls-${MBEDTLS_VERSION}-apache.tgz;
> -fi
> -
> -tar zxf download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz
> -cd mbedtls-${MBEDTLS_VERSION} && make > build.log 2>&1 || (cat build.log && 
> exit 1)
> -make install DESTDIR=$MBEDTLS_PREFIX && cd ..
> diff --git a/.travis/build-mbedtls-osx.sh b/.travis/build-mbedtls-osx.sh
> deleted file mode 100755
> index dc92aaf..000
> --- a/.travis/build-mbedtls-osx.sh
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -#!/bin/sh
> -
> -if [ ! -f download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz ]; then
> - wget -O download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz 
> https://tls.mbed.org/download/mbedtls-${MBEDTLS_VERSION}-apache.tgz;
> -fi
> -
> -tar zxf download-cache/mbedtls-${MBEDTLS_VERSION}-apache.tgz
> -cd mbedtls-${MBEDTLS_VERSION} && make > build.log 2>&1 || (cat build.log && 
> exit 1)
> -make install DESTDIR=$MBEDTLS_PREFIX && cd ..
> diff --git a/.travis/build-openssl-linux.sh b/.travis/build-openssl-linux.sh
> deleted file mode 100755
> index 84f4aae..000
> --- a/.travis/build-openssl-linux.sh
> +++ /dev/null
> @@ -1,12 +0,0 @@
> -#!/bin/sh
> -
> -if [ ! -f download-cache/openssl-${OPENSSL_VERSION}.tar.gz ]; then
> - wget -O download-cache/openssl-${OPENSSL_VERSION}.tar.gz 
> https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz;
> -fi
> -
> -tar zxf download-cache/openssl-${OPENSSL_VERSION}.tar.gz
> -cd openssl-${OPENSSL_VERSION}/
> -./config shared --prefix=$OPENSSL_PREFIX -DPURIFY > build.log 2>&1 || (cat 
> build.log && exit 1)
> -make > build.log 2>&1 || (cat build.log && exit 1)
> -make install_sw > build.log 2>&1 || (cat build.log && exit 1)
> -cd ..
> diff --git a/.travis/build-openssl-osx.sh b/.travis/build-openssl-osx.sh
> deleted file mode 100755
> index 61c8016..000
> --- a/.travis/build-openssl-osx.sh
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#!/bin/sh
> -
> -if [ ! -f download-cache/openssl-${OPENSSL_VERSION}.tar.gz ]; then
> -wget -O download-cache/openssl-${OPENSSL_VERSION}.tar.gz 
> https://www.openssl.org/source/openssl-${OPENSSL_VERSION}.tar.gz;
> -fi
> -
> -tar zxf download-cache/openssl-${OPENSSL_VERSION}.tar.gz
> -cd openssl-${OPENSSL_VERSION}/
> -./Configure darwin64-x86_64-cc shared --prefix=$OPENSSL_PREFIX -DPURIFY > 
> build.log 2>&1 || (cat build.log && exit 1)
> -make depend install > build.log 2>&1 || (cat build.log && exit 1)
> -cd ..
> 

ACK

-Steffan

--
Announcing the Oxford Dictionaries API! The API offers world-renowned
dictionary content that is easy and intuitive to access. Sign up for an
account today to start using our lexical data to power your apps and
projects. Get started today and enter our developer competition.
http://sdm.link/oxford
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Be less picky about keyUsage extensions

[Steffan Karger]

We long recommended users to use --ns-cert-type to distinguish between
client and server certificates, but that extension is long deprecated and
now can even no longer be accurately checked in OpenSSL 1.1+.  We support
a more modern alternative, --remote-cert-tls (which expands to
--remote-cert-ku + --remote-cert-eku), but are overly strict in checking
the keyUsage.  This patch makes our implementation less picky, so that
correct-but-slightly-weird certicates will not immediately be rejected.

We currently allow users to specify a list of allowed keyUsage values, and
require that the remote certificate matches one of these values exactly.
This is for more strict than keyUsage usually requires; which is that a
certificate is okay to use if it can *at least* be used for our intended
purpose.  This patch changes the behaviour to match that, by using the
library-provided mbedtls_x509_crt_check_key_usage() function in mbed TLS
builds, and performing the 'at least bits xyz' check for OpenSSL builds
(OpenSSL unfortunately does not expose a similar function).

Furthermore, this patch adds better error messages when the checking fails;
it now explains that is expects to match either of the supplied values,
and only does so if the check actually failed.

This patch also changes --remote-cert-tls to still require a specific EKU,
but only *some* keyUsage value.  Both our supported crypto libraries will
check the keyUsage value for correctness during the handshake, but only if
it is present.  So this still enforces a correct keyUsage, but is a bit
less picky about certificates that do not exactly match expectations.

This patch should be applied together with the 'deprecate --ns-cert-type'
patch I sent earlier.

Signed-off-by: Steffan Karger 
---
 Changes.rst  |  7 
 doc/openvpn.8| 33 ++
 src/openvpn/options.c| 15 +
 src/openvpn/ssl_verify.h |  3 ++
 src/openvpn/ssl_verify_mbedtls.c | 42 ++-
 src/openvpn/ssl_verify_openssl.c | 72 +---
 6 files changed, 102 insertions(+), 70 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 0af29e3..2a94990 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -306,6 +306,13 @@ Maintainer-visible changes
 
 Version 2.4.1
 =
+ - ``--remote-cert-ku`` now only requires the certificate to have at least the
+   bits set of one of the values in the supplied list, instead of requiring an
+   exact match to one of the values in the list.
+ - ``--remote-cert-tls`` now only requires that a keyUsage is present in the
+   certificate, and leaves the verification of the value up to the crypto
+   library, which has more information (i.e. the key exchange method in use)
+   to verify that the keyUsage is correct.
  - ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
The nsCertType x509 extension is very old, and barely used.
``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index f6822ec..89229fb 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5344,15 +5344,25 @@ or
 .B \-\-tls\-verify.
 .\"*
 .TP
-.B \-\-remote\-cert\-ku v...
+.B \-\-remote\-cert\-ku [v...]
 Require that peer certificate was signed with an explicit
 .B key usage.
 
-This is a useful security option for clients, to ensure that
-the host they connect to is a designated server.
+If present in the certificate, the keyUsage value is validated by the TLS
+library during the TLS handshake.  Specifying this option without arguments
+requires this extension to be present (so the TLS library will verify it).
 
-The key usage should be encoded in hex, more than one key
-usage can be specified.
+If the list
+.B v...
+is also supplied, the keyUsage field must have
+.B at least
+the same bits set as the bits in
+.B one of
+the values supplied in the list
+.B v...
+
+The key usage values in the list must be encoded in hex, e.g.
+"\-\-remote\-cert\-ku a0"
 .\"*
 .TP
 .B \-\-remote\-cert\-eku oid
@@ -5373,24 +5383,21 @@ and
 .B extended key usage
 based on RFC3280 TLS rules.
 
-This is a useful security option for clients, to ensure that
-the host they connect to is a designated server.
+This is a useful security option for clients, to ensure that the host they
+connect to is a designated server.  Or the other way around; for a server to
+verify that only hosts with a client certificate can connect.
 
 The
 .B \-\-remote\-cert\-tls client
 option is equivalent to
 .B
-\-\-remote\-cert\-ku 80 08 88 \-\-remote\-cert\-eku "TLS Web Client 
Authentication"
-
-The key usage is digitalSignature and/or keyAgreement.
+\-\-remote\-cert\-ku \-\-remote\-cert\-eku "TLS Web Client Authentication"
 
 The
 .B \-\-remote\-cert\-tls ser

Re: [Openvpn-devel] [PATCH] Fix Building Using MSVC

[Steffan Karger]

Hi,

On 15-03-17 22:00, Gert Doering wrote:
> On Tue, Mar 14, 2017 at 09:26:52AM +1100, Eric Thorpe wrote:
>>   #ifdef HAVE_CONFIG_MSVC_LOCAL_H
>>   #include 
>> diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
>> index 5549d70..bed39f3 100644
>> --- a/src/openvpn/crypto_openssl.c
>> +++ b/src/openvpn/crypto_openssl.c
>> @@ -287,7 +287,12 @@ show_available_ciphers()
>>
>>   /* If we ever exceed this, we must be more selective */
>>   const size_t cipher_list_len = 1000;
>> +#ifdef _MSC_VER
>> +//While GCC will allow you to use a const, MSVC won't (at least 
>> with a simple declaration). Use a compile time constant for now
>> +const EVP_CIPHER *cipher_list[1000];
>> +#else
>>   const EVP_CIPHER *cipher_list[cipher_list_len];
>> +#endif
>>   size_t num_ciphers = 0;
> 
> I don't think we should do this.  If we have a length, use it.  If
> the compiler is too daft to understand consts, maybe we should go
> for "#define CIPHER_LIST_LEN 1000" instead - indeed, more changes,
> but no magic numbers.  Or abandon the definition, use [1000], and
> sizeof() in the out of bounds check below.
> 
> Steffan, your code, what would you say?

Hm, this is somewhat chewing on our decision that 'we now only support
compilers that do C99', but I can see that this is easily fixed so I can
live with just begin pragmatic.  In that case, let's go for the
sizeof().  Adding a define of course works, but I find it somewhat clunky.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix non-C99-compliant builds: don't use const size_t as array length

[Steffan Karger]

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

diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index 5f28391..9139480 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -292,8 +292,7 @@ show_available_ciphers()
 size_t i;
 
 /* If we ever exceed this, we must be more selective */
-const size_t cipher_list_len = 1000;
-const EVP_CIPHER *cipher_list[cipher_list_len];
+const EVP_CIPHER *cipher_list[1000];
 size_t num_ciphers = 0;
 #ifndef ENABLE_SMALL
 printf("The following ciphers and cipher modes are available for use\n"
@@ -318,7 +317,7 @@ show_available_ciphers()
 {
 cipher_list[num_ciphers++] = cipher;
 }
-if (num_ciphers == cipher_list_len)
+if (num_ciphers == (sizeof(cipher_list)/sizeof(*cipher_list)))
 {
 msg(M_WARN, "WARNING: Too many ciphers, not showing all");
 break;
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make ENABLE_OCC no longer depend on !ENABLE_SMALL

[Steffan Karger]

Hi,

On 19-03-17 19:41, Gert Doering wrote:
> OCC is useful functionality which (according to LEDE devs) adds only
> about 3k to the binary size - and if the embedded router folks can
> afford this trade-off, everyone else can :-)
> 
> Inspired by 
> https://git.lede-project.org/?p=source.git;a=commit;h=b613c96d94bcdcda7abb3be68ea1c281ce5fbb47
> 
> Signed-off-by: Gert Doering 
> ---
>  src/openvpn/syshead.h | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/src/openvpn/syshead.h b/src/openvpn/syshead.h
> index a1b6047..f445864 100644
> --- a/src/openvpn/syshead.h
> +++ b/src/openvpn/syshead.h
> @@ -589,9 +589,7 @@ socket_defined(const socket_descriptor_t sd)
>  /*
>   * Should we include OCC (options consistency check) code?
>   */
> -#ifndef ENABLE_SMALL
>  #define ENABLE_OCC
> -#endif
>  
>  /*
>   * Should we include NTLM proxy functionality
> 

If we unconditionally enable OCC, should we not just rip out #ifdef
ENABLE_OCC everywhere?

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Make ENABLE_OCC no longer depend on !ENABLE_SMALL

[Steffan Karger]

On 20-03-17 19:28, Gert Doering wrote:
> On Mon, Mar 20, 2017 at 07:20:50PM +0100, Steffan Karger wrote:
>>> @@ -589,9 +589,7 @@ socket_defined(const socket_descriptor_t sd)
>>>  /*
>>>   * Should we include OCC (options consistency check) code?
>>>   */
>>> -#ifndef ENABLE_SMALL
>>>  #define ENABLE_OCC
>>> -#endif
>>>  
>>>  /*
>>>   * Should we include NTLM proxy functionality
>>>
>>
>> If we unconditionally enable OCC, should we not just rip out #ifdef
>> ENABLE_OCC everywhere?
> 
> We certainly could, but someone who still wants "no OCC! smaaall!" 
> still has the option to turn it off...
> 
> We might revisit that, though - there's "the option checking code",
> which indeed brings in quite a bit of code that might be considered
> optional, but there is also stuff in sig.c that makes --explicit-exit-notify
> depend on ENABLE_OCC, and I'd consider that as something quite 
> important...

Ok, let's revisit that later.  This patch doesn't hurt if we decide to
rip out more later, and would be good to get into 2.4.1, so ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only configurations"

[Steffan Karger]

Hi,

On 28 March 2017 at 08:50, Илья Шипицин  wrote:
> I opened https://github.com/OpenVPN/openvpn/pull/85
> for discussion
>
> thoughts ?

I put the patch on my review list, but need to tackle other things
first.  Will get back to you.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Allow changing cipher from a ccd file

[Steffan Karger]

Hi,

On 17-02-17 16:20, Steffan Karger wrote:
> As described in msg  <374a7eb7-f539-5231-623b-41f208ed8...@belkam.com> on
> openvpn-devel@lists.sourceforge.net, clients that are compiled with
> --disable-occ (included in --enable-small) won't send an options string.
> Without the options string, the 2.4 server doesn't know which cipher to
> use for poor man's NCP.
> 
> This patch allows working around that issue by allowing the 'cipher'
> directive to be used in --client-config-dir files.  That way, a server
> admin can add ccd files to specify per-client which cipher to use.
> 
> Because the ccd files are read after where we would normally generate keys,
> this patch delays key generation for non-NCP p2mp servers until after
> reading the ccd file.
> 
> Trac: #845
> 
> Signed-off-by: Steffan Karger 
> ---
> v2: postpone p2mp non-NCP key generation, such that setting cipher in
> a ccd file for a non-NCP client actually works.
> 
>  src/openvpn/multi.c   | 14 ++
>  src/openvpn/options.c |  2 +-
>  src/openvpn/options.h |  2 +-
>  src/openvpn/ssl.c |  9 -
>  4 files changed, 20 insertions(+), 7 deletions(-)
> 
> diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
> index 56009b7..4c81e9a 100644
> --- a/src/openvpn/multi.c
> +++ b/src/openvpn/multi.c
> @@ -2086,6 +2086,20 @@ script_failed:
>  mi->context.c2.context_auth = cc_succeeded_count ? CAS_PARTIAL : 
> CAS_FAILED;
>  }
>  
> +/* Generate tunnel keys, unless IV_NCP >= 2 is negotiated. The first 
> key
> + * generation is then postponed until after the pull/push, so we can
> + * process pushed cipher directives.
> + */
> +struct tls_session *session = 
> &mi->context.c2.tls_multi->session[TM_ACTIVE];
> +struct key_state *ks = &session->key[KS_PRIMARY];
> +if (!session->opt->ncp_enabled && ks->authenticated
> +&& !tls_session_update_crypto_params(session, 
> &mi->context.options,
> + &mi->context.c2.frame))
> +{
> +msg(D_TLS_ERRORS, "TLS Error: server generate_key_expansion 
> failed");
> +cc_succeeded = false;
> +}
> +
>  /* set flag so we don't get called again */
>  mi->connection_established_flag = true;
>  
> diff --git a/src/openvpn/options.c b/src/openvpn/options.c
> index dde1f48..0e6b393 100644
> --- a/src/openvpn/options.c
> +++ b/src/openvpn/options.c
> @@ -7536,7 +7536,7 @@ add_option(struct options *options,
>  }
>  else if (streq(p[0], "cipher") && p[1] && !p[2])
>  {
> -VERIFY_PERMISSION(OPT_P_NCP);
> +VERIFY_PERMISSION(OPT_P_NCP|OPT_P_INSTANCE);
>  options->ciphername = p[1];
>  }
>  else if (streq(p[0], "ncp-ciphers") && p[1] && !p[2])
> diff --git a/src/openvpn/options.h b/src/openvpn/options.h
> index a14f2ab..f4f0226 100644
> --- a/src/openvpn/options.h
> +++ b/src/openvpn/options.h
> @@ -628,7 +628,7 @@ struct options
>  #define OPT_P_MTU (1<<14) /* TODO */
>  #define OPT_P_NICE(1<<15)
>  #define OPT_P_PUSH(1<<16)
> -#define OPT_P_INSTANCE(1<<17)
> +#define OPT_P_INSTANCE(1<<17) /**< Allow usage in ccd file */
>  #define OPT_P_CONFIG  (1<<18)
>  #define OPT_P_EXPLICIT_NOTIFY (1<<19)
>  #define OPT_P_ECHO(1<<20)
> diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
> index 8c724cb..1479c77 100644
> --- a/src/openvpn/ssl.c
> +++ b/src/openvpn/ssl.c
> @@ -2401,12 +2401,11 @@ key_method_2_write(struct buffer *buf, struct 
> tls_session *session)
>  }
>  
>  /* Generate tunnel keys if we're a TLS server.
> - * If we're a p2mp server and IV_NCP >= 2 is negotiated, the first key
> - * generation is postponed until after the pull/push, so we can process 
> pushed
> - * cipher directives.
> + * If we're a p2mp server, the first key generation is postponed so we 
> can
> + * switch cipher during the connection setup phase.
>   */
> -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)
>  {
> 

This patch seems to work for the reporter from #845:
https://community.openvpn.net/openvpn/ticket/845#comment:5

-Steffan

(Yes, this is a shameless bump to trick people into reviewing this patch
;-) )

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] building HEAD + openssl 1.1 api fails @ "crypto.c:823:32: error: invalid application of ???sizeof??? to incomplete type ???cipher_ctx_t"

[Steffan Karger]

Hi,

On 28-03-17 10:33, Emmanuel Deloget wrote:
> ​I should be able to push a new version of the remaining patches in the
> foreseeable future (let's say today or tomorrow, because I will be
> unavailable at the end of this week).
> 
> I found a solution to overcome the big X509_check_purpose() issue, so
> now I'm able to propose a solution that does not change the behavior of
> OpenVPN.

That's great!  This way, 2.4 does not have to change it's behaviour.
Still, I think it makes sense to deprecate --ns-cert-type, and remove it
in favour or --remote-cert-tls in openvpn 2.5.

-Steffan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] building HEAD + openssl 1.1 api fails @ "crypto.c:823:32: error: invalid application of ???sizeof??? to incomplete type ???cipher_ctx_t"

[Steffan Karger]

On 28-03-17 15:02, debbie10t wrote:
> On 28/03/17 13:47, Gert Doering wrote:
>> We need to communicate better what might affect users in new versions, so
>> they can test and complain/adjust in time (like, the stricter CRL handling
>> in 2.4, and - obviously - the --tls-remote bit)
> 
> Suggestion: A Wiki Page detailing deprecation plans with dated targets.

We have Changes.rst for that:
https://github.com/OpenVPN/openvpn/blob/master/Changes.rst

Let's please keep this list on one location only, and I think
Changes.rst is the right place.

-Steffan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] building HEAD + openssl 1.1 api fails @ "crypto.c:823:32: error: invalid application of ???sizeof??? to incomplete type ???cipher_ctx_t"

[Steffan Karger]

On 28-03-17 15:31, Samuli Seppänen wrote:
> On 28/03/2017 16:08, Steffan Karger wrote:
>> On 28-03-17 15:02, debbie10t wrote:
>>> On 28/03/17 13:47, Gert Doering wrote:
>>>> We need to communicate better what might affect users in new versions, so
>>>> they can test and complain/adjust in time (like, the stricter CRL handling
>>>> in 2.4, and - obviously - the --tls-remote bit)
>>>
>>> Suggestion: A Wiki Page detailing deprecation plans with dated targets.
>>
>> We have Changes.rst for that:
>> https://github.com/OpenVPN/openvpn/blob/master/Changes.rst
>>
>> Let's please keep this list on one location only, and I think
>> Changes.rst is the right place.
> 
> Ah, Changes.rst had "Deprecated features" section, good. I think that is
> sufficient. The question then becomes: do we need to link to Changes.rst
> from somewhere so that people find it?
> 

Yeah, linking to the changes.rst on github (which gets nicely rendered)
from the wiki sounds like a good plan.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] auth-token: Ensure tokens are always wiped on de-auth

[Steffan Karger]

Hi,

On 28-03-17 21:19, David Sommerseth wrote:
> If tls_deauthenticate() was called, it could in some scenarios leave the
> authentication token for a session in memory.  This change just ensures
> auth-tokens are always wiped as soon as a TLS session is considered
> broken.
> 
> Signed-off-by: David Sommerseth 
> 
> ---
> 
> The wipe_auth_token() function is otherwise moved to be declared before
> tls_deauthenticate() and the latter function is also slightly modified to
> make use of the C99 feature of inline declaration - mostly to have a more
> reasonable coding style when adding the wipe_auth_token() call.
> ---
>  src/openvpn/ssl_verify.c | 44 
>  1 file changed, 24 insertions(+), 20 deletions(-)
> 
> diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
> index a6e9be3..008a60d 100644
> --- a/src/openvpn/ssl_verify.c
> +++ b/src/openvpn/ssl_verify.c
> @@ -80,6 +80,26 @@ setenv_untrusted(struct tls_session *session)
>  setenv_link_socket_actual(session->opt->es, "untrusted", 
> &session->untrusted_addr, SA_IP_PORT);
>  }
>  
> +
> +/**
> + *  Wipes the authentication token out of the memory, frees and cleans up 
> related buffers and flags
> + *
> + *  @param multi  Pointer to a multi object holding the auth_token variables
> + */
> +static void
> +wipe_auth_token(struct tls_multi *multi)
> +{
> +if( multi ) {
> + if (multi->auth_token ) {

The spaces in theses lines look a bit odd.

> + secure_memzero(multi->auth_token, AUTH_TOKEN_SIZE);
> + free(multi->auth_token);
> + }
> + multi->auth_token = NULL;
> + multi->auth_token_sent = false;
> +}
> +}
> +
> +
>  /*
>   * Remove authenticated state from all sessions in the given tunnel
>   */
> @@ -88,10 +108,10 @@ tls_deauthenticate(struct tls_multi *multi)
>  {
>  if (multi)
>  {
> -int i, j;
> -for (i = 0; i < TM_SIZE; ++i)
> +wipe_auth_token(multi);
> +for (int i = 0; i < TM_SIZE; ++i)
>  {
> -for (j = 0; j < KS_SIZE; ++j)
> +for (int j = 0; j < KS_SIZE; ++j)
>  {
>  multi->session[i].key[j].authenticated = false;
>  }
> @@ -1219,21 +1239,6 @@ verify_user_pass_management(struct tls_session 
> *session, const struct user_pass
>  }
>  #endif /* ifdef MANAGEMENT_DEF_AUTH */
>  
> -/**
> - *  Wipes the authentication token out of the memory, frees and cleans up 
> related buffers and flags
> - *
> - *  @param multi  Pointer to a multi object holding the auth_token variables
> - */
> -static void
> -wipe_auth_token(struct tls_multi *multi)
> -{
> -secure_memzero(multi->auth_token, AUTH_TOKEN_SIZE);
> -free(multi->auth_token);
> -multi->auth_token = NULL;
> -multi->auth_token_sent = false;
> -}
> -
> -
>  /*
>   * Main username/password verification entry point
>   */
> @@ -1285,7 +1290,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
> *multi,
>  /* Ensure that the username has not changed */
>  if (!tls_lock_username(multi, up->username))
>  {
> -wipe_auth_token(multi);
> +/* auth-token cleared in tls_lock_username() on failure */
>  ks->authenticated = false;
>  goto done;
>  }
> @@ -1306,7 +1311,6 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
> *multi,
>  if (memcmp_constant_time(multi->auth_token, up->password,
>   strlen(multi->auth_token)) != 0)
>  {
> -wipe_auth_token(multi);
>  ks->authenticated = false;
>  tls_deauthenticate(multi);
>  
> 

Shouldn't we also clear the token if the ccd authentication check in
verify_final_auth_checks() fails?

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] auth-token: Ensure tokens are always wiped on de-auth

[Steffan Karger]

Hi,

On 28-03-17 22:53, David Sommerseth wrote:
> If tls_deauthenticate() was called, it could in some scenarios leave the
> authentication token for a session in memory.  This change just ensures
> auth-tokens are always wiped as soon as a TLS session is considered
> broken.
> 
> Signed-off-by: David Sommerseth 
> 
> ---
> 
> The wipe_auth_token() function is otherwise moved to be declared before
> tls_deauthenticate() and the latter function is also slightly modified to
> make use of the C99 feature of inline declaration - mostly to have a more
> reasonable coding style when adding the wipe_auth_token() call.
> 
> v2 - Fixed coding style issues after changes in wipe_auth_token()
>- Added wipe_auth_token() call when --ccd-exclusive auth fails
> ---
>  src/openvpn/ssl_verify.c | 47 +++
>  1 file changed, 27 insertions(+), 20 deletions(-)
> 
> diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
> index a6e9be3..bc578fa 100644
> --- a/src/openvpn/ssl_verify.c
> +++ b/src/openvpn/ssl_verify.c
> @@ -80,6 +80,28 @@ setenv_untrusted(struct tls_session *session)
>  setenv_link_socket_actual(session->opt->es, "untrusted", 
> &session->untrusted_addr, SA_IP_PORT);
>  }
>  
> +
> +/**
> + *  Wipes the authentication token out of the memory, frees and cleans up 
> related buffers and flags
> + *
> + *  @param multi  Pointer to a multi object holding the auth_token variables
> + */
> +static void
> +wipe_auth_token(struct tls_multi *multi)
> +{
> +if( multi )
> +{
> +if (multi->auth_token )
> +{

This still has weird spaces: "if( multi )" should be "if (multi)", and
"if (multi->auth_token )" should be "if (multi->auth_token)".

> +secure_memzero(multi->auth_token, AUTH_TOKEN_SIZE);
> +free(multi->auth_token);
> +}
> +multi->auth_token = NULL;
> +multi->auth_token_sent = false;
> +}
> +}
> +
> +
>  /*
>   * Remove authenticated state from all sessions in the given tunnel
>   */
> @@ -88,10 +110,10 @@ tls_deauthenticate(struct tls_multi *multi)
>  {
>  if (multi)
>  {
> -int i, j;
> -for (i = 0; i < TM_SIZE; ++i)
> +wipe_auth_token(multi);
> +for (int i = 0; i < TM_SIZE; ++i)
>  {
> -for (j = 0; j < KS_SIZE; ++j)
> +for (int j = 0; j < KS_SIZE; ++j)
>  {
>  multi->session[i].key[j].authenticated = false;
>  }
> @@ -1219,21 +1241,6 @@ verify_user_pass_management(struct tls_session 
> *session, const struct user_pass
>  }
>  #endif /* ifdef MANAGEMENT_DEF_AUTH */
>  
> -/**
> - *  Wipes the authentication token out of the memory, frees and cleans up 
> related buffers and flags
> - *
> - *  @param multi  Pointer to a multi object holding the auth_token variables
> - */
> -static void
> -wipe_auth_token(struct tls_multi *multi)
> -{
> -secure_memzero(multi->auth_token, AUTH_TOKEN_SIZE);
> -free(multi->auth_token);
> -multi->auth_token = NULL;
> -multi->auth_token_sent = false;
> -}
> -
> -
>  /*
>   * Main username/password verification entry point
>   */
> @@ -1285,7 +1292,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
> *multi,
>  /* Ensure that the username has not changed */
>  if (!tls_lock_username(multi, up->username))
>  {
> -wipe_auth_token(multi);
> +/* auth-token cleared in tls_lock_username() on failure */
>  ks->authenticated = false;
>  goto done;
>  }
> @@ -1306,7 +1313,6 @@ verify_user_pass(struct user_pass *up, struct tls_multi 
> *multi,
>  if (memcmp_constant_time(multi->auth_token, up->password,
>   strlen(multi->auth_token)) != 0)
>  {
> -wipe_auth_token(multi);
>  ks->authenticated = false;
>  tls_deauthenticate(multi);
>  
> @@ -1478,6 +1484,7 @@ verify_final_auth_checks(struct tls_multi *multi, 
> struct tls_session *session)
>  if (!cn || !strcmp(cn, CCD_DEFAULT) || !test_file(path))
>  {
>  ks->authenticated = false;
> +wipe_auth_tokens(multi);

This should be wipe_auth_token(), not wipe_auth_tokens().

>  msg(D_TLS_ERRORS, "TLS Auth Error: --client-config-dir 
> authentication failed for common name '%s' file='%s'",
>  session->common_name,
>  path ? path : "UNDEF");
> 

Otherwise this looks good.  So if the above two comments are processed,
ACK.  I'm fine with you doing that on-the-fly.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] docs: Fixed man-page warnings discoverd by rpmlint

[Steffan Karger]

On 29-03-17 11:49, David Sommerseth wrote:
> Running rpmlint against Fedora RPM packages revealed these warnings:
> 
>   W: manual-page-warning /usr/share/man/man8/openvpn.8.gz 2738:
>  a special character is not allowed in a name
>   W: manual-page-warning /usr/share/man/man8/openvpn.8.gz 2740:
>  a special character is not allowed in a name
> 
> This is just a typo mistake in the .B formatting, missing a trailing
> space.
> 
> Signed-off-by: David Sommerseth 
> ---
>  doc/openvpn.8 | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index f29b72f..a9f5db7 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -2735,9 +2735,9 @@ DEFAULT_DIR is replaced by the default plug-in 
> directory,
>  which is configured at the build time of OpenVPN.  CWD is the
>  current directory where OpenVPN was started or the directory
>  OpenVPN have swithed into via the
> -.B\-\-cd
> +.B \-\-cd
>  option before the
> -.B\-\-plugin
> +.B \-\-plugin
>  option.
>  
>  For more information and examples on how to build OpenVPN
> 

This is easy enough: ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Upgrading EasyRSA 2's defaults

[Steffan Karger]

Hi,

On 31-03-17 22:34, David Sommerseth wrote:
> On 31/03/17 10:56, Илья Шипицин wrote:
>> 2017-03-31 13:26 GMT+05:00 Samuli Seppänen > >:
>>
>> Hi,
>>
>> We still bundle EasyRSA 2 with our Windows installers and it is
>> prominently advertised on our widely linked to HOWTO:
>>
>> > >
>>
>> As such, EasyRSA 2 is used by many/most OpenVPN server admins.
>>
>> However, the default values for EasyRSA 2 such as MD5 hashing algorithm
>> and 1024-bit keysize seem totally inadequate for today's standards:
>>
>> 
>> > 
>> >
>> 
>> > 
>> >
>>
>> I think we should upgrade these to something more recent. What would
>> more modern reasonable defaults be?
>>
>>
>>
>> someday we decided to use DSA (instead of default RSA)
>> it worked ... until we started to use OpenVPN Connect for iOS.
>> next, we had to change back to RSA
>>
>>
>> the conclusion would be "test all available platforms and take a
>> decision", probably even set up special test server and ask people on
>> openvpn-users mailing list
> 
> Always a good idea to test as many platforms as possible.  But we can
> also leverage all the testing which have been done indirectly by others
> as well.
> 
> The suggestion from Samuli is to update the default key size and hashing
> algorithm.  MD5 is broken.  MD5 have been broken for years.  SHA1 have
> the recent SHAttering panic, which have its own set of challenges - and
> should not be used for certificates any longer (if I have understood the
> crypto-gurus correctly).
> 
> Also considering that the "world in general" have been moving towards
> stronger keys *and* have moved towards SHA256 hashing in certificates,
> updating EasyRSA is more than reasonable.
> 
> So, I would highly recommend using SHA256.  I have used that for my
> OpenVPN setups for several years already.  That works fine for me, and I
> know others have done the same.  This is actually the most challenging
> move, from a technical point of view - using a new algorithm.  But this
> algorithm is well supported by all OpenSSL and mbed TLS implementations
> OpenVPN can be built against.
> 
> Secondly, updating the key length from 1024 bits to at least 2048 should
> not cause any issues at all.  Many users (myself included) often use
> 4096 bits keys without any issues.
> 
> Swapping RSA for DSA is an issue of a completely different league. And
> DSA is by OpenSSH considered too weak; IIRC it was even removed in
> OpenSSH v7.0.

Yes, upgrading would be good if we still ship it.  I can echo David's
SHA256 / RSA2048+ recommendation.  Enough security margin, and very good
interop (not only crypto libs, but also smart cards, OS key stores,
...).  To not dramatically slow down connection setup on low-cpu-power
devices (e.g. home routers), don't go beyond RSA4096 though.

DSA is _not_ a preferred choice.  The original 1024-bit DSA is too weak
nowadays, and the 'larger' DSA variants are not even close to the wide
support that RSA has.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Upgrading EasyRSA 2's defaults

[Steffan Karger]

Hi,

On 3 April 2017 at 23:14, Selva Nair  wrote:
>
>
> On Mon, Apr 3, 2017 at 4:43 PM, David Sommerseth
>  wrote:
>>
>> On 03/04/17 16:12, Jan Just Keijser wrote:
>> > Hi Samuli,
>> >
>> > On 03/04/17 15:53, Samuli Seppänen wrote:
>> >> On 02/04/2017 10:57, Steffan Karger wrote:
>
>
> snip..
>
>>
>> >>> DSA is _not_ a preferred choice.  The original 1024-bit DSA is too
>> >>> weak
>> >>> nowadays, and the 'larger' DSA variants are not even close to the wide
>> >>> support that RSA has.
>> >>>
>> >>> -Steffan
>> >>>
>> >> Hi,
>> >>
>> >> I've issue a pull request here and review would be appreciated:
>> >>
>> >> <https://github.com/OpenVPN/easy-rsa-old/pull/1>
>> >>
>> >> I tested these changes on Debian 8 which has OpenSSL-1.0.1. Key size
>> >> was
>> >> set to 4096-bits and signature algorithm to SHA256WithRSAEncryption.
>> >>
>> >> The only real issue was DH parameter generation: it took ~25 minutes on
>> >> my Intel i5 laptop. Is that acceptable default behavior?
>> >>
>> > what kind of i5 is this? on my i7-4810 it took 5 minutes. Can you give
>> > the full CPUID string (from /proc/cpuinfo) ?  then I can
>> > guestimate whether the 25 minutes is realistic for slower hardware.
>>
>> I've run a a couple of "quick" tests ... on a two different laptops
>>
>> --- test 1 --
>> $ time openssl gendh -out test 4096
>> [...snip...]
>>
>> real35m40.098s
>> user35m38.922s
>> sys 0m0.367s
>> $ cat /proc/cpuinfo  | grep model\ name | uniq -c
>>   4 model name  : Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz
>
>
> 4096 bit "strong" prime is indeed an intensive computation.. Is using
> -dsaparam  option not secure enough?
>
> openssl dhparam -dsaparam -out test 4096
>
> is 15 seconds vs forever without it on my ancient desktop.

From the openssl man page:

"Beware that with such DSA-style DH parameters, a fresh DH key should
be created for each use to avoid small-subgroup attacks that may be
possible otherwise."

This means that if for some reason a non-ephemeral diffie-hellman
cipher suite is selected, you are at risk of these attacks.

If you are worried about the parameter generation time, just use one
of the IETF-provided parameters, e.g:
https://tools.ietf.org/html/rfc7919#appendix-A.2

But beware that using larger groups does not only slow down parameter
generation, it also slows down connection setup.  ECDH is much faster,
but if you need to use DH, do some performance tests before blindly
using 4096-bits parameters.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Steffan Karger]

Hi,

On 05-04-17 08:57, Gert Doering wrote:
> On Wed, Apr 05, 2017 at 06:34:34AM +0200, Simon Matter wrote:
>> I've attached v2 now which works without any config change:
> [..]
>> I prefer this version as it allows everybody to profit from it without
>> touching any config files.
> 
> I can see the reasoning, but 25% feels a bit on the high side :-) - so
> let the ratholing begin what the number should be.
> 
> Steffan, any views from the crypto side of things?

Not really.  I think the feature makes sense, and I like that this will
only *substract* from the set time (so not exceed any set limits).

(And I agree that 25% feels on the high side - my gut says somewhere
around 10%, but I have no analysis to show why that would be better.
I'll leave picking that number to you.)

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Add per session pseudo-random component to --reneg-sec intervals

[Steffan Karger]

Hi,

On 6 April 2017 at 12:26, David Sommerseth
 wrote:
> On 06/04/17 11:45, Simon Matter wrote:
>>
>>> I like Arne's and David's suggestion - the existing option "as is" will
>>> enable X% jitter, while a second parameter can specify a more specific
>>> range.  Following Arne's argument about users and percent math, it might
>>> indeed be better to have "min max" here ("3500 3600"), because that is
>>> really easy to understand and explain.
>>
>> After all the discussion I prefer the simple solution. I've changed my
>> systems to the reduced 10% jitter and I'm wondering if it has to be made
>> more complicated than this? I works very well and after some hours the
>> renegs have spread very well. If you ask me it's perfectly fine that way
>> as long as the docs clearly state that a pseudo random 10% us deducted
>> from reneg-sec automatically to spread renegs.
>
> It must be configurable, based on many years experience with helping out
> on configuring OpenVPN tunnels.  There are millions of OpenVPN
> configurations out in the world (and I don't even think I'm exaggerating
> that much even), many small ones and quite some large ones.  There are
> VPN service providers with several hundred thousands paying customers,
> and there are an enormous amount of VPN service providers in addition.
> In addition to all the private and corporate deployments.
>
> So enforcing a good feature equally on all these configurations will
> backfire at us.
>
> And the more I think about the 10% randomness vlaue (or any percentage),
> I really wonder how clever that is.  If a site uses --reneg-sec 1800 (I
> have seen that), that means a 3 minute window.  If a site uses 14400 (4
> hours, I've seen that too), that gives a 24 minute window.  These window
> sizes may be perfectly fine.  But depending on the amount of connected
> users, this may be troublesome too.
>
> Last night I chatted with krzee on #openvpn-devel about this.  He does
> quite some cool stuff with OpenVPN and have lots of IP phones connecting
> to VPN servers.  He said that randomness by default may not be ideal for
> some of the setups he manages.   But he loves the idea behind this
> feature.
>
> Krzee argued that configurations explicitly setting --reneg-sec 3600
> should not have any randomness.  If a configuration does _not* set
> --reneg-sec, it may have randomness with 1 hour as the base.  And those
> wanting better control of the time window should use:
>   --reneg-sec min max
>
> I initially was of the opinion --reneg-sec 3600 should have randomness
> (the 10-17% base).  But after having slept on it, I think Krzee have a
> good point.  Setting --reneg-sec explicitly with only a single value
> should not have any randomness.
>
> With the 1 hour default, not setting --reneg-sec gives a time window of
> 6 minutes with 10%.  That is a reasonable default unless explicitly
> overridden by either --reneg-sec 3600 (no randomness) or --reneg-sec
> 3000 4000 (with a 1000 seconds large time window)

Wow, this discussion suddenly caught some attention!  I'll chip in too.

I was fine with not making this configurable, but the discussion
convinced me that people really want to be able to configure this, so
I agree we should.

As for the option, I think Arne's proposal is the best:
  --reneg-sec max [min]
where  == --reneg-sec 3600 == --reneg-sec 3600 3240 (assuming
10% default randomization)

Why? Because this
1) doesn't change the meaning of the first argument based on whether
the second is present.  That's just confusing.
2) does by default what we expect is best for most users: randomize
the reneg-sec value
3) still allows administrators to disable randomization
4) 'max' and 'min' are hard to misinterpret ('window', 'jitter' or
'offset' are much easier to misinterpret)

As for 'first time only' or 'always': go for always. That will slowly
spread out the clients over the entire reneg-sec window, instead of
over just xx% of the window. The odds that 'all periods line up' that
David mentioned seem negligible to me. Especially assuming that
clients will occasionally reconnect at 'random' times. I did not do
the calculations, but can do that if you really want to.

Finally, we should probably only randomize by default on the server
side. We effectively renegotiate at min(server-reneg-interval,
client-reneg-interval), which will cause a bias towards the earlier
part of the interval if randomize at both sides.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only configurations"

[Steffan Karger]

Hi,

On 26-03-17 13:21, Ilya Shipitsin wrote:
> Inspired by 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html
> build options are taken from regular windows installer builds

Feature-ACK.  Adding cross-compile builds for Windows on travis is a
good plan.

Initial feedback below.

> 
> Signed-off-by: Ilya Shipitsin 
> ---
>  .travis.yml   | 30 +---
>  .travis/build-deps.sh | 55 
> ++-
>  2 files changed, 73 insertions(+), 12 deletions(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 3c0aa7d..9ab30a2 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -12,6 +12,9 @@ env:
>global:
>  - JOBS=3
>  - PREFIX="${HOME}/opt"
> +- TAP_WINDOWS_VERSION=9.21.2
> +- LZO_VERSION=2.10
> +- PKCS11_HELPER_VERSION=1.11
>  - MBEDTLS_VERSION="2.4.0"
>  - MBEDTLS_CFLAGS="-I${PREFIX}/include"
>  - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto"
> @@ -50,6 +53,12 @@ matrix:
>os: osx
>osx_image: xcode7.3
>compiler: clang
> +- env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32
> +  os: linux
> +  compiler: ": Win64 build only"
> +- env: SSLLIB="openssl" CHOST=i686-w64-mingw32
> +  os: linux
> +  compiler: ": Win32 build only"
>exclude:
>  - compiler: gcc
>  
> @@ -60,6 +69,7 @@ addons:
>- libpam0g-dev
>- liblz4-dev
>- linux-libc-dev
> +  - man2html
>  
>  cache:
>ccache: true
> @@ -72,16 +82,22 @@ before_install:
>- if [ "${TRAVIS_OS_NAME}" = "osx" ]; then brew install lzo; fi
>  
>  install:
> +  - if [ ! -z "${CHOST+xxx}" ]; then unset CC; unset CXX; fi

What is the function of this +xxx ?  It seems to me that all you need is
"if [ ! -z "${CHOST}" ]".

>- .travis/build-deps.sh > build-deps.log 2>&1 || (cat build-deps.log && 
> exit 1)
>  
>  script:
>- if [ "${TRAVIS_OS_NAME}" = "linux" ]; then export 
> LD_LIBRARY_PATH="${PREFIX}/lib:${LD_LIBRARY_PATH}"; fi
>- if [ "${TRAVIS_OS_NAME}" = "osx"   ]; then export 
> DYLD_LIBRARY_PATH="${PREFIX}/lib:${DYLD_LIBRARY_PATH}"; fi
>- autoreconf -vi
> -  - ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1)
> -  - make -j$JOBS
> -  - src/openvpn/openvpn --version || true
> -  - if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; fi
> -  - make check
> -  - $EXTRA_SCRIPT
> +  - if [ -z "${CHOST+xxx}" ]; then
> +  ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1);
> +  make -j$JOBS;
> +  src/openvpn/openvpn --version || true;
> +  if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi;
> +  if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; 
> fi;
> +  make check;
> +  $EXTRA_SCRIPT;
> +else
> +  TAP_CFLAGS="-I${PWD}/tap-windows-${TAP_WINDOWS_VERSION}/include" 
> LZO_CFLAGS="-I${PREFIX}/include" LZO_LIBS="-L${PREFIX}/lib -llzo2" 
> PKCS11_HELPER_LIBS="-L${PREFIX}/lib -lpkcs11-helper" 
> PKCS11_HELPER_CFLAGS="-I${PREFIX}/include" ./configure --host=${CHOST} 
> --build=x86_64-pc-linux-gnu --enable-pkcs11 --disable-plugins || (cat 
> config.log && exit 1);

All these _CFLAGS and _LIBS should go into the env: section above.

Any reason to --enable-pkcs11 for the windows builds, while that's not
done for the non-windows builds?

> +  make -j$JOBS;
> +fi
> diff --git a/.travis/build-deps.sh b/.travis/build-deps.sh
> index 3ffba0b..18f40ec 100755
> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -31,7 +31,6 @@ download_openssl () {
>  }
>  
>  build_openssl_linux () {
> -tar zxf "download-cache/openssl-${OPENSSL_VERSION}.tar.gz"
>  (
>  cd "openssl-${OPENSSL_VERSION}/"
>  ./config shared --openssldir="${PREFIX}" -DPURIFY
> @@ -40,7 +39,6 @@ build_openssl_linux () {
>  }
>  
>  build_openssl_osx () {
> -tar zxf "download-cache/openssl-${OPENSSL_VERSION}.tar.gz"
>  (
>  cd "openssl-${OPENSSL_VERSION}/"
>  ./Configure darwin64-x86_64-cc shared \
> @@ -49,9 +47,25 @@ build_openssl_osx () {
>  )
>  }
>  
> +build_openssl_mingw () {
> +(
> +cd "openssl-${OPENSSL_VERSION}/"
> +
> +if [ "${CHOST}" = "i686-w64-mingw32" ]; then export target=mingw; fi
> +if [ "${CHOST}" = "x86_64-w64-mingw32" ]; then export 
> target=mingw64; fi
> +
> +./Configure --cross-compile-prefix=${CHOST}- shared \
> +   $target no-multilib no-capieng --openssldir="${PREFIX}" 
> -static-libgcc

Can you try to keep style consistent?  I.e. use all-caps variable names
(TARGET instead of target) and use quoting ("${TARGET}" instead of $target).

> +make install  
> +)
> +}
> +
>  build_openssl () {
>  if [ "$(cat ${PREFIX}/.openssl-version)" != "${OPENSSL_VERSION}" ]; then
> -if

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only configurations"

[Steffan Karger]

Hi,

On 09-04-17 12:54, Илья Шипицин wrote:
> 
> 2017-04-09 13:44 GMT+05:00 Steffan Karger  <mailto:stef...@karger.me>>:
> 
> On 26-03-17 13:21, Ilya Shipitsin wrote:
> > +  TAP_CFLAGS="-I${PWD}/tap-windows-${TAP_WINDOWS_VERSION}/include"
> LZO_CFLAGS="-I${PREFIX}/include" LZO_LIBS="-L${PREFIX}/lib -llzo2"
> PKCS11_HELPER_LIBS="-L${PREFIX}/lib -lpkcs11-helper"
> PKCS11_HELPER_CFLAGS="-I${PREFIX}/include" ./configure
> --host=${CHOST} --build=x86_64-pc-linux-gnu --enable-pkcs11
> --disable-plugins || (cat config.log && exit 1);
> 
> All these _CFLAGS and _LIBS should go into the env: section above.
> 
> 
> there are 3 "env" sections: global and 2 "mingw".
> I'm afraid, defining those variables in global section might have some
> side effect, while specifying variables 2 times in both mingw sections
> also do not make much sense.

Good point, my suggestion will not work.  I'm still not quite happy with
this very long line though.  Maybe put them in something like
.travis/win_build_vars and source that file from .travis.yml ?  Other
suggestions are welcome too.

> Any reason to --enable-pkcs11 for the windows builds, while that's not
> done for the non-windows builds?
> 
> 
> regular windows installer is built with pkcs11. that's why I added that
> option.

Ok.  Makes sense to verify that at least our own Windows builds work.

> build matrix for non-windows builds was discussed and nobody asked me to
> add pkcs11 there.

I just wondered why the difference, didn't mean to suggest that we need
to add pkcs11 to the other builds.

> >  # Enable ccache
> > -if [ "${TRAVIS_OS_NAME}" != "osx" ]; then
> > +if [ "${TRAVIS_OS_NAME}" != "osx" ] && [ -z "${CHOST+xxx}" ]; then
> >  # ccache not available on osx, see:
> >  # https://github.com/travis-ci/travis-ci/issues/5567
> <https://github.com/travis-ci/travis-ci/issues/5567>
> 
> Is ccache not available for mingw?  In that case, please update the
> comment, preferably with a reference to a travis issue so that we can
> enable it if travis adds support later on.
> 
> 
> I could not get ccache working with mingw, but there's no issue, I'm not
> sure it is related to travis either.

Ok.  Then just make sure to update the comment so it becomes clear that
&& [ -z "${CHOST+xxx}" ] disables ccache for windows cross compiles.

> > @@ -70,7 +84,6 @@ if [ "${TRAVIS_OS_NAME}" != "osx" ]; then
> >  fi
> >
> >  # Download and build crypto lib
> > -mkdir -p download-cache
> >  if [ "${SSLLIB}" = "openssl" ]; then
> >  download_openssl
> >  build_openssl
> > @@ -81,3 +94,35 @@ else
> >  echo "Invalid crypto lib: ${SSLLIB}"
> >  exit 1
> >  fi
> > +
> > +if [ ! -z ${CHOST+xxx} ]; then
> > +  echo "deb http://archive.ubuntu.com/ubuntu 
> <http://archive.ubuntu.com/ubuntu>
> xenial main universe" | sudo tee -a /etc/apt/sources.list.d/xenial.list
> > +  echo "deb http://archive.ubuntu.com/ubuntu 
> <http://archive.ubuntu.com/ubuntu>
> xenial main" | sudo tee -a /etc/apt/sources.list.d/xenial.list
> > +  sudo apt-get update
> > +  sudo apt-get -y install dpkg mingw-w64
> > +  if [ ! -f 
> "download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip" ]; then
> > + wget -P download-cache/ 
> http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip>
> > +  fi
> 
> This should be in a download_tap_windows() function.
> 
> 
> can you be more particular on "should be".
> it does not mean "must be".
> if so, we can leave it, right ?

I'll be more clear (and less polite..):  writing long lists of commands
is bad.  That's not only true for code, it goes for scripts as well.
Writing functions (with good names!) allows the reader to not have to
parse the commands to understand what the author wanted to do.

If we put this in functions, the pkcs11 section will read

  download_pkcs11helper
  build_pkcs11helper

Which makes it immediately clear what the intent of that code is.

For tap-windows we only have to download and extract, to that would only
read

 download_tap_windows

which makes this immediately clear to

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only configurations"

[Steffan Karger]

Hi,

On 09-04-17 15:31, Илья Шипицин wrote:
> > > @@ -70,7 +84,6 @@ if [ "${TRAVIS_OS_NAME}" != "osx" ]; then
> > >  fi
> > >
> > >  # Download and build crypto lib
> > > -mkdir -p download-cache
> > >  if [ "${SSLLIB}" = "openssl" ]; then
> > >  download_openssl
> > >  build_openssl
> > > @@ -81,3 +94,35 @@ else
> > >  echo "Invalid crypto lib: ${SSLLIB}"
> > >  exit 1
> > >  fi
> > > +
> > > +if [ ! -z ${CHOST+xxx} ]; then
> > > +  echo "deb http://archive.ubuntu.com/ubuntu
>   >
> > xenial main universe" | sudo tee -a 
> /etc/apt/sources.list.d/xenial.list
> > > +  echo "deb http://archive.ubuntu.com/ubuntu
>   >
> > xenial main" | sudo tee -a /etc/apt/sources.list.d/xenial.list
> > > +  sudo apt-get update
> > > +  sudo apt-get -y install dpkg mingw-w64
> > > +  if [ ! -f 
> "download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip" ]; then
> > > + wget -P download-cache/ 
> http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> 
> > 
>  
> >
> > > +  fi
> >
> > This should be in a download_tap_windows() function.
> >
> >
> > can you be more particular on "should be".
> > it does not mean "must be".
> > if so, we can leave it, right ?
> 
> I'll be more clear (and less polite..):  writing long lists of commands
> is bad.  That's not only true for code, it goes for scripts as well.
> Writing functions (with good names!) allows the reader to not have to
> parse the commands to understand what the author wanted to do.
> 
> If we put this in functions, the pkcs11 section will read
> 
>   download_pkcs11helper
>   build_pkcs11helper
> 
> Which makes it immediately clear what the intent of that code is.
> 
> For tap-windows we only have to download and extract, to that would only
> read
> 
>  download_tap_windows
> 
> which makes this immediately clear too.
> 
> This really is basic software engineering, and the lack of quality in
> quite some of your contributions is an important reason why your
> contributions aren't picked up quickly.  Your ideas and intentions are
> good, but we need to put in far too much effort to make the quality of
> your contribution acceptable.  Time that we can also spend on
> better-quality contributions.  It would help us all (including you) if
> you would try to improve on that.
> 
> 
> 
> those code lines are not reusable, so not splitting it into functions
> does not mean poor quality (for me)
> the rule of thumb is "to put into function piece of code, which is
> called many times"
> 
> otherwise, it might be either function or not.

Functions are not only to prevent code duplication.  They are also for
structuring your code.  Which is exactly what I'm suggesting here.  Code
does not only need to do it's job, it also needs to be maintainable.

> how did you came to conclusion that it means poor code quality?
> is it written somewhere on the https://openvpn.net on how to write bash
> scripts ?

We're not here to give software engineering classes.  Nor is the openvpn
wiki meant to be a book on software engineering.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only configurations"

[Steffan Karger]

Hi,

[This will be my last on-list reply about this.]

On 09-04-17 19:10, Илья Шипицин wrote:
> 
> 
> 2017-04-09 21:58 GMT+05:00 Steffan Karger  <mailto:stef...@karger.me>>:
> 
> Hi,
> 
> On 09-04-17 15:31, Илья Шипицин wrote:
> > > > @@ -70,7 +84,6 @@ if [ "${TRAVIS_OS_NAME}" != "osx" ]; then
> > > >  fi
> > > >
> > > >  # Download and build crypto lib
> > > > -mkdir -p download-cache
> > > >  if [ "${SSLLIB}" = "openssl" ]; then
> > > >  download_openssl
> > > >  build_openssl
> > > > @@ -81,3 +94,35 @@ else
> > > >  echo "Invalid crypto lib: ${SSLLIB}"
> > > >  exit 1
> > > >  fi
> > > > +
> > > > +if [ ! -z ${CHOST+xxx} ]; then
> > > > +  echo "deb http://archive.ubuntu.com/ubuntu 
> <http://archive.ubuntu.com/ubuntu>
> > <http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu>>
> <http://archive.ubuntu.com/ubuntu <http://archive.ubuntu.com/ubuntu>
> > <http://archive.ubuntu.com/ubuntu 
> <http://archive.ubuntu.com/ubuntu>>>
> > > xenial main universe" | sudo tee -a 
> /etc/apt/sources.list.d/xenial.list
> > > > +  echo "deb http://archive.ubuntu.com/ubuntu 
> <http://archive.ubuntu.com/ubuntu>
> > <http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu>>
> <http://archive.ubuntu.com/ubuntu <http://archive.ubuntu.com/ubuntu>
> > <http://archive.ubuntu.com/ubuntu
> <http://archive.ubuntu.com/ubuntu>>>
> > > xenial main" | sudo tee -a
> /etc/apt/sources.list.d/xenial.list
> > > > +  sudo apt-get update
> > > > +  sudo apt-get -y install dpkg mingw-w64
> > > > +  if [ ! -f
> "download-cache/tap-windows-${TAP_WINDOWS_VERSION}.zip" ]; then
> > > > + wget -P download-cache/
> 
> http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip>
> >   
>  
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip>>
> > >   
>  
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip>
> >   
>  
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip
> 
> <http://build.openvpn.net/downloads/releases/tap-windows-${TAP_WINDOWS_VERSION}.zip>>>
> > > > +  fi
> > >
> > > This should be in a download_tap_windows() function.
> > >
> > >
> > > can you be more particular on "should be".
> > > it does not mean "must be".
> > > if so, we can leave it, right ?
> >
> > I'll be more clear (and less polite..):  writing long lists of
> commands
> > is bad.  That's not only true for code, it goes for scripts as
> well.
> > Writing functions (with good names!) allows the reader to not
> have to
> > parse the commands to understand what the author wanted to do.
> >
> > If we put this in functions, the pkcs11 section will read
> >
> >   download_pkcs11helper
> >   build_pkcs11helper
> >
> > Which makes it immediately clear what the intent of that code is.
> >
> > For tap-windows we only have to download and extract, to that
> would only
> > read
> >
> >  download_tap_windows
> >
> > which makes this immediately clear too.
> >
> > This really is basic software engineering, and the lack of
> quality in
> > quite some of your contributions is an important reason why your
> > contributions aren't p

[Openvpn-devel] [PATCH] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

This allows the user to specify what certificate crypto algorithms to
support.  The supported profiles are 'preferred' (default), 'legacy' and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214.html).

This only implements the feature for mbed TLS builds, because for mbed it
is both more easy to implement and the most relevant because mbed TLS 2+
is by default somewhat restrictive by requiring 2048-bit+ for RSA keys.

Signed-off-by: Steffan Karger 
---
 src/openvpn/options.c |  8 
 src/openvpn/options.h |  1 +
 src/openvpn/ssl.c |  3 +++
 src/openvpn/ssl_backend.h | 10 ++
 src/openvpn/ssl_mbedtls.c | 51 +++
 src/openvpn/ssl_mbedtls.h |  1 +
 src/openvpn/ssl_openssl.c |  6 ++
 7 files changed, 80 insertions(+)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 9fef394..7142243 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -873,6 +873,7 @@ init_options(struct options *o, const bool init_gc)
 o->renegotiate_seconds = 3600;
 o->handshake_window = 60;
 o->transition_window = 3600;
+o->tls_cert_profile = "preferred";
 o->ecdh_curve = NULL;
 #ifdef ENABLE_X509ALTUSERNAME
 o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
@@ -1752,6 +1753,7 @@ show_settings(const struct options *o)
 SHOW_STR(cryptoapi_cert);
 #endif
 SHOW_STR(cipher_list);
+SHOW_STR(tls_cert_profile);
 SHOW_STR(tls_verify);
 SHOW_STR(tls_export_cert);
 SHOW_INT(verify_x509_type);
@@ -2734,6 +2736,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 MUST_BE_UNDEF(pkcs12_file);
 #endif
 MUST_BE_UNDEF(cipher_list);
+MUST_BE_UNDEF(tls_cert_profile);
 MUST_BE_UNDEF(tls_verify);
 MUST_BE_UNDEF(tls_export_cert);
 MUST_BE_UNDEF(verify_x509_name);
@@ -7813,6 +7816,11 @@ add_option(struct options *options,
 VERIFY_PERMISSION(OPT_P_GENERAL);
 options->cipher_list = p[1];
 }
+else if (streq(p[0], "tls-cert-profile") && p[1] && !p[2])
+{
+VERIFY_PERMISSION(OPT_P_GENERAL);
+options->tls_cert_profile = p[1];
+}
 else if (streq(p[0], "crl-verify") && p[1] && ((p[2] && streq(p[2], "dir"))
|| (p[2] && streq(p[1], 
INLINE_FILE_TAG) ) || !p[2]) && !p[3])
 {
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index b3ab029..9085413 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -500,6 +500,7 @@ struct options
 const char *priv_key_file;
 const char *pkcs12_file;
 const char *cipher_list;
+const char *tls_cert_profile;
 const char *ecdh_curve;
 const char *tls_verify;
 int verify_x509_type;
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 1033e58..72dbec3 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -702,6 +702,9 @@ init_ssl(const struct options *options, struct tls_root_ctx 
*new_ctx)
 /* Allowable ciphers */
 tls_ctx_restrict_ciphers(new_ctx, options->cipher_list);
 
+/* Restrict allowed certificate crypto algorithms */
+tls_ctx_set_cert_profile(new_ctx, options->tls_cert_profile);
+
 #ifdef ENABLE_CRYPTO_MBEDTLS
 /* Personalise the random by mixing in the certificate */
 tls_ctx_personalise_random(new_ctx);
diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index 206400f..3b14908 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -178,6 +178,16 @@ void tls_ctx_set_options(struct tls_root_ctx *ctx, 
unsigned int ssl_flags);
 void tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const char *ciphers);
 
 /**
+ * Set the TLS certificate profile.  The profile defines which crypto
+ * algorithms may be used in the supplied certificate.
+ *
+ * @param ctx   TLS context to restrict, must be valid.
+ * @param profile   The profile name ('preferred', 'legacy' or 'suiteb').
+ *  May NOT be NULL.
+ */
+void tls_ctx_set_cert_profile(struct tls_root_ctx *ctx, const char *profile);
+
+/**
  * Check our certificate notBefore and notAfter fields, and warn if the cert is
  * either not yet valid or has expired.  Note that this is a non-fatal error,
  * since we compare against the system time, which might be incorrect.
diff --git a/src/openvpn/ssl_mbedtls.c b/src/openvpn/ssl_mbedtls.c
index ba8dadf..1fcee72 100644
--- a/src/openvpn/ssl_mbedtls.c
+++ b/src/openvpn/ssl_mbedtls.c
@@ -63,6 +63,34 @@
 #include 
 #include 
 
+static const mbedtls_x509_crt_profile openvpn_x509_crt_profile_legacy =
+{
+/* Hashes from SHA-1 and above */
+MBEDTLS_X509_ID_FLAG( MBE

Re: [Openvpn-devel] [PATCH] Make --cipher/--auth none more explicit on the risks

[Steffan Karger]

On 11-04-17 10:55, David Sommerseth wrote:
> On 11/04/17 06:26, Simon Matter wrote:
>>> The warning provided to --cipher and --auth using the 'none' setting may
>>> not have been too clearly understandable to non-developers or people not
>>> fully understanding encryption and cryptography.  This tries to improve
>>> that.
>>>
>>> While at it, also break up the long source lines.
>>>
>>> Signed-off-by: David Sommerseth 
>>> ---
>>>  src/openvpn/crypto.c | 11 +--
>>>  src/openvpn/init.c   |  5 -
>>>  2 files changed, 13 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
>>> index 909f725..8a5c723 100644
>>> --- a/src/openvpn/crypto.c
>>> +++ b/src/openvpn/crypto.c
>>> @@ -784,7 +784,10 @@ init_key_type(struct key_type *kt, const char
>>> *ciphername,
>>>  {
>>>  if (warn)
>>>  {
>>> -msg(M_WARN, "*** WARNING ***: null cipher specified,
>>> no encryption will be used");
>>> +msg(M_WARN, "*** WARNING ***: '--cipher none' was
>>> specified. "
>>> +"This means NO encryption will be performed and tunnelled
>>> "
>>> +"data WILL be transmitted in clear text over the network!
>>> "
>>> +"PLEASE DO RECONIDER THIS SETTING!");
>>
>> Hi
>>
>> Small typos, you may want to 's/RECONIDER/RECONSIDER/g' the patches.
> 
> Meh, yeah, sorry about that.  That need to be fixed, but also something
> I can fix on-the-fly at commit time; that's an uncritical last minute
> change.  Just need an ACK first ;-)

ACK if you fix the typos :)

-Steffan




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Require minimum OpenSSL 1.0.1

[Steffan Karger]

Hi,

On 11-04-17 19:31, David Sommerseth wrote:
> As RHEL 5 has reached EOL, we no longer need to support OpenSSL v0.9.8.
> This also makes it possible to remove a few workaronds which was
> needed earlier, as well as some left overs from v0.9.6.
> 
> This also makes ./configure really stop running unless a new enough
> OpenSSL library is found.
> 
> Compile tested on RHEL7.3 and RHEL6.7 (mock chroot build), both shipping
> openssl-1.0.1e.
> 
> Signed-off-by: David Sommerseth 
> ---
>  configure.ac  |  6 +++---
>  doc/openvpn.8 |  1 -
>  .../keying-material-exporter-demo/keyingmaterialexporter.c|  3 +--
>  sample/sample-plugins/log/log_v3.c|  3 +--
>  src/openvpn/ssl_openssl.c |  3 ---
>  src/openvpn/ssl_openssl.h | 11 
> ---
>  src/openvpn/ssl_verify_openssl.c  |  6 ++
>  7 files changed, 7 insertions(+), 26 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index 2406ad8..acea060 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -859,9 +859,9 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   # if the user did not explicitly specify flags, try to 
> autodetect
>   PKG_CHECK_MODULES(
>   [OPENSSL],
> - [libcrypto >= 0.9.8, libssl >= 0.9.8],
> - [have_openssl="yes"],
> - [have_openssl="no"] # Provide if-not-found to prevent 
> erroring out
> + [libcrypto >= 1.0.1, libssl >= 1.0.1],
> + [have_openssl="yes"],
> + [AC_MSG_ERROR([Minimum supported OpenSSL version is 
> 1.0.1])]
>   )
>  
>   OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index a9f5db7..c3248fd 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -2773,7 +2773,6 @@ OPENVPN_PLUGIN_TLS_FINAL callback.
>  Note that exporter labels have the potential to collide with existing PRF
>  labels. In order to prevent this, labels MUST begin with "EXPORTER".
>  
> -This option requires OpenSSL 1.0.1 or newer.
>  .\"*
>  .SS Server Mode
>  Starting with OpenVPN 2.0, a multi-client TCP/UDP server mode
> diff --git 
> a/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
>  
> b/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
> index 177977d..a72b374 100644
> --- 
> a/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
> +++ 
> b/sample/sample-plugins/keying-material-exporter-demo/keyingmaterialexporter.c
> @@ -143,8 +143,7 @@ session_user_set(struct session *sess, X509 *x509)
>  {
>  continue;
>  }
> -/* bug in OpenSSL 0.9.6b ASN1_STRING_to_UTF8 requires this 
> workaround */
> -unsigned char *buf = (unsigned char *)1;
> +unsigned char *buf = NULL;
>  if (ASN1_STRING_to_UTF8(&buf, val) <= 0)
>  {
>  continue;
> diff --git a/sample/sample-plugins/log/log_v3.c 
> b/sample/sample-plugins/log/log_v3.c
> index 9037225..d3014f3 100644
> --- a/sample/sample-plugins/log/log_v3.c
> +++ b/sample/sample-plugins/log/log_v3.c
> @@ -197,7 +197,7 @@ x509_print_info(X509 *x509crt)
>  X509_NAME *x509_name;
>  X509_NAME_ENTRY *ent;
>  const char *objbuf;
> -unsigned char *buf;
> +unsigned char *buf = NULL;
>  
>  x509_name = X509_get_subject_name(x509crt);
>  n = X509_NAME_entry_count(x509_name);
> @@ -228,7 +228,6 @@ x509_print_info(X509 *x509crt)
>  {
>  continue;
>  }
> -buf = (unsigned char *)1; /* bug in OpenSSL 0.9.6b 
> ASN1_STRING_to_UTF8 requires this workaround */
>  if (ASN1_STRING_to_UTF8(&buf, val) <= 0)
>  {
>  continue;
> diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
> index d7cc2ba..645ccf5 100644
> --- a/src/openvpn/ssl_openssl.c
> +++ b/src/openvpn/ssl_openssl.c
> @@ -254,10 +254,7 @@ tls_ctx_set_options(struct tls_root_ctx *ctx, unsigned 
> int ssl_flags)
>  sslopt |= SSL_OP_NO_TLSv1_2;
>  }
>  #endif
> -#ifdef SSL_OP_NO_COMPRESSION
> -/* Disable compression - flag not available in OpenSSL 0.9.8 */
>  sslopt |= SSL_OP_NO_COMPRESSION;
> -#endif
>  SSL_CTX_set_options(ctx->ctx, sslopt);
>  }
>  
> diff --git a/src/openvpn/ssl_openssl.h b/src/openvpn/ssl_openssl.h
> index 6ca4cb6..60a1f5e 100644
> --- a/src/openvpn/ssl_openssl.h
> +++ b/src/openvpn/ssl_openssl.h
> @@ -33,17 +33,6 @@
>  #include 
>  
>  /**
> - * SSL_OP_NO_TICKET tells OpenSSL to disable "stateless session resumption",
> - * as this is something we do not want nor need, but could potentially be
> - * used for a fut

Re: [Openvpn-devel] [PATCH] Require minimum OpenSSL 1.0.1

[Steffan Karger]

Hi,

On 11-04-17 23:56, David Sommerseth wrote:
> On 11/04/17 23:20, Steffan Karger wrote:
>> On 11-04-17 19:31, David Sommerseth wrote:
>>> As RHEL 5 has reached EOL, we no longer need to support OpenSSL v0.9.8.
>>> This also makes it possible to remove a few workaronds which was
>>> needed earlier, as well as some left overs from v0.9.6.
>>>
>>> This also makes ./configure really stop running unless a new enough
>>> OpenSSL library is found.
>>>
>>> Compile tested on RHEL7.3 and RHEL6.7 (mock chroot build), both shipping
>>> openssl-1.0.1e.
>>>
>>> Signed-off-by: David Sommerseth 
>>> ---
>>>  configure.ac  |  6 +++---
>>>  doc/openvpn.8 |  1 -
>>>  .../keying-material-exporter-demo/keyingmaterialexporter.c|  3 +--
>>>  sample/sample-plugins/log/log_v3.c|  3 +--
>>>  src/openvpn/ssl_openssl.c |  3 ---
>>>  src/openvpn/ssl_openssl.h | 11 
>>> ---
>>>  src/openvpn/ssl_verify_openssl.c  |  6 ++
>>>  7 files changed, 7 insertions(+), 26 deletions(-)
>>>
> [...snip...]
>>
>> For master: ACK.
>>
>> For release/2.4: I wonder whether we need to keep 0.9.8 support, as
>> SLES11 still ships with 0.9.8h, and has general support until 31 Mar 2019.
> 
> While it is James who insisted on RHEL being the oldest supported distro
> many years ago, I have no issues with keeping SLES *or* RHEL as the
> oldest supported distro, in regards to package dependencies.
> 
> Do we know if we have a large group of SLES 11 users?  Initially I
> thought it was related to OpenVPN-NL ... until I recalled that
> OPenVPN-NL should be built against mbed TLS :)

Well, I don't care much for legacy support (and for OpenVPN-NL, I don't
care at all, indeed).  I consider you to be our authority on what Linux
platforms we want to support.  Just wanted to point this out so you
could decide on what to do for 2.4.  I'm fine with whatever you decide here.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

This allows the user to specify what certificate crypto algorithms to
support.  The supported profiles are 'preferred' (default), 'legacy' and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214.html).

This only implements the feature for mbed TLS builds, because for mbed it
is both more easy to implement and the most relevant because mbed TLS 2+
is by default somewhat restrictive by requiring 2048-bit+ for RSA keys.

Signed-off-by: Steffan Karger 
---
v2:
 - add documentation (manpage, Changes.rst and --help)
 - no longer print a warning message on each startup for OpenSSL builds

 Changes.rst   | 28 +++---
 doc/openvpn.8 | 19 ++
 src/openvpn/options.c | 14 -
 src/openvpn/options.h |  1 +
 src/openvpn/ssl.c |  3 +++
 src/openvpn/ssl_backend.h | 10 ++
 src/openvpn/ssl_mbedtls.c | 51 +++
 src/openvpn/ssl_mbedtls.h |  1 +
 src/openvpn/ssl_openssl.c |  6 ++
 9 files changed, 120 insertions(+), 13 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 2a94990..ffd4ac3 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -306,15 +306,19 @@ Maintainer-visible changes
 
 Version 2.4.1
 =
- - ``--remote-cert-ku`` now only requires the certificate to have at least the
-   bits set of one of the values in the supplied list, instead of requiring an
-   exact match to one of the values in the list.
- - ``--remote-cert-tls`` now only requires that a keyUsage is present in the
-   certificate, and leaves the verification of the value up to the crypto
-   library, which has more information (i.e. the key exchange method in use)
-   to verify that the keyUsage is correct.
- - ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
-   The nsCertType x509 extension is very old, and barely used.
-   ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
-   extension instead.  Make sure your certificates carry these to be able to
-   use ``--remote-cert-tls``.
+- ``--remote-cert-ku`` now only requires the certificate to have at least the
+  bits set of one of the values in the supplied list, instead of requiring an
+  exact match to one of the values in the list.
+- ``--remote-cert-tls`` now only requires that a keyUsage is present in the
+  certificate, and leaves the verification of the value up to the crypto
+  library, which has more information (i.e. the key exchange method in use)
+  to verify that the keyUsage is correct.
+- ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
+  The nsCertType x509 extension is very old, and barely used.
+  ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
+  extension instead.  Make sure your certificates carry these to be able to
+  use ``--remote-cert-tls``.
+- The new option ``--tls-cert-profile`` can be used to restrict the set of
+  allowed crypto algorithms in TLS certificates in mbed TLS builds.  The
+  'legacy' profile can be used to re-enable support for SHA1 and 1024-bit RSA
+  keys.
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index c3248fd..1e46abe 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4878,6 +4878,25 @@ when using PolarSSL or
 OpenSSL.
 .\"*
 .TP
+.B \-\-tls\-cert\-profile profile
+Set the allowed cryptographic algorithms for certificates according to
+.B profile\fN.
+
+The following profiles are supported:
+
+.B preferred
+(default): SHA2 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B legacy
+: SHA1 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B suiteb
+: SHA256/SHA384, ECDSA with P-256 or P-384.
+
+This option is only supported for mbed TLS builds.  OpenSSL builds accept any
+certificate that OpenSSL accepts.
+.\"*
+.TP
 .B \-\-tls\-timeout n
 Packet retransmit timeout on TLS control channel
 if no acknowledgment from remote within
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index dcb6ecf..c6fb2c8 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -598,6 +598,8 @@ static const char usage_message[] =
 #endif
 "--tls-cipher l  : A list l of allowable TLS ciphers separated by : 
(optional).\n"
 ": Use --show-tls to see a list of supported TLS 
ciphers.\n"
+"--tls-cert-profile p : Set the allowed certificate crypto algorithm 
profile\n"
+"  (default=%s).\n"
 "--tls-timeout n : Packet retransmit timeout on TLS control channel\n"
 "  if no ACK from remote within n seconds (default=%d).\n"
 "--reneg-bytes n : Renegotiate data chan. key after n bytes sent and 
recvd.\n"
@@ -871,6 +873,7 @@

Re: [Openvpn-devel] [PATCH] cleanup: merge packet_id_alloc_outgoing() into packet_id_write()

[Steffan Karger]

On 19-12-16 00:01, Steffan Karger wrote:
> The functions packet_id_alloc_outgoing() and packet_id_write() were
> always called in tandem.  Instead of forcing the caller to allocate a
> packet_id_net to do so, merge the two functions.  This simplifies the API
> and reduces the chance on mistakes in the future.
> 
> This patch adds unit tests to verify the behaviour of packet_id_write().
> Verifying that we assert out correctly required the change to mock_msg.c.
> 
> Signed-off-by: Steffan Karger 
> ---
> This patch is for the master branch only.
> 
>  src/openvpn/crypto.c  |  19 ++--
>  src/openvpn/packet_id.c   |  24 -
>  src/openvpn/packet_id.h   |  35 +++
>  src/openvpn/tls_crypt.c   |   4 +-
>  tests/unit_tests/openvpn/Makefile.am  |  16 ++-
>  tests/unit_tests/openvpn/mock_msg.c   |  15 ++-
>  tests/unit_tests/openvpn/test_packet_id.c | 168 
> ++
>  7 files changed, 229 insertions(+), 52 deletions(-)

Can I tempt anyone into reviewing this patch?  Don't get scared by the
size - it's mostly adding tests.  The function changes are very small.

-Steffan


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

On 12-04-17 13:35, Steffan Karger wrote:
>  Version 2.4.1
>  =
> - - ``--remote-cert-ku`` now only requires the certificate to have at least 
> the
> -   bits set of one of the values in the supplied list, instead of requiring 
> an
> -   exact match to one of the values in the list.
> - - ``--remote-cert-tls`` now only requires that a keyUsage is present in the
> -   certificate, and leaves the verification of the value up to the crypto
> -   library, which has more information (i.e. the key exchange method in use)
> -   to verify that the keyUsage is correct.
> - - ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
> -   The nsCertType x509 extension is very old, and barely used.
> -   ``--remote-cert-tls`` uses the far more common keyUsage and 
> extendedKeyUsage
> -   extension instead.  Make sure your certificates carry these to be able to
> -   use ``--remote-cert-tls``.
> +- ``--remote-cert-ku`` now only requires the certificate to have at least the
> +  bits set of one of the values in the supplied list, instead of requiring an
> +  exact match to one of the values in the list.
> +- ``--remote-cert-tls`` now only requires that a keyUsage is present in the
> +  certificate, and leaves the verification of the value up to the crypto
> +  library, which has more information (i.e. the key exchange method in use)
> +  to verify that the keyUsage is correct.
> +- ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
> +  The nsCertType x509 extension is very old, and barely used.
> +  ``--remote-cert-tls`` uses the far more common keyUsage and 
> extendedKeyUsage
> +  extension instead.  Make sure your certificates carry these to be able to
> +  use ``--remote-cert-tls``.
> +- The new option ``--tls-cert-profile`` can be used to restrict the set of
> +  allowed crypto algorithms in TLS certificates in mbed TLS builds.  The
> +  'legacy' profile can be used to re-enable support for SHA1 and 1024-bit RSA
> +  keys.

Hrmpf, this should of course get a new section '2.4.2'...  Let me know
if you want a v3, or whether this can be fixed on-the-fly.  Apologies!

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

On 13-04-17 15:09, David Sommerseth wrote:
> I'm however a bit puzzled of the "non-changes" (well, the indenting is
> changing, unless I'm blind to other changes) to --remote-cert-cu,
> --remote-cert-tls and --ns-cert-type.  If we want to change the
> indenting, I think that should be kept in a separate patch, and keep
> --tls-cert-profile as a patch of its own.

Ah, indeed.  The indenting change is needed to make Github parse the rst
correctly.  Feel free to remove the indenting changes and I'll send a
follow-up patch doing just that.

> On a more generic note to this patch.  I wonder if we should keep
> "legacy" the default in the v2.4 branch.  In the Fedora 26 (and
> Rawhide/27) builds I had to do something similar [1] to keep users
> happy.  As OpenVPN isn't ready for OpenSSL v1.1, I had to switch to mbed
> TLS.  Unfortunately that haven't been as successful as I really hoped it
> would be, but that's an entirely different story (and mail thread).  As
> long as the Fedora builds need to be built with mbed TLS, I will need to
> ensure 'legacy' is the default there for a while.  For the coming Fedora
> Rawhide (which will be F28), I can make some announcements preparing
> users to move to stricter defaults.
> 
> [1]
> 

The current mbed TLS builds already reject legacy crypto (except the
fedora packaged build, apparently).  With this patch users have the
ability to use legacy stuff again, but I would prefer to not go any
further than that.  I think we should encourage people to drop the
legacy.  Just like the browser vendors are doing.

And for Fedora, they chose to experience intense pain when they chose to
go for OpenSSL 1.1 this fast, that's their problem I guess...  If they
want to be that cutting edge, they should also stop using legacy crypto.
 And otherwise, it will be a simple patch in the fedora packaging.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v2] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

Hi,

On 13-04-17 18:40, David Sommerseth wrote:
> On 13/04/17 15:37, Steffan Karger wrote:
>> On 13-04-17 15:09, David Sommerseth wrote:
>>> On a more generic note to this patch.  I wonder if we should keep
>>> "legacy" the default in the v2.4 branch.  In the Fedora 26 (and
>>> Rawhide/27) builds I had to do something similar [1] to keep users
>>> happy.  As OpenVPN isn't ready for OpenSSL v1.1, I had to switch to mbed
>>> TLS.  Unfortunately that haven't been as successful as I really hoped it
>>> would be, but that's an entirely different story (and mail thread).  As
>>> long as the Fedora builds need to be built with mbed TLS, I will need to
>>> ensure 'legacy' is the default there for a while.  For the coming Fedora
>>> Rawhide (which will be F28), I can make some announcements preparing
>>> users to move to stricter defaults.
>>>
>>> [1]
>>> <http://pkgs.fedoraproject.org/cgit/rpms/openvpn.git/tree/0001-workaround-Allow-weaker-RSA-keys-and-MD-algorithms-i.patch?h=f26>
>>
>> The current mbed TLS builds already reject legacy crypto (except the
>> fedora packaged build, apparently).  With this patch users have the
>> ability to use legacy stuff again, but I would prefer to not go any
>> further than that.  I think we should encourage people to drop the
>> legacy.  Just like the browser vendors are doing.
> 
> I do agree.  But the pain as a package maintainer is quite noticeable
> when you're getting complaints about configurations this breaks.  In
> fact, I got quite some dissatisfied remarks even for moving from 2.3 to
> 2.4 on the OpenSSL builds (F25 + EPEL) - as that also broke some setups
> - mostly due to our option parser now doesn't ignore configuration
> errors any more or we actually implement the dual stack IPv4/IPv6
> properly on the transport side.
>
> [..snip..]
> 
>> And for Fedora, they chose to experience intense pain when they chose to
>> go for OpenSSL 1.1 this fast, that's their problem I guess...  If they
>> want to be that cutting edge, they should also stop using legacy crypto.
>>  And otherwise, it will be a simple patch in the fedora packaging.
> 
> Well, they do make things move forward fast.  And they do a lot of work
> to get upstream projects moving towards OpenSSL 1.1.  As there is a
> major Fedora release roughly every 6 months, it is a fast moving target.
> 
> But Fedora users as side, they know each major release is a huge step
> forward in many areas.  For most OpenVPN users, regardless of OS or
> distro, they are used to the more sloppy legacy crypto support of
> OpenSSL.  So enforcing a stricter set of crypto parameters in OpenVPN
> v2.4 only on mbed TLS seems a bit odd to me.

I agree - which is why I plan to add similar behaviour to the OpenSSL
builds.  I'm convinced by the argument to better aligning OpenSSL and
mbed TLS behaviour, so I agree that we should default to 'legacy' as
long as the OpenSSL counterpart is missing.

Do you prefer a v3?

The thing I still don't buy is that we have to jump through hoops
because Fedora pushes openssl 1.1 (even though 1.0.2 is fine and
supported and all), but we have to keep enabling deprecated crypto *by
default* that people should not be using anymore, and can easily
re-enable with a --enable-old-cruft flag if they really want to.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH (release/2.4)] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

This allows the user to specify what certificate crypto algorithms to
support.  The supported profiles are 'preferred', 'legacy' (default) and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214.html).

This only implements the feature for mbed TLS builds, because for mbed it
is both more easy to implement and the most relevant because mbed TLS 2+
is by default somewhat restrictive by requiring 2048-bit+ for RSA keys.

In contrast with the patch for the master branch, this patch uses 'legacy'
as the default profile following discussion on the openvpn-devel mailing
list.

Signed-off-by: Steffan Karger 
---
This patch is a cherry-picked and adjusted version of the v3 patch for master.
The only difference being that this patch uses 'legacy' as the default profile
and documents that.

 Changes.rst   |  8 
 doc/openvpn.8 | 22 
 src/openvpn/options.c | 14 -
 src/openvpn/options.h |  1 +
 src/openvpn/ssl.c |  3 +++
 src/openvpn/ssl_backend.h | 10 ++
 src/openvpn/ssl_mbedtls.c | 51 +++
 src/openvpn/ssl_mbedtls.h |  1 +
 src/openvpn/ssl_openssl.c |  6 ++
 9 files changed, 115 insertions(+), 1 deletion(-)

diff --git a/Changes.rst b/Changes.rst
index 2a94990..91cd977 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -318,3 +318,11 @@ Version 2.4.1
``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
extension instead.  Make sure your certificates carry these to be able to
use ``--remote-cert-tls``.
+
+Version 2.4.2
+=
+- The new option ``--tls-cert-profile`` can be used to restrict the set of
+  allowed crypto algorithms in TLS certificates in mbed TLS builds.  The
+  default profile is 'legacy' for now, which allows SHA1+, RSA-1024+ and any
+  elliptic curve certificates.  The default will be changed to the 'preferred'
+  profile in the future, which requires SHA2+, RSA-2048+ and any curve.
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index a9f5db7..19f755b 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4879,6 +4879,28 @@ when using PolarSSL or
 OpenSSL.
 .\"*
 .TP
+.B \-\-tls\-cert\-profile profile
+Set the allowed cryptographic algorithms for certificates according to
+.B profile\fN.
+
+The following profiles are supported:
+
+.B preferred
+: SHA2 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B legacy
+(default): SHA1 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B suiteb
+: SHA256/SHA384, ECDSA with P-256 or P-384.
+
+This option is only supported for mbed TLS builds.  OpenSSL builds accept any
+certificate that OpenSSL accepts.
+
+OpenVPN will migrate to 'preferred' as default in the future.  Please ensure
+that your keys already comply.
+.\"*
+.TP
 .B \-\-tls\-timeout n
 Packet retransmit timeout on TLS control channel
 if no acknowledgment from remote within
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 9fef394..19d732a 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -599,6 +599,8 @@ static const char usage_message[] =
 #endif
 "--tls-cipher l  : A list l of allowable TLS ciphers separated by : 
(optional).\n"
 ": Use --show-tls to see a list of supported TLS 
ciphers.\n"
+"--tls-cert-profile p : Set the allowed certificate crypto algorithm 
profile\n"
+"  (default=%s).\n"
 "--tls-timeout n : Packet retransmit timeout on TLS control channel\n"
 "  if no ACK from remote within n seconds (default=%d).\n"
 "--reneg-bytes n : Renegotiate data chan. key after n bytes sent and 
recvd.\n"
@@ -873,6 +875,7 @@ init_options(struct options *o, const bool init_gc)
 o->renegotiate_seconds = 3600;
 o->handshake_window = 60;
 o->transition_window = 3600;
+o->tls_cert_profile = "legacy";
 o->ecdh_curve = NULL;
 #ifdef ENABLE_X509ALTUSERNAME
 o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
@@ -1752,6 +1755,7 @@ show_settings(const struct options *o)
 SHOW_STR(cryptoapi_cert);
 #endif
 SHOW_STR(cipher_list);
+SHOW_STR(tls_cert_profile);
 SHOW_STR(tls_verify);
 SHOW_STR(tls_export_cert);
 SHOW_INT(verify_x509_type);
@@ -2734,6 +2738,7 @@ options_postprocess_verify_ce(const struct options 
*options, const struct connec
 MUST_BE_UNDEF(pkcs12_file);
 #endif
 MUST_BE_UNDEF(cipher_list);
+MUST_BE_UNDEF(tls_cert_profile);
 MUST_BE_UNDEF(tls_verify);
 MUST_BE_UNDEF(tls_export_cert);
 MUST_BE_UNDEF(verify_x509_name);

[Openvpn-devel] [PATCH v3] Add --tls-cert-profile option for mbedtls builds

[Steffan Karger]

This allows the user to specify what certificate crypto algorithms to
support.  The supported profiles are 'preferred' (default), 'legacy' and
'suiteb', as discussed in <84590a17-1c48-9df2-c48e-4160750b2...@fox-it.com>
(https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14214.html).

This only implements the feature for mbed TLS builds, because for mbed it
is both more easy to implement and the most relevant because mbed TLS 2+
is by default somewhat restrictive by requiring 2048-bit+ for RSA keys.

Signed-off-by: Steffan Karger 
---
v2:
 - add documentation (manpage, Changes.rst and --help)
 - no longer print a warning message on each startup for OpenSSL builds
v3:
 - remove format changes in unrelated items (introduced in v2)
 - Update Changes.rst text to reflect that the default in 2.4.2 is 'legacy'
   and the default in 2.5 will be 'preferred' (as discussed on the ML).
 - This patch is for the master branch only now (due to the default).

 Changes.rst   | 19 +-
 doc/openvpn.8 | 19 ++
 src/openvpn/options.c | 14 -
 src/openvpn/options.h |  1 +
 src/openvpn/ssl.c |  3 +++
 src/openvpn/ssl_backend.h | 10 ++
 src/openvpn/ssl_mbedtls.c | 51 +++
 src/openvpn/ssl_mbedtls.h |  1 +
 src/openvpn/ssl_openssl.c |  6 ++
 9 files changed, 122 insertions(+), 2 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 2a94990..4b4360a 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -1,6 +1,15 @@
-Overview of changes in 2.4
+Overview of changes in 2.5
 ==
 
+User-visible Changes
+
+- (For mbed TLS buils) The default certificate profile is now "preferred",
+  which means that only SHA2+, RSA-2048+ and EC certs are accepted.  Legacy
+  crypto can be re-enabled by setting ``--tls-cert-profile legacy``.
+
+
+Overview of changes in 2.4
+==
 
 New features
 
@@ -318,3 +327,11 @@ Version 2.4.1
``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
extension instead.  Make sure your certificates carry these to be able to
use ``--remote-cert-tls``.
+
+Version 2.4.2
+=
+- The new option ``--tls-cert-profile`` can be used to restrict the set of
+  allowed crypto algorithms in TLS certificates in mbed TLS builds.  The
+  default profile is 'legacy' for now, which allows SHA1+, RSA-1024+ and any
+  elliptic curve certificates.  The default will be changed to the 'preferred'
+  profile in the future, which requires SHA2+, RSA-2048+ and any curve.
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index a9f5db7..fd821c7 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4879,6 +4879,25 @@ when using PolarSSL or
 OpenSSL.
 .\"*
 .TP
+.B \-\-tls\-cert\-profile profile
+Set the allowed cryptographic algorithms for certificates according to
+.B profile\fN.
+
+The following profiles are supported:
+
+.B preferred
+(default): SHA2 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B legacy
+: SHA1 and newer, RSA 2048-bit+, any elliptic curve.
+
+.B suiteb
+: SHA256/SHA384, ECDSA with P-256 or P-384.
+
+This option is only supported for mbed TLS builds.  OpenSSL builds accept any
+certificate that OpenSSL accepts.
+.\"*
+.TP
 .B \-\-tls\-timeout n
 Packet retransmit timeout on TLS control channel
 if no acknowledgment from remote within
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 9fef394..74536fb 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -599,6 +599,8 @@ static const char usage_message[] =
 #endif
 "--tls-cipher l  : A list l of allowable TLS ciphers separated by : 
(optional).\n"
 ": Use --show-tls to see a list of supported TLS 
ciphers.\n"
+"--tls-cert-profile p : Set the allowed certificate crypto algorithm 
profile\n"
+"  (default=%s).\n"
 "--tls-timeout n : Packet retransmit timeout on TLS control channel\n"
 "  if no ACK from remote within n seconds (default=%d).\n"
 "--reneg-bytes n : Renegotiate data chan. key after n bytes sent and 
recvd.\n"
@@ -873,6 +875,7 @@ init_options(struct options *o, const bool init_gc)
 o->renegotiate_seconds = 3600;
 o->handshake_window = 60;
 o->transition_window = 3600;
+o->tls_cert_profile = "preferred";
 o->ecdh_curve = NULL;
 #ifdef ENABLE_X509ALTUSERNAME
 o->x509_username_field = X509_USERNAME_FIELD_DEFAULT;
@@ -1752,6 +1755,7 @@ show_settings(const struct options *o)
 SHOW_STR(cryptoapi_cert);
 #endif
 SHOW_STR(cipher_list);
+SHOW_STR(tls_cert_profile);
 

Re: [Openvpn-devel] [PATCH v2] Fix broken ./configure on systems without openssl.pc

[Steffan Karger]

Hi,
On 17-04-17 11:01, David Sommerseth wrote:
> [..]
> 
> We should anyway in this case have a better check of OpenSSL version
> available.  So in the case pkg-config fails, it will run an additional
> test looking for the OpenSSL version number in the opensslv.h header
> file and check against that version number.

Content-wise this looks good, but two remarks:

> @@ -861,12 +861,34 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   [OPENSSL],
>   [libcrypto >= 1.0.1, libssl >= 1.0.1],
>   [have_openssl="yes"],
> - [AC_MSG_ERROR([Minimum supported OpenSSL version is 
> 1.0.1])]
> + [] # If this fails, we will do another test next
>   )
>  
>   OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
>   fi

I think this OPENSSL_LIBS default can go now, since it is set below if
needed.

> +# 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])]
> +)
> +   OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
> +fi

Tabs and spaces are mixed here.  The surrounding lines seem to be
tabs-only.  (This bites me each time I edit configure.ac too...)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v3] Fix broken ./configure on systems without openssl.pc

[Steffan Karger]

Hi,

On 18-04-17 01:28, David Sommerseth wrote:
> Commit 039a89c331e9b799 changed the OpenSSL check slightly, but that
> broke ./configure on systems which do not install the openssl.pc
> pkg-config support file.  This is typically an issue on most of the BSD
> platforms, where the OpenSSL package from the base repository does not
> provide that file.
> 
> We should anyway in this case have a better check of OpenSSL version
> available.  So in the case pkg-config fails, it will run an additional
> test looking for the OpenSSL version number in the opensslv.h header
> file and check against that version number.
> 
> I did consider to rip out the pkg-config test all together, but decided
> to let it stay.  If pkg-config works, it provides much more details to
> the ./configure script than just the version number check - such as
> include and library paths if those are outside the default system paths.
> 
> If the user adds OPENSSL_CFLAGS or OPENSSL_LIBS to the ./configure
> script, the pkg-config will not be run.  But this patch ensures that the
> OpenSSL version is also checked in this situation.
> 
> This patch have been tested on Scientic Linux 7.3 (RHEL clone) and
> FreeBSD 10.3-RELEASE-p11.
> 
> v3 - Remove not needed and duplicated OPENSSL_LIBS assignment
>- Fix tab/space issues in modified lines
> 
> v2 - Don't use try to simplify the version matching, use the full
>  OPENSSL_VERSION_NUMBER
>- Fixed typo (OpneSSL -> OpenSSL)
>- Improve a few comments
> 
> Signed-off-by: David Sommerseth 
> ---
>  configure.ac | 26 +++---
>  1 file changed, 23 insertions(+), 3 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index acea060..a0cbc98 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -860,11 +860,31 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   PKG_CHECK_MODULES(
>   [OPENSSL],
>   [libcrypto >= 1.0.1, libssl >= 1.0.1],
> - [have_openssl="yes"],
> - [AC_MSG_ERROR([Minimum supported OpenSSL version is 
> 1.0.1])]
> + [have_openssl="yes"],
> + [] # If this fails, we will do another test next
>   )
> + fi
>  
> - OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
> + # 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])]
> +)
> +OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
>   fi
>  
>   saved_CFLAGS="${CFLAGS}"
> 

Sorry I didn't spot this before, but the new check should come after the
lines that update the CFLAGS and LIBS, otherwise this checks the system
lib, rather than the one specified though OPENSSL_LIBS and
OPENSSL_CFLAGS.  (The first line of that is the last line of this patch.)

And still some spaces in there ;-)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Fix broken ./configure on systems without openssl.pc

[Steffan Karger]

Hi,

On 22-04-17 00:07, David Sommerseth wrote:
> Commit 039a89c331e9b799 changed the OpenSSL check slightly, but that
> broke ./configure on systems which do not install the openssl.pc
> pkg-config support file.  This is typically an issue on most of the BSD
> platforms, where the OpenSSL package from the base repository does not
> provide that file.
> 
> We should anyway in this case have a better check of OpenSSL version
> available.  So in the case pkg-config fails, it will run an additional
> test looking for the OpenSSL version number in the opensslv.h header
> file and check against that version number.
> 
> I did consider to rip out the pkg-config test all together, but decided
> to let it stay.  If pkg-config works, it provides much more details to
> the ./configure script than just the version number check - such as
> include and library paths if those are outside the default system paths.
> 
> If the user adds OPENSSL_CFLAGS or OPENSSL_LIBS to the ./configure
> script, the pkg-config will not be run.  But this patch ensures that the
> OpenSSL version is also checked in this situation.
> 
> This patch have been tested on Scientic Linux 7.3 (RHEL clone) and
> FreeBSD 10.3-RELEASE-p11.
> 
> v4 - Move the CFLAGS/LDFLAGS declarations before the manual
>  version test; otherwise we're still testing the system install
>  version
> 
> v3 - Remove not needed and duplicated OPENSSL_LIBS assignment
>- Fix tab/space issues in modified lines
> 
> v2 - Don't use try to simplify the version matching, use the full
>  OPENSSL_VERSION_NUMBER
>- Fixed typo (OpneSSL -> OpenSSL)
>- Improve a few comments
> 
> Signed-off-by: David Sommerseth 
> ---
>  configure.ac | 28 
>  1 file changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/configure.ac b/configure.ac
> index acea060..2b98375 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -860,11 +860,9 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   PKG_CHECK_MODULES(
>   [OPENSSL],
>   [libcrypto >= 1.0.1, libssl >= 1.0.1],
> - [have_openssl="yes"],
> - [AC_MSG_ERROR([Minimum supported OpenSSL version is 
> 1.0.1])]
> + [have_openssl="yes"],
> + [] # If this fails, we will do another test next
>   )
> -
> - OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
>   fi
>  
>   saved_CFLAGS="${CFLAGS}"
> @@ -872,6 +870,28 @@ if test "${enable_crypto}" = "yes" -a 
> "${with_crypto_library}" = "openssl"; then
>   CFLAGS="${CFLAGS} ${OPENSSL_CFLAGS}"
>   LIBS="${LIBS} ${OPENSSL_LIBS}"
>  
> + # 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])]
> +)
> +OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto}
> + fi
> +
>   AC_CHECK_FUNCS([SSL_CTX_new EVP_CIPHER_CTX_set_key_length],
>  ,
>  [AC_MSG_ERROR([openssl check failed])]
> 

This looks good now, ACK.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] 2.4 sees all client certificates as expired when using crl-verify

[Steffan Karger]

On 22-04-17 20:24, debbie10t wrote:
> 
> On 02/01/17 15:39, Steffan Karger wrote:
>> On 02-01-17 16:24, SviMik wrote:
>>>
>>>> On 02-01-17 15:26, Gert Doering wrote:
>>>>> On Mon, Jan 02, 2017 at 03:17:23PM +0100, Alberto Gonzalez
>>>>> Iniesta wrote:
>>>>>> I just got this [1] bug report on OpenVPN 2.4 threating all
>>>>>> certs as expired when upgrading from 2.3. I find this quite
>>>>>> weird, but until I have some time to test it I thought asking
>>>>>> here would be faster.
>>>>>
>>>>> From the bug report:
>>>>>
>>>>> Mon Jan  2 07:37:10 2017 us=466023 1.2.3.4:36241 VERIFY ERROR:
>>>>> depth=0,
>>>> error=CRL has expired: C=XX, ST=XX, L=XXX, O=None, CN=mycn,
>>>> emailAddress=my@email
>>>>>
>>>>> "what the log says" :-)
>>>>>
>>>>> 2.4 checks CRLs much more rigidly than 2.3 (precisely: 2.3 had
>>>>> some built-in checking which only looked at revocations, while
>>>>> 2.4 leaves this to the crypto library, and they check all fields
>>>>> more rigidly).
>>>>>
>>>>> Specifically, CRLs with an expired "next update" field are
>>>>> flagged as "expired" by OpenSSL, while the built-in check in 2.3
>>>>> did not.
>>>>
>>>> This.  I replied something similar on the debian bug tracker, but I
>>>> have no clue what will happen with that mail.
>>>>
>>>>> Since this bit a few people already, I wonder how we could
>>>>> communicate this better.
>>>>
>>>> I wonder about that too.  Maybe some more verbose text on a wiki
>>>> page? We could even detect this specific error and add a link to
>>>> that page in the warning.
>>>>
>>>
>>> Is there an option to disable this check? It would be extremely
>>> useful to maintain (at least optional) backward compatibility with
>>> already existing setups, which originally relied on 2.3 behaviour.
>>>
>>
>> No, there is not.  And I don't think there is an easy way to implement
>> that either.
>>
>> But, the fix is just as easy as the workaround:  just regenerate the
>> CRL, with a more correct nextUpdate value.  If you don't want your CRLs
>> expire, just put that value far enough into the future.
> 
> Following this up, something like:
> https://community.openvpn.net/openvpn/wiki/SandBox

Excellent text!  Thanks.  Let's give this a good spot on the wiki.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v4] Fix broken ./configure on systems without openssl.pc

[Steffan Karger]

On 22-04-17 17:27, David Sommerseth wrote:
> On 22/04/17 13:29, Gert Doering wrote:
>> On Sat, Apr 22, 2017 at 08:28:33AM +0200, Steffan Karger wrote:
>>>> v4 - Move the CFLAGS/LDFLAGS declarations before the manual
>>>>  version test; otherwise we're still testing the system install
>>>>  version
>> [..]
>>> This looks good now, ACK.
>>
>> I'm not exactly sure what happened here in v4 - but now it's broken for
>> "just run configure, with no extra WITH_OPENSSL_* arguments" (on a system 
>> without pkgconfig).  So, NAK, as annoying as you'll surely find me :-/
>>
>> It does the version check just fine...
>>
>> configure:16566: checking additionally if OpenSSL is available and version 
>> >= 1.
>> 0.1
>> configure:16587: cc -c -g -O2 -std=c99   conftest.c >&5
>> configure:16587: $? = 0
>> configure:16588: result: ok
>>
>> ... and then it tests for SSL_CTX_new, omitting the -lssl/-lcrypto bits:
>>
>> configure:16601: checking for SSL_CTX_new
>> configure:16601: cc -o conftest -g -O2 -std=c99conftest.c   >&5
>> /var/tmp/conftest-e1c536.o: In function `main':
>> /home/gert/src/openvpn-maint/test-build-master-fbsd/conftest.c:193: 
>> undefined re
>> ference to `SSL_CTX_new'
>> cc: error: linker command failed with exit code 1 (use -v to see invocation)
>>
>>
>> ... failing.
>>
>> This is on FreeBSD 10.3, with the system libs, having pkg-config installed, 
>> but no openssl.pc:
>>
>> configure:16509: $PKG_CONFIG --exists --print-errors "libcrypto >= 1.0.1, 
>> libssl
>>  >= 1.0.1"
>> Package libcrypto was not found in the pkg-config search path.
>> Perhaps you should add the directory containing `libcrypto.pc'
>> to the PKG_CONFIG_PATH environment variable
>> Package 'libcrypto', required by 'virtual:world', not found
>> Package 'libssl', required by 'virtual:world', not found
>>
>> (not sure if this is related, but maybe the configure code path for
>> "pkg-config exists" is different from "no pkg-config found")
>>
>>
>> On Linux, with pkg-config + openssl.pc, it works fine:
>>
>> configure:16601: checking for SSL_CTX_new
>> configure:16601: gcc -o conftest -g -O2 -std=c99conftest.c  -lcrypto 
>> -lssl
>>> &5
>> configure:16601: $? = 0
>> configure:16601: result: yes
>>
>> (-lcrypto -lssl present, though I wonder why it's putting -lcrypto 
>> first - dependency order should have -lssl first)
> 
> I will dig further into this an submit a v5.  Gee, this autotools stuff
> can be fragile.  Each time I fight with autotools, I think of migrating
> to CMake.  But each time I struggle with CMake, I think of migrating to
> autotools.  I so wonder if there are some sane alternatives - somewhat,
> I doubt so :/

Gah, of course.

Two things:

1) The OPENSSL_LIBS=${OPENSSL_LIBS:--lssl -lcrypto} line should be at
the old location, and the new one should go.  That's why it now fails on
systems without pkg-config or _LIBS set manually.

2) The incorrect linking order is related to the stuff from ticket #863.
 "[libcrypto >= 1.0.1, libssl >= 1.0.1]" should be replaced with
"[openssl >= 1.0.1]".  I was waiting for this patch to get through
before sending a follow-up patch for that, but I'm fine with integrating
that into this patch too.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix extract_x509_field_ssl for external objects

[Steffan Karger]

Hi,

The change makes sense, so 'Feature-ACK', but one remark:

On 20-04-17 16:41, Hristo Venev wrote:
> @@ -191,16 +191,23 @@ extract_x509_field_ssl(X509_NAME *x509, const char 
> *field_name, char *out,
>  X509_NAME_ENTRY *x509ne = 0;
>  ASN1_STRING *asn1 = 0;
>  unsigned char *buf = NULL;
> -int nid = OBJ_txt2nid(field_name);
> +ASN1_OBJECT *obj = OBJ_txt2obj(field_name, 0);
> +
> +if (obj == NULL)
> +{
> +crypto_msg(M_FATAL, "Cannot get ASN1_OBJECT for %s", field_name);
> +}

M_FATAL is currently acceptable, because field_name always comes from
the local config file, but I'd prefer to make this non-fatal, and return
FAILURE.  That ensures that if someone decides to use this function in a
way where field_name *is* attacker controlled, we do not introduce a
remote DoS.

As for the log level of this message: I think D_TLS_DEBUG_LOW (--verb 3)
or possibly D_TLS_ERRORS (--verb 1) are appropriate.

-Steffan



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH v5] Fix broken ./configure on systems without openssl.pc

[Steffan Karger]

Hi,

On 24-04-17 22:57, Gert Doering wrote:
> On Mon, Apr 24, 2017 at 04:39:10PM +0200, David Sommerseth wrote:
>> This patch have been tested on Scientic Linux 7.3 (RHEL clone) and
>> FreeBSD 10.3-RELEASE-p11.
>>
>> v5 - Remove the right OPENSSL_LIBS and preserve the old one
>>- In PKG_CHECK_MODULES(), check for openssl instead of libssl
>>  + libcrypto
>>- Fix tab/space issues once again
> [..]
> 
> This looks good for me.
> 
> FreeBSD 10.3, no pkg-config   -> works
> Gentoo, pkg-config-> works
> FreeBSD 7.3, no pkg-config, openssl 0.9.8 -> fails (as it should)
> 
>checking for OPENSSL... no
>checking additionally if OpenSSL is available and version >= 1.0.1... 
> configure: error: OpenSSL version too old
> 
> NetBSD 7.0.1, pkg-config, openssl 1.0.1t  -> works
> OpenBSD 6.0, pkg-config, LibreSSL 2.4.2 (OPENSSL_VERSION_NUMBER 0x2000L)
>   -> works
> 
> 
> I'd like to see a review from Steffan whether we've anything left that
> I didn't see in my setups (I run without setting env vars, with openssl
> installed "in the default places"), but for my machines, this is good to 
> go (=ACK).

This works fine with my OPENSSL_LIBS and OPENSSL_CFLAGS build setup too.
 Patch looks good.  So, ACK :)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only" configurations

[Steffan Karger]

Hi,

On 25-04-17 09:50, Ilya Shipitsin wrote:
> Inspired by 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html
> build options are taken from regular windows installer builds
> 
> Signed-off-by: Ilya Shipitsin 
> ---
> v2: moved download/build dependencies into functions, changed cross build
> detection from shell expansion ${CHOST+x} to more recognised -z "${CHOST}",
> which required changing 'set -eux' to 'set -ex'. Added comments to make
> code readable without looking into commit message.

Thanks, this looks much better now!  Just one nit: if we give $CHOST a
default value, we don't have to remove set -u:

> --- a/.travis/build-deps.sh
> +++ b/.travis/build-deps.sh
> @@ -1,9 +1,58 @@
>  #!/bin/sh
> -set -eux
> +set -ex
>  
>  # Set defaults
>  PREFIX="${PREFIX:-${HOME}/opt}"

Just add a CHOST="${CHOST:-}" line here.  Keeping -u will help us catch
future problems (typos in variable names, for example).

Samuli already verified that this does what it should, so once we can
get -u back I too agree that this patch is ready to be applied.

Thanks for improving the patch and not giving up :)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] travis-ci: add 2 mingw "build only" configurations

[Steffan Karger]

Hi,

On 25-04-17 20:51, Илья Шипицин wrote:
> 2017-04-25 22:49 GMT+05:00 Steffan Karger  <mailto:stef...@karger.me>>:
> 
> On 25-04-17 09:50, Ilya Shipitsin wrote:
> > Inspired by 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html
> 
> <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html>
> > build options are taken from regular windows installer builds
> >
> > Signed-off-by: Ilya Shipitsin  <mailto:chipits...@gmail.com>>
> > ---
> > v2: moved download/build dependencies into functions, changed cross 
> build
> > detection from shell expansion ${CHOST+x} to more recognised -z 
> "${CHOST}",
> > which required changing 'set -eux' to 'set -ex'. Added comments to make
> > code readable without looking into commit message.
> 
> Thanks, this looks much better now!  Just one nit: if we give $CHOST a
> default value, we don't have to remove set -u:
> 
> defining CHOST when we actually do not need it does not make any sense.
> I can keep "set -u" and use shell variable expansion trick
> 
> http://stackoverflow.com/questions/3601515/how-to-check-if-a-variable-is-set-in-bash

Yeah, shell scripting can be a bit cumbersome...  Both options are
hacks, and I do not have a clear preference.  As long as we can have
"set -u" :-)

> > --- a/.travis/build-deps.sh
> > +++ b/.travis/build-deps.sh
> > @@ -1,9 +1,58 @@
> >  #!/bin/sh
> > -set -eux
> > +set -ex
> >
> >  # Set defaults
> >  PREFIX="${PREFIX:-${HOME}/opt}"
> 
> Just add a CHOST="${CHOST:-}" line here.  Keeping -u will help us catch
> future problems (typos in variable names, for example).
> 
> we already had problems with such complicated definition
> 
> https://github.com/OpenVPN/openvpn/commit/368991264d82f038bde30a67910ac6c7681a4ba9#diff-ff51f64442ce689bd8d8466e365dd600R6
> 
> those errors are not easy to catch, so I would avoid defining variables
> in such way.
> 
> I think, we need to remove PREFIX definition as well.

Ok, let's do that.  (But as a separate patch, as it does not have
anything to do with windows builds.)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] v3, travis-ci: add 2 mingw "build only" configurations

[Steffan Karger]

Hi,

On 26-04-17 10:13, Ilya Shipitsin wrote:
> Inspired by 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html
> build options are taken from regular windows installer builds
> 
> Signed-off-by: Ilya Shipitsin 
> ---
> v2: moved download/build dependencies into functions, changed cross build
> detection from shell expansion ${CHOST+x} to more recognised -z "${CHOST}",
> which required changing 'set -eux' to 'set -ex'. Added comments to make
> code readable without looking into commit message.
> 
> v3: fixed "trailing whitespaces" found by Samuli Seppänen. Added back "set 
> -u",
> thanks to Steffan Karger. Changed repo manipulation to "apt-add-repository", 
> thanks
> to Nathan Stratton Treadway.

Thanks for not giving up - this looks a lot better now!  Still a problem
though:

> -  - ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1)
> -  - make -j$JOBS
> -  - src/openvpn/openvpn --version || true
> -  - if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; fi
> -  - make check
> -  - $EXTRA_SCRIPT
> +  - if [ -z "${CHOST}" ]; then
> +  ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1);
> +  make -j$JOBS;
> +  src/openvpn/openvpn --version || true;
> +  if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi;
> +  if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; 
> fi;
> +  make check;
> +  $EXTRA_SCRIPT;
> +else
> +  export 
> TAP_CFLAGS="-I${PWD}/tap-windows-${TAP_WINDOWS_VERSION}/include";
> +  export LZO_CFLAGS="-I${PREFIX}/include";
> +  export LZO_LIBS="-L${PREFIX}/lib -llzo2";
> +  export PKCS11_HELPER_LIBS="-L${PREFIX}/lib -lpkcs11-helper";
> +  export PKCS11_HELPER_CFLAGS="-I${PREFIX}/include";
> +  ./configure --with-crypto-library="${SSLLIB}" --host=${CHOST} 
> --build=x86_64-pc-linux-gnu --enable-pkcs11 --disable-plugins || (cat 
> config.log && exit 1);
> +  make -j$JOBS;
> +fi

Adding this as a command - with the steps separated by ; - will cause
failures to be ignored.  This patch should fail the build:

   make check;
+  false;
   $EXTRA_SCRIPT;

... but it doesn't:

https://github.com/syzzer/openvpn/commit/df910243428589691cfaa1c0dcc6d92ec7d12b8e

https://travis-ci.org/syzzer/openvpn/builds/228462383?utm_source=github_status&utm_medium=notification

To fix this, I propose to create a .travis/build-check.sh script, which
contains the build steps (and set -eu), and call that script from
.travis.yml

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] crypto: Enable SHA256 fingerprint checking in --verify-hash

[Steffan Karger]

Hi,

On 26-04-17 18:00, David Sommerseth wrote:
> This enhances --verify-hash with an optional algorithm flag.  If not
> provided, it defaults to SHA1 to preserve backwards compatbilitity with
> existing configurations.  The only valid flags are SHA1 and SHA256.

Feature-ACK.

> In addition it moves the hash verification away from memcmp() to
> memcmp_constant_time().  And slightly it enhances the layout of the
> --verify-hash section in the man page.

Hashes are public, so there is no real need to use
memcmp_constant_time() here.  It doesn't hurt either though - so I won't
complain further if you prefer to keep it ;-)

> Signed-off-by: David Sommerseth 
> 
> ---
> 
> Simple test script
> ==
> 
> * Server:
>   # openvpn --dev tun --reneg-sec 60 --verb 4 \
> --server 10.8.0.0 255.255.255.0 --topology subnet \
> --ca sample/sample-keys/ca.crt \
> --key sample/sample-keys/server.key \
> --cert sample/sample-keys/server.crt \
> --dh sample/sample-keys/dh2048.pem \
> --cipher AES-256-CBC --auth SHA256 \
> --verify-hash 
> 57:4D:B3:49:7E:FB:9E:FD:DC:BC:A4:ED:BC:B3:C2:8D:C3:D7:2A:E3:0F:6F:76:57:F0:BB:F4:90:56:1C:DC:F9
>  SHA256
> 
> * Client:
>   # openvpn --dev tun --verb 4 \
> --remote 192.168.122.1 --explicit-exit-notify \
> --client --ca sample/sample-keys/ca.crt \
> --key sample/sample-keys/client.key \
> --cert sample/sample-keys/client.crt \
> --cipher AES-256-CBC --auth SHA256 \
> --verify-hash 
> 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:44
> 
>   Alternative --verify-hash variant which must succeed:
>  --verify-hash 
> 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:44 SHA1
> 
>   These --verify-hash variants must fail:
>  --verify-hash 
> 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:44 SHA256
>  --verify-hash 
> 57:4D:B3:49:7E:FB:9E:FD:DC:BC:A4:ED:BC:B3:C2:8D:C3:D7:2A:E3:0F:6F:76:57:F0:BB:F4:90:56:1C:DC:F9
>  --verify-hash 
> 57:4D:B3:49:7E:FB:9E:FD:DC:BC:A4:ED:BC:B3:C2:8D:C3:D7:2A:E3:0F:6F:76:57:F0:BB:F4:90:56:1C:DC:00
>  SHA256
>  --verify-hash 
> 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:00 SHA1
>  --verify-hash 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:00
>  --verify-hash 06:30:DA:EA:77:41:5B:D6:8C:C5:CC:CA:F5:D7:91:87:FA:6D:89:XX
> 
> To retrieve the SHA fingerprints in certificates:
> 
> $ openssl x509 -noout -fingerprint -in sample/sample-keys/ca.crt
> $ openssl x509 -noout -fingerprint -sha256 -in sample/sample-keys/ca.crt
> ---
>  Changes.rst  |  3 +++
>  doc/openvpn.8| 18 +++---
>  src/openvpn/crypto_backend.h |  6 ++
>  src/openvpn/init.c   |  1 +
>  src/openvpn/options.c| 22 +++---
>  src/openvpn/options.h|  5 +
>  src/openvpn/ssl_common.h |  1 +
>  src/openvpn/ssl_verify.c | 15 +--
>  8 files changed, 63 insertions(+), 8 deletions(-)
> 
> diff --git a/Changes.rst b/Changes.rst
> index 2a94990e..da93060c 100644
> --- a/Changes.rst
> +++ b/Changes.rst
> @@ -318,3 +318,6 @@ Version 2.4.1
> ``--remote-cert-tls`` uses the far more common keyUsage and 
> extendedKeyUsage
> extension instead.  Make sure your certificates carry these to be able to
> use ``--remote-cert-tls``.
> + - ``--verify-hash`` can now take an optional flag which changes the hashing
> +   algorithm. It can be either SHA1 or SHA256.  The default if not provided 
> is
> +   SHA1 to preserve backwards compatibility with existing configurations.
> diff --git a/doc/openvpn.8 b/doc/openvpn.8
> index c3248fde..fcf825c6 100644
> --- a/doc/openvpn.8
> +++ b/doc/openvpn.8
> @@ -4694,15 +4694,27 @@ and
>  Not available with PolarSSL.
>  .\"*
>  .TP
> -.B \-\-verify\-hash hash
> -Specify SHA1 fingerprint for level-1 cert.  The level-1 cert is the
> +.B \-\-verify\-hash hash [algo]
> +Specify SHA1 or SHA256 fingerprint for level-1 cert.  The level-1 cert is the
>  CA (or intermediate cert) that signs the leaf certificate, and is
>  one removed from the leaf certificate in the direction of the root.
>  When accepting a connection from a peer, the level-1 cert
>  fingerprint must match
>  .B hash
>  or certificate verification will fail.  Hash is specified
> -as XX:XX:...  For example: 
> AD:B0:95:D8:09:C8:36:45:12:A9:89:C8:90:09:CB:13:72:A6:AD:16
> +as XX:XX:... For example:
> +
> +.nf
> +.ft 3
> +.in +4
> +AD:B0:95:D8:09:C8:36:45:12:A9:89:C8:90:09:CB:13:72:A6:AD:16
> +.in -4
> +.ft
> +.fi
> +
> +The
> +.B algo
> +flag can be either SHA1 or SHA256.  If not provided, it defaults to SHA1.
>  .\"*
>  .TP
>  .B \-\-pkcs11\-cert\-private [0|1]...
> diff --git a/src/openvpn/crypto_backend.h b/src/openvpn/crypto_backend.h
> index 2c79baa1..9b113d

Re: [Openvpn-devel] [PATCH] crypto: Enable SHA256 fingerprint checking in --verify-hash

[Steffan Karger]

On 03-05-17 22:15, Steffan Karger wrote:
> On 26-04-17 18:00, David Sommerseth wrote:
>> In addition it moves the hash verification away from memcmp() to
>> memcmp_constant_time().  And slightly it enhances the layout of the
>> --verify-hash section in the man page.
> 
> Hashes are public, so there is no real need to use
> memcmp_constant_time() here.  It doesn't hurt either though - so I won't
> complain further if you prefer to keep it ;-)

Hrmpf, on sending I realize this is not the right argument.

Public doesn't matter (MACs are public too), what matters is that we are
not comparing attacker input (a MAC), but the calculated hash of
attacker input (the hash of the supplied cert).  As long as the hash
function is preimage resistant, we don't have to do constant time
comparison.  (And SHA1/SHA256 and even MD5 are pre-image resistant.)

Hashing the inputs and comparing the hashes actually is one of the
options to do a constant time memcmp :-)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH v2] cleanup: merge packet_id_alloc_outgoing() into packet_id_write()

[Steffan Karger]

The functions packet_id_alloc_outgoing() and packet_id_write() were
always called in tandem.  Instead of forcing the caller to allocate a
packet_id_net to do so, merge the two functions.  This simplifies the API
and reduces the chance on mistakes in the future.

This patch adds unit tests to verify the behaviour of packet_id_write().
Verifying that we assert out correctly required the change to mock_msg.c.

Signed-off-by: Steffan Karger 
---
v2 - rebased onto current master branch

 src/openvpn/crypto.c  |  20 ++--
 src/openvpn/packet_id.c   |  24 -
 src/openvpn/packet_id.h   |  35 +++
 src/openvpn/tls_crypt.c   |   6 +-
 tests/unit_tests/openvpn/Makefile.am  |  13 ++-
 tests/unit_tests/openvpn/mock_msg.c   |  15 ++-
 tests/unit_tests/openvpn/test_packet_id.c | 168 ++
 7 files changed, 228 insertions(+), 53 deletions(-)
 create mode 100644 tests/unit_tests/openvpn/test_packet_id.c

diff --git a/src/openvpn/crypto.c b/src/openvpn/crypto.c
index 7b00601..f5250ac 100644
--- a/src/openvpn/crypto.c
+++ b/src/openvpn/crypto.c
@@ -85,7 +85,6 @@ openvpn_encrypt_aead(struct buffer *buf, struct buffer work,
 /* Prepare IV */
 {
 struct buffer iv_buffer;
-struct packet_id_net pin;
 uint8_t iv[OPENVPN_MAX_IV_LENGTH] = {0};
 const int iv_len = cipher_ctx_iv_length(ctx->cipher);
 
@@ -94,8 +93,7 @@ openvpn_encrypt_aead(struct buffer *buf, struct buffer work,
 buf_set_write(&iv_buffer, iv, iv_len);
 
 /* IV starts with packet id to make the IV unique for packet */
-packet_id_alloc_outgoing(&opt->packet_id.send, &pin, false);
-ASSERT(packet_id_write(&pin, &iv_buffer, false, false));
+ASSERT(packet_id_write(&opt->packet_id.send, &iv_buffer, false, 
false));
 
 /* Remainder of IV consists of implicit part (unique per session) */
 ASSERT(buf_write(&iv_buffer, ctx->implicit_iv, ctx->implicit_iv_len));
@@ -195,22 +193,20 @@ openvpn_encrypt_v1(struct buffer *buf, struct buffer work,
 /* Put packet ID in plaintext buffer */
 if (packet_id_initialized(&opt->packet_id))
 {
-struct packet_id_net pin;
-packet_id_alloc_outgoing(&opt->packet_id.send, &pin, 
BOOL_CAST(opt->flags & CO_PACKET_ID_LONG_FORM));
-ASSERT(packet_id_write(&pin, buf, BOOL_CAST(opt->flags & 
CO_PACKET_ID_LONG_FORM), true));
+ASSERT(packet_id_write(&opt->packet_id.send, buf,
+   opt->flags & CO_PACKET_ID_LONG_FORM,
+   true));
 }
 }
 else if (cipher_kt_mode_ofb_cfb(cipher_kt))
 {
-struct packet_id_net pin;
 struct buffer b;
 
 /* packet-ID required for this mode. */
 ASSERT(packet_id_initialized(&opt->packet_id));
 
-packet_id_alloc_outgoing(&opt->packet_id.send, &pin, true);
 buf_set_write(&b, iv_buf, iv_size);
-ASSERT(packet_id_write(&pin, &b, true, false));
+ASSERT(packet_id_write(&opt->packet_id.send, &b, true, false));
 }
 else /* We only support CBC, CFB, or OFB modes right now */
 {
@@ -257,9 +253,9 @@ openvpn_encrypt_v1(struct buffer *buf, struct buffer work,
 {
 if (packet_id_initialized(&opt->packet_id))
 {
-struct packet_id_net pin;
-packet_id_alloc_outgoing(&opt->packet_id.send, &pin, 
BOOL_CAST(opt->flags & CO_PACKET_ID_LONG_FORM));
-ASSERT(packet_id_write(&pin, buf, BOOL_CAST(opt->flags & 
CO_PACKET_ID_LONG_FORM), true));
+ASSERT(packet_id_write(&opt->packet_id.send, buf,
+BOOL_CAST(opt->flags & CO_PACKET_ID_LONG_FORM),
+true));
 }
 if (ctx->hmac)
 {
diff --git a/src/openvpn/packet_id.c b/src/openvpn/packet_id.c
index e34c228..5175fb0 100644
--- a/src/openvpn/packet_id.c
+++ b/src/openvpn/packet_id.c
@@ -325,12 +325,30 @@ packet_id_read(struct packet_id_net *pin, struct buffer 
*buf, bool long_form)
 return true;
 }
 
+static void
+packet_id_send_update(struct packet_id_send *p, bool long_form)
+{
+if (!p->time)
+{
+p->time = now;
+}
+p->id++;
+if (!p->id)
+{
+ASSERT(long_form);
+p->time = now;
+p->id = 1;
+}
+}
+
 bool
-packet_id_write(const struct packet_id_net *pin, struct buffer *buf, bool 
long_form, bool prepend)
+packet_id_write(struct packet_id_send *p, struct buffer *buf, bool

[Openvpn-devel] [PATCH] Don't run packet_id unit tests for --disable-crypto builds

[Steffan Karger]

Because there is no packet_id in those builds...  This fixes 'make check'
for --disable-crypto builds, caught by travis.

Signed-off-by: Steffan Karger 
---
 tests/unit_tests/openvpn/Makefile.am | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/unit_tests/openvpn/Makefile.am 
b/tests/unit_tests/openvpn/Makefile.am
index 5d7123e..3bd382c 100644
--- a/tests/unit_tests/openvpn/Makefile.am
+++ b/tests/unit_tests/openvpn/Makefile.am
@@ -3,11 +3,11 @@ AUTOMAKE_OPTIONS = foreign
 check_PROGRAMS=
 
 if HAVE_LD_WRAP_SUPPORT
-check_PROGRAMS += argv_testdriver buffer_testdriver packet_id_testdriver
+check_PROGRAMS += argv_testdriver buffer_testdriver
 endif
 
 if ENABLE_CRYPTO
-check_PROGRAMS += tls_crypt_testdriver
+check_PROGRAMS += packet_id_testdriver tls_crypt_testdriver
 endif
 
 TESTS = $(check_PROGRAMS)
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix Changes.rst layout

[Steffan Karger]

The extra space before each line made the 2.4.1 section stand out from the
other sections.

Signed-off-by: Steffan Karger 
---
 Changes.rst | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/Changes.rst b/Changes.rst
index 2a94990..c1583b3 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -306,15 +306,15 @@ Maintainer-visible changes
 
 Version 2.4.1
 =
- - ``--remote-cert-ku`` now only requires the certificate to have at least the
-   bits set of one of the values in the supplied list, instead of requiring an
-   exact match to one of the values in the list.
- - ``--remote-cert-tls`` now only requires that a keyUsage is present in the
-   certificate, and leaves the verification of the value up to the crypto
-   library, which has more information (i.e. the key exchange method in use)
-   to verify that the keyUsage is correct.
- - ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
-   The nsCertType x509 extension is very old, and barely used.
-   ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
-   extension instead.  Make sure your certificates carry these to be able to
-   use ``--remote-cert-tls``.
+- ``--remote-cert-ku`` now only requires the certificate to have at least the
+  bits set of one of the values in the supplied list, instead of requiring an
+  exact match to one of the values in the list.
+- ``--remote-cert-tls`` now only requires that a keyUsage is present in the
+  certificate, and leaves the verification of the value up to the crypto
+  library, which has more information (i.e. the key exchange method in use)
+  to verify that the keyUsage is correct.
+- ``--ns-cert-type`` is deprecated.  Use ``--remote-cert-tls`` instead.
+  The nsCertType x509 extension is very old, and barely used.
+  ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
+  extension instead.  Make sure your certificates carry these to be able to
+  use ``--remote-cert-tls``.
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Document tls-crypt security considerations in man page

[Steffan Karger]

The tls-crypt commit message contained an elaborate discussion on the
function's security properties.  This commit adds the gist of that
discussion, "rotate keys periodically" to the man page.

(The 'real' solution will follow later: add support for per-client
tls-crypt keys.  That will make tls-crypt useful for VPN providers too.)

Signed-off-by: Steffan Karger 
---
Note to non-crypto-geek reviewers: please verify that this text is clear
enough to explain you when you need to replace tls-crypt keys.

Note to crypto-geek reviewers: please check the numbers - see the
--tls-crypt commit message (c6e24fa3) for details.

 doc/openvpn.8 | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index c3248fd..3a303a9 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5090,6 +5090,28 @@ In contrast to
 .B \-\-tls\-crypt
 does *not* require the user to set
 .B \-\-key\-direction\fR.
+
+.B Security Considerations
+
+All peers use the same
+.B \-\-tls-crypt
+pre-shared group key to authenticate and encrypt control channel messages.
+To ensure that IV collisions remain unlikely, this key should not be used
+to encrypt more than 2^48 client-to-server or 2^48 server-to-client
+control channel messages.  A typical initial negotiation is about 10 packets
+in each direction.  Assuming both initial negotation and renogatiations are
+at most 2^16 (65536) packets, and (re)negotiations happen each minute for
+each user (24/7), this limits the tls\-crypt key lifetime to 8171 year divided
+by the number of users.  So a setup with 1000 users should rotate the key at
+least once each eight years.  (And a setup with 8000 users each year.)
+
+If IV collisions were to occur, this could result in the security of
+.B \-\-tls\-crypt
+degrading to the same security as using
+.B \-\-tls\-auth\fR.
+That is, the control channel still benefits from the extra protection against
+active man-in-the-middle-attacks and DoS attacks, but may no longer offer
+extra privacy and post-quantum security on top of what TLS itself offers.
 .\"*
 .TP
 .B \-\-askpass [file]
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Document tls-crypt security considerations in man page

[Steffan Karger]

Hi,

On 07-05-17 11:39, Magnus Kroken wrote:
> Non-crypto geek here, comments inline.
> 
> On 05.05.2017 22:30, Steffan Karger wrote:
>> +control channel messages.  A typical initial negotiation is about 10 packets
>> +in each direction.  Assuming both initial negotation and renogatiations are
>> +at most 2^16 (65536) packets, and (re)negotiations happen each minute for
>> +each user (24/7)
> 
> Does 10 and 65536 represent the same actual thing here, where 10 is a 
> practical real-world estimate, and 65536 is an extremely conservative 
> estimate?

Exactly.

> Or does it mean that each user will cause a total of 65536
> (re)negotiation packets in his lifetime? I think using a conservative 
> estimate is a good idea, but the large difference is somewhat confusing 
> (and I'm not entirely sure I get the correct meaning myself).

Good point, I'll try to make this more clear.

Maybe useful as background information:  I am really trying to keep this
section short, because I fear otherwise people will just "TL;DR" and
skip it.  But that does result in a high information density.

>> this limits the tls\-crypt key lifetime to 8171 year divided
> 
> 8171 years (just a typo I suppose, but it's significant to the meaning 
> of the sentence).

Ah, yes.  This is a Dutch-English mixup - the Dutch (mostly) don't use
plural for more-then-one years.  Will fix too.

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Fix memory leak in x509_verify_cert_ku()

[Steffan Karger]

If keyUsage was only required to be present, but no specific value was
required, we would omit to free the extracted string.  This happens as of
2.4.1, if --remote-cert-tls is used.  In that case we leak a bit of
memory on each TLS (re)negotiation.

Signed-off-by: Steffan Karger 
---
 Changes.rst  | 9 +
 src/openvpn/ssl_verify_openssl.c | 1 +
 2 files changed, 10 insertions(+)

diff --git a/Changes.rst b/Changes.rst
index c1583b3..3dba7e0 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -318,3 +318,12 @@ Version 2.4.1
   ``--remote-cert-tls`` uses the far more common keyUsage and extendedKeyUsage
   extension instead.  Make sure your certificates carry these to be able to
   use ``--remote-cert-tls``.
+
+
+Version 2.4.2
+=
+
+Bugfixes
+
+- Fix memory leak introduced in 2.4.1: if --remote-cert-tls is used, we leaked
+  some memory on each TLS (re)negotiation.
diff --git a/src/openvpn/ssl_verify_openssl.c b/src/openvpn/ssl_verify_openssl.c
index 54eadbd..337729c 100644
--- a/src/openvpn/ssl_verify_openssl.c
+++ b/src/openvpn/ssl_verify_openssl.c
@@ -599,6 +599,7 @@ x509_verify_cert_ku(X509 *x509, const unsigned *const 
expected_ku,
 if (expected_ku[0] == OPENVPN_KU_REQUIRED)
 {
 /* Extension required, value checked by TLS library */
+ASN1_BIT_STRING_free(ku);
 return SUCCESS;
 }
 
-- 
2.7.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] v4, travis-ci: add 2 mingw "build only" configurations

[Steffan Karger]

Hi,

On 05-05-17 20:08, Ilya Shipitsin wrote:
> Inspired by 
> https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg13032.html
> build options are taken from regular windows installer builds
> 
> Signed-off-by: Ilya Shipitsin 
> ---
> v2: moved download/build dependencies into functions, changed cross build
> detection from shell expansion ${CHOST+x} to more recognised -z "${CHOST}",
> which required changing 'set -eux' to 'set -ex'. Added comments to make
> code readable without looking into commit message.
> 
> v3: fixed "trailing whitespaces" found by Samuli Seppänen. Added back "set 
> -u",
> thanks to Steffan Karger. Changed repo manipulation to "apt-add-repository", 
> thanks
> to Nathan Stratton Treadway.
> 
> v4: moved build/test logic into separate script running with "set -eux", 
> thanks
> to Steffan Karger
> 
>  .travis.yml| 22 ++--
>  .travis/build-check.sh | 30 
>  .travis/build-deps.sh  | 98 
> +++---
>  3 files changed, 135 insertions(+), 15 deletions(-)
>  create mode 100755 .travis/build-check.sh
> 
> diff --git a/.travis.yml b/.travis.yml
> index 3c0aa7d..bb44222 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -12,6 +12,9 @@ env:
>global:
>  - JOBS=3
>  - PREFIX="${HOME}/opt"
> +- TAP_WINDOWS_VERSION=9.21.2
> +- LZO_VERSION=2.10
> +- PKCS11_HELPER_VERSION=1.11
>  - MBEDTLS_VERSION="2.4.0"
>  - MBEDTLS_CFLAGS="-I${PREFIX}/include"
>  - MBEDTLS_LIBS="-L${PREFIX}/lib -lmbedtls -lmbedx509 -lmbedcrypto"
> @@ -50,6 +53,12 @@ matrix:
>os: osx
>osx_image: xcode7.3
>compiler: clang
> +- env: SSLLIB="openssl" CHOST=x86_64-w64-mingw32
> +  os: linux
> +  compiler: ": Win64 build only"
> +- env: SSLLIB="openssl" CHOST=i686-w64-mingw32
> +  os: linux
> +  compiler: ": Win32 build only"
>exclude:
>  - compiler: gcc
>  
> @@ -60,6 +69,7 @@ addons:
>- libpam0g-dev
>- liblz4-dev
>- linux-libc-dev
> +  - man2html
>  
>  cache:
>ccache: true
> @@ -72,16 +82,8 @@ before_install:
>- 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)
>  
>  script:
> -  - if [ "${TRAVIS_OS_NAME}" = "linux" ]; then export 
> LD_LIBRARY_PATH="${PREFIX}/lib:${LD_LIBRARY_PATH}"; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx"   ]; then export 
> DYLD_LIBRARY_PATH="${PREFIX}/lib:${DYLD_LIBRARY_PATH}"; fi
> -  - autoreconf -vi
> -  - ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG} || (cat 
> config.log && exit 1)
> -  - make -j$JOBS
> -  - src/openvpn/openvpn --version || true
> -  - if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
> -  - if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; fi
> -  - make check
> -  - $EXTRA_SCRIPT
> +  - .travis/build-check.sh
> diff --git a/.travis/build-check.sh b/.travis/build-check.sh
> new file mode 100755
> index 000..5ef8c6c
> --- /dev/null
> +++ b/.travis/build-check.sh
> @@ -0,0 +1,30 @@
> +#!/bin/sh
> +set -eux
> +
> +if [ "${TRAVIS_OS_NAME}" = "linux" ]; then 
> + export LD_LIBRARY_PATH="${PREFIX}/lib:${LD_LIBRARY_PATH:-}"
> +fi
> +
> +if [ "${TRAVIS_OS_NAME}" = "osx"   ]; then 
> + export DYLD_LIBRARY_PATH="${PREFIX}/lib:${DYLD_LIBRARY_PATH:-}"
> +fi
> +
> +autoreconf -vi
> +
> +if [ -z ${CHOST+x} ]; then
> + ./configure --with-crypto-library="${SSLLIB}" ${EXTRA_CONFIG:-} || (cat 
> config.log && exit 1)
> + make -j$JOBS
> + src/openvpn/openvpn --version || true
> + if [ "${TRAVIS_OS_NAME}" = "linux" ]; then ldd src/openvpn/openvpn; fi
> + if [ "${TRAVIS_OS_NAME}" = "osx" ]; then otool -L src/openvpn/openvpn; 
> fi
> + make check
> + ${EXTRA_SCRIPT:-}
> +else
> + export TAP_CFLAGS="-I${PWD}/tap-windows-${TAP_WINDOWS_VERSION}/include"
> + export LZO_CFLAGS="-I${PREFIX}/include"
> + export LZO_LIBS="-L${PREFIX}/lib -llzo2"
> + export PKCS11_HELPER_LIBS="-L${PREFIX}/lib -lpkcs