Re: [Openvpn-devel] build against openssl 1.1.0

[Илья Шипицин]

2017-02-19 9:48 GMT+05:00 Илья Шипицин :

>
>
> 2017-02-19 4:16 GMT+05:00 David Sommerseth  topphemmelig.net>:
>
>> On 18/02/17 08:34, Илья Шипицин wrote:
>> > I added openssl-1.0.1e to test matrix (do not pay attention to
>> > commit title, it happened accidently from iPad), so ...
>> >
>> > https://travis-ci.org/OpenVPN/openvpn/jobs/202709493
>> >
>> > t_cltsrv.sh + openssl-1.0.1f  = OK
>> > t_cltsrv.sh + openssl-1.0.1e = FAIL
>>
>> Okay, lets get a few important details straight first.  When I spoke
>> about openssl-1.0.1e, it was in an RHEL context (including CentOS and
>> Scientific Linux).  In reality, that is not the same version as OpenSSL
>> upstream 1.0.1e.  Red Hat employs people to backport bugfixes and
>> security fixes from newer OpenSSL 1.0.x releases to 1.0.1e. So the
>> OpenSSL _baseline_ is 1.0.1e [1].  But it must not be compared directly
>> against v1.0.1e from openssl.org.  The baseline defines a /stable ABI/
>> (Application Binary Interface) which applications linking against the
>> library can rely on.  This is what makes RHEL and the clones so stable
>> over 7-10++ years.  And this is the challenge backporters in Red Hat
>> struggle with; not breaking applications which works.
>>
>> So unless I have misunderstood your travis commit ... you set the
>> version to 1.0.1e regardless of Linux distribution.  This itself does
>> not provide any real value for us.  As there are a lot of bugfixes and
>> security implemented in the OpenSSL package RHEL ships ... you can get
>> an idea by looking at the changelog of the openssl RPM package:
>> > 8fd69f148538c635dd990d6/SPECS!openssl.spec#L642>
>>
>> RHEL6 was released in May 2010 while RHEL7 in June 2014.  What you see
>> above is the changelog for RHEL7.  If my count is correct, that is
>> currently 127 patches *on top of* the upstream OpenSSL v1.0.1e.  I
>> wouldn't expect this patch list to be much longer on RHEL 6 though.
>>
>> So unless your travis script is clever enough to only test OpenSSL
>> v1.0.1e on RHEL, CentOS or ScientificLinux *or* build OpenSSL using the
>> CentOS source RPM ... then I am not surprised things may fail.  Red Hat
>> may very well have fixed some bugs which we're hitting.
>>
>
>
> well, RedHat not only ship their very own openssl, but also their own
> openvpn package
>
> https://dl.fedoraproject.org/pub/epel/7/SRPMS/o/
>
> I see, there's %check section, but it is commented. Not sure how thay test
> it. We should get in touch with redhat people if we want openvpn properly
> tested and packaged
>
> I'll have a look at 'make check' under centos later
>

make check

is ok under CentOS 7 (it is shipped with openssl-1.0.1e)


>
>
>>
>>
>> --
>> kind regards,
>>
>> David Sommerseth
>> OpenVPN Technologies, Inc
>>
>>
>>
>>
>> [1] The reason is that all the _baseline_ packages in major RHEL
>> releases are certified against a lot of hardware (IBM, HP, Dell,
>> EMC, NetApp, etc, etc) and third party software (SAP, Oracle, etc,
>> etc).  So rebasing is out of question, as that requires new, time
>> consuming and expensive re-certifications.  Which is why you
>> extremely seldom see version updates on packages.  Those few times
>> that happens, it is usually considered to not break any important
>> certifications.  Like, a SAP server installation probably don't
>> have any dependencies against the GNOME 3 packages.
>>
>>
>>
>>
>>
>>
>
--
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?

[James Yonan]

On 23/02/2017 01:22, Steffan Karger wrote:

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

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?

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

Wondering what the defaults should be.

James

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


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

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

[Christian Hesse]

