[Openvpn-devel] [PATCH 1/2] Get rid of old OpenSSL workarounds.

[Steffan Karger]

We now only support OpenSSL 0.9.8+, so we don't have to work around the bug
in 0.9.6b anymore.  Also, OBJ_txt2nid() now takes a const char * (instead
of a char *), so we no langer have to cast away const.

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

diff --git a/src/openvpn/ssl_verify_openssl.c b/src/openvpn/ssl_verify_openssl.c
index 0348e98..81b2e38 100644
--- a/src/openvpn/ssl_verify_openssl.c
+++ b/src/openvpn/ssl_verify_openssl.c
@@ -169,8 +169,8 @@ extract_x509_field_ssl (X509_NAME *x509, const char 
*field_name, char *out,
   int tmp = -1;
   X509_NAME_ENTRY *x509ne = 0;
   ASN1_STRING *asn1 = 0;
-  unsigned char *buf = (unsigned char *)1; /* bug in OpenSSL 0.9.6b 
ASN1_STRING_to_UTF8 requires this workaround */
-  int nid = OBJ_txt2nid((char *)field_name);
+  unsigned char *buf = NULL;
+  int nid = OBJ_txt2nid(field_name);

   ASSERT (size > 0);
   *out = '\0';
-- 
2.1.0

[Openvpn-devel] [PATCH applied] Re: Document the default for tls-cipher.

[Gert Doering]

Your patch has been applied to the master branch.

commit 77f464bddcfcc958f10fd3e9c45e1cb46d5206d0
Author: Arne Schwabe
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Wed Mar 4 15:23:45 2015 +0100

 Document the default for tls-cipher.

 Acked-by: Gert Doering 
 Message-Id: <1425479025-7573-2-git-send-email-a...@rfc2549.org>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/9503
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering

[Openvpn-devel] [PATCH applied] Re: Remove unused function sock_addr_set

[Gert Doering]

Your patch has been applied to the master branch.

commit a6ef6c7c3318a4bc8f9a4df8c75c943da43a7662
Author: Arne Schwabe
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Wed Mar 4 15:23:44 2015 +0100

 Remove unused function sock_addr_set

 Acked-by: Gert Doering 
 Message-Id: <1425479025-7573-1-git-send-email-a...@rfc2549.org>
 URL: http://article.gmane.org/gmane.network.openvpn.devel/9502
 Signed-off-by: Gert Doering 


--
kind regards,

Gert Doering

Re: [Openvpn-devel] [PATCH] Fix CN maximum length

[Steffan Karger]

On 05-02-15 23:08, Gert Doering wrote:

On Thu, Feb 05, 2015 at 06:15:21PM -0300, Jorge Luiz Silva Peixoto wrote:

64 characters according to some specs, but needs to be 65 to allow NULL
termination?  I'm speculating here ... so if I'm right I'd appreciate an
update to the comment above if it includes NULL termination or not.


OK. Do I send this patch again to the list? Comment updated below.


Yes, please.  (Please mark as "patch v2").


  /** Maximum length of common name (rfc5280) + null character byte */
-#define TLS_USERNAME_LEN 64
+#define TLS_USERNAME_LEN 65


NAK on this approach, see my other mail.

If this is the length, it should be the length - and if we need extra
space in the buffer, the buffer should have the "+1", and not all the
other stuff that want the real length a "-1".


Since is has been silent around this one for a while, attached an 
updated patch with the approach suggested by Gert (which indeed is nicer).


-Steffan
>From fef692c154be3cc358c1c4950034f91eeeb57083 Mon Sep 17 00:00:00 2001
From: Steffan Karger 
List-Post: openvpn-devel@lists.sourceforge.net
Date: Thu, 5 Mar 2015 22:24:49 +0100
Subject: [PATCH] Allow for CN/username of 64 characters (fixes off-by-one)

This is an alternative patch to fix the issue reported in trac #515 by
Jorge Peixoto. Instead of increasing the TLS_USERNAME_LEN define, do +1 at
the relevant places in the code.

Also see Jorge's original patch and the discussion on the maillinglist:
http://thread.gmane.org/gmane.network.openvpn.devel/9438

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

diff --git a/src/openvpn/ssl_verify.c b/src/openvpn/ssl_verify.c
index ad50458..c4f56f9 100644
--- a/src/openvpn/ssl_verify.c
+++ b/src/openvpn/ssl_verify.c
@@ -592,7 +592,7 @@ verify_cert(struct tls_session *session, openvpn_x509_cert_t *cert, int cert_dep
 {
   result_t ret = FAILURE;
   char *subject = NULL;
-  char common_name[TLS_USERNAME_LEN] = {0};
+  char common_name[TLS_USERNAME_LEN+1] = {0}; /* null-terminated */
   const struct tls_options *opt;
   struct gc_arena gc = gc_new();

@@ -615,7 +615,7 @@ verify_cert(struct tls_session *session, openvpn_x509_cert_t *cert, int cert_dep
   string_replace_leading (subject, '-', '_');

   /* extract the username (default is CN) */
-  if (SUCCESS != backend_x509_get_username (common_name, TLS_USERNAME_LEN,
+  if (SUCCESS != backend_x509_get_username (common_name, sizeof(common_name),
   opt->x509_username_field, cert))
 {
   if (!cert_depth)
@@ -1163,7 +1163,7 @@ verify_user_pass(struct user_pass *up, struct tls_multi *multi,
 s2 = verify_user_pass_script (session, up);

   /* check sizing of username if it will become our common name */
-  if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME) && strlen (up->username) >= TLS_USERNAME_LEN)
+  if ((session->opt->ssl_flags & SSLF_USERNAME_AS_COMMON_NAME) && strlen (up->username) > TLS_USERNAME_LEN)
 {
   msg (D_TLS_ERRORS, "TLS Auth Error: --username-as-common name specified and username is longer than the maximum permitted Common Name length of %d characters", TLS_USERNAME_LEN);
   s1 = OPENVPN_PLUGIN_FUNC_ERROR;
-- 
2.1.0

[Openvpn-devel] [PATCH] Fix mssfix default value

[Lev Stipakov]

Due to this bug, mssfix hasn't been assigned to fragment value
and used default value (1450) instead. As a consequence, TCP packets
get fragmented, which causes performance penalty.

Since dual stack patch
https://github.com/OpenVPN/openvpn/commit/23d61c56b9fd218c39ad151b01b7e2d6690e6093
OpenVPN uses options->connection_list, even for single remote.

This fix assigns mssfix value to fragment value for connection_entry
inside connection_list instead of connection_entry inside options struct
(which does not work for connection_list case).
---
 src/openvpn/options.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 4ea03d1..20b37db 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2352,7 +2352,7 @@ options_postprocess_mutate_ce (struct options *o, struct 
connection_entry *ce)
 {
 #ifdef ENABLE_FRAGMENT
   if (ce->fragment)
-   o->ce.mssfix = ce->fragment;
+   ce->mssfix = ce->fragment;
 #else
   msg (M_USAGE, "--mssfix must specify a parameter");
 #endif  
-- 
1.9.1

[Openvpn-devel] New OpenVPN 2.3.6 Windows installers released

[Samuli Seppänen]

Hi all,

New Windows installers were released today, primarily to bundle OpenSSL
1.0.1l which fixes the FREAK vulnerability. All users of the official
OpenVPN Windows installers are encouraged to upgrade their systems or to
take other measures to mitigate the attacks. More details are available
in our official statement[*]
regarding
the vulnerability.

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

irc freenode net: mattock

[*] 


signature.asc
Description: OpenPGP digital signature

[Openvpn-devel] reading from the status file from another pid

[Reinoud Koornstra]

Hi Everyone,

I've configured openvpn to write the status every 5 seconds to a status file.
Looking at the code that when openvpn starts you call open()

Then every 5 seconds, the status file is truncated in status_flush.

Only when you close openvpn, the file descriptor will be closed again.
Hence, the file remains open all the time, but is truncated every 5 seconds.

Now I would the read from the status file periodically as well in
another process that is running.
I can open the file just fine, the only issue that makes me incertain
is the truncating of the file every 5 seconds. Currently I am looking
for a safe way to read from the status file, while it is opened and
truncated every 5 seconds.
Any suggestions?
Thanks,

Reinoud.

[Openvpn-devel] reading from the status file from another pid

[Reinoud Koornstra]

Hi Everyone,

I've configured openvpn to write the status every 5 seconds to a status
file.
Looking at the code that when openvpn starts you call open()

Then every 5 seconds, the status file is truncated in status_flush.

Only when you close openvpn, the file descriptor will be closed again.
Hence, the file remains open all the time, but is truncated every 5 seconds.

Now I would the read from the status file periodically as well in another
process that is running.
I can open the file just fine, the only issue that makes me incertain is
the truncating of the file every 5 seconds. Currently I am looking for a
safe way to read from the status file, while it is opened and truncated
every 5 seconds.
Any suggestions?
Thanks,

Reinoud.