[Openvpn-devel] [PATCH applied] Re: Do not load certificate from tls_ctx_use_external_private_key()

[Gert Doering]

Your patch has been applied to the master branch.

I have only done a very cursory sanity check, plus test build (of course,
mbedtls + openssl), and fixed one funky indentation artefact (8 spaces 
plus a tab in the very last change).

commit 73513aaa301e9e9413b6156ed263dd27f8fad7fd
Author: Steffan Karger
Date:   Fri Sep 14 11:14:17 2018 +0200

 Do not load certificate from tls_ctx_use_external_private_key()

 Signed-off-by: Steffan Karger 
 Acked-by: Arne Schwabe 
 Message-Id: <1536916459-25900-1-git-send-email-steffan.kar...@fox-it.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17464.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] [PATCH applied] Re: mbedtls: make external signing code generic

[Gert Doering]

Tested with a mbedTLS "t_client" run, but no "external key" tests here
- trusting Arne and Steffan on this.  Cursory review.

Your patch has been applied to the master branch.

commit 03defa3b29eafc954304532d766aff11712ff9de
Author: Steffan Karger
Date:   Fri Sep 14 11:14:18 2018 +0200

 mbedtls: make external signing code generic

 Signed-off-by: Steffan Karger 
 Acked-by: Arne Schwabe 
 Message-Id: <1536916459-25900-2-git-send-email-steffan.kar...@fox-it.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17465.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] [PATCH applied] Re: mbedtls: remove dependency on mbedtls pkcs11 module

[Gert Doering]

Cursory review, way too much crypto / too little time for me to say 
"I understand the changes".  But nothing that looks obviously erroneous.

Trusting Arne, Steffan and my t_client tests on this :-)

Your patch has been applied to the master branch.

commit 03c8bfc90fbc63007f62d3ed165942d149225551
Author: Steffan Karger
Date:   Fri Sep 14 11:14:19 2018 +0200

 mbedtls: remove dependency on mbedtls pkcs11 module

 Signed-off-by: Steffan Karger 
 Acked-by: Arne Schwabe 
 Message-Id: <1536916459-25900-3-git-send-email-steffan.kar...@fox-it.com>
 URL: 
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg17463.html
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering



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

[Openvpn-devel] Summary of the community meeting (Wed, 26th Sep 2018)

[Samuli Seppänen]

Hi,

Here's the summary of the IRC meeting.

---

COMMUNITY MEETING

Place: #openvpn-meeting on irc.freenode.net
Date: Wednesday 26th Sep 2018
Time: 11:30 CEST (9:30 UTC)

Planned meeting topics for this meeting were here:



The next meeting has not been scheduled yet.

Your local meeting time is easy to check from services such as



SUMMARY

cron2, dazo, lev, mattock, ordex, plaisthos, syzzer and tincantech
participated in this meeting.

--

Discussed tap-windows6 release and HLK testing. An outsourcing company
is currently HLK testing the driver, but they are probably unable to fix
some of the issues. OpenVPN Inc. may have to hire a Windows kernel
driver developer to resolve those issues, after which we can make HLK
tests pass, get WHQL certification and finally release a driver that
loads on Windows Server 2016 and later. Mattock will discuss this topic
in an internal meeting the upcoming Friday.

--

Discussed the Lviv hackathon:

https://community.openvpn.net/openvpn/wiki/LvivHackathon2018

Agreed that the focus should be on "what should go in to OpenVPN 2.5".
It was agreed that being in sync with Debian 10's release cycle would be
good:

https://lists.debian.org/debian-devel-announce/2018/04/msg6.html

However, it will be a tough deadline to meet due to the number of
potential features:

https://community.openvpn.net/openvpn/wiki/StatusOfOpenvpn25

Dazo and mattock will try to get more focus on 2.5 from OpenVPN Inc's
developers.

--

Discussed tap-windows6 in relation to the new Windows VPN API. It was
agreed that we can't migrate away from tap-windows6 any time soon, plus
the VPN API only works with "modern" apps. OpenVPN Inc has written a
proprietary OpenVPN 3-based "modern" app that uses the VPN API, but it
is still in beta in Windows Marketplace. Plus there are glitches in the
VPN API itself.

--

Full chatlog attached.

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

irc freenode net: mattock