Emmanuel Deloget  on Thu, 2017/02/23 15:35:
> This is v3 of the remaining patches for the "Add support for OpenSSL 
> 1.1.x" series. This series is partial: only the modified patches are 
> sent to the ML -- the other have not changed. The stats are a bit off 
> so I don't include them in this mail.
> 
> They have been generated after a rebase from the master tree. Individual
> commits can be viewed at
> 
>   https://github.com/emmanuel-deloget/openvpn/commits/openssl-1.1-v3
> 
> (This time, the branch name is correct :))
> 
> Changes v2 --> v3: 
> 
> * RSA_METHOD (04/15): rsa_meth->name is now a dup of the name parameter; 
>   it's freed in RSA_meth_free(). 
> 
> * RSA (07/15): calling RSA_set_method() in rsa_finish() is both a Bad 
>   Idea and not required so it has been removed.
>   
> Changes v1 --> v2:
> 
> * EVP_PKEY (06/15): add missing function EVP_PKEY_id() for 0.9.8.
> 
> * replace patch 15/15 with a new patch to use EVP_CipherInit_ex() 
>   instead of EVP_CipherInit() when a full init is not needed.
> 
> 
> Emmanuel Deloget (15):
>   [commited] OpenSSL: don't use direct access to the internal of SSL_CTX
>   [commited] OpenSSL: don't use direct access to the internal of X509_STORE
>   [commited] OpenSSL: don't use direct access to the internal of X509_OBJECT
>   OpenSSL: don't use direct access to the internal of RSA_METHOD
>   OpenSSL: don't use direct access to the internal of X509
>   OpenSSL: don't use direct access to the internal of EVP_PKEY
>   OpenSSL: don't use direct access to the internal of RSA
>   OpenSSL: don't use direct access to the internal of DSA
>   [commited] OpenSSL: don't use direct access to the internal of
> X509_STORE_CTX OpenSSL: don't use direct access to the internal of
> EVP_MD_CTX OpenSSL: don't use direct access to the internal of
> EVP_CIPHER_CTX OpenSSL: don't use direct access to the internal of HMAC_CTX
>   OpenSSL: SSLeay symbols are no longer available in OpenSSL 1.1
>   OpenSSL: constify getbio() parameters
>   OpenSSL: use EVP_CipherInit_ex() instead of EVP_CipherInit()

Built v3 against openssl 1.0.2k without issues, tests succeed and two
instanced successfully established vpn connection (with server version 2.3.12
and 2.4.0).

Built against openssl 1.1.0e without issues, tests succeed. Did not test with
real world connectivity, though.
-- 
main(a){char*c=/*Schoene Gruesse */"B?IJj;MEH"
"CX:;",b;for(a/*Best regards my address:*/=0;b=c[a++];)
putchar(b-1/(/*Chriscc -ox -xc - && ./x*/b/42*2-3)*42);}


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

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

[Ilya Shipitsin]

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
-- 
2.5.5


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

[Emmanuel Deloget]

This is v3 of the remaining patches for the "Add support for OpenSSL 
1.1.x" series. This series is partial: only the modified patches are 
sent to the ML -- the other have not changed. The stats are a bit off 
so I don't include them in this mail.

They have been generated after a rebase from the master tree. Individual
commits can be viewed at

  https://github.com/emmanuel-deloget/openvpn/commits/openssl-1.1-v3

(This time, the branch name is correct :))

Changes v2 --> v3: 

* RSA_METHOD (04/15): rsa_meth->name is now a dup of the name parameter; 
  it's freed in RSA_meth_free(). 

* RSA (07/15): calling RSA_set_method() in rsa_finish() is both a Bad 
  Idea and not required so it has been removed.
  
Changes v1 --> v2:

* EVP_PKEY (06/15): add missing function EVP_PKEY_id() for 0.9.8.

* replace patch 15/15 with a new patch to use EVP_CipherInit_ex() 
  instead of EVP_CipherInit() when a full init is not needed.


Emmanuel Deloget (15):
  [commited] OpenSSL: don't use direct access to the internal of SSL_CTX
  [commited] OpenSSL: don't use direct access to the internal of X509_STORE
  [commited] OpenSSL: don't use direct access to the internal of X509_OBJECT
  OpenSSL: don't use direct access to the internal of RSA_METHOD
  OpenSSL: don't use direct access to the internal of X509
  OpenSSL: don't use direct access to the internal of EVP_PKEY
  OpenSSL: don't use direct access to the internal of RSA
  OpenSSL: don't use direct access to the internal of DSA
  [commited] OpenSSL: don't use direct access to the internal of X509_STORE_CTX
  OpenSSL: don't use direct access to the internal of EVP_MD_CTX
  OpenSSL: don't use direct access to the internal of EVP_CIPHER_CTX
  OpenSSL: don't use direct access to the internal of HMAC_CTX
  OpenSSL: SSLeay symbols are no longer available in OpenSSL 1.1
  OpenSSL: constify getbio() parameters
  OpenSSL: use EVP_CipherInit_ex() instead of EVP_CipherInit()

-- 
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 v3 04/15] OpenSSL: don't use direct access to the internal of RSA_METHOD