(12:30:50) mattock: hi
(12:30:52) mattock: meeting time
(12:32:12) mattock: who is joining today?
(12:33:11) cron2: a mattock!
(12:34:21) lev__: hello there
(12:34:31) mattock: hi!
(12:34:57) mattock: https://community.openvpn.net/openvpn/wiki/Topics-2018-09-26
(12:34:59) vpnHelper: Title: Topics-2018-09-26 – OpenVPN Community (at 
community.openvpn.net)
(12:35:19) mattock: I can start with #1, as that's only a status update for 
those not in the loop
(12:35:27) cron2: go for it
(12:35:42) mattock: so, right now tap-windows6 is being HLK-tested by an 
outsourcing company
(12:35:52) mattock: they've made some progress, but some HLK tests are still 
failing
(12:36:28) mattock: according to jon fixing some of the issues might take an 
experienced NDIS developer a couple of weeks even
(12:36:33) mattock: so they're not trivially fixable
(12:36:54) cron2: e
(12:36:56) mattock: I will discuss the option of hiring such a developer the 
upcoming Friday
(12:37:14) mattock: I'll be in a meeting with CEO of OpenVPN Inc.
(12:37:45) cron2: has there been a change of role there?
(12:38:01) mattock: then there's another (rather big) company who has the same 
tap-windows6 / HLK / WHQL certification issue, and we may be able to co-operate 
with them
(12:38:06) ***ordex is here
(12:38:13) mattock: cron2: change of role where?
(12:38:21) cron2: CEO.  Still Francis?
(12:38:23) mattock: yes
(12:38:39) cron2: ok (I just wondered because you've never spoke so formally)
(12:38:43) mattock: :)
(12:38:54) mattock: well, people who read the chatlog might not know Francis is 
the CEO
(12:38:58) mattock: that was my reasoning
(12:38:59) cron2: yeah
(12:39:09) mattock: but now they _will_ know
(12:39:10) plaisthos: I am here too
(12:39:15) ordex: :D
(12:39:45) mattock: oh, I will send email to the "other company" about 
tap-windows6 WHQL certification - they've been a bit slow to respond after we 
requested GPG encryption :P
(12:39:57) mattock: that's all I have to share about this topic
(12:40:29) mattock: Lviv next?
(12:40:46) ordex: ok
(12:41:02) ordex: it seems it is not going be to be a crowded hackathon
(12:41:14) plaisthos: yeah sadly :/
(12:41:48) ***syzzer present too
(12:42:11) syzzer: (lost track of time while debugging an issue with $coworker)
(12:42:27) cron2: you need to spend less time on work!
(12:42:35) mattock: https://community.openvpn.net/openvpn/wiki/LvivHackathon2018
(12:42:37) vpnHelper: Title: LvivHackathon2018 – OpenVPN Community (at 
community.openvpn.net)
(12:42:44) mattock: well we do have a fair amount of people joining
(12:42:57) mattock: not like last year, but still
(12:43:53) mattock: only two who are _not_ openvpn inc employees, but I guess 
that's to be expected when OpenVPN Inc has tried to hire almost all OpenVPN 
devs there are
(12:44:18) ordex: :D
(12:44:20) cron2: yeah, I noticed the numbers :)
(12:44:33) mattock: so anything in particular to discuss about hackathon? go

[Openvpn-devel] [PATCH] Add message explaining early TLS client hello failure

[Arne Schwabe]

Am 26.09.18 um 08:52 schrieb Antonio Quartulli:
> Hi,
> 
> On 26/09/18 06:19, Arne Schwabe wrote:
>> Am 25.09.18 um 16:31 schrieb David Sommerseth:
>>> On 25/09/18 14:48, Arne Schwabe wrote:
 In my tests an OpenSSL 1.1.1 server does not accept TLS 1.0 only clients
 anymore. Unfortunately, Debian 8 still has OpenVPN 2.3.4, which is
 TLS 1.0 only without setting tls-version-min.

 We currently log only
 OpenSSL: error:14209102:SSL 
 routines:tls_early_post_process_client_hello:unsupported protocol
 which indicates the right technical error but is not very helpful to a
 person without deep knowledge in SSL/TLS and OpenVPN's TLS version
 history.

 This commit adds a hopefully helpful message and also tells users how
 to fix the old Debian 8 clients.
 ---
  src/openvpn/crypto_openssl.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

 diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
 index 9ec2048d..3360bb19 100644
 --- a/src/openvpn/crypto_openssl.c
 +++ b/src/openvpn/crypto_openssl.c
 @@ -199,7 +199,15 @@ crypto_print_openssl_errors(const unsigned int flags)
  "in common with the client. Your --tls-cipher setting 
 might be "
  "too restrictive.");
  }
 -
 +else if (ERR_GET_REASON(err) == SSL_R_UNSUPPORTED_PROTOCOL)
 +{
 +msg(D_CRYPT_ERRORS, "TLS error: Unsupported protocol. This 
 typically "
 + "indicates that client and server have no common TLS 
 version enabled. "
 + "This can be caused by mismatched tls-version-min and 
 tls-version-max options "
 + "on client and server. "
 + "If your client is 2.3.6 or older  consider adding 
 tls-version 1.1"
 + "to the the configuration to use TLS 1.1+ instead of TLS 
 1.0 only");
>>>
>>>
>>> Good advice in the log.  But should this be added in the local or remote
>>> configuration?  It is the 2.3.6 reference which makes it confusing for me,
>>> otherwise I would have interpreted this as the local side where this warning
>>> occurs.  So this could be clearer.
>>
>> 2.3.7 is the first version of OpenVPN which enables TLS 1.0+ instead TLS
>> 1.0 only by default. See this commit by Steffan:
>>
>> https://github.com/OpenVPN/openvpn/commit/8dc6ed28941cb9b9167e0b466e96b5f11359eb59
>>
> 
> I think the problem is: we apply this patch to the latest 2.3.x release,
> so it will never appear on "2.3.6 or older" clients.
> Hence, does it really make sense to print that particular sentence?

This appears in the server log when a 2.3.6 client or older tries to
connect to a server that has OpenSSL 1.1.1.

I am not sure that OpenVPN 2.3.x has OpenSSL 1.1 support.

Arne




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

[Openvpn-devel] [PATCH v2] Add message explaining early TLS client hello failure

[Arne Schwabe]

In my tests an OpenSSL 1.1.1 server does not accept TLS 1.0 only clients
anymore. Unfortunately, Debian 8 still has OpenVPN 2.3.4, which is
TLS 1.0 only without setting tls-version-min.

We currently log only
OpenSSL: error:14209102:SSL 
routines:tls_early_post_process_client_hello:unsupported protocol
which indicates the right technical error but is not very helpful to a
person without deep knowledge in SSL/TLS and OpenVPN's TLS version
history.

This commit adds a hopefully helpful message and also tells users how
to fix the old Debian 8 clients. The error message will be displayed on
the server side only.

Note that connecting with an OpenSSL 1.1.1 client to a TLS 1.0 only
server works fine.

This behaviour is also not specific to OpenVPN. Using an openssl s_client
with the -tls1 option against an openssl s_server exhibits the same
behaviour.

Patch V2: fixed message grammar, use tls-version-min 1.0 and clarify
2.3.6 and older to be actually between 2.3.2 and 2.3.6
---
 src/openvpn/crypto_openssl.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/crypto_openssl.c b/src/openvpn/crypto_openssl.c
index 9ec2048d..43d75b89 100644
--- a/src/openvpn/crypto_openssl.c
+++ b/src/openvpn/crypto_openssl.c
@@ -199,7 +199,16 @@ crypto_print_openssl_errors(const unsigned int flags)
 "in common with the client. Your --tls-cipher setting might be 
"
 "too restrictive.");
 }
-
+else if (ERR_GET_REASON(err) == SSL_R_UNSUPPORTED_PROTOCOL)
+{
+msg(D_CRYPT_ERRORS, "TLS error: Unsupported protocol. This 
typically "
+ "indicates that client and server have no common TLS version 
enabled. "
+ "This can be caused by mismatched tls-version-min and 
tls-version-max "
+ "options on client and server. "
+ "If your OpenVPN client is between v2.3.6 and v2.3.2 try 
adding "
+ "tls-version-min 1.0 to the client configuration to use TLS 
1.0+ "
+ "instead of TLS 1.0 only");
+}
 msg(flags, "OpenSSL: %s", ERR_error_string(err, NULL));
 }
 }
-- 
2.19.0



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

[Openvpn-devel] [PATCH] Add support for tls-ciphersuites for TLS 1.3

[Arne Schwabe]

OpenSSL 1.1.1 introduces a seperate list for TLS 1.3 ciphers. As these
interfaces are meant to be user facing or not exposed at all and we
expose the tls-cipher interface, we should also expose tls-cipherlist.

Combining both settings into tls-cipher would add a lot of glue logic
that needs to be maintained and is error prone. On top of that, users
should not set either settings unless absolutely required.

OpenSSL's own s_client/s_server also expose both settings and I believe
most other software will too:

 -cipher val Specify TLSv1.2 and below cipher list to be used
 -ciphersuites val   Specify TLSv1.3 ciphersuites to be used