[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 | 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_METHOD object
+ *
+ * @param meth   The RSA_METHOD object
+ * @param priv_dec   the private decoding function
+ * @return   1 on success, 0 on error
+ */
+static inline int
+RSA_meth_set_priv_dec(RSA_METHOD *meth,
+  int (*priv_dec) (int flen, const unsigned char *from,
+  

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

[Gert Doering]

ACK, thanks.

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

commit 07372a0fdeb3638204d197d0614f776a0eb73ab9 (master)
commit b97a5cc044dc6db3f0e1f9f06a6f5da522f0a33a (release/2.4)
Author: Steffan Karger
Date:   Thu Feb 23 11:35:38 2017 +0100

 OpenSSL: 1.1 fallout - fix configure on old autoconf

 Signed-off-by: Steffan Karger 
 Acked-by: Gert Doering 
 Message-Id: <1487846138-22231-1-git-send-email-steffan.kar...@fox-it.com>
 URL: 
http://www.mail-archive.com/search?l=mid=1487846138-22231-1-git-send-email-steffan.kar...@fox-it.com
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


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

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

[Emmanuel Deloget]

Hi Steffan,

On Wed, Feb 22, 2017 at 11:13 PM, Steffan Karger  wrote:
> 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+:

I failed to see that when I implemented my solution. I'll give a look
as soon as possible.

>   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 

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

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

[Emmanuel Deloget]

Hello,

On Thu, Feb 23, 2017 at 10:23 AM, Gert Doering  wrote:
> Hi,
>
> On Thu, Feb 23, 2017 at 09:03:47AM +0100, Gert Doering wrote:
>> This patch brings two problems outside the "OpenSSL functionality"
>> part.
>>
>>  - openssl_compat.h is not included in the built tarballs, so mingw builds
>>fail (and "builds for anyone building from tarballs" would break) ->
>>findable by running "make distcheck"
>
> This has been fixed & pushed (so we can build windows snapshots again).
>
>>  - 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.

Best regards,

-- Emmanuel Deloget

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

[Gert Doering]

Hi,

On Thu, Feb 23, 2017 at 09:03:47AM +0100, Gert Doering wrote:
> This patch brings two problems outside the "OpenSSL functionality" 
> part.
> 
>  - openssl_compat.h is not included in the built tarballs, so mingw builds
>fail (and "builds for anyone building from tarballs" would break) ->
>findable by running "make distcheck"

This has been fixed & pushed (so we can build windows snapshots again).

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

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


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

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

[Gert Doering]

Thanks.

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

commit 2fe5547c1df854d41611633ea533649fe88e3031 (master)
commit c9b4313eae6fc59f7d075edf23a7f59b137ba11f (release/2.4)
Author: Simon Matter
Date:   Tue Feb 21 20:34:15 2017 +0100

 Fix segfault when using crypto lib without AES-256-CTR or SHA256

 Acked-by: Steffan Karger 
 Message-Id: <345db0ac-f6e8-8490-a80a-ffbd81972...@karger.me>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg14138.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


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

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

[Gert Doering]

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

commit 827c05732b0414dbf3cc05bf4ae6bfda042eadd3 (master)
commit bbc671c2fdf6287605ef5057b1d44811bcd81785 (release/2.4)
Author: Gert Doering
Date:   Thu Feb 23 09:49:54 2017 +0100

 Add openssl_compat.h to openvpn_SOURCES

 Signed-off-by: Gert Doering 
 Acked-by: Steffan Karger 
 Message-Id: <20170223084954.58464-1-g...@greenie.muc.de>
 URL: 
http://www.mail-archive.com/search?l=mid=20170223084954.58464-1-g...@greenie.muc.de
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering


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

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] 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] [RFC PATCH v1 01/15] OpenSSL: don't use direct access to the internal of SSL_CTX

[Gert Doering]

Good morning,

On Fri, Feb 17, 2017 at 11:00:40PM +0100, 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 
> 

This patch brings two problems outside the "OpenSSL functionality" 
part.

 - openssl_compat.h is not included in the built tarballs, so mingw builds
   fail (and "builds for anyone building from tarballs" would break) ->
   findable by running "make distcheck"

 - 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'



The first one is easily fixed, but I do not know how to tackle the 
second one - no access to a CentOS6/RHEL6 box, and not enough autoconf
clue to see this right away.  Patch *looks* good...  most likely just a 
stray "\" where none should be, or so...

Please :-)

gert
-- 
USENET is *not* the non-clickable part of WWW!
   //www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025g...@net.informatik.tu-muenchen.de


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