For mbed TLS only the future can tell if we will see a combined or also
two seperate lists.
---
 doc/openvpn.8 |  19 -
 src/openvpn/options.c |   7 ++
 src/openvpn/options.h |   1 +
 src/openvpn/ssl.c |   3 +-
 src/openvpn/ssl_backend.h |  13 ++-
 src/openvpn/ssl_mbedtls.c |  12 +++
 src/openvpn/ssl_openssl.c | 167 +++---
 7 files changed, 151 insertions(+), 71 deletions(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 15a10296..0b44a29d 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -5001,11 +5001,13 @@ determines the derivation of the tunnel session keys.
 .\"*
 .TP
 .B \-\-tls\-cipher l
+.TQ
+.B \-\-tls\-ciphersuites l
 A list
 .B l
 of allowable TLS ciphers delimited by a colon (":").
 
-This setting can be used to ensure that certain cipher suites are used (or
+These setting can be used to ensure that certain cipher suites are used (or
 not used) for the TLS connection.  OpenVPN uses TLS to secure the control
 channel, over which the keys that are used to protect the actual VPN traffic
 are exchanged.
@@ -5014,13 +5016,24 @@ The supplied list of ciphers is (after potential 
OpenSSL/IANA name translation)
 simply supplied to the crypto library.  Please see the OpenSSL and/or mbed TLS
 documentation for details on the cipher list interpretation.
 
+For OpenSSL the
+.B \-\-tls-cipher
+is used for TLS 1.2 and below. For TLS 1.3 and up
+the
+.B \-\-tls\-ciphersuites
+setting is used. mbed TLS has no TLS 1.3 support yet and only the
+.B \-\-tls-cipher
+setting is used.
+
 Use
 .B \-\-show\-tls
 to see a list of TLS ciphers supported by your crypto library.
 
 Warning!
 .B \-\-tls\-cipher
-is an expert feature, which \- if used correcly \- can improve the security of
+and
+.B \-\-tls\-ciphersuites
+are expert features, which \- if used correcly \- can improve the security of
 your VPN connection.  But it is also easy to unwittingly use it to carefully
 align a gun with your foot, or just break your connection.  Use with care!
 
@@ -5028,6 +5041,8 @@ The default for \-\-tls\-cipher is to use mbed TLS's 
default cipher list
 when using mbed TLS or
 "DEFAULT:!EXP:!LOW:!MEDIUM:!kDH:!kECDH:!DSS:!PSK:!SRP:!kRSA" when using
 OpenSSL.
+
+The default for \-\-tls\-ciphersuites is to use the crypto library's default.
 .\"*
 .TP
 .B \-\-tls\-cert\-profile profile
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 03550c1e..a574c9f9 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -1766,6 +1766,7 @@ show_settings(const struct options *o)
 #endif
 SHOW_STR(cipher_list);
 SHOW_STR(tls_cert_profile);
+SHOW_STR(cipher_list_tls13);
 SHOW_STR(tls_verify);
 SHOW_STR(tls_export_cert);
 SHOW_INT(verify_x509_type);
@@ -2759,6 +2760,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(cipher_list_tls13);
 MUST_BE_UNDEF(tls_cert_profile);
 MUST_BE_UNDEF(tls_verify);
 MUST_BE_UNDEF(tls_export_cert);
@@ -7948,6 +7950,11 @@ add_option(struct options *options,
 VERIFY_PERMISSION(OPT_P_GENERAL);
 options->tls_cert_profile = p[1];
 }
+else if (streq(p[0], "tls-ciphersuites") && p[1] && !p[2])
+{
+  VERIFY_PERMISSION(OPT_P_GENERAL);
+  options->cipher_list_tls13 = 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 4c3bc4fb..3e7ef4f8 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -508,6 +508,7 @@ struct options
 const char *priv_key_file;
 const char *pkcs12_file;
 const char *cipher_list;
+const char *cipher_list_tls13;
 const char *tls_cert_profile;
 const char *ecdh_curve;
 const char *tls_verify;
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index e5e4aac2..616c2696 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -626,9 +626,10 @@ init_ssl(const struct options *options, struct 
tls_root_

[Openvpn-devel] [PATCH] Fix memory leak in SSL_CTX_use_certificate

[Steffan Karger]

Commit 98bfeeb4 introduced a memory leak in SSL_CTX_use_certificate by
removing the "if(x509) { ... }" bit while not changing the
"else if(x) {}" right after to an "if(x) {}".

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

diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index d9bc9d74..fe4db604 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -855,7 +855,7 @@ end:
 {
 BIO_free(in);
 }
-else if (x)
+if (x)
 {
 X509_free(x);
 }
-- 
2.17.1



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