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

[James Yonan]

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.

James


--
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 25/02/2017 08:40, Steffan Karger wrote:

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

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

[James Yonan]

On 24/02/2017 16:10, Steffan Karger wrote:

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

That sounds good.  So how about legacy allows 1024-bit RSA keys and 
sha1, default requires 2048-bit keys and sha256 or higher?

James


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

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.

James


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

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

[James Yonan]

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.

James

--
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 02/10] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

On 04/03/2016 02:49, Arne Schwabe wrote:


Am 04.03.16 um 08:29 schrieb James Yonan:

On 03/03/2016 16:48, Arne Schwabe wrote:

Am 03.03.16 um 09:18 schrieb James Yonan:

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.

Basically what this patch does is to change the condition to

if (flags)

and if for example PASSTOS_CAPABILITY is not 1, the following path will
always be taken:

process_ip_header (c, PIPV4_PASSTOS|PIP_MSSFIX|PIPV4_CLIENT_NAT,
>c2.buf);

flags mean that possible passtos, mssfix and client_nat should be
applied here.

#if PASSTOS_CAPABILITY
if (!c->options.passtos)
  flags &= ~PIPV4_PASSTOS;
#endif

is not compiled in. So flags is at least PIPV4_PASSTOS

So if (flags & 0x) is still true.

So NACK from me butthe code is very confusing...

Arne

I think what makes this patch confusing is that it's really a patch
that facilitates another patch that we've used in the past at OpenVPN
Tech. for some custom NAT algs.  This patch reduces the footprint of
the second patch, making it easier to maintain.


Yes. I think I get the intention of the patch. But if this patch should
work in OpenVPN now we need to replace

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
 flags &= ~PIPV4_PASSTOS;
#endif

with

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
#endif
  flags &= ~PIPV4_PASSTOS;

to have the correct behaviour if PASSTOS_CAPABILITY is missing.


Actually, I'm fine to withdraw this patch for now -- it's probably more 
trouble than it's worth.


James

Re: [Openvpn-devel] [PATCH 02/10] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

On 03/03/2016 16:48, Arne Schwabe wrote:

Am 03.03.16 um 09:18 schrieb James Yonan:

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.

Basically what this patch does is to change the condition to

if (flags)

and if for example PASSTOS_CAPABILITY is not 1, the following path will
always be taken:

   process_ip_header (c, PIPV4_PASSTOS|PIP_MSSFIX|PIPV4_CLIENT_NAT,
>c2.buf);

flags mean that possible passtos, mssfix and client_nat should be
applied here.

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
 flags &= ~PIPV4_PASSTOS;
#endif

is not compiled in. So flags is at least PIPV4_PASSTOS

So if (flags & 0x) is still true.

So NACK from me butthe code is very confusing...

Arne


I think what makes this patch confusing is that it's really a patch that 
facilitates another patch that we've used in the past at OpenVPN Tech. 
for some custom NAT algs.  This patch reduces the footprint of the 
second patch, making it easier to maintain.


James





Merged from OpenVPN 2.1

Signed-off-by: James Yonan <ja...@openvpn.net>
---
  src/openvpn/forward.c | 8 +---
  src/openvpn/forward.h | 4 +++-
  2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 4a91f92..ef554fc 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1054,13 +1054,7 @@ process_ip_header (struct context *c, unsigned int 
flags, struct buffer *buf)
 * The --passtos and --mssfix options require
 * us to examine the IPv4 header.
 */
-
-  if (flags & (PIP_MSSFIX
-#if PASSTOS_CAPABILITY
- | PIPV4_PASSTOS
-#endif
- | PIPV4_CLIENT_NAT
- ))
+  if (flags & PIP_OPT_MASK)
{
  struct buffer ipbuf = *buf;
  if (is_ipv4 (TUNNEL_TYPE (c->c1.tuntap), ))
diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index af3b0a6..7debcb1 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -249,9 +249,11 @@ bool send_control_channel_string (struct context *c, const 
char *str, int msglev
  
  #define PIPV4_PASSTOS (1<<0)

  #define PIP_MSSFIX(1<<1) /* v4 and v6 */
-#define PIPV4_OUTGOING(1<<2)
  #define PIPV4_EXTRACT_DHCP_ROUTER (1<<3)
  #define PIPV4_CLIENT_NAT  (1<<4)
+#define PIP_OPT_MASK  0x /* all possible options for */
+ /* process_ip_header() */
+#define PIPV4_OUTGOING(1<<16)
  
  void process_ip_header (struct context *c, unsigned int flags, struct buffer *buf);
  

[Openvpn-devel] [PATCH 10/10] Bind to local socket before dropping privileges

[James Yonan]

Bind the local TCP/UDP socket before UID/GID downgrade,
otherwise we cannot bind to ports < 1024.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/init.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index cb73a3d..9658895 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -3630,16 +3630,16 @@ init_instance (struct context *c, const struct env_set 
*env, const unsigned int
 open_plugins (c, false, OPENVPN_PLUGIN_INIT_POST_DAEMON);
 #endif

+  /* finalize the TCP/UDP socket */
+  if (c->mode == CM_P2P || c->mode == CM_TOP || c->mode == CM_CHILD_TCP)
+do_init_socket_2 (c);
+
   /*
* Actually do UID/GID downgrade, and chroot, if requested.
* May be delayed by --client, --pull, or --up-delay.
*/
   do_uid_gid_chroot (c, c->c2.did_open_tun);

-  /* finalize the TCP/UDP socket */
-  if (c->mode == CM_P2P || c->mode == CM_TOP || c->mode == CM_CHILD_TCP)
-do_init_socket_2 (c);
-
   /* initialize timers */
   if (c->mode == CM_P2P || child)
 do_init_timers (c, false);
-- 
1.9.1

[Openvpn-devel] [PATCH 09/10] Added directive to specify HTTP proxy credentials in config.

[James Yonan]

The inline directive http-proxy-user-pass can be used to
specify proxy credentials in config, e.g.:

http-proxy proxy.tld 3128 auto-nct

foo
bar


This usage is already supported by OpenVPN 3.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/misc.c|  8 
 src/openvpn/misc.h|  2 ++
 src/openvpn/options.c | 13 +
 src/openvpn/proxy.c   |  2 ++
 src/openvpn/proxy.h   |  1 +
 5 files changed, 26 insertions(+)

diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index 05ed073..4766a17 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -1090,6 +1090,14 @@ get_user_pass_cr (struct user_pass *up,
  if (!strlen (up->password))
strcpy (up->password, "ok");
}
+  else if (flags & GET_USER_PASS_INLINE_CREDS)
+   {
+ struct buffer buf;
+ buf_set_read (, (uint8_t*) auth_file, strlen (auth_file) + 1);
+ if (!(flags & GET_USER_PASS_PASSWORD_ONLY))
+   buf_parse (, '\n', up->username, USER_PASS_LEN);
+ buf_parse (, '\n', up->password, USER_PASS_LEN);
+   }
   else if (from_authfile)
 {
   /*
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index 65a6e55..b694096 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -256,6 +256,8 @@ struct static_challenge_info {};
 #define GET_USER_PASS_STATIC_CHALLENGE   (1<<8) /* SCRV1 protocol -- 
static challenge */
 #define GET_USER_PASS_STATIC_CHALLENGE_ECHO  (1<<9) /* SCRV1 protocol -- echo 
response */

+#define GET_USER_PASS_INLINE_CREDS (1<<10)  /* indicates that auth_file is 
actually inline creds */
+
 bool get_user_pass_cr (struct user_pass *up,
   const char *auth_file,
   const char *prefix,
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index b53f7ac..8f560a7 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -5121,6 +5121,19 @@ add_option (struct options *options,
  ho->auth_method_string = "none";
}
 }
+  else if (streq (p[0], "http-proxy-user-pass") && p[1])
+{
+  struct http_proxy_options *ho;
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  ho = init_http_proxy_options_once (>ce.http_proxy_options, 
>gc);
+  if (streq (p[1], INLINE_FILE_TAG) && p[2])
+   {
+ ho->auth_file = p[2];
+ ho->inline_creds = true;
+   }
+  else
+   ho->auth_file = p[1];
+}
   else if (streq (p[0], "http-proxy-retry") && !p[1])
 {
   struct http_proxy_options *ho;
diff --git a/src/openvpn/proxy.c b/src/openvpn/proxy.c
index 2568e19..865a026 100644
--- a/src/openvpn/proxy.c
+++ b/src/openvpn/proxy.c
@@ -241,6 +241,8 @@ get_user_pass_http (struct http_proxy_info *p, const bool 
force)
   unsigned int flags = GET_USER_PASS_MANAGEMENT;
   if (p->queried_creds)
flags |= GET_USER_PASS_PREVIOUS_CREDS_FAILED;
+  if (p->options.inline_creds)
+   flags |= GET_USER_PASS_INLINE_CREDS;
   get_user_pass (_proxy_user_pass,
 p->options.auth_file,
 UP_TYPE_PROXY,
diff --git a/src/openvpn/proxy.h b/src/openvpn/proxy.h
index 4715940..864d3b9 100644
--- a/src/openvpn/proxy.h
+++ b/src/openvpn/proxy.h
@@ -58,6 +58,7 @@ struct http_proxy_options {
   const char *http_version;
   const char *user_agent;
   struct http_custom_header custom_headers[MAX_CUSTOM_HTTP_HEADER];
+  bool inline_creds;
 };

 struct http_proxy_options_simple {
-- 
1.9.1

[Openvpn-devel] [PATCH 08/10] Added ./configure flag to disable user-defined scripts.

[James Yonan]

Added ./configure --disable-scripts build flag to ignore the
"script-security" directive in configs.  This can be used to
prevent configs from raising the script-security level to
allow user-defined script execution.

At the C level, script support is enabled by:

  /* Enable user-defined scripting */
  #define ENABLE_SCRIPTS 1

or disabled by ensuring that ENABLE_SCRIPTS is undefined.

If ENABLE_SCRIPTS is undefined, OpenVPN will log "[NOSCRIPTS]"
in the initial version info line.

This patch assumes that script_security defaults to
SSEC_BUILT_IN or less.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 configure.ac  | 8 
 src/openvpn/options.c | 7 +++
 2 files changed, 15 insertions(+)

diff --git a/configure.ac b/configure.ac
index b75d51f..c3ff472 100644
--- a/configure.ac
+++ b/configure.ac
@@ -128,6 +128,13 @@ AC_ARG_ENABLE(
 )

 AC_ARG_ENABLE(
+   [scripts],
+   [AS_HELP_STRING([--disable-scripts], [disable user-defined scripting 
support @<:@default=yes@:>@])],
+   ,
+   [enable_scripts="yes"]
+)
+
+AC_ARG_ENABLE(
[pkcs11],
[AS_HELP_STRING([--enable-pkcs11], [enable pkcs11 support 
@<:@default=no@:>@])],
,
@@ -1059,6 +1066,7 @@ test "${ac_cv_header_sys_uio_h}" = "yes" && 
AC_DEFINE([HAVE_IOVEC], [1], [struct
 test "${enable_multi}" = "yes" && AC_DEFINE([ENABLE_CLIENT_SERVER], [1], 
[Enable client/server capability])
 test "${enable_server}" = "no" && AC_DEFINE([ENABLE_CLIENT_ONLY], [1], [Enable 
client capability only])
 test "${enable_management}" = "yes" && AC_DEFINE([ENABLE_MANAGEMENT], [1], 
[Enable management server capability])
+test "${enable_scripts}" = "yes" && AC_DEFINE([ENABLE_SCRIPTS], [1], [Enable 
user-defined scripting])
 test "${enable_multihome}" = "yes" && AC_DEFINE([ENABLE_MULTIHOME], [1], 
[Enable multi-homed UDP server capability])
 test "${enable_debug}" = "yes" && AC_DEFINE([ENABLE_DEBUG], [1], [Enable 
debugging support])
 test "${enable_small}" = "yes" && AC_DEFINE([ENABLE_SMALL], [1], [Enable 
smaller executable size])
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 0942a4d..b53f7ac 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -99,6 +99,9 @@ const char title_string[] =
 #if ENABLE_IP_PKTINFO
   " [MH]"
 #endif
+#ifndef ENABLE_SCRIPTS
+  " [NOSCRIPTS]"
+#endif
   " [IPv6]"
   " built on " __DATE__
 ;
@@ -5476,7 +5479,11 @@ add_option (struct options *options,
   else if (streq (p[0], "script-security") && p[1] && !p[2])
 {
   VERIFY_PERMISSION (OPT_P_GENERAL);
+#ifdef ENABLE_SCRIPTS
   script_security = atoi (p[1]);
+#else
+  msg (M_WARN, "NOTE: script-security directive ignored due to build 
setting");
+#endif
 }
   else if (streq (p[0], "mssfix") && !p[2])
 {
-- 
1.9.1

[Openvpn-devel] [PATCH 07/10] Implemented x509-track for PolarSSL.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_verify_polarssl.c | 166 ++
 src/openvpn/syshead.h |   2 +-
 2 files changed, 167 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/ssl_verify_polarssl.c 
b/src/openvpn/ssl_verify_polarssl.c
index 9d0d086..ab693d2 100644
--- a/src/openvpn/ssl_verify_polarssl.c
+++ b/src/openvpn/ssl_verify_polarssl.c
@@ -198,6 +198,172 @@ x509_get_subject(x509_crt *cert, struct gc_arena *gc)
   return subject;
 }

+#ifdef ENABLE_X509_TRACK
+
+/* these match NID's in OpenSSL crypto/objects/objects.h */
+#define NID_undef  0
+#define NID_sha164
+#define NID_commonName  13
+#define NID_countryName 14
+#define NID_localityName15
+#define NID_stateOrProvinceName 16
+#define NID_organizationName   17
+#define NID_organizationalUnitName  18
+#define NID_pkcs9_emailAddress  48
+
+struct nid_entry {
+  const char *name;
+  int nid;
+};
+
+static const struct nid_entry nid_list[] = {
+  { "SHA1", NID_sha1 },
+  { "CN",   NID_commonName },
+  { "C",NID_countryName },
+  { "L",NID_localityName },
+  { "ST",   NID_stateOrProvinceName },
+  { "O",NID_organizationName },
+  { "OU",   NID_organizationalUnitName },
+  { "emailAddress", NID_pkcs9_emailAddress },
+  { NULL, 0 }
+};
+
+static int
+name_to_nid(const char *name)
+{
+  const struct nid_entry *e = nid_list;
+  while (e->name)
+{
+  if (!strcmp(name, e->name))
+   return e->nid;
+  ++e;
+}
+  return NID_undef;
+}
+
+static void
+do_setenv_x509 (struct env_set *es, const char *name, char *value, int depth)
+{
+  char *name_expand;
+  size_t name_expand_size;
+
+  string_mod (value, CC_ANY, CC_CRLF, '?');
+  msg (D_X509_ATTR, "X509 ATTRIBUTE name='%s' value='%s' depth=%d", name, 
value, depth);
+  name_expand_size = 64 + strlen (name);
+  name_expand = (char *) malloc (name_expand_size);
+  check_malloc_return (name_expand);
+  openvpn_snprintf (name_expand, name_expand_size, "X509_%d_%s", depth, name);
+  setenv_str (es, name_expand, value);
+  free (name_expand);
+}
+
+static void
+do_setenv_nid_value(struct env_set *es, const struct x509_track *xt, const 
x509_name *xn,
+   int depth, struct gc_arena *gc)
+{
+  size_t i;
+  char *val;
+
+  for (i = 0; i < xn->val.len; ++i)
+if (xn->val.p[i] == '\0') /* error if embedded null in value */
+  return;
+  val = gc_malloc(xn->val.len+1, false, gc);
+  memcpy(val, xn->val.p, xn->val.len);
+  val[xn->val.len] = '\0';
+  do_setenv_x509(es, xt->name, val, depth);
+}
+
+static void
+do_setenv_nid(struct env_set *es, const struct x509_track *xt, const x509_crt 
*cert,
+ int depth, struct gc_arena *gc)
+{
+  const x509_name *xn;
+  for (xn = >subject; xn != NULL; xn = xn->next)
+{
+  switch (xt->nid)
+   {
+   case NID_commonName:
+ if (OID_CMP(OID_AT_CN, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_countryName:
+ if (OID_CMP(OID_AT_COUNTRY, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_localityName:
+ if (OID_CMP(OID_AT_LOCALITY, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_stateOrProvinceName:
+ if (OID_CMP(OID_AT_STATE, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_organizationName:
+ if (OID_CMP(OID_AT_ORGANIZATION, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_organizationalUnitName:
+ if (OID_CMP(OID_AT_ORG_UNIT, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   case NID_pkcs9_emailAddress:
+ if (OID_CMP(OID_PKCS9_EMAIL, >oid))
+   do_setenv_nid_value(es, xt, xn, depth, gc);
+ break;
+   }
+}
+}
+
+void
+x509_track_add (const struct x509_track **ll_head, const char *name, int 
msglevel, struct gc_arena *gc)
+{
+  struct x509_track *xt;
+  ALLOC_OBJ_CLEAR_GC (xt, struct x509_track, gc);
+  if (*name == '+')
+{
+  xt->flags |= XT_FULL_CHAIN;
+  ++name;
+}
+  xt->name = name;
+  xt->nid = name_to_nid(name);
+  if (xt->nid != NID_undef)
+{
+  xt->next = *ll_head;
+  *ll_head = xt;
+}
+  else
+msg(msglevel, "x509_track: no such attribute '%s'", name);
+}
+
+void
+x509_setenv_track (const struct x509_track *xt, struct env_set *es, const int 
depth, x509_crt *cert)
+{
+  struct gc_arena gc = gc_new();
+  while (xt)
+{
+  if (depth == 0 || (xt->flags & 

[Openvpn-devel] [PATCH 06/10] PolarSSL x509_get_sha1_hash now returns correct SHA1 fingerprint.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_verify_polarssl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/ssl_verify_polarssl.c 
b/src/openvpn/ssl_verify_polarssl.c
index e87d2e2..9d0d086 100644
--- a/src/openvpn/ssl_verify_polarssl.c
+++ b/src/openvpn/ssl_verify_polarssl.c
@@ -176,7 +176,7 @@ unsigned char *
 x509_get_sha1_hash (x509_crt *cert, struct gc_arena *gc)
 {
   unsigned char *sha1_hash = gc_malloc(SHA_DIGEST_LENGTH, false, gc);
-  sha1(cert->tbs.p, cert->tbs.len, sha1_hash);
+  sha1(cert->raw.p, cert->raw.len, sha1_hash);
   return sha1_hash;
 }

-- 
1.9.1

[Openvpn-devel] [PATCH 05/10] Extended x509-track for OpenSSL to report SHA1 fingerprint.

[James Yonan]

For example:

  x509-track "+SHA1"

will extract the SHA1 fingerprints for all certs in the
peer chain.

This patch is ported from OpenVPN 2.1.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_verify_openssl.c | 114 +--
 1 file changed, 74 insertions(+), 40 deletions(-)

diff --git a/src/openvpn/ssl_verify_openssl.c b/src/openvpn/ssl_verify_openssl.c
index d014f9d..cde884b 100644
--- a/src/openvpn/ssl_verify_openssl.c
+++ b/src/openvpn/ssl_verify_openssl.c
@@ -305,6 +305,27 @@ err:

 #ifdef ENABLE_X509_TRACK

+/*
+ * x509-track implementation -- save X509 fields to environment,
+ * using the naming convention:
+ *
+ *  X509_{cert_depth}_{name}={value}
+ *
+ * This function differs from x509_setenv below in the following ways:
+ *
+ * (1) Only explicitly named attributes in xt are saved, per usage
+ * of "x509-track" program options.
+ * (2) Only the level 0 cert info is saved unless the XT_FULL_CHAIN
+ * flag is set in xt->flags (corresponds with prepending a '+'
+ * to the name when specified by "x509-track" program option).
+ * (3) This function supports both X509 subject name fields as
+ * well as X509 V3 extensions.
+ * (4) This function can return the SHA1 fingerprint of a cert, e.g.
+ *   x509-track "+SHA1"
+ * will return the SHA1 fingerprint for each certificate in the
+ * peer chain.
+ */
+
 void
 x509_track_add (const struct x509_track **ll_head, const char *name, int 
msglevel, struct gc_arena *gc)
 {
@@ -346,58 +367,71 @@ do_setenv_x509 (struct env_set *es, const char *name, 
char *value, int depth)
 void
 x509_setenv_track (const struct x509_track *xt, struct env_set *es, const int 
depth, X509 *x509)
 {
+  struct gc_arena gc = gc_new();
   X509_NAME *x509_name = X509_get_subject_name (x509);
   const char nullc = '\0';
-  int i;

   while (xt)
 {
   if (depth == 0 || (xt->flags & XT_FULL_CHAIN))
{
- i = X509_NAME_get_index_by_NID(x509_name, xt->nid, -1);
- if (i >= 0)
+ switch (xt->nid)
{
- X509_NAME_ENTRY *ent = X509_NAME_get_entry(x509_name, i);
- if (ent)
-   {
- ASN1_STRING *val = X509_NAME_ENTRY_get_data (ent);
- unsigned char *buf;
- buf = (unsigned char *)1; /* bug in OpenSSL 0.9.6b 
ASN1_STRING_to_UTF8 requires this workaround */
- if (ASN1_STRING_to_UTF8 (, val) > 0)
-   {
- do_setenv_x509(es, xt->name, (char *)buf, depth);
- OPENSSL_free (buf);
-   }
-   }
-   }
- else
-   {
- i = X509_get_ext_by_NID(x509, xt->nid, -1);
- if (i >= 0)
-   {
- X509_EXTENSION *ext = X509_get_ext(x509, i);
- if (ext)
-   {
- BIO *bio = BIO_new(BIO_s_mem());
- if (bio)
-   {
- if (X509V3_EXT_print(bio, ext, 0, 0))
-   {
- if (BIO_write(bio, , 1) == 1)
-   {
- char *str;
- BIO_get_mem_data(bio, );
- do_setenv_x509(es, xt->name, str, depth);
-   }
-   }
- BIO_free(bio);
-   }
-   }
-   }
+   case NID_sha1:
+ {
+   char *sha1_fingerprint = format_hex_ex(x509->sha1_hash, 
SHA_DIGEST_LENGTH, 0, 1 | FHE_CAPS, ":", );
+   do_setenv_x509(es, xt->name, sha1_fingerprint, depth);
+ }
+ break;
+   default:
+ {
+   int i = X509_NAME_get_index_by_NID(x509_name, xt->nid, -1);
+   if (i >= 0)
+ {
+   X509_NAME_ENTRY *ent = X509_NAME_get_entry(x509_name, i);
+   if (ent)
+ {
+   ASN1_STRING *val = X509_NAME_ENTRY_get_data (ent);
+   unsigned char *buf;
+   buf = (unsigned char *)1; /* bug in OpenSSL 0.9.6b 
ASN1_STRING_to_UTF8 requires this workaround */
+   if (ASN1_STRING_to_UTF8 (, val) > 0)
+ {
+   do_setenv_x509(es, xt->name, (char *)buf, depth);
+   OPENSSL_free (buf);
+ }
+ }
+ }
+   else
+ {
+   i = X509_get_ext_by_NID(x509, xt->nid, -1);
+   if (i >= 0)
+ {
+   X509_EXTENSION *ext = X509_get_ext(x509, i);
+  

[Openvpn-devel] [PATCH 04/10] Added flags parameter to format_hex_ex.

[James Yonan]

We add the flags parameter without changing the signature of
the function by repurposing the space_break parameter into
space_break_flags where the lower 8 bits are used for the
previous space_break parameter and the higher bits are used
for flag values.

Added new flag FHE_CAPS that formats the generated hex string
in upper case.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/buffer.c | 11 +++
 src/openvpn/buffer.h |  4 +++-
 2 files changed, 10 insertions(+), 5 deletions(-)

diff --git a/src/openvpn/buffer.c b/src/openvpn/buffer.c
index bc67d65..52c6ab9 100644
--- a/src/openvpn/buffer.c
+++ b/src/openvpn/buffer.c
@@ -435,18 +435,21 @@ gc_transfer (struct gc_arena *dest, struct gc_arena *src)

 char *
 format_hex_ex (const uint8_t *data, int size, int maxoutput,
-  int space_break, const char* separator,
+  unsigned int space_break_flags, const char* separator,
   struct gc_arena *gc)
 {
   struct buffer out = alloc_buf_gc (maxoutput ? maxoutput :
-   ((size * 2) + (size / space_break) * (int) 
strlen (separator) + 2),
+   ((size * 2) + (size / (space_break_flags & 
FHE_SPACE_BREAK_MASK)) * (int) strlen (separator) + 2),
gc);
   int i;
   for (i = 0; i < size; ++i)
 {
-  if (separator && i && !(i % space_break))
+  if (separator && i && !(i % (space_break_flags & FHE_SPACE_BREAK_MASK)))
buf_printf (, "%s", separator);
-  buf_printf (, "%02x", data[i]);
+  if (space_break_flags & FHE_CAPS)
+   buf_printf (, "%02X", data[i]);
+  else
+   buf_printf (, "%02x", data[i]);
 }
   buf_catrunc (, "[more...]");
   return (char *)out.data;
diff --git a/src/openvpn/buffer.h b/src/openvpn/buffer.h
index 24f52aa..8070439 100644
--- a/src/openvpn/buffer.h
+++ b/src/openvpn/buffer.h
@@ -403,9 +403,11 @@ bool buf_parse (struct buffer *buf, const int delim, char 
*line, const int size)
 /*
  * Hex dump -- Output a binary buffer to a hex string and return it.
  */
+#define FHE_SPACE_BREAK_MASK 0xFF /* space_break parameter in lower 8 bits */
+#define FHE_CAPS 0x100/* output hex in caps */
 char *
 format_hex_ex (const uint8_t *data, int size, int maxoutput,
-  int space_break, const char* separator,
+  unsigned int space_break_flags, const char* separator,
   struct gc_arena *gc);

 static inline char *
-- 
1.9.1

[Openvpn-devel] [PATCH 03/10] tls_serial_{n} value should be distinguishable as hex or decimal.

[James Yonan]

To accomplish this, prepend 'x' before hex serial numbers, so they
can be distinguished from decimal serial numbers.  For example:

  tls_serial_1 = "x4D:9B:7C:94"

is equivalent to:

  tls_serial_1 = "1302035604"

Currently, only PolarSSL generates hex serial numbers while
OpenSSL returns decimal serial numbers.

RFC 5280, published in 2008, decrees that serial numbers can be
up to 20 bytes long, hence it is necessary to support SSL
libraries that return the serial number as a hex string.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_verify_polarssl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/ssl_verify_polarssl.c 
b/src/openvpn/ssl_verify_polarssl.c
index a2e6a8e..e87d2e2 100644
--- a/src/openvpn/ssl_verify_polarssl.c
+++ b/src/openvpn/ssl_verify_polarssl.c
@@ -161,11 +161,12 @@ char *
 backend_x509_get_serial_hex (openvpn_x509_cert_t *cert, struct gc_arena *gc)
 {
   char *buf = NULL;
-  size_t len = cert->serial.len * 3 + 1;
+  size_t len = cert->serial.len * 3;

-  buf = gc_malloc(len, true, gc);
+  buf = gc_malloc(len+1, true, gc);

-  if(x509_serial_gets(buf, len-1, >serial) < 0)
+  buf[0] = 'x';
+  if(x509_serial_gets(buf+1, len, >serial) < 0)
 buf = NULL;

   return buf;
-- 
1.9.1

[Openvpn-devel] [PATCH 02/10] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.

Merged from OpenVPN 2.1

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/forward.c | 8 +---
 src/openvpn/forward.h | 4 +++-
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 4a91f92..ef554fc 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1054,13 +1054,7 @@ process_ip_header (struct context *c, unsigned int 
flags, struct buffer *buf)
* The --passtos and --mssfix options require
* us to examine the IPv4 header.
*/
-
-  if (flags & (PIP_MSSFIX
-#if PASSTOS_CAPABILITY
- | PIPV4_PASSTOS
-#endif
- | PIPV4_CLIENT_NAT
- ))
+  if (flags & PIP_OPT_MASK)
{
  struct buffer ipbuf = *buf;
  if (is_ipv4 (TUNNEL_TYPE (c->c1.tuntap), ))
diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index af3b0a6..7debcb1 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -249,9 +249,11 @@ bool send_control_channel_string (struct context *c, const 
char *str, int msglev

 #define PIPV4_PASSTOS (1<<0)
 #define PIP_MSSFIX(1<<1) /* v4 and v6 */
-#define PIPV4_OUTGOING(1<<2)
 #define PIPV4_EXTRACT_DHCP_ROUTER (1<<3)
 #define PIPV4_CLIENT_NAT  (1<<4)
+#define PIP_OPT_MASK  0x /* all possible options for */
+ /* process_ip_header() */
+#define PIPV4_OUTGOING(1<<16)

 void process_ip_header (struct context *c, unsigned int flags, struct buffer 
*buf);

-- 
1.9.1

[Openvpn-devel] [PATCH 01/10] Added "remote-override" config directive.

[James Yonan]

remote-override  -- replace the hostname in all remote
directives with alt-remote.

Merged from OpenVPN 2.1

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 doc/openvpn.8 | 5 +
 src/openvpn/options.c | 8 +++-
 src/openvpn/options.h | 2 ++
 3 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 628d877..249100d 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -281,6 +281,11 @@ DNS caching.  For example, "foo.bar.gov" would be modified 
to
 ".foo.bar.gov".
 .\"*
 .TP
+.B \-\-remote-override [alt-remote]
+Replace the hostname in all remote directives with
+.B alt-remote.
+.\"*
+.TP
 .B 
 Define a client connection
 profile.  Client connection profiles are groups of OpenVPN options that
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 02def3a..0942a4d 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -118,6 +118,7 @@ static const char usage_message[] =
   "--remote host [port] : Remote host name or ip address.\n"
   "--remote-random : If multiple --remote options specified, choose one 
randomly.\n"
   "--remote-random-hostname : Add a random string to remote DNS name.\n"
+  "--remote-override a : Replace the hostname in all remote directives with 
a.\n"
   "--mode m: Major mode, m = 'p2p' (default, point-to-point) or 
'server'.\n"
   "--proto p   : Use protocol p for communicating with peer.\n"
   "  p = udp (default), tcp-server, or tcp-client\n"
@@ -4565,6 +4566,11 @@ add_option (struct options *options,
goto err;
 }
 #endif
+  else if (streq (p[0], "remote-override") && p[1])
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->remote_override = p[1];
+}
   else if (streq (p[0], "remote") && p[1] && !p[4])
 {
   struct remote_entry re;
@@ -4573,7 +4579,7 @@ add_option (struct options *options,
   re.af=0;

   VERIFY_PERMISSION (OPT_P_GENERAL|OPT_P_CONNECTION);
-  re.remote = p[1];
+  re.remote = options->remote_override ? options->remote_override : p[1];
   if (p[2])
{
  re.remote_port = p[2];
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index 23d3992..e281069 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -213,6 +213,8 @@ struct options

   struct remote_host_store *rh_store;

+  const char *remote_override;
+
   bool remote_random;
   const char *ipchange;
   const char *dev;
-- 
1.9.1

[Openvpn-devel] --block-outside-dns speed

[James Yonan]

Has anyone seen issues with --block-outside-dns speed?  Because this 
approach drops certain DNS packets, I'm wondering if apps will 
experience lag time while waiting for dropped DNS requests to time out.


James

Re: [Openvpn-devel] [PATCH v7-master] Add Windows DNS Leak fix using WFP ('block-outside-dns')

[James Yonan]

These may have been fixed by now, but noticed some issues in the 
original patch that was discussed in the OpenVPN-devel IRC meeting 
several weeks ago.


* win_adapter_index_to_luid is declared to return a
  NET_LUID but not all code paths return a value.

* wcscat(svchostpath, L"\\svchost.exe") isn't checking
  for buffer overflow.

* FwpmGetAppIdFromFileName0 must be paired with a
  corresponding FwpmFreeMemory0

James

Re: [Openvpn-devel] Adding a ctrl-C handler in windows

[James Yonan]

On 09/11/2015 00:38, Samuli Seppänen wrote:



Hi,

I plan to add a control-C handler in win32.c. The handler will simply
map it to SIGTERM. Is there any particular reason why control-C is not
currently handled?


Hi,

I forwarded this email to James - he might have a clue.


Currently the Windows implementation, when running in console mode, uses 
function keys to trigger various Unix signals (see win32_signal_get() 
function in win32.c).


The current code looks like this:

  switch (win32_keyboard_get (ws))
{
case 0x3B: /* F1 -> USR1 */
  ret = SIGUSR1;
  break;
case 0x3C: /* F2 -> USR2 */
  ret = SIGUSR2;
  break;
case 0x3D: /* F3 -> HUP */
  ret = SIGHUP;
  break;
case 0x3E: /* F4 -> TERM */
  ret = SIGTERM;
  break;
}


It's probably okay to just make CTRL-c generate a SIGTERM as F4 is 
already doing.


James

Re: [Openvpn-devel] OpenVPN protocol extensions update

[James Yonan]

On 09/01/2015 02:41, Lev Stipakov wrote:

Hi James,

A few comments on peer-id part:

   * A disabled peer ID is denoted by 0xFF.
   * Server tells the client to use DATA_V2/peer_id by pushing
  the directive "peer-id ID" where ID is a decimal integer
  in the range [-1, 16777215].  Setting the peer ID to -1
  transmits DATA_V2 packets with the peer ID field set to
  0xFF.  Setting the peer_id to -1 is the same as
  setting it to 16777215 (i.e. 0xFF).

There is no such thing as "disabled peer-id" in current
implementation, server does not send "-1" and client does not send
0xFF. I can surely do it, if needed. Could you maybe explain its
meaning?


I see DATA_V2 as playing multiple roles, e.g. aside from its intended 
use of client float, it also improves packet alignment.


So conceivably, a connection might want to use DATA_V2 for alignment, 
but not need the peer-id/float capability.


Another thing I've observed about protocol changes in the past, is that 
once a protocol change reaches maturity after many years, where almost 
every OpenVPN client/server universally supports it, you can safely 
deprecate the old protocol variant (case in point: 
CONTROL_HARD_RESET_(CLIENT|SERVER)_V1 which has been been completely 
supplanted by V2).  So eventually we may want to deprecate DATA_V1, but 
we can't do that unless DATA_V2 is flexible enough to replace it.  And 
being able to use DATA_V2 without peer-id/float would give it the 
flexibility to be used as a drop-in replacement for DATA_V1 in cases 
where peer-id/float is not wanted or needed.



And just to make sure - if server gets DATA_V2 with peer-id
-1, it should skip peer-id bytes and treat it as data_v1, correct?


Right.


There is no specific check for the max value of peer-id at the place
where peer-id is issued. Logic relies on max_clients option. So in
case if max_clients is set to 2^24 or above, peer-id will wrap. There
is a check, however, that peer-id is between 0 and max_clients in the
code which handles incoming data packets.


It's an improbable corner case, but I would still check for wrap.

My rationale for checking for improbable corner cases is that code is 
always evolving, and sometimes code changes can make previously 
forgotten-about rare corner cases much more probable.



   * Server never pushes a "peer-id" directive unless the client has
indicated its support for DATA_V2 by including "IV_PROTO=2" in the
peer info data.

Server pushes peer-id if IV_PROTO>=2. Is it ok or should it be changed to =2 ?


That's a good question.  I think IV_PROTO>=2 is okay.  If we made a 
future change to the protocol that wasn't backward compatible, then we 
would have to make a new IV symbol for it, but having IV_PROTO be 
versioned does make it easier to introduce changes that _are_ backward 
compatible.




   * ensure that the float doesn't clobber a pre-existing client (i.e.
if the address floated to is already owned by another client) unless
it can be verified that the pre-existing client is a previous instance
of the floating client.

Thanks to this mail, I've checked code again and found a bug - a lame
duck client may float to an address taken by another client. I have
submitted a fix:

http://thread.gmane.org/gmane.network.openvpn.devel/9386

which is waiting for an ACK.

Otherwise implementation is pretty much in line with your spec.


Great, thanks.

James


-Lev

2015-01-07 2:08 GMT+02:00 James Yonan <ja...@openvpn.net>:

I've updated the OpenVPN protocol extension doc with additional details, now
that more of these features have been implemented in OpenVPN 3.

If you are implementing any of these features in OpenVPN 2.x, please review
so we can ensure that OpenVPN 2.x and 3 are on the same page with respect to
protocol extensions.

Changes:

1. Added specific details on DATA_V2/peer-id/float support.

2. For AEAD mode, emphasized that the leading 8 bytes (4 bytes for
DATA_V2/peer-id and 4 for packet ID) is all included in the AD.

3. Added specific details on protocol negotiation where the client indicates
protocol extension availability with IV_x parameters in the peer info
string, and the server responds by pushing directives to the client to
enable the feature.

4. Added "TCP nonlinear mode" section, a new protocol extension that is
needed by multithreaded TCP servers.

James

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN protocol extensions update

[James Yonan]

I've updated the OpenVPN protocol extension doc with additional details, 
now that more of these features have been implemented in OpenVPN 3.


If you are implementing any of these features in OpenVPN 2.x, please 
review so we can ensure that OpenVPN 2.x and 3 are on the same page with 
respect to protocol extensions.


Changes:

1. Added specific details on DATA_V2/peer-id/float support.

2. For AEAD mode, emphasized that the leading 8 bytes (4 bytes for 
DATA_V2/peer-id and 4 for packet ID) is all included in the AD.


3. Added specific details on protocol negotiation where the client 
indicates protocol extension availability with IV_x parameters in the 
peer info string, and the server responds by pushing directives to the 
client to enable the feature.


4. Added "TCP nonlinear mode" section, a new protocol extension that is 
needed by multithreaded TCP servers.


James
OpenVPN Protocol extensions
2015-01-06

1. DATA_V2 opcode with 24-bit peer ID

   * The DATA_V2 opcode is 9.
   * The DATA_V2 opcode/key_id byte is followed by 3 additional
 (network endian) bytes indicating the peer ID.
   * If a 4-byte DATA_V2 header is passed through ntohl,
 the resulting high 8 bits will be the DATA_V2 opcode/key_id,
 and the lower 24 bits will be the peer ID.
   * A disabled peer ID is denoted by 0xFF.
   * Server tells the client to use DATA_V2/peer_id by pushing
 the directive "peer-id ID" where ID is a decimal integer
 in the range [-1, 16777215].  Setting the peer ID to -1
 transmits DATA_V2 packets with the peer ID field set to
 0xFF.  Setting the peer_id to -1 is the same as
 setting it to 16777215 (i.e. 0xFF).
   * Client never transmits DATA_V2 packets unless the server
 has pushed a "peer-id" directive.
   * Server never pushes a "peer-id" directive unless the
 client has indicated its support for DATA_V2 by
 including "IV_PROTO=2" in the peer info data.
   * When DATA_V2 is used for "float" functionality, the server
 must perform the following checks before allowing
 a client to float, i.e. to assume a new source address.
 (a) verify integrity (HMAC or GCM auth tag, replay
 protection, etc.) of the DATA_V2 packet, and
 (b) ensure that the float doesn't clobber a pre-existing
 client (i.e. if the address floated to is already
 owned by another client) unless it can be verified
 that the pre-existing client is a previous instance
 of the floating client.

2. AEAD mode

   To support AEAD crypto modes such as AES-GCM, some protocol
   changes are in order.  AES-GCM, for example, requires a 12
   byte unique nonce for every packet.  I would propose that 4
   bytes be taken from the Packet ID which increments for every
   packet and therefore provides uniqueness.  The remaining 8
   bytes would be derived from the random key material that would
   normally be used to key the HMAC key.  This is possible since
   AEAD modes use a combined key for encryption and integrity
   checking, therefore the random key material for HMAC is
   unused and can be repurposed as an AEAD nonce source.  The 8
   byte nonce component derived from the HMAC keying material
   would remain constant for a given Key State.  Only the 4 byte
   Packet ID would increment for each packet.  Because AEAD
   encryption can be compromised if the nonce ever repeats for
   a given key, the implementation MUST disable encryption
   for a key if the 32-bit packet ID wraps.  In practical usage,
   renegotiation usually preempts wrapping, so the
   disable-encryption-on-wrap feature is a failsafe.

   AEAD Nonce:

 [ Packet ID ] [ HMAC keying material ]
 [ 4 bytes   ] [ 8 bytes  ]
 [ AEAD nonce total: 12 bytes ]

   TLS wire protocol:

 [ DATA_V2 opcode ] [ Packet ID ] [ AEAD Auth tag ] [ ciphertext ]
 [ 4 bytes] [ 4 bytes   ] [ 16 bytes  ]
 [ AEAD additional data (AD)]

   Static Key wire protocol:

 [ DATA_V2 opcode ] [ Packet ID ] [ Nonce tail (random) ]  [ AEAD Auth tag 
] [ ciphertext ]
[   AEAD nonce  ]
 [ 4 bytes] [ 8 bytes   ] [ 4 bytes ]  [ 16 bytes  ]
 [ AEAD additional data (AD)]

   Note that the AEAD additional data (AD) includes all data
   preceding the AEAD Auth tag including the DATA_V2/peer_id
   opcode and packet ID.

   Also, note that because the HMAC keying material used to derive
   the last 8 bytes of the AEAD nonce is negotiated once per key
   as part of the control channel handshake, we can omit it from the
   data channel packets, thereby saving 8 bytes per packet.  So
   only the 4-byte Packet ID component of the nonce must be
   transmitted with every packet.

   When negotiating AEAD mode, the client indicates its support
   of AES-128-GCM, AES-192-GCM, and AES-192-GCM by including:

 IV_NCP=2

   in the peer info string (NCP stands for 

[Openvpn-devel] OpenVPN Protocol extensions

[James Yonan]

In addition to the Peer-ID/DATA_V2 protocol change proposal,
here are a couple more proposed extensions for AEAD mode and
Compression V2 that we can discuss at the upcoming Munich
hackathon.

James
OpenVPN Protocol extensions

1. DATA_V2 opcode with 24-bit peer ID

2. AEAD mode

   To support AEAD crypto modes such as AES-GCM, some protocol
   changes are in order.  AES-GCM, for example, requires a 12
   byte unique nonce for every packet.  I would propose that 4
   bytes be taken from the Packet ID which increments for every
   packet and therefore provides uniqueness.  The remaining 8
   bytes would be derived from the random key material that would
   normally be used to key the HMAC key.  This is possible since
   AEAD modes use a combined key for encryption and integrity
   checking, therefore the random key material for HMAC is
   unused and can be repurposed as an AEAD nonce source.  The 8
   byte nonce component derived from the HMAC keying material
   would remain constant for a given Key State.  Only the 4 byte
   Packet ID would increment for each packet.  Because AEAD
   encryption can be compromised if the nonce ever repeats for
   a given key, the implementation MUST disable encryption
   for a key if the 32-bit packet ID wraps.  In practical usage,
   renegotiation usually preempts wrapping, so the
   disable-encryption-on-wrap feature is a failsafe.

   AEAD Nonce:

 [ Packet ID ] [ HMAC keying material ]
 [ 4 bytes   ] [ 8 bytes  ]
 [ AEAD nonce total: 12 bytes ]

   TLS wire protocol:

 [ DATA_V2 opcode ] [ Packet ID ] [ AEAD Auth tag ] [ ciphertext ]
 [ 4 bytes] [ 4 bytes   ] [ 16 bytes  ]

   Static Key wire protocol:

 [ DATA_V2 opcode ] [ Packet ID ] [ Nonce tail (random) ]  [ AEAD Auth tag 
] [ ciphertext ]
[   AEAD nonce  ]
 [ 4 bytes] [ 8 bytes   ] [ 4 bytes ]  [ 16 bytes  ]

   Note that because the HMAC keying material used to derive the
   last 8 bytes of the AEAD nonce is negotiated once per key
   as part of the control channel handshake, we can omit it from the
   data channel packets, thereby saving 8 bytes per packet.  So
   only the 4-byte Packet ID component of the nonce must be
   transmitted with every packet.

   Also note that that the TLS wire protocol overhead is only 24
   bytes, including the new 4 byte DATA_V2 opcode that includes
   the Peer ID!  Compare that with traditional AES-CBC mode and
   DATA_V1 opcode: 1 (DATA_V1 opcode) + 20 (HMAC-SHA1 hash)
   + 8 (IV) + 4 (Packet ID) + 1-8 (PKCS#7 padding) = 34-41 bytes.

3. Compression V2

   I have observed that compression in many cases, even when
   enabled, often does not produce packet size reduction
   because much of the packet data typically generated by web
   sessions is already compressed.  Further, the single byte that
   precedes the packet and indicates whether or not compression
   occurred has the unfortunate side effect of misaligning the IP
   packet in cases where compression did not occur.  To remedy this,
   I propose a Compression V2 header that is optimized for the
   case where compression does not occur.

   a. No compression occurred and first byte of IP/Ethernet packet
  is NOT 0x50 (0 bytes of overhead and maintains alignment):

[ uncompressed IP/Ethernet packet ]

   b. No compression occurred and first byte of IP/Ethernet packet
  is 0x50 (2 bytes of overhead but unlikely since no known
  IP packet can begin with 0x50):

[ 0x50 ] [ 0x00 ] [ uncompressed IP/Ethernet packet ]

   c. Compression occurred (2 bytes of overhead):

[ 0x50 ] [ compression Alg ID ] [ compressed IP/Ethernet packet ]

  Compression Alg ID is one-byte algorithm identifier
  for LZ4 (0x1), LZO (0x2), or Snappy (0x3).

   This approach has several beneficial effects:

   1. In the common case where compression does not occur, no
  compression op is required, therefore there is zero overhead.

   2. When compression does not occur, the IP/Ethernet packet
  alignment is retained.

   3. This technique does not require any byte swapping with
  the tail of the packet which can potentially incur an
  expensive cache miss.

[Openvpn-devel] [PATCH 6/6] Fixed some compile issues with show_library_versions()

[James Yonan]

* Refactored show_library_versions to work around the fact
  that some compilers (such as MSVC 2008) can't handle #ifdefs
  inside of macro references.

* Declare show_library_versions() in options.h because it's
  referenced by other files such as openvpn.c.

* Declare get_ssl_library_version() as returning const char *,
  to avoid loss of const qualifier in ssl_openssl.c.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/options.c  | 15 +--
 src/openvpn/options.h  |  2 ++
 src/openvpn/ssl_backend.h  |  2 +-
 src/openvpn/ssl_openssl.c  |  2 +-
 src/openvpn/ssl_polarssl.c |  2 +-
 5 files changed, 14 insertions(+), 9 deletions(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 59d7895..8406822 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -3439,18 +3439,21 @@ usage_small (void)
 void
 show_library_versions(const unsigned int flags)
 {
-  msg (flags, "library versions: %s%s%s",
 #ifdef ENABLE_SSL
-   get_ssl_library_version(),
+#define SSL_LIB_VER_STR get_ssl_library_version()
 #else
-   "",
+#define SSL_LIB_VER_STR ""
 #endif
 #ifdef ENABLE_LZO
-   ", LZO ", lzo_version_string()
+#define LZO_LIB_VER_STR ", LZO ", lzo_version_string()
 #else
-   "", ""
+#define LZO_LIB_VER_STR "", ""
 #endif
-   );
+
+  msg (flags, "library versions: %s%s%s", SSL_LIB_VER_STR, LZO_LIB_VER_STR);
+
+#undef SSL_LIB_VER_STR
+#undef LZO_LIB_VER_STR
 }

 static void
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index c6378d8..7bb61e0 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -685,6 +685,8 @@ void notnull (const char *arg, const char *description);

 void usage_small (void);

+void show_library_versions(const unsigned int flags);
+
 void init_options (struct options *o, const bool init_gc);
 void uninit_options (struct options *o);

diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index b37b1e5..fc23175 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -472,6 +472,6 @@ void get_highest_preference_tls_cipher (char *buf, int 
size);
  * return a pointer to a static memory area containing the
  * name and version number of the SSL library in use
  */
-char * get_ssl_library_version(void);
+const char * get_ssl_library_version(void);

 #endif /* SSL_BACKEND_H_ */
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index d845fd7..e77b736 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -1354,7 +1354,7 @@ get_highest_preference_tls_cipher (char *buf, int size)
   SSL_CTX_free (ctx);
 }

-char *
+const char *
 get_ssl_library_version(void)
 {
 return SSLeay_version(SSLEAY_VERSION);
diff --git a/src/openvpn/ssl_polarssl.c b/src/openvpn/ssl_polarssl.c
index 0dfffd6..e3e3017 100644
--- a/src/openvpn/ssl_polarssl.c
+++ b/src/openvpn/ssl_polarssl.c
@@ -1068,7 +1068,7 @@ get_highest_preference_tls_cipher (char *buf, int size)
   strncpynt (buf, cipher_name, size);
 }

-char *
+const char *
 get_ssl_library_version(void)
 {
 static char polar_version[30];
-- 
1.8.5.5

[Openvpn-devel] [PATCH 5/6] Define PATH_SEPARATOR for MSVC builds.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 config-msvc.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/config-msvc.h b/config-msvc.h
index 9a95ae6..fa99384 100644
--- a/config-msvc.h
+++ b/config-msvc.h
@@ -76,6 +76,9 @@

 #define HAVE_OPENSSL_ENGINE 1

+#define PATH_SEPARATOR '\\'
+#define PATH_SEPARATOR_STR "\\"
+
 #ifndef __cplusplus
 #define inline __inline
 #endif
-- 
1.8.5.5

[Openvpn-devel] [PATCH 4/6] MSVC 2008 doesn't support dimensioning an array with a const var nor using %z as a printf format specifier.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_openssl.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 481600a..d845fd7 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -261,8 +261,7 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const 
char *ciphers)

   const tls_cipher_name_pair *cipher_pair;

-  const size_t openssl_ciphers_size = 4096;
-  char openssl_ciphers[openssl_ciphers_size];
+  char openssl_ciphers[4096];
   size_t openssl_ciphers_len = 0;
   openssl_ciphers[0] = '\0';

@@ -301,8 +300,8 @@ tls_ctx_restrict_ciphers(struct tls_root_ctx *ctx, const 
char *ciphers)
}

   // Make sure new cipher name fits in cipher string
-  if (((openssl_ciphers_size-1) - openssl_ciphers_len) < 
current_cipher_len) {
-   msg(M_SSLERR, "Failed to set restricted TLS cipher list, too long 
(>%zu).", openssl_ciphers_size-1);
+  if (((sizeof(openssl_ciphers)-1) - openssl_ciphers_len) < 
current_cipher_len) {
+   msg(M_SSLERR, "Failed to set restricted TLS cipher list, too long 
(>%d).", (int)sizeof(openssl_ciphers)-1);
   }

   // Concatenate cipher name to OpenSSL cipher string
-- 
1.8.5.5

[Openvpn-devel] [PATCH 3/6] Explicitly cast the third parameter of setsockopt to const void * to avoid warning.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/socket.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/openvpn/socket.h b/src/openvpn/socket.h
index 4e7e7f8..793cd9f 100644
--- a/src/openvpn/socket.h
+++ b/src/openvpn/socket.h
@@ -1023,7 +1023,7 @@ static inline void
 link_socket_set_tos (struct link_socket *ls)
 {
   if (ls && ls->ptos_defined)
-setsockopt (ls->sd, IPPROTO_IP, IP_TOS, >ptos, sizeof (ls->ptos));
+setsockopt (ls->sd, IPPROTO_IP, IP_TOS, (const void *)>ptos, sizeof 
(ls->ptos));
 }

 #endif
-- 
1.8.5.5

[Openvpn-devel] [PATCH 2/6] In socket.c, fixed issue where uninitialized value (err) is being passed to to gai_strerror.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/socket.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 7ff14cc..6e68c18 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1150,7 +1150,6 @@ resolve_bind_local (struct link_socket *sock)
case AF_INET6:
{
  int status;
- int err;
  CLEAR(sock->info.lsa->local.addr.in6);
  if (sock->local_host)
{
@@ -1173,7 +1172,7 @@ resolve_bind_local (struct link_socket *sock)
{
  msg (M_FATAL, "getaddr6() failed for local \"%s\": %s",
   sock->local_host,
-  gai_strerror(err));
+  gai_strerror(status));
}
  sock->info.lsa->local.addr.in6.sin6_port = htons 
(sock->local_port);
}
-- 
1.8.5.5

[Openvpn-devel] [PATCH 1/6] Fixed several instances of declarations after statements.

[James Yonan]

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/init.c   | 10 ++
 src/openvpn/socket.c |  2 +-
 src/openvpn/win32.c  |  6 +++---
 3 files changed, 10 insertions(+), 8 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index 52d370b..3fb 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -183,10 +183,12 @@ ce_management_query_proxy (struct context *c)
   if (management)
 {
   gc = gc_new ();
-  struct buffer out = alloc_buf_gc (256, );
-  buf_printf (, ">PROXY:%u,%s,%s", (l ? l->current : 0) + 1,
-  (proto_is_udp (ce->proto) ? "UDP" : "TCP"), np (ce->remote));
-  management_notify_generic (management, BSTR ());
+  {
+   struct buffer out = alloc_buf_gc (256, );
+   buf_printf (, ">PROXY:%u,%s,%s", (l ? l->current : 0) + 1,
+   (proto_is_udp (ce->proto) ? "UDP" : "TCP"), np 
(ce->remote));
+   management_notify_generic (management, BSTR ());
+  }
   ce->flags |= CE_MAN_QUERY_PROXY;
   while (ce->flags & CE_MAN_QUERY_PROXY)
 {
diff --git a/src/openvpn/socket.c b/src/openvpn/socket.c
index 23566f1..7ff14cc 100644
--- a/src/openvpn/socket.c
+++ b/src/openvpn/socket.c
@@ -1227,6 +1227,7 @@ resolve_remote (struct link_socket *sock,
  unsigned int flags = 
sf2gaf(GETADDR_RESOLVE|GETADDR_UPDATE_MANAGEMENT_STATE, sock->sockflags);
  int retry = 0;
  int status = -1;
+ struct addrinfo* ai;

  if (sock->connection_profiles_defined && 
sock->resolve_retry_seconds == RESOLV_RETRY_INFINITE)
{
@@ -1263,7 +1264,6 @@ resolve_remote (struct link_socket *sock,
  ASSERT (0);
}

- struct addrinfo* ai;
  /* Temporary fix, this need to be changed for dual stack */
  status = openvpn_getaddrinfo(flags, sock->remote_host, retry,

  signal_received, af, );
diff --git a/src/openvpn/win32.c b/src/openvpn/win32.c
index 13fd881..f35c96b 100644
--- a/src/openvpn/win32.c
+++ b/src/openvpn/win32.c
@@ -870,6 +870,9 @@ openvpn_execve (const struct argv *a, const struct env_set 
*es, const unsigned i
   WCHAR *cl = wide_cmd_line (a, );
   WCHAR *cmd = wide_string (a->argv[0], );

+  /* this allows console programs to run, and is ignored otherwise */
+  DWORD proc_flags = CREATE_NO_WINDOW;
+
   CLEAR (start_info);
   CLEAR (proc_info);

@@ -879,9 +882,6 @@ openvpn_execve (const struct argv *a, const struct env_set 
*es, const unsigned i
   start_info.dwFlags = STARTF_USESHOWWINDOW;
   start_info.wShowWindow = SW_HIDE;

-  /* this allows console programs to run, and is ignored otherwise */
-  DWORD proc_flags = CREATE_NO_WINDOW;
-
   if (CreateProcessW (cmd, cl, NULL, NULL, FALSE, proc_flags, env, 
NULL, _info, _info))
 {
   DWORD exit_status = 0;
-- 
1.8.5.5

[Openvpn-devel] MSVC Fixes for 2.3

[James Yonan]

This series of patches is for the 2.3 branch and fixes MSVC compile issues.
Some of these may be applicable to master as well, though I haven't checked yet.

James

Re: [Openvpn-devel] [PATCH 4/4] When tls-version-min is unspecified, revert to original versioning approach.

[James Yonan]

On 28/04/2014 15:19, Steffan Karger wrote:

Hi,

On 27-04-14 22:10, Steffan Karger wrote:

On 27-04-14 19:53, Gert Doering wrote:

On Mon, Apr 21, 2014 at 01:10:04AM -0600, James Yonan wrote: The
attached patch is what I intend to commit to release/2.3 *only*,
not to master - as agreed at the IRC meeting.  "Please ACK" :-)


Sorry, but NAK.


On a more constructive note: attached a new proposal for this patch.


The OpenSSL bits look fine


On a closer look, the wrapping "if (tls_version_min > TLS_VER_UNSPEC)"
in tls_ctx_set_options() seems redundant, because TLS_VER_UNSPEC <
TLS_VER_1_0 < TLS_VER_1_1 < TLS_VER_1_2 and the ifs are checking for
"tls_version_min > TLS_VER_1_x". I've removed these changes in the
attached patch proposal.


the PolarSSL bits
would also allow for SSL_MINOR_VERSION_0, which is SSLv3 and thus a
reduction in security (and actually increases the handshake complexity).


To elaborate a bit: The naming is a bit confusing, but
SSL_MAJOR_VERSION_3 + SSL_MINOR_VERSION_O means SSLv3, ... +
SSL_MINOR_VERSION_1 means TLSv1.0, ... + SSL_MINOR_VERSION_2 means
TLSv1.1, etc. If none are given (what would happen in the previous
version of the patch), PolarSSL defaults the minimum version to SSLv3
and maximum to TLSv1.2. The attached patch thus removes the wrapping "if
(tls_version_min > TLS_VER_UNSPEC)" and sets the default to TLSv1.0 to
TLSv1.2 again. That is equal to the behaviour prior to the TLS
versioning patch.

-Steffan


This is fine.  I can ACK this.

Thanks,
James

Re: [Openvpn-devel] Progress on Version negotiation

[James Yonan]

On 23/04/2014 18:22, Timothe Litt wrote:

I don't see that cryptoapi.c has been updated to work with TLS 1.2.

Yes, just came to the same conclusion.

Long-term the key-loaders need to get updated.

Maybe short-term the options that invoke them could force NO_TLSv_1_2...

That would make things work for most people in the short term.


One option would be to have a tls-version-max, but I'm wondering if this 
might be overkill.


It would also force people to add "tls-version-max 1.0" to their configs 
to go back to the original 2.3 behavior.


My preferred solution is to simply turn off tls-version-min if it's not 
specified in the config, and use the 2.3 behavior.  That basically 
forces TLS 1.0.


I've seen a lot more breakage than just this... I believe the first 
significant real-world exposure was the iOS 1.0.2 and 1.0.3 releases 
from several months ago.  There were hundreds of reports of breakage, 
mostly from countries behind government firewalls.  This was using 
OpenVPN 3 with PolarSSL, so the issue seems to occur with different 
OpenVPN and SSL implementations.


James

Re: [Openvpn-devel] Progress on Version negotiation

[James Yonan]

On 23/04/2014 17:21, Timothe Litt wrote:

On 23-Apr-14 16:06, Steffan Karger wrote:

I generated a matching pair of traces of the failure (client and server)
& posted a summary.

Let me know if you would like the full traces.

Sent off-list.


I've been trying to reproduce the error. I grabbed my spare pi from the
desk drawer and built 2.3.3 from sources like you describe in #385. I
fired up a Windows 8.1 VM, and installed OpenVPN 2.3.3-I002 (x64). This
setup however happily connects with TLSv1.2. It's hard to get a hold on
this one...

My windows client is XP, 32-bit.  It's a physical machine (old notebook).

Although the problem first surfaced on 2.3.3, I'm now running off
git-master (of a few days back).  How I did that is in #385 too.

For those on the list:

With a hint from Steffan,

I have established that the client certificate is not being sent.  I
believe this is a client issue.

It appears that including the cert/key in the conf file, rather than
from the crypto API makes 1.2 work.

We suspect there's some issue due to 1.2's larger hashes/message size.
Not clear whether the cryptoapi interface is the cause or a victim.

As I can't build the windows client (it's really annoying that it
requires commercial tools), further debug will need help from folks who
can.

As always, let me know if I can do anything more to help.


I don't see that cryptoapi.c has been updated to work with TLS 1.2. 
Note the comment in rsa_priv_enc that says "For now, we only support 
NID_md5_sha1".  But TLS 1.2 appears to require the support of additional 
hash algorithms.


See section 4.7. "Cryptographic Attributes" in TLS 1.2 RFC.

Note that the signature algorithm is now specified along with the signature:

  struct {
 SignatureAndHashAlgorithm algorithm;
 opaque signature<0..2^16-1>;
  } DigitallySigned;

So it would appear that any client-side private key offloading (such as 
Crypto API, PKCS#11, OS-level KeyChains, etc. would need to be aware of 
this feature so as to take into account the hash algorithm.


James

Re: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

On 23/04/2014 04:17, Arne Schwabe wrote:

Am 21.04.14 21:26, schrieb James Yonan:

On 21/04/2014 05:27, Arne Schwabe wrote:

On 21.04.2014 09:10, James Yonan wrote:

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.


I haven't look at the code but if remember  correctly, this method does
not get passed the actual flags but the flags should *potientially* be
checked.


Yes, the point is to aggregate the potential flags of interest to
process_ip_header under a single mask, i.e. PIP_OPT_MASK.

So instead of having "if (flags & (PIPV4_PASSTOS|PIP_MSSFIX|...|...))"
you just have "if (flags & PIP_OPT_MASK)".

The main issue for us is that we have an internal patch for one of our
services that adds an additional flag, and the previous usage is a
merge conflict attractor because all the flags of interest are
explicitly given on a single line.


I only wanted to point out my patch also exits. I looked at the code again.

I think to really get rid of the #ifdef here we also need to
unconditionally enable the other &= ~ statements:

Change

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
 flags &= ~PIPV4_PASSTOS;
#endif

to

#if PASSTOS_CAPABILITY
   if (!c->options.passtos)
#endif
 flags &= ~PIPV4_PASSTOS;


Otherwise if the function is called with PIPV4_PASSTOS but not compiled
with PASSTOS_CAPABILITY the

flags & PIP_OPT_MASK will be always true.

Arne


Sure, that makes sense.

James

Re: [Openvpn-devel] [PATCH 1/4] Added "remote-override" config directive.

[James Yonan]

On 21/04/2014 05:33, Arne Schwabe wrote:

On 21.04.2014 09:10, James Yonan wrote:

remote-override  -- replace the hostname in all remote
directives with alt-remote.


Just a question. How does remote-override differ from ip-remote-hint?
Both options seem to have the same effect aside from very subtle
differences. Perhaps we should add this as an alias for the already
existing option.


They are different options.

ip-remote-hint is used when the app driving the client via management 
interface has already done a DNS lookup on the remote address, and wants 
to save the OpenVPN core from having to do a redundant lookup.


remote-override is used when the client UI has an option that allows the 
end user to override the default server address.  For example a UI might 
give the user a drop-down list of regions to connect to.  Since it is 
common in OpenVPN configs to have a list of many "remote" directives for 
failover, we needed a directive that would do a "search/replace" on the 
hostname component of each "remote" item.


That's different from the approach of ip-remote-hint which is designed 
to only provide a DNS resolution hint for the first "remote" item.


James

Re: [Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

On 21/04/2014 05:27, Arne Schwabe wrote:

On 21.04.2014 09:10, James Yonan wrote:

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.


I haven't look at the code but if remember  correctly, this method does
not get passed the actual flags but the flags should *potientially* be
checked.


Yes, the point is to aggregate the potential flags of interest to 
process_ip_header under a single mask, i.e. PIP_OPT_MASK.


So instead of having "if (flags & (PIPV4_PASSTOS|PIP_MSSFIX|...|...))" 
you just have "if (flags & PIP_OPT_MASK)".


The main issue for us is that we have an internal patch for one of our 
services that adds an additional flag, and the previous usage is a merge 
conflict attractor because all the flags of interest are explicitly 
given on a single line.



See also my never reviewed patch:
http://thread.gmane.org/gmane.network.openvpn.devel/7532


Your patch would be simplified with this approach because you don't need 
to add the test for PIPV4_CLIENT_NAT to "if (flags & ...)".


James

Re: [Openvpn-devel] [PATCH 4/4] When tls-version-min is unspecified, revert to original versioning approach.

[James Yonan]

On 21/04/2014 05:49, Gert Doering wrote:

Hi,

On Mon, Apr 21, 2014 at 01:11:05PM +0200, Arne Schwabe wrote:

Yes. But with this patch it is always turned off, keeping OpenVPN in 99%
of installations in TLS 1.0. Is there any other known case where it
breaks aside from the Tomato OpenVPN client?


http://community.openvpn.net/openvpn/ticket/385

this is the only case I know - and I blaim the openssl library on the
server side (ARM).  So for me, "default-on with a way to turn it off" would
be sufficient.  But I assume James has much more visibility...


The problem with tls-version-min is that it defaults to 1.0 even if not 
used.  We've received many reports of breakage with this approach, 
probably because setting the min to 1.0 is actually subtly different 
from the approach used before tls-version-min was implemented.


So this patch turns off tls-version-min unless it's explicit in the config.

James

Re: [Openvpn-devel] [PATCH] PolarSSL 1.3

[James Yonan]

On 19/04/2014 08:33, Steffan Karger wrote:

Hi,

On 04/18/2014 02:49 PM, Steffan Karger wrote:

On 04/17/2014 09:41 PM, James Yonan wrote:

I'm not sure I understand the (SIZE_MAX - hashlen) > asn_len part.
Wouldn't this always be true for reasonable values of hashlen and asn_len?


This should indeed always be true for reasonable input.


Ouch, James was totally right. This would always be true, but should
always be *false* for reasonable input; the check has to be the other
way around. Attached the same two patches, except for that single
character...

On the positive side: I've added my management-external-key test to my
vanilla-openvpn tests too, so I should catch regressions more easily now.


ACK for the revised patches (0001-Upgrade-to-PolarSSL-1.3.patch and 
0002-Improve-error-reporting-during-key-cert-loading-with.patch).


James

[Openvpn-devel] [PATCH 4/4] When tls-version-min is unspecified, revert to original versioning approach.

[James Yonan]

For OpenSSL, this means to use TLSv1_(client|server)_method rather
than SSLv23_(client|server)_method combined with SSL_OP_NO_x flags
for specific TLS versions to disable.

For PolarSSL, this means to avoid calling ssl_set_min_version and
instead implicitly control the TLS version via allowed ciphersuites.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl.c  |  4 ++--
 src/openvpn/ssl_backend.h  | 15 +--
 src/openvpn/ssl_openssl.c  | 31 ++-
 src/openvpn/ssl_polarssl.c | 43 +++
 4 files changed, 56 insertions(+), 37 deletions(-)

diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index b09e52b..af30641 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -486,12 +486,12 @@ init_ssl (const struct options *options, struct 
tls_root_ctx *new_ctx)

   if (options->tls_server)
 {
-  tls_ctx_server_new(new_ctx);
+  tls_ctx_server_new(new_ctx, options->ssl_flags);
   tls_ctx_load_dh_params(new_ctx, options->dh_file, 
options->dh_file_inline);
 }
   else /* if client */
 {
-  tls_ctx_client_new(new_ctx);
+  tls_ctx_client_new(new_ctx, options->ssl_flags);
 }

   tls_ctx_set_options(new_ctx, options->ssl_flags);
diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index 57b03df..0b41ff2 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -109,10 +109,11 @@ void tls_clear_error();
  * @return One of the TLS_VER_x constants or TLS_VER_BAD
  *  if a parse error should be flagged.
  */
-#define TLS_VER_BAD   -1
-#define TLS_VER_1_00 /* default */
-#define TLS_VER_1_11
-#define TLS_VER_1_22
+#define TLS_VER_BAD-1
+#define TLS_VER_UNSPEC  0
+#define TLS_VER_1_0 1 /* default */
+#define TLS_VER_1_1 2
+#define TLS_VER_1_2 3
 int tls_version_min_parse(const char *vstr, const char *extra);

 /**
@@ -127,15 +128,17 @@ int tls_version_max(void);
  * Initialise a library-specific TLS context for a server.
  *
  * @param ctx  TLS context to initialise
+ * @param ssl_flags SSLF_x flags from ssl_common.h
  */
-void tls_ctx_server_new(struct tls_root_ctx *ctx);
+void tls_ctx_server_new(struct tls_root_ctx *ctx, unsigned int ssl_flags);

 /**
  * Initialises a library-specific TLS context for a client.
  *
  * @param ctx  TLS context to initialise
+ * @param ssl_flags SSLF_x flags from ssl_common.h
  */
-void tls_ctx_client_new(struct tls_root_ctx *ctx);
+void tls_ctx_client_new(struct tls_root_ctx *ctx, unsigned int ssl_flags);

 /**
  * Frees the library-specific TLSv1 context
diff --git a/src/openvpn/ssl_openssl.c b/src/openvpn/ssl_openssl.c
index 1923230..abf39ac 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -94,22 +94,32 @@ tls_clear_error()
 }

 void
-tls_ctx_server_new(struct tls_root_ctx *ctx)
+tls_ctx_server_new(struct tls_root_ctx *ctx, unsigned int ssl_flags)
 {
+  const int tls_version_min = (ssl_flags >> SSLF_TLS_VERSION_SHIFT) & 
SSLF_TLS_VERSION_MASK;
+
   ASSERT(NULL != ctx);

-  ctx->ctx = SSL_CTX_new (SSLv23_server_method ());
+  if (tls_version_min > TLS_VER_UNSPEC)
+ctx->ctx = SSL_CTX_new (SSLv23_server_method ());
+  else
+ctx->ctx = SSL_CTX_new (TLSv1_server_method ());

   if (ctx->ctx == NULL)
 msg (M_SSLERR, "SSL_CTX_new SSLv23_server_method");
 }

 void
-tls_ctx_client_new(struct tls_root_ctx *ctx)
+tls_ctx_client_new(struct tls_root_ctx *ctx, unsigned int ssl_flags)
 {
+  const int tls_version_min = (ssl_flags >> SSLF_TLS_VERSION_SHIFT) & 
SSLF_TLS_VERSION_MASK;
+
   ASSERT(NULL != ctx);

-  ctx->ctx = SSL_CTX_new (SSLv23_client_method ());
+  if (tls_version_min > TLS_VER_UNSPEC)
+ctx->ctx = SSL_CTX_new (SSLv23_client_method ());
+  else
+ctx->ctx = SSL_CTX_new (TLSv1_client_method ());

   if (ctx->ctx == NULL)
 msg (M_SSLERR, "SSL_CTX_new SSLv23_client_method");
@@ -182,16 +192,19 @@ tls_ctx_set_options (struct tls_root_ctx *ctx, unsigned 
int ssl_flags)
   {
 long sslopt = SSL_OP_SINGLE_DH_USE | SSL_OP_NO_TICKET | SSL_OP_NO_SSLv2 | 
SSL_OP_NO_SSLv3;
 const int tls_version_min = (ssl_flags >> SSLF_TLS_VERSION_SHIFT) & 
SSLF_TLS_VERSION_MASK;
-if (tls_version_min > TLS_VER_1_0)
-  sslopt |= SSL_OP_NO_TLSv1;
+if (tls_version_min > TLS_VER_UNSPEC)
+  {
+   if (tls_version_min > TLS_VER_1_0)
+ sslopt |= SSL_OP_NO_TLSv1;
 #ifdef SSL_OP_NO_TLSv1_1
-if (tls_version_min > TLS_VER_1_1)
-  sslopt |= SSL_OP_NO_TLSv1_1;
+   if (tls_version_min > TLS_VER_1_1)
+ sslopt |= SSL_OP_NO_TLSv1_1;
 #endif
 #ifdef SSL_OP_NO_TLSv1_2
 if (tls_version_min > TLS_VER_1_2)
-  sslopt |= SSL_OP_NO_TLSv1_2;
+   sslopt |= SSL_OP_NO_TLSv1_2;
 #endif
+  }
 SSL_CTX_set_options (ctx->ctx, sslopt

[Openvpn-devel] [PATCH 3/4] Use native strtoull() with MSVC 2013.

[James Yonan]

MSVC 2013 C library now defines strtoull() function,
so use the native implementation when available.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 config-msvc.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/config-msvc.h b/config-msvc.h
index 99c00f9..9a95ae6 100644
--- a/config-msvc.h
+++ b/config-msvc.h
@@ -89,7 +89,10 @@
 #define strncasecmp strnicmp
 #define strcasecmp _stricmp
 #define snprintf _snprintf
+
+#if _MSC_VER < 1800
 #define strtoull strtoul
+#endif

 #define in_addr_t uint32_t
 #define ssize_t SSIZE_T
-- 
1.8.5.5

[Openvpn-devel] [PATCH 2/4] Added PIP_OPT_MASK for process_ip_header fast exit path.

[James Yonan]

Define PIP_OPT_MASK to represent all flags of interest to
process_ip_header, so that it can have a fast exit path
if no flags are set.

Merged from OpenVPN 2.1

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/forward.c | 6 +-
 src/openvpn/forward.h | 4 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/src/openvpn/forward.c b/src/openvpn/forward.c
index 0ec00f3..fbc58c7 100644
--- a/src/openvpn/forward.c
+++ b/src/openvpn/forward.c
@@ -1026,11 +1026,7 @@ process_ip_header (struct context *c, unsigned int 
flags, struct buffer *buf)
* The --passtos and --mssfix options require
* us to examine the IPv4 header.
*/
-#if PASSTOS_CAPABILITY
-  if (flags & (PIPV4_PASSTOS|PIP_MSSFIX))
-#else
-  if (flags & PIP_MSSFIX)
-#endif
+  if (flags & PIP_OPT_MASK)
{
  struct buffer ipbuf = *buf;
  if (is_ipv4 (TUNNEL_TYPE (c->c1.tuntap), ))
diff --git a/src/openvpn/forward.h b/src/openvpn/forward.h
index 1830a00..0ece01e 100644
--- a/src/openvpn/forward.h
+++ b/src/openvpn/forward.h
@@ -229,9 +229,11 @@ bool send_control_channel_string (struct context *c, const 
char *str, int msglev

 #define PIPV4_PASSTOS (1<<0)
 #define PIP_MSSFIX(1<<1) /* v4 and v6 */
-#define PIPV4_OUTGOING(1<<2)
 #define PIPV4_EXTRACT_DHCP_ROUTER (1<<3)
 #define PIPV4_CLIENT_NAT  (1<<4)
+#define PIP_OPT_MASK  0x /* all possible options for */
+ /* process_ip_header() */
+#define PIPV4_OUTGOING(1<<16)

 void process_ip_header (struct context *c, unsigned int flags, struct buffer 
*buf);

-- 
1.8.5.5

[Openvpn-devel] [PATCH 1/4] Added "remote-override" config directive.

[James Yonan]

remote-override  -- replace the hostname in all remote
directives with alt-remote.

Merged from OpenVPN 2.1

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/options.c | 7 ++-
 src/openvpn/options.h | 2 ++
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 4af2974..1739460 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -4512,6 +4512,11 @@ add_option (struct options *options,
goto err;
 }
 #endif
+  else if (streq (p[0], "remote-override") && p[1])
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->remote_override = p[1];
+}
   else if (streq (p[0], "remote") && p[1])
 {
   struct remote_entry re;
@@ -4520,7 +4525,7 @@ add_option (struct options *options,
   re.af=0;

   VERIFY_PERMISSION (OPT_P_GENERAL|OPT_P_CONNECTION);
-  re.remote = p[1];
+  re.remote = options->remote_override ? options->remote_override : p[1];
   if (p[2])
{
  re.remote_port = p[2];
diff --git a/src/openvpn/options.h b/src/openvpn/options.h
index ec1d091..1775c02 100644
--- a/src/openvpn/options.h
+++ b/src/openvpn/options.h
@@ -222,6 +222,8 @@ struct options

   struct remote_host_store *rh_store;

+  const char *remote_override;
+
   bool remote_random;
   const char *ipchange;
   const char *dev;
-- 
1.8.5.5

[Openvpn-devel] x509-track for PolarSSL

[James Yonan]

Just wondering if anyone has looked at implementing x509-track for PolarSSL?

James

Re: [Openvpn-devel] [PATCH] PolarSSL 1.3

[James Yonan]

On 27/02/2014 12:40, steffan.kar...@fox-it.com wrote:

Hi,

The attached patches add support for PolarSSL 1.3. These patches are for
master only, as they drop support for PolarSSL 1.2. Supporting both versions
would require a lot of #ifdef's, so I opted for dropping 1.2.

Along with PolarSSL 1.3 comes support for AES-NI and elliptic curve crypto.
PolarSSL requires no specific initialization for EC crypto; everything just
works out-of-the-box.


Just tested this on server side -- works great so far.

But I scanned the patch and noticed this:

  sig_len = ctx->signature_length;
  if ( (SIZE_MAX - hashlen) > asn_len || (hashlen + asn_len) > sig_len )
return POLARSSL_ERR_RSA_BAD_INPUT_DATA;

I'm not sure I understand the (SIZE_MAX - hashlen) > asn_len part. 
Wouldn't this always be true for reasonable values of hashlen and asn_len?


And the *p++ lines below, I assume that the buffer's size is 
ctx->signature_length?  Maybe add some comments about buffer-sizing 
assumptions?


James

Re: [Openvpn-devel] [PATCH] Fix man page and OSCP script: tls_serial_{n} is decimal

[James Yonan]

On 30/03/2014 07:46, Gert Doering wrote:

Hi,

On Sun, Mar 30, 2014 at 12:48:37AM +0100, Steffan Karger wrote:

3 - Change OpenSSL builds to use hax representation


I tend toward this one - user visible behaviour shouldn't change (unless
unavoidable) depending on SSL library used.

So for me this boils down to "how many users are relying on the current
behaviour, which is not what the docs say it should be"?


If we keep the current behavior (PolarSSL serial numbers are hex while 
OpenSSL are decimal) then we should at least mark the serial number when 
it's hex, so client software can distinguish it.


This very simple patch does that.

James
>From a8f0d219d4edd1e95520cc40d27a0cd79cace2c2 Mon Sep 17 00:00:00 2001
From: James Yonan <ja...@openvpn.net>
List-Post: openvpn-devel@lists.sourceforge.net
Date: Wed, 16 Apr 2014 21:29:42 -0600
Subject: [PATCH] tls_serial_{n} value should be distinguishable as hex or
 decimal.

To accomplish this, prepend 'x' before hex serial numbers, so they
can be distinguished from decimal serial numbers.  For example:

  tls_serial_1 = "x4D:9B:7C:94"

is equivalent to:

  tls_serial_1 = "1302035604"

Currently, only PolarSSL generates hex serial numbers while
OpenSSL returns decimal serial numbers.

RFC 5280, published in 2008, decrees that serial numbers can be
up to 20 bytes long, hence it is necessary to support SSL
libraries that return the serial number as a hex string.

Signed-off-by: James Yonan <ja...@openvpn.net>
---
 src/openvpn/ssl_verify_polarssl.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/src/openvpn/ssl_verify_polarssl.c 
b/src/openvpn/ssl_verify_polarssl.c
index 1b2990c..4367eb1 100644
--- a/src/openvpn/ssl_verify_polarssl.c
+++ b/src/openvpn/ssl_verify_polarssl.c
@@ -127,11 +127,12 @@ char *
 backend_x509_get_serial (x509_crt *cert, struct gc_arena *gc)
 {
   char *buf = NULL;
-  size_t len = cert->serial.len * 3 + 1;
+  size_t len = cert->serial.len * 3;

-  buf = gc_malloc(len, true, gc);
+  buf = gc_malloc(len+1, true, gc);

-  if(x509_serial_gets(buf, len-1, >serial) < 0)
+  buf[0] = 'x';
+  if(x509_serial_gets(buf+1, len, >serial) < 0)
 buf = NULL;

   return buf;
-- 
1.8.5.3

[Openvpn-devel] possible socks authentication issue?

[James Yonan]

Someone on the Tor lists is claiming that OpenVPN isn't implementing 
SOCKSv5 authentication correctly:


https://lists.torproject.org/pipermail/tor-dev/2014-March/006427.html

Any ideas?

James

Re: [Openvpn-devel] [PATCH] Fix man page and OSCP script: tls_serial_{n} is decimal

[James Yonan]

On 30/03/2014 07:46, Gert Doering wrote:

Hi,

On Sun, Mar 30, 2014 at 12:48:37AM +0100, Steffan Karger wrote:

3 - Change OpenSSL builds to use hax representation


I tend toward this one - user visible behaviour shouldn't change (unless
unavoidable) depending on SSL library used.

So for me this boils down to "how many users are relying on the current
behaviour, which is not what the docs say it should be"?


I think the problem here is that historically, going back as far as 2005 
(commit 6fbf66fad3367b24fd6743bcd50254902fd9c8d5), tls_serial_n has 
always given the serial number as decimal, and the documentation never 
indicated that the serial number was hex.


Commit 7ae5fb20d7dc52641ef853b896dffc0f283d16d2 in early 2011 added 
support for large serial numbers using BN_bn2dec, but the format was 
still decimal.


Now it looks like there was an alternative tls_serial_n implementation 
committed in 2010 (7d5e26cbb53e2700c966e6b6e815f0c824da8956) that 
changed the implementation to hex, but the code was later reverted, 
however unfortunately the comment in openvpn.8 that tls_serial_n is hex 
remained from that commit until now.


So a lot of code out there is assuming n is decimal, including some of 
our own code at OpenVPN Tech.


I would vote for preserving decimal behavior and updating the docs to 
reflect this.


It's unfortunate that PolarSSL is using hex, and I'm wondering how 
disruptive it would be to the PolarSSL user base if we change this to 
decimal.


I would tend to agree that the behavior should be consistent, regardless 
of underlying SSL library.


James

Re: [Openvpn-devel] [PATCH] Set SSL_OP_NO_TICKET flag in SSL context for OpenSSL builds, to disable TLS stateless session resumption.

[James Yonan]

On 17/03/2014 14:29, Gert Doering wrote:

Hi,

On Sun, Mar 16, 2014 at 06:49:36PM -0600, James Yonan wrote:

However, even with the above code, stateless session resumption
is still possible unless explicitly disabled with the
SSL_OP_NO_TICKET flag.  This patch does this.


This actually raises an interesting question.  My OpenSolaris buildslave
fails compilation with

gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include  -I../../src/compat -g -O2 -MT 
ssl_openssl.o -MD -MP -MF .deps/ssl_openssl.Tpo -c -o ssl_openssl.o 
ssl_openssl.c
ssl_openssl.c: In function `tls_ctx_set_options':
ssl_openssl.c:183: error: `SSL_OP_NO_TICKET' undeclared (first use in this 
function)

... while "configure" doesn't flag an error about the OpenSSL version
installed (0.9.8a-fips).  This is not ideal, if we know we're going to
fail at compile time due to missing functionality, we should tell the
user earlier.

Right now, if I read configure.ac correct, we require 0.9.6 or later (and
check this only if pkg-config is available) - but obviously, SSL_OP_NO_TICKET
was added later on.

Fix 1: only use SSL_OP_NO_TICKET if available
Fix 2: require a more recent OpenSSL version


I would think an #ifdef should be fine.

James

[Openvpn-devel] [PATCH] Set SSL_OP_NO_TICKET flag in SSL context for OpenSSL builds, to disable TLS stateless session resumption.

[James Yonan]

OpenVPN doesn't want or need SSL session renegotiation or
resumption, as it handles renegotiation on its own.

For this reason, OpenVPN always disables the SSL session cache:

SSL_CTX_set_session_cache_mode (ctx, SSL_SESS_CACHE_OFF)

However, even with the above code, stateless session resumption
is still possible unless explicitly disabled with the
SSL_OP_NO_TICKET flag.  This patch does this.
---
 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 0dc1e81..938e9d4 100644
--- a/src/openvpn/ssl_openssl.c
+++ b/src/openvpn/ssl_openssl.c
@@ -208,7 +208,7 @@ tls_ctx_set_options (struct tls_root_ctx *ctx, unsigned int 
ssl_flags)

   /* process SSL options including minimum TLS version we will accept from 
peer */
   {
-long sslopt = SSL_OP_SINGLE_DH_USE | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3;
+long sslopt = SSL_OP_SINGLE_DH_USE | SSL_OP_NO_TICKET | SSL_OP_NO_SSLv2 | 
SSL_OP_NO_SSLv3;
 const int tls_version_min = (ssl_flags >> SSLF_TLS_VERSION_SHIFT) & 
SSLF_TLS_VERSION_MASK;
 if (tls_version_min > TLS_VER_UNSPEC)
   {
-- 
1.8.5.3

Re: [Openvpn-devel] Adding support for AEAD cipher modes (AES-GCM, et al.)

[James Yonan]

On 18/06/2013 01:23, Joachim Schipper wrote:

Joachim Schipper wrote [I'm continuing my own message here]:

-Original Message-
From: Kenny Root [mailto:ke...@the-b.org]
Sent: dinsdag 4 juni 2013 2:15
To: openvpn-devel@lists.sourceforge.net
Subject: [Openvpn-devel] Adding support for AEAD cipher modes
(AES-GCM, et al.)

I wrote a patch to add AEAD cipher modes to OpenVPN.

It also doesn't appear PolarSSL has added AES-GCM to their main crypto
API yet.



Cool to see support for GCM in the data channel!

PolarSSL does support GCM (since 1.2, see include/polarssl/gcm.h), and
indeed OpenVPN-NL exclusively uses a GCM SSL ciphersuite in the control
channel. However, it would be very neat to also have it in the data
channel, so I looked at your patch with great interest. It's really
neat, but I do have some comments.



The prng_bytes() on src/openvpn/crypto.c:144 seems odd in various ways.
I'll continue reviewing tonight and tomorrow morning, and I'll take a
good look at this chunk of code then. (Sorry for the slow review; life
and spotty internet in the train got in the way.)


Continuing this train of thought, both GCM and CCM need non-repeating (but
possibly predictable) IVs. As long as net_time and net_id are unique to the
current packet, your code works fine; and you should still have 32 bits of
randomness left to guard against Bad Things happening to the clock. So this
code is just fine.


I don't understand src/openvpn/crypto.c:194 either, but I'll take
another look tonight.


After another reading, I understand just fine. Consider adding "else
ASSERT(outlen == 0)", but ok.


Again, thanks for the patch! I'm no contributor, but I do think it's
really cool.


Let me reiterate: thanks! I've just taken a quick look, but it looks quite
nice.


Agreed -- adding AEAD support is great.  That gives us access to 
AES-GCM, which has spectacular performance when accelerated at the CPU 
level (i.e. AES-NI).


Testing the patch with AES-GCM, the packet crypto header looks like this 
(appearing to be loosely inspired by RFC 4106):


7e7046bd 444a7e28 cc6387b1 64a4d6c1 0005 521c3b01 4308c041 380275a
[ auth tag] [seq # ] [time_t] [random] [ payload 
... ]

[   used like HMAC signature  ] [   12-byte IV/nonce/AD  ]

This is running in static key mode.  The time_t field is only used in 
static key mode and is based on the daemon startup time.  It doesn't 
change unless (a) the daemon is restarted or (b) the sequence number 
field wraps around.  In TLS mode there would be a leading control byte, 
and the time_t field would be replaced by randomness.


The "12-byte IV/nonce/AD" is the "associated data" field meaning that it 
is integrity-checked but not encrypted.  This is so it can double as the IV.


I'm thinking there might be some possible efficiency gains here by 
building the 12-byte nonce differently for TLS mode, such as by 
pre-agreeing to 8 bytes of randomness for each key negotiation, then 
send 4 additional bytes over the wire as a sequence number instead of 
12.  The IV could be synthesized on each end by combining the sequence 
number with the 8 bytes of agreed randomness.  This would cut 8 bytes 
out of the packet because [time_t] [random] vanishes, while retaining 
the essential property that the IV never repeats for a given key.


Can we get some more reviewers on this?

One question that applies to AEAD crypto in general and not specifically 
this patch, is what are the security implications of doing away with 
HMAC and trusting the cipher to do both encryption/decryption and 
integrity checking?  Is there general agreement in the crypto community 
that the integrity checking component of AEAD is as solid as 
encrypt-then-HMAC?  Because crypto history seems littered with the 
wreckage of attempts to pipe untrusted data directly into decryption 
algorithms.


James

Re: [Openvpn-devel] [Openvpn-users] why doesn't openvpn negotiate settings?

[James Yonan]

We've recently merged some patches allowing OpenVPN to negotiate certain 
settings (such as compression), but unfortunately at this time neither 
cipher nor auth directives can be negotiated in the 2.x branch.


The 3.0 branch has fixed this somewhat by having the client support 
cipher and auth directives that are pushed by the server (*).


However, to make cipher/auth negotiation really work, there are a few 
more things that are needed.  For one, the client would need to push a 
list of supported cipher/auth methods, so the server can choose a 
mutually supported combination.  Another possibility is to have OpenVPN 
leverage on the preexisting TLS ciphersuite negotiation, so as to use 
the same cipher/auth settings as TLS.


Some of this was discussed recently in the TLS versioning thread on 
openvpn-devel:


http://sourceforge.net/mailarchive/forum.php?thread_name=1CED409804E2164C8104F9E623B08B901455DE1C69%40FOXDFT02.FOX.local_name=openvpn-devel

James

*  The 3.0 branch is currently used by the OpenVPN Connect clients for 
Android and iOS.  Source core for the core is available from 
http://staging.openvpn.net/openvpn3/


On 01/08/2013 09:07, Jan Just Keijser wrote:

Hi Gert,

Gert Doering wrote:

Hi,

On Thu, Aug 01, 2013 at 12:02:55PM +0200, Jan Just Keijser wrote:


It should be possible to add negotiation without completely breaking
backwards compatibility; right now, when a server pushes an option to
the client that is unrecognized the client will print a warning but it
will not abort. This could be used to push a 'negotation request' - if
the client responds then a negotation phase can start , during which the
encryption key, hashing cipher, MTU settings etc can be negotiated. If
the client does not respond the server would need to assume that it's a
2.3 or older client.



Maybe I'm a bit naive, but since the data layer cipher is independent of
the TLS cipher anyway, can't we just "push cipher xxx"?

Or is push/pull crypted with the data layer cipher?



good question and one that I've asked myself as well -  there seems to
be something funny going on with the data layer cipher (or auth parm) .
I remember that I tried making the cipher and auth settings pushable and
failed miserably. The flow of when and how the data cipher (and digest)
are set up seems to be complicated and may happen (partially) *before*
the options are pushed.
Perhaps someone else (JamesY?) can comment on this.

cheers,

JJK



--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent
caught up. So what steps can you take to put your SQL databases under
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711=/4140/ostg.clktrk



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

[Openvpn-devel] [PATCH] MSVC fixes

[James Yonan]

Fixes to allow compilation with Microsoft Visual Studio 2008

* Fixed several instances of declarations after statements.

* In socket.c, fixed issue where uninitialized value (err)
  is being passed to to gai_strerror.

* ssl.c is trying to access multi_output_peer_info_env
  function in multi.c, causing an undefined symbol warning
  at compile time.  ssl.c is strictly a client of multi.c
  (but not the other way around), therefore ssl.c does not
  include multi.h and should not depend on multi.h API.  To
  fix, moved validate_peer_info_line and multi_output_peer_info_env
  from multi.c to misc.c.

* MSVC doesn't support %z as a printf format specifier for size_t

* MSVC doesn't support a const variable being used to dimension
  an array.

* Explicitly cast the third parameter to setsockopt to
  const void *
---
 src/openvpn/init.c|   10 
 src/openvpn/misc.c|   56 +
 src/openvpn/misc.h|7 ++
 src/openvpn/multi.c   |   52 -
 src/openvpn/multi.h   |3 ---
 src/openvpn/socket.c  |5 ++--
 src/openvpn/socket.h  |2 +-
 src/openvpn/ssl.c |2 +-
 src/openvpn/ssl_openssl.c |7 +++---
 src/openvpn/win32.c   |6 ++---
 10 files changed, 79 insertions(+), 71 deletions(-)

diff --git a/src/openvpn/init.c b/src/openvpn/init.c
index fb14726..031fb20 100644
--- a/src/openvpn/init.c
+++ b/src/openvpn/init.c
@@ -183,10 +183,12 @@ ce_management_query_proxy (struct context *c)
   if (management)
 {
   gc = gc_new ();
-  struct buffer out = alloc_buf_gc (256, );
-  buf_printf (, ">PROXY:%u,%s,%s", (l ? l->current : 0) + 1,
-  (proto_is_udp (ce->proto) ? "UDP" : "TCP"), np (ce->remote));
-  management_notify_generic (management, BSTR ());
+  {
+   struct buffer out = alloc_buf_gc (256, );
+   buf_printf (, ">PROXY:%u,%s,%s", (l ? l->current : 0) + 1,
+   (proto_is_udp (ce->proto) ? "UDP" : "TCP"), np 
(ce->remote));
+   management_notify_generic (management, BSTR ());
+  }
   ce->flags |= CE_MAN_QUERY_PROXY;
   while (ce->flags & CE_MAN_QUERY_PROXY)
 {
diff --git a/src/openvpn/misc.c b/src/openvpn/misc.c
index 1120adc..4688444 100644
--- a/src/openvpn/misc.c
+++ b/src/openvpn/misc.c
@@ -2063,3 +2063,59 @@ compat_flag (unsigned int flag)
   return (compat_flags & (flag >> 1));

 }
+
+#if P2MP_SERVER
+
+/* helper to parse peer_info received from multi client, validate
+ * (this is untrusted data) and put into environment
+ */
+bool
+validate_peer_info_line(char *line)
+{
+  uint8_t c;
+  int state = 0;
+  while (*line)
+{
+  c = *line;
+  switch (state)
+   {
+   case 0:
+   case 1:
+ if (c == '=' && state == 1)
+   state = 2;
+ else if (isalnum(c) || c == '_')
+   state = 1;
+ else
+   return false;
+   case 2:
+ /* after the '=', replace non-printable or shell meta with '_' */
+ if (!isprint(c) || isspace(c) ||
+  c == '$' || c == '(' || c == '`' )
+   *line = '_';
+   }
+  line++;
+}
+  return (state == 2);
+}
+
+void
+output_peer_info_env (struct env_set *es, const char * peer_info)
+{
+  char line[256];
+  struct buffer buf;
+  buf_set_read (, (const uint8_t *) peer_info, strlen(peer_info));
+  while (buf_parse (, '\n', line, sizeof (line)))
+{
+  chomp (line);
+  if (validate_peer_info_line(line) &&
+(strncmp(line, "IV_", 3) == 0 || strncmp(line, "UV_", 3) == 0) )
+   {
+ msg (M_INFO, "peer info: %s", line);
+ env_set_add(es, line);
+   }
+  else
+   msg (M_WARN, "validation failed on peer_info line received from 
client");
+}
+}
+
+#endif /* P2MP_SERVER */
diff --git a/src/openvpn/misc.h b/src/openvpn/misc.h
index 183898e..41748bd 100644
--- a/src/openvpn/misc.h
+++ b/src/openvpn/misc.h
@@ -369,4 +369,11 @@ void argv_printf_cat (struct argv *a, const char *format, 
...)
 #define COMPAT_NO_NAME_REMAPPING  (1<<2)  /** compat flag: --compat-names 
without char remapping */
 bool compat_flag (unsigned int flag);

+#if P2MP_SERVER
+/* helper to parse peer_info received from multi client, validate
+ * (this is untrusted data) and put into environment */
+bool validate_peer_info_line(char *line);
+void output_peer_info_env (struct env_set *es, const char * peer_info);
+#endif /* P2MP_SERVER */
+
 #endif
diff --git a/src/openvpn/multi.c b/src/openvpn/multi.c
index 50f398d..f016b14 100644
--- a/src/openvpn/multi.c
+++ b/src/openvpn/multi.c
@@ -1562,58 +1562,6 @@ multi_client_connect_mda (struct multi_context *m,

 #endif

-/* helper to parse peer_info received from multi client, validate
- * (this is untrusted data) and put into environment
- */
-bool
-validate_peer_info_line(char *line)
-{
-  uint8_t c;
-  int state = 0;
-  while (*line)
-{
-  c = *line;
-  switch (state)
-   {

[Openvpn-devel] [PATCH] TLS versioning

[James Yonan]

This is the TLS versioning patch as discussed in last Thursday's IRC 
meeting.


It combines these two patches:

https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436

https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40

James
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 174fd6d..d3fb468 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4235,6 +4235,15 @@ when you built your peer's certificate (see
 above).
 .\"*
 .TP
+.B \-\-tls-version-min version ['or-highest']
+Sets the minimum
+TLS version we will accept from the peer (default is "1.0").
+Examples for version
+include "1.0", "1.1", or "1.2".  If 'or-highest' is specified
+and version is not recognized, we will only accept the highest TLS
+version supported by the local SSL implementation.
+.\"*
+.TP
 .B \-\-pkcs12 file
 Specify a PKCS #12 file containing local private key,
 local certificate, and root CA certificate.
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 883136f..ba5bb1f 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -582,6 +582,9 @@ static const char usage_message[] =
   "  by a Certificate Authority in --ca file.\n"
   "--extra-certs file : one or more PEM certs that complete the cert chain.\n"
   "--key file  : Local private key in .pem format.\n"
+  "--tls-version-min  ['or-highest'] : sets the minimum TLS version 
we\n"
+  "will accept from the peer.  If version is unrecognized and 
'or-highest'\n"
+  "is specified, require max TLS version supported by SSL 
implementation.\n"
 #ifndef ENABLE_CRYPTO_POLARSSL
   "--pkcs12 file   : PKCS#12 file containing local private key, local 
certificate\n"
   "  and optionally the root CA certificate.\n"
@@ -6506,6 +6509,19 @@ add_option (struct options *options,
  options->priv_key_file_inline = p[2];
}
 }
+  else if (streq (p[0], "tls-version-min") && p[1])
+{
+  int ver;
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  ver = tls_version_min_parse(p[1], p[2]);
+  if (ver == TLS_VER_BAD)
+   {
+ msg (msglevel, "unknown tls-version-min parameter: %s", p[1]);
+  goto err;
+   }
+  options->ssl_flags &= ~(SSLF_TLS_VERSION_MASK << SSLF_TLS_VERSION_SHIFT);
+  options->ssl_flags |= (ver << SSLF_TLS_VERSION_SHIFT);
+}
 #ifndef ENABLE_CRYPTO_POLARSSL
   else if (streq (p[0], "pkcs12") && p[1])
 {
diff --git a/src/openvpn/ssl.c b/src/openvpn/ssl.c
index 736dfc9..a8b5d3d 100644
--- a/src/openvpn/ssl.c
+++ b/src/openvpn/ssl.c
@@ -447,6 +447,27 @@ ssl_put_auth_challenge (const char *cr_str)
 #endif

 /*
+ * Parse a TLS version string, returning a TLS_VER_x constant.
+ * If version string is not recognized and extra == "or-highest",
+ * return tls_version_max().
+ */
+int
+tls_version_min_parse(const char *vstr, const char *extra)
+{
+  const int max_version = tls_version_max();
+  if (!strcmp(vstr, "1.0") && TLS_VER_1_0 <= max_version)
+return TLS_VER_1_0;
+  else if (!strcmp(vstr, "1.1") && TLS_VER_1_1 <= max_version)
+return TLS_VER_1_1;
+  else if (!strcmp(vstr, "1.2") && TLS_VER_1_2 <= max_version)
+return TLS_VER_1_2;
+  else if (extra && !strcmp(extra, "or-highest"))
+return max_version;
+  else
+return TLS_VER_BAD;
+}
+
+/*
  * Initialize SSL context.
  * All files are in PEM format.
  */
diff --git a/src/openvpn/ssl_backend.h b/src/openvpn/ssl_backend.h
index 72235ae..4516897 100644
--- a/src/openvpn/ssl_backend.h
+++ b/src/openvpn/ssl_backend.h
@@ -94,6 +94,29 @@ void tls_free_lib();
 void tls_clear_error();

 /**
+ * Parse a TLS version specifier
+ *
+ * @param vstr The TLS version string
+ * @param extraAn optional extra parameter, may be NULL
+ *
+ * @return One of the TLS_VER_x constants or TLS_VER_BAD
+ *  if a parse error should be flagged.
+ */
+#define TLS_VER_BAD   -1
+#define TLS_VER_1_00 /* default */
+#define TLS_VER_1_11
+#define TLS_VER_1_22
+int tls_version_min_parse(const char *vstr, const char *extra);
+
+/**
+ * Return the maximum TLS version (as a TLS_VER_x constant)
+ * supported by current SSL implementation
+ *
+ * @return One of the TLS_VER_x constants (but not TLS_VER_BAD).
+ */
+int tls_version_max(void);
+
+/**
  * Initialise a library-specific TLS context for a server.
  *
  * @param ctx  TLS context to initialise
diff --git a/src/openvpn/ssl_common.h b/src/openvpn/ssl_common.h
index 7e52f9a..04ba789 100644
--- a/src/openvpn/ssl_common.h
+++ b/src/openvpn/ssl_common.h
@@ -290,12 +290,14 @@ struct tls_options
   struct compress_options comp_options;
 #endif

-  /* configuration file boolean options */
+  /* configuration file SSL-related boolean and low-permutation options */
 # define SSLF_CLIENT_CERT_NOT_REQUIRED (1<<0)
 # define 

Re: [Openvpn-devel] OpenVPN Versioning

[James Yonan]

On 18/06/2013 01:41, Joachim Schipper wrote:

From: James Yonan <ja...@openvpn.net>:

On 14/06/2013 02:47, Joachim Schipper wrote:

>From James Yonan <ja...@openvpn.net>:

TLS Protocol


Since day 1, OpenVPN has used TLS 1.0 as a control channel and key
exchange mechanism.  But now we have TLS 1.1 and 1.2, each of which
addresses significant shortcomings in its predecessor.  Fortunately,
SSL/TLS already includes dynamic version negotiation.  So I've put
together a patch that leverages on this, by allowing OpenVPN client
and server to negotiate the TLS version and use the highest version
supported by both peers.  The patch also adds a new directive "tls-
version-min" that allows either client or server to specify a

minimum

required TLS version from the peer.



https://github.com/jamesyonan/openvpn/commit/6ee8faade224cc346d67a7f1

7
1
6df4012782999a


[snip: SSL negotiation. Thanks for the explanation; I agree that speaking
the highest supported protocol is good.]


I'm not sure what purpose the "or-highest" serves. Clients already

connect with the newest protocol supported by both client and server;
if you want to run a TLSv1.2-only network, just set min-version to 1.2
on the server. (...)

Suppose a server admin wants to upgrade to TLS 1.2 over some transition
period, to allow time to upgrade existing clients in the field.



The overall goal here is to provide tools that allow a controlled
rollout of TLS 1.2 that doesn't break any clients during the rollout
period, and to upgrade to 1.2 in a way that doesn't create the
potential for MiTM version rollback attacks.


But no modern SSL protocol allows version rollback attacks: modern
implementations will always speak the highest supported/configured protocol
version between each other. (Only) SSLv2 allows rollback attacks, which is
why the only sane way to deal with SSLv2 in 2013 is to unconditionally
disable support.


Right, and the patch is able to unconditionally disable support for SSL 
2 and 3 since these were never supported by even the earliest versions 
of OpenVPN.



The switch(tls_version_min) needs a default case, just compile the

first case/default: unconditionally.

There is a default case already -- it's right under "case
TLS_VER_1_0:".


Yes, but that's #ifdef'ed. I'd be happier if the default case remained
present even if PolarSSL foolishly decides to drop TLSv1 support.


Agreed -- there shouldn't be any implicit assumption
that SSL lib might not implement TLS 1.0.

https://github.com/jamesyonan/openvpn/commit/d23005413b0e0f28a3c48a6342f494763d5c9b40


[snip: ciphersuites]

Negotiating ciphers might be fatal in some configurations that were a
bad idea to begin with. E.g. if you use OpenVPN with a static key and
--auth none (which is a bad idea!), adding this negotation could

allow

an attacker to set the cipher to none or, more dangerously, to a very
weak cipher like DES (provided it is mutually supported). An attacker
could then bruteforce the key and use his knowledge of 56 bits of the
key to attack stronger protocols like AES or 3DES. (Or do we only
negotiate in SSL mode? I must admit to being fuzzy on the non-SSL
mode.)


Static key mode has no negotiation.

Agreed that any negotiation model must have constraints placed on the
security of the negotiated cipher and HMAC digest.  You would probably
want to disable "cipher none" or "auth none" on the presumption that
users who want a cleartext tunnel would explicitly configure the client
and server for this.


Sure. Just disabling negotiations unless you have an SSL'd control channel
works fine against this.


One thing to keep in mind is that OpenVPN protocol negotiation occurs
over the already-negotiated TLS session, so it is immune to being
tampered with by a MiTM.  This is in contrast to SSL/TLS where a MiTM
can affect the negotiation.


As above, MiTM attackers cannot effect the negotiation step in SSL/TLS
protocols after SSLv2, except trivially (by causing the negotiation to fail, 
possibly a couple of protocol steps later, e.g. by dropping all packets.)


Aha, that's good to know.  Apparently browsers are still vulnerable to 
version rollback attacks due to compatibility fallback mechanisms, but 
that's great that SSL/TLS protocols are immune above SSL 3.  There's a 
good writeup on the subject here:


http://www.carbonwind.net/blog/post/Random-SSLTLS-101%E2%80%93SSLTLS-version-rollbacks-and-browsers.aspx

James

Re: [Openvpn-devel] OpenVPN Versioning

[James Yonan]

On 17/06/2013 01:58, Steffan Karger wrote:

On 06/14/2013 09:53 PM, James Yonan wrote:

To get the adaptive versioning behavior in OpenSSL, you have to use
SSLv23_server_method() or SSLv23_client_method() and then explicitly
disable the versions you don't want to consider, i.e. SSL_OP_NO_SSLv2,
SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1, SSL_OP_NO_TLSv1_1, etc.


Wow, so SSLv23_{client,server}_method() is the 'wildcard' you need to
dynamically negotiate the version. Yet it sounds like something
completely broken that should be avoided at all cost. OpenSSL keeps
amazing me.


It really shows OpenSSL's age, doesn't it?  But aside from the 
cruftiness, I wouldn't say that it's broken.  It's arguably a more 
flexible mechanism than PolarSSL because it allows you to cherry-pick 
the SSL/TLS versions you want to support, rather than just give a 
min/max range.



Does the change to key_state_ssl_init() do anything?


I had to add ssl_flags (containing tls-version-min parameter) to
key_state_ssl_init because that seems like the most appropriate place to
configure tls-version-min for PolarSSL.

For OpenSSL, tls_ctx_set_options is the right place to configure
tls-version-min.


The ssl_flags are already available through the tls session that is
passed as the fourth parameter. To make this a bit more clear, commit
b97e2c3 changed the type of session to struct tls session* (see
https://github.com/OpenVPN/openvpn/commit/b97e2c3c90afdbb1a24bc1357ec6b94d626defcd).


Right, I've rebased the patch against master and now use 
session->opt->ssl_flags


This simplifies the patch because now it's no longer necessary to pass 
ssl_flags to key_state_ssl_init


https://github.com/jamesyonan/openvpn/commit/03a5599202bdc3ba07983dc4efdae387fb8fb436

James

Re: [Openvpn-devel] OpenVPN Versioning

[James Yonan]

On 12/06/2013 15:08, Arne Schwabe wrote:

Am 12.06.13 21:38, schrieb James Yonan:

About finding out which cipher client and server use. I am not really
familiar with this code so forgive my stupid question. TLS somehow also
does this "select the best cipher to use" dance. Why can't we use the
TLS mechanism but have to use our own IV_CIPHER?


TLS includes a handshake mechanism for TLS version and ciphersuite 
selection.  In TLS, a single ciphersuite specifies a set of cipher, 
mode, keysize, MAC digest, etc., while in OpenVPN the cipher and HMAC 
digest are separately selected by cipher and auth directives.


Historically, OpenVPN has never implemented any interaction between the 
TLS ciphersuite selection and the cipher/auth selection for the OpenVPN 
protocol -- they are completely decoupled from one another, so using TLS 
negotiation isn't going to have any effect on OpenVPN cipher/auth.


But you raise an interesting point that we might want to explore, i.e. 
looking at the TLS ciphersuite that ends up getting negotiated, and 
extract the cipher/auth directive from that since you know it will be 
consistent on both client and server.



Suppose I want to put this directive in the config files I distribute to
clients, but have it be ignored by older clients that don't recognize
it.  I could do this as follows on the client:

setenv opt tls-version-min 1.2

I suppose this a good idea too also support older client. I would to
*additionally* add a way to support this in a nicer way for future
release. Like also adding an option

ignore-unknown-options tls-version new-cool-option

so newer can some day can still be written with having to use "setenv opt"


Sure, that makes sense.


Loosly related this would also allow to give use a "default" set of
options that can be ignored (ip-win32 on *nix)


Deciding whether or not to ignore options is tricky.  With the new 3.0 
core, it was necessary to ignore some options because they are simply 
not implemented, and raising an error for every unimplemented option 
would make it very difficult upgrade to 3.0 in a way that maintains 
reasonable config file compatibility with 2.x.


So the approach I took for 3.0 was to only raise an error on 
unimplemented options where ignoring the option might compromise 
security.  Initially tls-remote fell under this category, but it has 
since been implemented in the 3.0 core.


James

Re: [Openvpn-devel] [Openvpn-users] OpenVPN client released for iOS

[James Yonan]

On 18/01/2013 15:31, Marcel Pennewiß wrote:

On Wed, 16 Jan 2013 21:48:23 -0700
James Yonan <ja...@openvpn.net> wrote:


The client is based on the new C++ OpenVPN core that is also used in
the OpenVPN Connect client for Android.  The C++ core is a portable,
lightweight class library for building OpenVPN clients and is 100%
protocol-compatible with the 2.x branch.


It seems, that the client does not support net_gateway in pushed routes:

2013-01-17 16:55:59 EVENT: ASSIGN_IP
2013-01-17 16:55:59 TUN Error: tun_builder_error: error parsing IPv4
route: [route] [141.24.xxx.xxx] [255.255.255.255] [net_gateway] :
tun_builder_route_error: only tunnel routes supported
2013-01-17 16:55:59 EVENT: TUN_SETUP_FAILED tun_builder_error: error
parsing IPv4 route: [route] [141.24.xxx.xxx] [255.255.255.255]
[net_gateway] : tun_builder_route_error: only tunnel routes supported
[ERR]
2013-01-17 16:55:59 EVENT: DISCONNECTED

This works as expected on Win, Linux and Android 4 (reported by user
that there are no connection issues).

Will net_gateway be available in iOS-Client in future?


It's tricky to make some of these features like net_gateway work on 
mobile devices, because they don't let you add routes directly, except 
through a limited API.


I'll take another look at the iOS VPN API and see if this is doable.

Also... You mentioned Android 4 -- I don't think the Android 4 VPN API 
has the capability to support net_gateway.  OpenVPN Connect for Android 
definitely doesn't support it.  And looking at Arne Schwabe's FAQ for 
ics-openvpn, in the Routing/Interface Configuration, it specifically 
mentions net_gateway as not being supported.  I think that 
VpnService.Builder would have to add an excludeRoute method to make this 
possible.


James

[Openvpn-devel] OpenVPN client released for iOS

[James Yonan]

Just wanted to let everyone know that the OpenVPN Connect client for iOS 
has just been released and is now available in the app store.


This is an official Apple-sanctioned OpenVPN client developed by OpenVPN 
Technologies in collaboration with Apple.


The client is based on the new C++ OpenVPN core that is also used in the 
OpenVPN Connect client for Android.  The C++ core is a portable, 
lightweight class library for building OpenVPN clients and is 100% 
protocol-compatible with the 2.x branch.


The current plan is to open-source the C++ core within the coming weeks. 
 We won't be able to open source the full iOS client because portions 
of it use Apple-proprietary APIs to integrate with the iOS VPN 
framework.  But we will be open-sourcing the core itself, which contains 
all of the code for building an OpenVPN client on Linux or Mac.


BTW, I'm going to be at FOSDEM in early February, so I look forward to 
meeting some of you there.


Enjoy,

James

[Openvpn-devel] OpenVPN and BEAST

[James Yonan]

We've gotten some questions about whether OpenVPN is vulnerable to the 
"BEAST" exploit.


At the time of this writing, the details of the "BEAST" exploit haven't 
been released yet, but the general consensus is that it exploits the 
known-IV weakness in SSL and TLS 1.0 that is discussed by Bard back in 2004:


http://eprint.iacr.org/2004/111.pdf

The vulnerability is present in all versions of SSL and TLS 1.0 but not 
TLS 1.1 or higher (OpenVPN currently uses TLS 1.0).


One of the common workarounds for this vulnerability is to have the SSL 
implementation add empty fragments into the application data stream. 
OpenSSL has implemented this workaround since 0.9.6d (9 May 2002).


See http://www.openssl.org/~bodo/tls-cbc.txt

So the bottom line is that even though OpenVPN uses TLS 1.0 which is 
technically vulnerable, the OpenSSL workaround added in 0.9.6d 
effectively protects TLS 1.0 from this vulnerability, and hence OpenVPN 
as well.


Now if OpenSSL patched this back in 2002, you might be wondering why 
it's an exploitable vulnerability today.  I think the answer is that 
while OpenSSL patched the vulnerability, NSS did not (NSS is an 
alternative to OpenSSL that is widely used in web browsers).


In fact, if you look at this recent commit to NSS by the Chromium 
project (presumably to address the BEAST exploit), you see the same 
workaround being added to NSS that was added to OpenSSL 9 years ago.


https://src.chromium.org/viewvc/chrome?view=rev=90643

James

[Openvpn-devel] OpenVPN and SSL vulnerability CVE-2010-3864

[James Yonan]

Regarding the recently discovered SSL vulnerability CVE-2010-3864, 
OpenVPN should not be affected because it is single-threaded.


James

[Openvpn-devel] Alternatives to tapinstall?

[James Yonan]

I would be interested to know if anyone has succeeded in using 
alternative approaches to install the windows TAP driver (other than 
using tapinstall/devcon).


In particular, has anyone tried using the Difx API?  This posting seems 
to indicate that people have succeeded along these lines, but I was not 
able to reproduce their results.


http://stackoverflow.com/questions/1167544/devcon-exe-driver-tool-and-openvpn

Thanks,
James

[Openvpn-devel] OpenVPN version 2.1.2 released

[James Yonan]

2010.08.09 -- Version 2.1.2

* Windows security issue:
  Fixed potential local privilege escalation vulnerability in
  Windows service. The Windows service did not properly quote the
  executable filename passed to CreateService.  A local attacker
  with write access to the root directory C:\ could create an
  executable that would be run with the same privilege level as
  the OpenVPN Windows service.  However, since non-Administrative
  users normally lack write permission on C:\, this vulnerability
  is generally not exploitable except on older versions of Windows
  (such as Win2K) where the default permissions on C:\ would allow
  any user to create files there.
  Credit:  Scott Laurie, MWR InfoSecurity

* Added Python-based based alternative build system for Windows using
  Visual Studio 2008 (in win directory).

* When aborting in a non-graceful way, try to execute do_close_tun in
  init.c prior to daemon exit to ensure that the tun/tap interface is
  closed and any added routes are deleted.

* Fixed an issue where AUTH_FAILED was not being properly delivered
  to the client when a bad password is given for mid-session reauth,
  causing the connection to fail without an error indication.

* Don't advance to the next connection profile on AUTH_FAILED errors.

* Fixed an issue in the Management Interface that could cause
  a process hang with 100% CPU utilization in --management-client
  mode if the management interface client disconnected at the
  point where credentials are queried.

* Fixed an issue where if reneg-sec was set to 0 on the client,
  so that the server-side value would take precedence,
  the auth_deferred_expire_window function would incorrectly
  return a window period of 0 seconds.  In this case, the
  correct window period should be the handshake window
  period.

* Modified ">PASSWORD:Verification Failed" management interface
  notification to include a client reason string:

>PASSWORD:Verification Failed: 'AUTH_TYPE' ['REASON_STRING']

* Enable exponential backoff in reliability layer
  retransmits.

* Set socket buffers (SO_SNDBUF and SO_RCVBUF) immediately after
  socket is created rather than waiting until after connect/listen.

* Management interface performance optimizations:

  1. Added env-filter MI command to perform filtering on env vars
 passed through as a part of --management-client-auth

  2. man_write will now try to aggregate output into larger blocks
 (up to 1024 bytes) for more efficient i/o

* Fixed minor issue in Windows TAP driver DEBUG builds
  where non-null-terminated unicode strings were being
  printed incorrectly.

* Fixed issue on Windows with MSVC compiler, where TCP_NODELAY support
  was not being compiled in.

* Proxy improvements:

  Improved the ability of http-auth "auto" flag to dynamically detect
  the auth method required by the proxy.

  Added http-auth "auto-nct" flag to reject weak proxy auth methods.

  Added HTTP proxy digest authentication method.

  Removed extraneous openvpn_sleep calls from proxy.c.

* Implemented http-proxy-override and http-proxy-fallback directives to 
make it
  easier for OpenVPN client UIs to start a pre-existing client config 
file with
  proxy options, or to adaptively fall back to a proxy connection if a 
direct

  connection fails.

* Implemented a key/value auth channel from client to server.

* Fixed issue where bad creds provided by the management interface
  for HTTP Proxy Basic Authentication would go into an infinite
  retry-fail loop instead of requerying the management interface for
  new creds.

* Added support for MSVC debugging of openvpn.exe in settings.in:

  # Build debugging version of openvpn.exe
  !define PRODUCT_OPENVPN_DEBUG

* Implemented multi-address DNS expansion on the network field of route
  commands.

  When only a single IP address is desired from a multi-address DNS
  expansion, use the first address rather than a random selection.

* Added --register-dns option for Windows.

  Fixed some issues on Windows with --log, subprocess creation
  for command execution, and stdout/stderr redirection.

* Fixed an issue where application payload transmissions on the
  TLS control channel (such as AUTH_FAILED) that occur during
  or immediately after a TLS renegotiation might be dropped.

* Added warning about tls-remote option in man page.

[Openvpn-devel] ESET Smart Security interferes with TAP driver install

[James Yonan]

I've observed a case on Windows Server 2008R2 where an antivirus product 
called ESET Smart Security prevents install of the TAP driver.


The net effect in tapinstall (devcon) is that 
UpdateDriverForPlugAndPlayDevices returns error code 1450 
(ERROR_NO_SYSTEM_RESOURCES).


Apparently ESET interferes with other VPN clients as well:

http://social.technet.microsoft.com/Forums/en/w7itpronetworking/thread/f92abbdf-a340-4629-a46c-f186f7c82340

James

Re: [Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[James Yonan]

looking at the multitude of DHCP clients available for unix, the completely
different handling of DHCP on MacOS, and the issues that most unix clients
seem to have with "DHCP active on two different interfaces (ethX and tapY),
and both trying to set a default gateway", ...

On Mon, Mar 08, 2010 at 08:21:35AM -0700, James Yonan wrote:
(2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
then translate the settings received in the DHCP reply to OpenVPN 
push-style directives (such as ifconfig, route, etc.) as if they had 
been pushed by the OpenVPN server.


... this seems to be the most portable way, as we already have the 
ifconfig/route code for all the platforms.


Well.  Let me rephrase.

The "simple way" is simple as far as the packet flow inside OpenVPN
goes (because OpenVPN only needs to transport packets, but not generate
them or parse them), but is, at the same time, the "most complex way" 
as far as getting it to work reliably across all supported operating 
systems.  Lots of testing and "configure" magic would be necessary to

reliably figure out how to do DHCP properly on each individual system.

I'm not saying it can't be done :-) - but just that the "simple way"
is not so simple, it's just complex in other places.


I would tend to agree.  All the discussion about the non-portable 
semantics of DHCP clients on different platforms makes me think that the 
"complex" method might really be the correct approach.


OpenVPN is already in the business of abstracting platform-specific 
network configuration complexity to a portable interface, i.e. in the 
manner of pushable directives such as route, ifconfig, dhcp-option, 
etc., so I think it makes sense to leverage on this.  Implementing a 
DHCP client within OpenVPN tends to make this a more self-contained problem.


James

Re: [Openvpn-devel] [PATCH] IPv6 support for TUN/TAP driver on windows

[James Yonan]

 - how does one debug Windows drivers?  Is there a printf() as in Linux
   that goes to console / syslog?


I have not yet figured out that part.  I did my debugging with Wireshark
("see what packets move back and forth and stare at the packet details").


While Windows doesn't support "printf" in device drivers, the TAP driver 
defines the DEBUGP macro that tries to do the same thing.


First, build a debug version of the driver.  This can be done by editing 
install-win32/settings.in (the domake-win configuration file) and 
uncommenting out this line:


  ;!define PRODUCT_TAP_DEBUG

If you look at the source code to the driver, you will see lots of 
DEBUGP macro references.  This is how you want to code your debugging 
printfs.


Next, there are two possible ways to view the debugging output:

Get the WinDBG tool from MS.  All of the DEBUGP calls will output log 
info in a form that can be received by WinDBG.


Use a special feature of OpenVPN on Windows that allows it to get the 
DEBUGP messages directly from the TAP driver and output them along with 
the normal OpenVPN log output.  This feature is enabled at --verb level 
6 and is internally referred to as D_TAP_WIN32_DEBUG in errlevel.h.


The disadvantage of the D_TAP_WIN32_DEBUG method is that it's only 
available after OpenVPN has successfully bound to a TAP adapter.  For 
example, if there's an error on initial driver loading that precludes 
OpenVPN from opening the TAP device, then only WinDBG would be able to 
show the DEBUGP output from such a condition.


James

[Openvpn-devel] Linux tun/tap performance issues

[James Yonan]

I believe this has been discussed before, but I noticed recently that a 
Linux-based OpenVPN client (Linux 2.6.24, OpenVPN 2.1.1) spends a lot 
more CPU time in kernel space than in user space.  This is surprising, 
given the fact that all of the CPU-intensive cryptographic operations 
are being done in user space.


Using the 'time' utility on the OpenVPN client, while a wget of a 50MB 
file was done over the VPN, I found that 80% of the CPU time was taken 
by the kernel, and 20% by user space (I should add that the Linux client 
was running as a VM on VMWare Fusion).


I'm wondering if anyone with kernel background has any insights on this. 
 Are there performance bottlenecks in the tun/tap driver?


James

[Openvpn-devel] Supporting "route-gateway dhcp" on non-Windows

[James Yonan]

OpenVPN 2.1 has a relatively recent feature that allows a TAP-based 
OpenVPN session to be established where the client gets its IP address 
assignment and other attributes from the server-side DHCP server.


The feature is enabled by the "route-gateway dhcp" directive on the client.

It's a pretty cool feature because it allows you to set up a TAP-based 
VPN server without configuring IP addresses, routes, etc. because you 
can simply leverage on the existing server-side DHCP server 
configuration.  When a client connects to the VPN, it gets an IP address 
assignment just as if it were physically "plugged into" the server-side LAN.


The problem is that "route-gateway dhcp" only works on platforms where 
the TAP driver negotiates a DHCP client handshake.  Currently, only 
Windows support this out-of-the-box (Windows supports it not because of 
any special code in the Windows TAP driver, but because the Windows DHCP 
client automatically binds to TAP adapter instances when they transition 
to the "up" state).


I'm hoping that we can make "route-gateway dhcp" work on Unix platforms 
as well.  I'm thinking there are two possible ways we could do this:


(1) Simple method: Trigger a DHCP client bind on TAP interfaces when 
they are instantiated.  (This is what Windows does automatically)


(2) Complex method: Write code in OpenVPN to simulate a DHCP client, 
then translate the settings received in the DHCP reply to OpenVPN 
push-style directives (such as ifconfig, route, etc.) as if they had 
been pushed by the OpenVPN server.


It would be great if someone wanted to volunteer to work on this.  I'm 
hoping that Mac and Linux could be supported via the Simple method.


James

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

Davide Brini wrote:

On Friday 11 December 2009, James Yonan wrote:


Try adding the "nobind" directive to your client config file.  I think
this will solve the problem.


That seems indeed to do it. Thank you very much!

However, never in my life could I have imagined that this was due to a setting 
*on the client*. For single-homed clients, my (possibly wrong) understanding 
was that using or not using "nobind" would essentially be the same. 
Since now I'm curious, could you please kindly provide a bit more insight as 
to *why* using "nobind" on the client fixes it, and how that affects the 
server?


Using nobind on the client for UDP client connections generates a socket 
with a dynamic source port number.  This is key because it means that 
when the client reconnects, it does so with a new source port number, 
and this allows OpenVPN to detect that the initial UDP packet represents 
a new connection, and is not part of the old connection.


The problem is that when nobind is not used, the source port on the new 
connection is recycled -- it's the same as the old connection.  So when 
OpenVPN sees the connection-initiating packet, after the client switches 
over to the secondary server address, it gets confused because it 
doesn't expect sessions from a given source address to change its 
destination address mid-session.


James

Re: [Openvpn-devel] Building the TAP drivers from source and then signing them (possible?)

[James Yonan]

Jon Onstott wrote:

Hello,

I am compiling OpenVPN and the TAP driver from source and would like the 
TAP driver to be signed so that it installs correctly on Vista (and 
doesn't pop-up warning dialog boxes).  I noticed that the configure 
scripts attempt to do that if "signtool" is defined.  Is there any way 
that I could sign the TAP driver?


I think for most people, signing drivers themselves would be more pain 
than it's worth.  You have to get a special certificate from Verisign 
that costs ~$450/year.  You have to get the full WDK toolchain from 
Microsoft.


I have thought about using the prebuilt TAP driver (from 
openvpn.net/prebuilt/ ) but the prebuilt 
binaries lag behind the current version and I need the TAP driver to be 
the most recent one possible.


The TAP driver in http://openvpn.net/prebuilt/ is based on rc22 which is 
identical to the driver that was just released with 1.2.0.


James

Re: [Openvpn-devel] OpenVPN project organization [WAS: Introducing OpenVPN Community Manager]

[James Yonan]

Karl O. Pinc wrote:

On 12/10/2009 04:39:57 AM, Samuli Seppänen wrote:

David Sommerseth ha scritto:



I believe James have received several patches in the past from

people on
the mailing list - or directly. 



They will either include patches into their own source

trees, or

kick them back to be reworked or cancelled completely.

Patches which are accepted will then be sent to James for a final

review

and inclusion.  If James don't like it, it must be discussed on the
mailing list so that everyone can see and understand why it was

rejected
and how to make it more acceptable for inclusion.  If James can 

take
the

time to bring this discussion on the mailing list directly himself

in

these cases, that would bring the needed transparency.  Further, it
should hopefully not happen too often, as James' "inner circle"

should

already have made sure it is suitable for inclusion.


Via public discussion.  Who wants to submit a patch when it
just disappears without comment.  Public discussion has been
sorely lacking in the past.


 Even

patches

these people write themselves should be posted to the openvpn-devel

list

(or other another more suitable one).  That way, more eyes can pay
attention and raise awareness if something seems to be wrong or

needs to

be discussed.


Absolutely.  Public discussion of all submitted patches is essential.

When you can commit to public discussion of submitted patches
then I'll re-send at least one.  (Something very minor.)

Another topic which is needed to be included is documentation.  

This

would be to organise the documentation and make sure all features

are

documented, review documentation to make sure it works as expected

etc,
etc.  This part do not necessarily require any coding skills at 

all.


However, it _could_ be a requirement that all patches be submitted
with documentation.  If not, I can't see how you'd want to
include any functional changes without also having documentation
so somebody else would have to be gotten to document the patch.
This is obviously up to whomever reviews the patches.



What I do see as much more urgent is actually a better distributed
VCS/RCS.  I believe SVN is used now - but I don't recall where I

found

the URL for it (and I have lost now, I believe).  There's also a

rather

outdated CVS tree on sourceforge.net.  This needs to be cleaned up,

and

a publicly available source tree must be made available.



David Sommerseth



The SVN repository URL's are here:

http://www.openvpn.net/index.php/open-source/documentation/
miscellaneous/subversion-repository.html

I checked the logs and last update in 2.1 branch was from 2009-11-20,
so
it's probably 100% up-to-date. I agree with you for the most part.
Beaker sounds interesting, as I guess OpenVPN probably lends itself
well
to automated testing. 


Are you saying that there has been no development on OpenVPN since
2009-11-20, approximately 20 days ago?  That seems a long time
for James to have done no work on the code or documentation.

A public revision control repository means that the public gets
to see all the changes as they are committed.  It does not mean
that we get to see the code only at arbitrary release points.

There are 2 reasons for this.  The first is trust and transparency.
We want to see where the code is going as it gets there so
we can make our plans.  The second is to assist the people who
review submitted patches.  Submitted patches should, by
strong preference, be against the very latest version
of the code.  This keeps merge conflicts, and related bugs,
to a minimum and makes the job of reviewing patches much
easier.

If you don't have a public version of the latest development
code you can't be said to be running an open project.

FWIW using a good (rather than merely adequate) revision control
system makes it much easier to keep the very latest code
on-line and still perform regression tests, keep separate
code branches for feature development, and so forth.

What's the real policy regards the SVN repository and
what are the concerns that have driven this policy?


I wanted to respond to some of the points brought up, as they are good 
points.


First of all, the patch policy: fundamentally, we have to balance two 
conflicting goals:


One the one hand people expect OpenVPN to be rock-solid in both 
stability and security.  In order to maintain this standard of quality, 
there needs to be a rigorous process of patch vetting.  On the other 
hand, as an open source project, OpenVPN needs to be transparent and 
open to contributions from the community.


It can be a challenge to balance these goals.  And certainly in the 
lead-up to the release of 2.1 there was a long period of time that we 
had to lean strongly towards (1) to ensure that 2.1 final would be solid.


I think it's great that Samuli Seppänen has come forward to serve as the 
OpenVPN Community Manager -- one of our key goals here is to create a 
community structure around the patch 

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

Davide,

Try adding the "nobind" directive to your client config file.  I think 
this will solve the problem.


James

Davide Brini wrote:

On Thursday 12 November 2009, David Sommerseth wrote:


On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf

On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


Sorry to jump in here, but I've run into a weird behavior when using multihome 
in all versions, up to rc15 (I haven't tried later versions, but I guess that 
it would be the same thing since I don't see anything related to this in the 
changelog). I'm using Gentoo on both the client and the server.


In short, it seems that, despite having "multihome" enabled, the server still 
sends replies back to the client out the "wrong" interface, but only under 
certain (not clearly defined) conditions and only after some time(?).


Here is the server config (don't mind IP addresses, this is a lab network):

port 1194
multihome   
proto udp

dev tap0
ca ca.crt
cert server.crt
key server.key
script-security 2
up up.sh
down down.sh
dh dh1024.pem
server-bridge 10.0.1.251 255.255.255.0 10.0.1.10 10.0.1.20
ifconfig-pool-persist ipp.txt
client-to-client
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 6

And here is the client config:

client
remote 1.1.1.1 1194
remote 2.2.2.2 1194
remote-random
proto udp
dev tap0
ca ca.crt
cert client.crt
key client.key
keepalive 10 120
comp-lzo
persist-key
persist-tun
verb 3

What I've noticed is that the very first connection from a client, regardless 
of the interface it hits, works fine. But for example, if that same client 
disconnects and then reconnects to the other interface (because of the remote-
random option), then the problem happens. However, if another client connects 
second (rather than the first one disconnecting and reconnecting), the second 
client doesn't have problems, regardless of the interface it connects to.
Here is an excerpt of the server log taken during the very first client 
connection:


--
Thu Nov 12 19:58:16 2009 us=7043 192.168.2.2:1194 TLS: Initial packet from 
192.168.2.2:1194 (via 2.2.2.2), sid=68a926bd 92b98d25
Thu Nov 12 19:58:16 2009 us=7235 192.168.2.2:1194 UDPv4 WRITE [26] to 
192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 0 ] 
pid=0 DATA len=0


Thu Nov 12 19:58:16 2009 us=146570 192.168.2.2:1194 Data Channel Encrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146664 192.168.2.2:1194 Data Channel Encrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication
Thu Nov 12 19:58:16 2009 us=146802 192.168.2.2:1194 Data Channel Decrypt: 
Cipher 'BF-CBC' initialized with 128 bit key
Thu Nov 12 19:58:16 2009 us=146886 192.168.2.2:1194 Data Channel Decrypt: 
Using 160 bit message hash 'SHA1' for HMAC authentication

...
Thu Nov 12 19:58:16 2009 us=151489 192.168.2.2:1194 Control Channel: TLSv1, 
cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 1024 bit RSA
Thu Nov 12 19:58:16 2009 us=151588 192.168.2.2:1194 [Test-Client] Peer 
Connection Initiated with 192.168.2.2:1194 (via 2.2.2.2)
Thu Nov 12 19:58:17 2009 us=181119 Test-Client/192.168.2.2:1194 UDPv4 READ 
[104] from 192.168.2.2:1194 (via 2.2.2.2): P_CONTROL_V1 kid=0 [ ] pid=26 DATA 
len=90
Thu Nov 12 19:58:17 2009 us=181558 Test-Client/192.168.2.2:1194 PUSH: Received 
control message: 'PUSH_REQUEST'
Thu Nov 12 19:58:17 2009 us=181841 Test-Client/192.168.2.2:1194 SENT CONTROL 
[Test-Client]: 'PUSH_REPLY,route-gateway 10.0.1.251,ping 10,ping-restart 
120,ifconfig 10.0.1.10 255.255.255.0' (status=1)

...
Thu Nov 12 19:58:30 2009 us=170924 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[77] to 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76
Thu Nov 12 19:58:30 2009 us=172448 Test-Client/192.168.2.2:1194 UDPv4 READ 
[77] from 192.168.2.2:1194 (via 2.2.2.2): P_DATA_V1 kid=0 DATA len=76

Thu Nov 12 19:58:30 2009 us=172747 Test-Client/192.168.2.2:1194 TUN WRITE [42]
---

As you can see, the connection keeps using the 2.2.2.2 IP address. The 
connection works fine indeed. So far so good. But here's what happens if the 
client disconnects and reconnects to the other IP address (excerpts):


---
Thu Nov 12 19:58:47 2009 us=536468 Test-Client/192.168.2.2:1194 TLS: new 
session incoming connection from 192.168.2.2:1194 (via 1.1.1.1)
Thu Nov 12 19:58:47 2009 us=536712 Test-Client/192.168.2.2:1194 UDPv4 WRITE 
[26] to 192.168.2.2:1194 (via 1.1.1.1): P_CONTROL_HARD_RESET_SERVER_V2 kid=0 [ 
0 ] pid=0 DATA len=0
Thu Nov 12 19:58:47 2009 us=538918 Test-Client/192.168.2.2:1194 UDPv4 READ 
[22] from 192.168.2.2:1194 (via 1.1.1.1): P_ACK_V1 kid=0 

Re: [Openvpn-devel] 2.1 rc20 and multiple interfaces problem

[James Yonan]

David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/09 19:33, Olaf Fraczyk wrote:

Hello,

No, I wasn't using --multihome - I didn't know that this option exists
and that is necessary. I haven't found it in man page and in
documentation on the web page. The only place where I found it (after
you let me know about it) was with openvpn --help.

Thank you, I'll try it.
BTW, why is it not by default?

Regards,

Olaf
On Thu, 2009-11-12 at 04:15 -0700, James Yonan wrote:

Are you using the --multihome option?


James, this option is not documented in the man pages, AFAICS.  Could
that be the reason the needed use was not discovered?


I've documented --multihome in the man page.  The change has been 
checked into svn and will be in the next release.


James

[Openvpn-devel] Prebuilt tarball available for 2.1_rc22

[James Yonan]

http://openvpn.net/prebuilt/2.1_rc22-prebuilt.tbz

Re: [Openvpn-devel] Character classes in the tls-verify script

[James Yonan]

Victor Wagner wrote:
> On 2009.10.24 at 13:39:56 -0600, James Yonan wrote:
>
>> Can you submit a patch (as an email attachment) with this fix?
> Attached
>
> This patch also contains X509_NAME_oneline replacement, which handles
> MSB characters.
>
> I've not checked if this patch applies cleanly to unmodified source.
> I've just diffed original 2.1_rc19 source, imported in our subversion
> repository with current working copy and removed all irrelevant chunks.

Thanks for putting this together.

I'm a bit concerned about changing any of the remapping behavior unless 
no-name-remapping is specified.  I see that in some areas, you test the 
no-name-remapping flag before you modify existing behavior, but in other 
areas such as my_X509_NAME_oneline, X509_NAME_CHAR_CLASS, and 
COMMON_NAME_CHAR_CLASS you don't.


Would it be possible for you to rework the patch so that it's a no-op 
unless no-name-remapping is specified?


James

Victor Wagner wrote:

On 2009.10.24 at 13:39:56 -0600, James Yonan wrote:


Can you submit a patch (as an email attachment) with this fix?
Attached 


This patch also contains X509_NAME_oneline replacement, which handles
MSB characters.

I've not checked if this patch applies cleanly to unmodified source.
I've just diffed original 2.1_rc19 source, imported in our subversion
repository with current working copy and removed all irrelevant chunks.






--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9 - 12, 2009. Register now!

http://p.sf.net/sfu/devconference




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

Re: [Openvpn-devel] Questions related to the SSL renegotiation vulnerability

[James Yonan]

Well the problem is that even though OpenVPN doesn't rely on OpenSSL 
renegotiations, it does not explicitly disable them.  So to be safe, 
it's better to upgrade to the fixed version of OpenSSL (0.9.8l).


Also note that using tls-auth prevents the cited MITM attack 
(CVE-2009-3555) even when using a vulnerable version of OpenSSL, as long 
as the MITM attacker doesn't possess the tls-auth key.


James

Dunc wrote:

Hi James,

Thanks for getting back to me.

I was starting to wonder the same myself, but when I found this thread

http://article.gmane.org/gmane.network.openvpn.user/28105

I thought I must be missing something.

So if OpenVPN always uses a new session, what would be the point of
adding an option to disable renegotiation at the server side?


Cheers,

Dunc


James Yonan wrote:

OpenVPN uses a fresh SSL/TLS session for each of its mid-session
renegotiations.  This means that when you see:

  TLS: soft reset sec=0 bytes=314/0 pkts=6/0

OpenVPN is actually creating a brand new SSL/TLS session.  So the
important point here is that OpenVPN does not rely on the session
renegotiation capability that is built into SSL/TLS, and therefore if
OpenVPN is linked against an OpenSSL library that disables SSL/TLS
renegotiation, there should be no loss of functionality.

James

Dunc wrote:

Hi all,

Apologies in advance if I'm just not understanding something here.

Following on from the recent SSL renegotiation problem, we're assessing
what we should do with all our SSL services, and as we use OpenVPN in
several places, this is on the list.

I thought that OpenVPN does renegotiations when re-keying, so at first I
thought I'd try and turn it off at the server end. From reading the docs
and testing I now know that it's not good enough as by default clients
will want to re-key after 1 hour unless it is turned off in the client
config too.

It might be hard to ensure that all our customers adjust their config
properly, so I'd rather deal with this at the server end only, so my
next thought was to install openssl-0.9.8l which bans renegotiation. I
figured this would make the VPN drop once an hour, but figured that's
not so bad in the grand scheme of things, and if it's really a problem
for anyone we can fix it by having them adjust the client config. This
was round seems more favourable as I can be sure renegotiations are
disabled, and work around the fallout.

So, I installed the latest openssl on a test box, and compiled openvpn.
I set the reneg-sec option to 40s on my client and fired up the VPN,
fully expecting it to bounce after 40s. Instead, what I see is this
message in the logs:-

Nov 11 14:13:51 2009 us=763149 TLS: soft reset sec=0 bytes=314/0 pkts=6/0

and then both ends seem to agree on some new crypto, and everything
carries on.


At first I thought maybe what OpenVPN does isn't the same as SSL
renegotiation and I had no need to worry anyway, but then I found this
thread...

http://article.gmane.org/gmane.network.openvpn.user/28105

where there is discussion about adding an option to openvpn to disable
it, so I now think I should indeed be concerned, but I must be missing
something obvious, and wondered if anybody here can help me.

I've checked with openssl s_server and s_client that my new openssl does
indeed ban renegotiation, so I wonder exactly what OpenVPN is doing
during rekeying.

Thanks in advance if anyone can shed light on this for me, and once
again sorry if I'm just misunderstanding, which is quite possible :-)

Cheers,

Dunc

--

Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day trial. Simplify your report design, integration and deployment
- and focus on what you do best, core application coding. Discover
what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] OpenVPN 2.1_rc21 released

[James Yonan]

This release is to respond to the OpenSSL vulnerability CVE-2009-3555.

Some people have worried that the fix made to OpenSSL to address this
vulnerability (ban all SSL/TLS renegotiations) would break OpenVPN's
session renegotiation capability.  This is not the case.  OpenVPN does 
not rely on the session renegotiation capability that is built into 
SSL/TLS, and therefore if OpenVPN is linked against an OpenSSL library 
that disables SSL/TLS renegotiation, there should be no loss of 
functionality.


Changes:

2009.11.12 -- Version 2.1_rc21

* Rebuilt OpenVPN Windows installer with OpenSSL 0.9.8l to address
  CVE-2009-3555.  Note that OpenVPN has never relied on the session
  renegotiation capabilities that are built into the SSL/TLS protocol,
  therefore the fix in OpenSSL 0.9.8l (disable SSL/TLS renegotiation
  completely) will not adversely affect OpenVPN mid-session SSL/TLS
  renegotation or any other OpenVPN capabilities.

* Added additional session renegotiation hardening.  OpenVPN has always
  required that mid-session renegotiations build up a new SSL/TLS
  session from scratch.  While the client certificate common name is
  already locked against changes in mid-session TLS renegotiations, we
  now extend this locking to the auth-user-pass username as well as all
  certificate content in the full client certificate chain.

James

Re: [Openvpn-devel] Questions related to the SSL renegotiation vulnerability

[James Yonan]

OpenVPN uses a fresh SSL/TLS session for each of its mid-session 
renegotiations.  This means that when you see:


  TLS: soft reset sec=0 bytes=314/0 pkts=6/0

OpenVPN is actually creating a brand new SSL/TLS session.  So the 
important point here is that OpenVPN does not rely on the session 
renegotiation capability that is built into SSL/TLS, and therefore if 
OpenVPN is linked against an OpenSSL library that disables SSL/TLS 
renegotiation, there should be no loss of functionality.


James

Dunc wrote:

Hi all,

Apologies in advance if I'm just not understanding something here.

Following on from the recent SSL renegotiation problem, we're assessing
what we should do with all our SSL services, and as we use OpenVPN in
several places, this is on the list.

I thought that OpenVPN does renegotiations when re-keying, so at first I
thought I'd try and turn it off at the server end. From reading the docs
and testing I now know that it's not good enough as by default clients
will want to re-key after 1 hour unless it is turned off in the client
config too.

It might be hard to ensure that all our customers adjust their config
properly, so I'd rather deal with this at the server end only, so my
next thought was to install openssl-0.9.8l which bans renegotiation. I
figured this would make the VPN drop once an hour, but figured that's
not so bad in the grand scheme of things, and if it's really a problem
for anyone we can fix it by having them adjust the client config. This
was round seems more favourable as I can be sure renegotiations are
disabled, and work around the fallout.

So, I installed the latest openssl on a test box, and compiled openvpn.
I set the reneg-sec option to 40s on my client and fired up the VPN,
fully expecting it to bounce after 40s. Instead, what I see is this
message in the logs:-

Nov 11 14:13:51 2009 us=763149 TLS: soft reset sec=0 bytes=314/0 pkts=6/0

and then both ends seem to agree on some new crypto, and everything
carries on.


At first I thought maybe what OpenVPN does isn't the same as SSL
renegotiation and I had no need to worry anyway, but then I found this
thread...

http://article.gmane.org/gmane.network.openvpn.user/28105

where there is discussion about adding an option to openvpn to disable
it, so I now think I should indeed be concerned, but I must be missing
something obvious, and wondered if anybody here can help me.

I've checked with openssl s_server and s_client that my new openssl does
indeed ban renegotiation, so I wonder exactly what OpenVPN is doing
during rekeying.

Thanks in advance if anyone can shed light on this for me, and once
again sorry if I'm just misunderstanding, which is quite possible :-)

Cheers,

Dunc

--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with

Crystal Reports now.  http://p.sf.net/sfu/bobj-july
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] Feature request: Client-side username/password retrieval using environment variables

[James Yonan]

The Zep Man wrote:

Dear openvpn-devel list,

OpenVPN supports verification of a username/password combination on the 
server-side by parsing these to a 'script' using auth-user-pass-verify'. 
With this, it is possible to use a file ('via-file') or environment 
variables ('via-env') to parse the given username and password for 
verification. The 'script' returns exit code 0 if the username and 
password are correct or non-0 if they are incorrect.


On the client-side, the only way to specify a username and a password 
(using the option 'auth-user-pass') is by directly using the OpenVPN 
prompt or (by default not possible because it isn't copmiled in) by 
using a file with on the first line the username and on the second line 
the password.


While it is easy to extend the username/password verification on the 
server, it isn't easy to extend the username/password input on the 
client. Even if OpenVPN is recompiled with the required option enabled 
for the client to accept a username/password from an earlier process, it 
is far from secure (because under some OS, like Windows, the 
username/password combination must be written plain-text to the disk for 
this to work).


Would it be a good idea to let OpenVPN on the client-side accept a 
username and a password as input from two separate environment variables 
using an extra option in the configuration file (when 'auth-user-pass' 
is also used)? This would make it easier to write an enduser-friendly 
front-end for OpenVPN which asks for an username and password.


My suggestion is to extend 'auth-user-pass [up]' to 'auth-user-pass 
via-file [up]' and 'auth-user-pass via-env'. By using 'via-env', the 
username and password should be taken from pre-specified environment 
variables. Perhaps the environment variables should be 'username' and 
'password', the same names 'auth-user-pass-verify' on the server uses.


Because this option would be more secure for Windows, would it also be 
possible to enable 'auth-user-pass via-env' by default during compilation?


The best way to programmatically supply the username/password on the 
client side is to use the OpenVPN management interface.


James

[Openvpn-devel] OpenVPN 2.1_rc20 released

[James Yonan]

2009.10.01 -- Version 2.1_rc20

* Fixed a bug introduced in 2.1_rc17 (svn r4436) where using the
  redirect-gateway option by itself, without any extra parameters,
  would cause the option to be ignored.

* Fixed build problem when ./configure --disable-server is used.

* Fixed ifconfig command for "topology subnet" on FreeBSD (Stefan Bethke).

* Added --remote-random-hostname option.

* Added "load-stats" management interface command to get global server
  load statistics.

* Added new ./configure flags:

  --disable-def-auth  Disable deferred authentication
  --disable-pfDisable internal packet filter

* Added "setcon" directive for interoperability with SELinux (Sebastien
  Raveau).

* Optimized PUSH_REQUEST handshake sequence to shave several seconds
  off of a typical client connection initiation.

* The maximum number of "route" directives (specified in the config
  file or pulled from a server) can now be configured via the new
  "max-routes" directive.

* Eliminated the limitation on the number of options that can be pushed
  to clients, including routes.  Previously, all pushed options needed
  to fit within a 1024 byte options string.

* Added --server-poll-timeout option : when polling possible remote
  servers to connect to in a round-robin fashion, spend no more than
  n seconds waiting for a response before trying the next server.

* Added the ability for the server to provide a custom reason string
  when an AUTH_FAILED message is returned to the client.  This
  string can be set by the server-side managment interface and read
  by the client-side management interface.

* client-kill management interface command, when issued on server, will
  now send a RESTART message to client.
  This feature is intended to make UDP clients respond the same as TCP
  clients in the case where the server issues a RESTART message in
  order to force the client to reconnect and pull a new options/route
  list.

Re: [Openvpn-devel] [PATCH] Post-initialization SELinux support for OpenVPN

[James Yonan]

Sebastien Raveau wrote:

Hi everybody!


OpenVPN already has support for dropping privileges and confining
itself to a directory *after* startup (thanks to calls like setgid,
setuid and chroot) which makes for much better management than if you
had to respectively start OpenVPN unprivileged and add the privileges
it (only) needs during startup, or if you chroot'ed OpenVPN before
startup and had to copy the necessary files in the confinement
directory.

The very same problem occurs with SELinux policy enforcement: one can
apply a policy before startup (such as the ready-to-use one provided
by 
http://oss.tresys.com/projects/refpolicy/browser/trunk/policy/modules/services/openvpn.te)
but it is wy too complicated, just because many rights have to be
granted to OpenVPN during its initialization... or one can apply a
very simple SELinux policy to OpenVPN when the only need left is
basically network I/O operations.

The only downside to this is that, just like with setuid() and
chroot(), OpenVPN has to call setcon() itself, which is why I am
submitting this patch :-)

Please note that, while this patch does indeed bring a new dependency
to libselinux in OpenVPN on Linux:
* the feature will of course only be added if detected by ./configure
* libselinux is so common now that even /bin/ls is linked against it
on most Linux systems
so OpenVPN should get SELinux support quite transparently ;-)


Sebastien,

This looks good...  Thanks for putting it together!

A couple things:

Can you adapt the patch to the OpenVPN 2.1 branch?

Can you modify the patch slightly so that no code is added unless #ifdef 
HAVE_SETCON is true?


Thanks,
James

Re: [Openvpn-devel] PATCH 2.1-RC*: critical fix for FreeBSD 8 in topology subnet mode.

[James Yonan]

Thanks Stefan and Matthias.  I've committed the patch.

James

Matthias Andree wrote:

Hi Jim,

there has been a recent change in FreeBSD 8 BETA that will break OpenVPN
2.1's "topology subnet" mode by (rightfully!) rejecting the ifconfig
command we're currently using (which incorrectly sets the local and
remote P2P IPv4 addresses to be the same, the FreeBSD 8 kernel will
reject that.)

FreeBSD's TUN interface can be switched from P2P to broadcast mode
however, which we will need to leverage in order to support subnet
topology.

Stefan Bethke (in CC) has written, revised and tested an OpenVPN patch
that works on all currently supported FreeBSD 6.X and 7.X versions and
also the upcoming FreeBSD 8.0. The patch makes sure that the tun
interface is switched to broadcast mode and configured appropriately.

Find it inlined below for easier review and also attached.

Please apply!

Thank you.

Best regards
Matthias
OpenVPN packager for FreeBSD ports

--- /home/stb/tun.c.orig2009-08-05 14:25:55.204943408 +0200
+++ tun.c   2009-08-05 17:57:51.886753309 +0200
@@ -863,11 +863,10 @@
   else {
if (tt->topology == TOP_SUBNET)
 argv_printf (,
-  "%s %s %s %s netmask %s mtu %d up",
+  "%s %s %s netmask %s mtu %d up",
   IFCONFIG_PATH,
   actual,
   ifconfig_local,
-  ifconfig_local,
   ifconfig_remote_netmask,
   tun_mtu
   );
@@ -1745,14 +1744,19 @@
 {
   open_tun_generic (dev, dev_type, dev_node, ipv6, true, true, tt);
 
-  if (tt->fd >= 0)

+  if (tt->fd >= 0 && tt->type == DEV_TYPE_TUN)
 {
   int i = 0;
 
-  /* Disable extended modes */

-  ioctl (tt->fd, TUNSLMODE, );
+  i = tt->topology == TOP_SUBNET ? IFF_BROADCAST : IFF_POINTOPOINT;
+  i |= IFF_MULTICAST;
+  if (ioctl (tt->fd, TUNSIFMODE, ) < 0) {
+   msg (M_WARN | M_ERRNO, "ioctl(TUNSIFMODE): %s", strerror(errno));
+  }
   i = 1;
-  ioctl (tt->fd, TUNSIFHEAD, );
+  if (ioctl (tt->fd, TUNSIFHEAD, ) < 0) {
+   msg (M_WARN | M_ERRNO, "ioctl(TUNSIFHEAD): %s", strerror(errno));
+  }
 }
 }
 

Re: [Openvpn-devel] OpenVPN 2.1_rc19 released

[James Yonan]

Matthias Andree wrote:

James Yonan schrieb:


2009.07.16 -- Version 2.1_rc19

...


* In configure.ac, use datadir instead of datarootdir for compatibility
   with 

Dear Jim,

This is backwards.  Please don't do that, but revert that change and
instead update the argument of AC_PREREQ in configure.ac to read this:
AC_PREREQ(2.60)

Since you're using autoconf/automake, configure.ac changes and
requirements have zero impact on end users who download the tarball that
you generate through "make dist". Such changes only affects developers
who want to hack configure.ac or use the SVN version, and you can simply
expect them to have an autoconf version no older than 36 months.

In my experience, newer autoconf versions are more portable, have less
bugs, and are good for a much smoother ride than older versions.

I'm happy to look into updating configure.ac, which in general needs an
overhaul anyways - unless you say "no configure.ac updates before 2.1
release".


We need to be able to build OpenVPN on older Linux distros, such as RHEL 
4, that use pre-2.60 versions of autoconf.


Before I made this change, I found that the previous code (using 
datarootdir instead of datadir on RHEL 4, autoconf-2.59-5) would 
generate a make install script that violated the --prefix argument -- 
i.e. make install would try to write stuff outside the --prefix dir.  I 
was running the make install as a non-root user, so the jailbreak out of 
--prefix was obvious because it tried to write to parts of the 
filesystem that generated "permission denied" errors and halted the script.


I'm not an autoconf/automake expert, so if there's a better way to fix 
the issue, I'm open to it.


James

[Openvpn-devel] OpenVPN 2.1_rc19 released

[James Yonan]

This release fixes an issue with the Windows TAP driver that can cause 
BSODs on Vista (normally seen in the OpenVPN client).  The problem is 
that Windows has always restricted kernel threads to a very small stack 
size (12KB on x86 32-bit).  If they go over this limit, Windows will 
crash with a BSOD.  Apparently Vista has added a bit more bloat to its 
kernel stack usage, and as a result, when the TAP driver is called, and 
then it in turn calls other kernel-level functions, there is a chance 
that the kernel stack can overflow in a particular sequence of code that 
is executed when the client initially connects and gets an IP address 
assignment from the server.  Apparently because XP is more efficient in 
its use of stack space, the same build of the TAP driver running on XP 
does not exhibit this defect.


2009.07.16 -- Version 2.1_rc19

* In Windows TAP driver, refactor DHCP/ARP packet injection code to
  use a DPC (deferred procedure call) to defer packet injection until
  IRQL < DISPATCH_LEVEL, rather than calling NdisMEthIndicateReceive
  in the context of AdapterTransmit.  This is an attempt to reduce kernel
  stack usage, and prevent EXCEPTION_DOUBLE_FAULT BSODs that have been
  observed on Vista.  Updated TAP driver version number to 9.6.

* In configure.ac, use datadir instead of datarootdir for compatibility
  with 

Re: [Openvpn-devel] Packet filtering in OpenVPN

[James Yonan]

Arne Schwabe wrote:

Hello,

I am at the moment looking to integrating packet filtering into OpenVPN. My
reason to do so, are the following: 


- Windows own Firewall does not work when routing/bridging is used
- I am not aware of a OpenSource Firewall for windows 
- Being able to do NAT without the help of the operating system can be very

nice

I have not yet looked very much at the code. But I would like to ask if
this is a feature which could go into the main OpenVPN release. If I
unterstood this correctly the OpenVPN code is currently released under GPL
but available under a non GPL license. So newly added code needs to honour
this. But BSD licensed code (eg. parts of ipfw2 or pf code) would be okay?


There is already rudimentary packet filtering code in OpenVPN -- see
pf.[ch] in the beta 2.1 branch.

James

Re: [Openvpn-devel] OpenVPN 2.1_rc17 released

[James Yonan]

David Sommerseth wrote:


James Yonan wrote:

Change Log:

2009.05.30 -- Version 2.1_rc17

* Reduce the debug level (--verb) at which received management interface
   commands are echoed from 7 to 3.  Passwords will be filtered.

* Fixed race condition in management interface recv code on
   Windows, where sending a set of several commands to the
   management interface in quick succession might cause the
   latter commands in the set to be ignored.

* Increased management interface input command buffer size
   from 256 to 1024 bytes.

* Minor tweaks to Windows build system.

* Added "redirect-private" option which allows private subnets
   to be pushed to the client in such a way that they don't accidently
   obscure critical local addresses such as the DHCP server address and
   DNS server addresses.

* Added 'autolocal' redirect-gateway flag.  When enabled, the OpenVPN
   client will examine the routing table and determine whether (a) the
   OpenVPN server is reachable via a locally connected interface, or (b)
   traffic to the server must be forwarded through the default router.
   Only add a special bypass route for the OpenVPN server if (b) is true.
   If (a) is true, behave as if the 'local' flag is specified, and do not
   add a bypass route.

   The new 'autolocal' flag depends on the non-portable test_local_addr()
   function in route.c, which is currently only implemented for Windows.
   The 'autolocal' flag will act as a no-op on platforms that have not
   yet defined a test_local_addr() function.

* Increased TLS_CHANNEL_BUF_SIZE to 2048 from 1024 (this will allow for
   more option content to be pushed from server to client).

* Raised D_MULTI_DROPPED debug level to 4 from 3 to filter out (at debug
   levels <=3) a common and usually innocuous warning.

* Fixed issue of symbol conflicts interfering with Windows CryptoAPI
   functionality (Alon Bar-Lev).

* Fixed bug where the remote_X environmental variables were not being
   set correctly when the 'local' option is specifed.

James


I just compared the 2.1_rc16 and 2.1_rc17 trees ... I see these files in 
the tar ball in addition:


contrib/pull-resolv-conf/client.down.bak
contrib/pull-resolv-conf/client.up.bak
easy-rsa/2.0/pkitool.bak
plugin/auth-pam/auth-pam.c.bak
plugin/defer/simple.c.bak
plugin/down-root/down-root.c.bak
plugin/examples/log.c.bak
plugin/examples/simple.c.bak
tap-win32/common.h.bak
tap-win32/constants.h.bak
tap-win32/dhcp.c.bak
tap-win32/dhcp.h.bak
tap-win32/endian.h.bak
tap-win32/error.c.bak
tap-win32/error.h.bak
tap-win32/hexdump.c.bak
tap-win32/hexdump.h.bak
tap-win32/i386/OemWin2k.inf.in.bak
tap-win32/instance.c.bak
tap-win32/lock.h.bak
tap-win32/macinfo.c.bak
tap-win32/macinfo.h.bak
tap-win32/mem.c.bak
tap-win32/proto.h.bak
tap-win32/prototypes.h.bak
tap-win32/tapdrvr.c.bak
tap-win32/types.h.bak

Just a missing clean-up?  or something we should be worried about?


This is fixed in rc18.  The .bak files were just left over from an 
automated script that updates the copyright year in the source files.


James

[Openvpn-devel] OpenVPN 2.1_rc18 released

[James Yonan]

2009.06.07 -- Version 2.1_rc18

* Fixed compile error on ./configure --enable-small

* Fixed issue introduced in r4475 (2.1-rc17) where cryptoapi.c change
  does not build on Windows on non-MINGW32.

James

Re: [Openvpn-devel] Loss of routes causes routing loop

[James Yonan]

Daniel Johnson wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl O. Pinc wrote:

Openvpn does not do DNS at all.  You can use it to push DNS related
DHCP options to the "clients" so that they are directed to a DNS
server that does the right thing.  (There may be a way to do
something similar in a "client-side" config, I don't recall.) That's
about it.


Sorry, I wasn't specific.  My clients look up
"openvpn1[2,3,4].chguernsey.com" to connect, and I'm interested in how
it handles the results.  I expect it uses the Windows resolver, and
that it will receive all of the numeric results.  So if I change my
DNS entries to report
  PTR mercury.chguernsey.com.
  A   65.120.131.235
  A   172.21.166.249
can I get the client to "notice" that it is directly connected to the
172.21.166 subnet and use that IP?

For the moment I'm pursuing a split-view DNS to report only the
internal address on that subnet.  It should hide the effects of the
routing-loop problem until it can be properly resolved.


Daniel,

Earlier you mentioned that "In wireless use, we find that Windows will
dump SOME of the routes created by OpenVPN when the radio changes APs".

When this occurs, does it trigger a reconnection by the OpenVPN clients
to the server?  If so, you can ensure that client-side routes are reset
as part of the reconnection by NOT using the "persist-tun" directive in
the client config file.

James

[Openvpn-devel] OpenVPN 2.1_rc17 released

[James Yonan]

Change Log:

2009.05.30 -- Version 2.1_rc17

* Reduce the debug level (--verb) at which received management interface
  commands are echoed from 7 to 3.  Passwords will be filtered.

* Fixed race condition in management interface recv code on
  Windows, where sending a set of several commands to the
  management interface in quick succession might cause the
  latter commands in the set to be ignored.

* Increased management interface input command buffer size
  from 256 to 1024 bytes.

* Minor tweaks to Windows build system.

* Added "redirect-private" option which allows private subnets
  to be pushed to the client in such a way that they don't accidently
  obscure critical local addresses such as the DHCP server address and
  DNS server addresses.

* Added 'autolocal' redirect-gateway flag.  When enabled, the OpenVPN
  client will examine the routing table and determine whether (a) the
  OpenVPN server is reachable via a locally connected interface, or (b)
  traffic to the server must be forwarded through the default router.
  Only add a special bypass route for the OpenVPN server if (b) is true.
  If (a) is true, behave as if the 'local' flag is specified, and do not
  add a bypass route.

  The new 'autolocal' flag depends on the non-portable test_local_addr()
  function in route.c, which is currently only implemented for Windows.
  The 'autolocal' flag will act as a no-op on platforms that have not
  yet defined a test_local_addr() function.

* Increased TLS_CHANNEL_BUF_SIZE to 2048 from 1024 (this will allow for
  more option content to be pushed from server to client).

* Raised D_MULTI_DROPPED debug level to 4 from 3 to filter out (at debug
  levels <=3) a common and usually innocuous warning.

* Fixed issue of symbol conflicts interfering with Windows CryptoAPI
  functionality (Alon Bar-Lev).

* Fixed bug where the remote_X environmental variables were not being
  set correctly when the 'local' option is specifed.

James

Re: [Openvpn-devel] Get server to listen for TCP and UDP connections

[James Yonan]

David Sommerseth wrote:

M. G. wrote:

Hello,
 
I recently changed my VPN-tunnel from TCP to UDP for the sake of better 
performance. It generally works very well but I noticed that I can't 
connect to my server from some networks when using UDP, e.g. at work. 
This may be an issue with the NAT/firewall configuration which I have no 
influence on.
Since I am connecting from random locations where I don't know 
beforehand if a UDP connection will succeed, I'm now kind of worried 
that it'll get a game of luck if a connection succeeds from a specific 
location.
 
So far my story, now to the question:
What is the reason that OpenVPN doesn't have an option to listen for TCP 
AND UDP connections simultaneously? Is it a technical problem that I 
cannot see, or am I simply the only one who thinks this would be a nice 
feature?


In theory, you are very right, this should not be a big issue.  But I 
believe this is connected to that openvpn is neither forked nor threaded 
when working with connections.  It's all in the same process scope, which 
does its own scheduling regarding the connections, if I've understood the 
code right.  And to make the current implementation work concurrently with 
both TCP and UDP will be somewhat more difficult.  And due to this, openvpn 
do not really use the power of multi-core hosts as one single process can 
only be run on one core at the time.


I've been looking at the whole connection handling, and I've been 
considering to try to rewrite it and to use proper Posix threading.  The 
challenge with doing that is that it might not work so well on non-posix 
compatible platforms.  And I'm not sure how that would work for the Windows 
world.  But by moving over to a proper threading model, I'd expect both 
performance and scalability to improve, and also concurrent TCP and UDP 
setups to work out more easily.  And with several threads, openvpn can also 
make better use of all available CPU cores on the host.


I know I could run two server instances on different tun devices but I 
think it'd be much nicer (and resource-friendly) if I could just put 
"proto udp tcp-server" (or whatever) into the config file and be 
flexible with my connections to the server.


It would sure be nicer to use the same tun device, also from a
configuration perspective (less instances to take care of).  But I'm not 
sure it is that much more resource-friendly, except less memory usage 
perhaps.  The kernel usually won't spend much extra CPU time on sleeping 
processes or devices.


But on the other side, if your openvpn processes are configured to run on 
separate CPU cores, you might have a better performance if you have 
multiple clients connecting at the same time, given the status of the 
current scheduling implementation.


I worry about trying to debug multi-threaded code -- it could fail in 
non-deterministic ways.  How can we maintain product quality when the 
code could have subtle race conditions that only show up in heavy 
production usage and leave no useful info to enable its reproduction? 
Personally, multithreading scares me, as does any design pattern that 
has the potential to introduce non-deterministic bugs.


I would also argue that multithreading is not a performance panacea, 
because of the necessity of using locking primitives such as mutexes, 
etc. that lock the global bus, and the often overlooked costs of 
maintaining cache coherency among multiple processors and cores, when 
multiple threads are writing to the same data structures.


I believe a better alternative to multithreading, in OpenVPN's case, is 
to use multiple processes where each process has it's own asynchronous 
event reactor (e.g. Python/Twisted, libevent, Boost::Asio), and the 
processes communicate via messaging, such as over a local unix domain 
socket or Windows named pipe.  This also has a performance advantage, 
because separate processes aren't going to be fighting over the same memory.


James

Re: [Openvpn-devel] Unable to use -OFB or -CFB ciphers in OpenVPN

[James Yonan]

Victor Wagner wrote:

On 2009.05.27 at 10:48:30 -0700, Frank Yellin wrote:


   I posted the following onto the OpenVPN forum, but it was suggested
   that I would be better off mailing directly to this list.
   =
   I seem to have found a bug in 2.1_rc16 that is also apparent in earlier
   versions. Although OpenVPN claims to support -CFB and -OFB cipher
   modes, using them seems to cause OpenVPN to crash consistently.

   For example, when I run the simple TLS example on the 2.1 documentation
   page, it works fine.  But if I add "--cipher bf-cfb" to both the client
   and server command lines, one or the other will crash. The error
   message is always "Assertion failed at crypto.c:162". The crasher is
   always the first one to try and send an encrypted message.


I've reported this problem more than a year ago, but nothing changed.
I really don't understand why openvpn prefers CBC modes. There is
nothing wrong with CFB and OFB neither from securith nor from
performance point of view.

But it is not only problem with non-CBC ciphers. If you try to use
preshared keys, you'll find out that they are explicitely disabled
unless --test-crypto option is given, even if your compile with 
-DALLOW_NON_CBC_CIPHERS.


Also, I've encountered some problems with UDP transport and stream
ciphers which I haven't find time to debug yet.



The OFB and CFB cipher modes in OpenVPN have not been well-tested and 
should be considered experimental at this point.


They are not compiled by default mostly to prevent someone from 
accidentally using them.


James

Re: [Openvpn-devel] version 2.1

[James Yonan]

We will be releasing a new Windows GUI for 2.1 that properly uses the
management interface, and can be run by a user without administrator
privileges.  The GUI has already been developed and is available now
with our Access Server product.  We will be open-sourcing this Windows
client GUI as part of the final 2.1 release.

The new GUI is based on the portable WxWidgets library, and carries a
small footprint, so it shouldn't increase the size of the Windows client
installer by very much.

James

Carsten Krüger wrote:

Hello,


imho keep the current install too (or create 2 different installer) and
can add the link.


I think it wouldn't be a good idea to propagate openvpn gui for new
installations. It's dead.
Who ever like/need openvpn gui can download it from http://openvpn.se/

Maybe include both GUIs in the installer and mark openvpn gui as
deprecated (no default installation).

greetings
Carsten


--
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image 
processing features enabled. http://p.sf.net/sfu/kodak-com

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

[Openvpn-devel] ANNOUNCEMENT: OpenVPN Access Server beta available

[James Yonan]

 8, 9, 10
  * 64-bit Ubuntu 8, 9


--
   OpenVPN Access Server v1.1.0b2 (beta 2)
   RELEASE NOTES

Feedback and Support:

We appreciate your feedback on this release. Register and login
at the Support Center to use the support ticketing system:

  http://beta.openvpn.net/index.php/access-server/support-center.html


New in Access Server v1.1.0:
---

Below are the main enhancements added since the Access Server v1.0.0
release:

-- Admin Web UI for configuration and management, including improved
   configuration options

-- Simplified CLI utility (ovpn-init) for initial configuration

-- Multi-profile support on Windows Client GUI

-- New method of authenticating via LDAP with enhanced configurability


Changes Since Access Server v1.1.0b:
---

The Access Server v1.1.0b2 contains these improvements since the
v1.1.0b release:

-- Better interoperation with installed OpenVPN open-source clients
   (installer no longer removes all TAP interfaces)

-- Corrected version numbering of the Windows Client, so that it
   properly detects an installed OpenVPN-AS v1.0.0 client.

-- Fix for an issue occasionally seen on Windows Client GUI where
   the TAP adapter cannot get an IP address due to a problem in DHCP
   handshaking between the TAP adapter and the Windows DHCP client.

-- Fix for an iptables issue that caused NAT forwarding to fail.


Installation:


After installing the OpenVPN-AS package (e.g., using 'yum' on Fedora
platforms), run the initialization script:

/usr/local/openvpn_as/bin/ovpn-init

You will be prompted for initial settings for the Admin Web UI networking
and for authenticating the administrator. When ovpn-init completes, it
displays the URL to use for logging into the Admin Web UI to continue
configuring OpenVPN-AS.


License Keys:


You can use the Admin UI after ovpn-init completes. However, to turn on
the VPN Server component of OpenVPN-AS, you must have an activated
license key. To get started, you can obtain a free, 5-concurrent-user
license by registering and logging in at the License Key page:

  http://beta.openvpn.net/index.php/access-server/license-key.html

Enter the license key into the "New License Key" box of the "License"
page in the Admin Web UI.


Known Issues:


-- Accessing the Client Web Server without an activated license key
   yields an error message "error communicating with server agent".

-- Windows Client status display may remain at "Connecting TCP..."
   or "Connecting UDP..." when communication with VPN server fails.

-- Occasionally, when the Windows Client GUI attempts to connect to
   the VPN Server for the first time, the connection may stall at
   the "Connecting" stage and not complete.

-- Administrators should ensure that the VPN Server is not configured
   to run on the same (IP Address:port) combination as the Client Web
   Server or Admin UI.  Currently, the Admin UI does not flag this
   condition with an error, though it is an invalid configuration.

-- The PAM authentication module uses the 'sshd' PAM service, so the
   /etc/pam.d/sshd file must exist and be properly configured for
   user authentication.

-- The Ubuntu package does not configure the system so that the
   openvpnas service starts during system startup.


Best Regards,
James Yonan & the OpenVPN Technologies Team

[Openvpn-devel] Patch Queue, was: Re: [PATCH] Fix for "Cannot read current defaultgateway" problem on Linux

[James Yonan]

Alon Bar-Lev wrote:

On Tuesday 10 February 2009 13:35:35 David Balazic wrote:

Ping ?

Should I resend the patch without the end-of-line-spaces change ?


James has his own response times.
I suggest you have much patience :)

Alon.


I apologize for not having the bandwidth to focus as much on the patch 
queue as I would like, but please understand that we're on the verge of 
releasing 2.1 and we have to be very conservative about accepting 
patches at this point.


I think it's fair to ask that we try to limit ourselves at this late 
stage to patches that address issues that affect a large number of 
users, or bug fixes that are sufficiently trivial that there is little 
or no chance of causing unforeseen breakage.  I think there needs to be 
an argument for why the patch is important right now, as opposed to 
waiting a while for the 2.2 beta series.


Remember that sometimes just posting a patch here on the list is an 
optimal solution even if it is not immediately merged into the mainline 
-- people that need it can always apply it, and this allows the patch to 
be tested more extensively before it is merged.


James

Re: [Openvpn-devel] IPv6 Support

[James Yonan]

Marcel Pennewiß wrote:

On Thursday 13 November 2008 01:23:46 Marcel Pennewiß wrote:

Hi,


Hi again,


a long time ago Juanjo Ciarlante wrote a patch for openvpn to create a
tunnel via ipv6 [1]. Later i fixed the patch to work with openvpn-2.0 and
2.1 which i use on OpenWRT and Gentoo. Roy (from Gentoo) wrote about this
also to the devel-list [1]. But since that no one answered :(

What about IPv6-support to create a tunnel over IPv6? Since my first patch
i try to adapt the patch to newer versions. This patches are not properly
tested but works fine for me (on gentoo).[2][3]


What about full IPv6-support - is this scheduled in the future or on any 
roadmap? No answer is not a good practice :(


Full IPv6 support is planned for OpenVPN 3.

Some more details on OpenVPN 3:

OpenVPN 3.0 is a revamping of the OpenVPN core into a modular, more
maintainable architecture.  Planned features include:

* IPv6 support
* IP multicast support
* Pluggable crypto library support (so that crypto libraries other than
OpenSSL may be used)
* Pluggable packet filter and network access control API
* Pluggable dynamic routing API (BGP, OSPF, etc.)
* Support for full-mesh topologies (in addition to the star and
point-to-point topologies supported in OpenVPN 2.x)
* Library API support allowing OpenVPN tunnels to be programmatically
created and destroyed
* Embedding support to allow OpenVPN to be embedded in other applications
* Asynchronous, event driven I/O subsystem (in the vein of Twisted,
boost::asio, or libevent)

James

Re: [Openvpn-devel] OVPN patching process RE: [PATCH] Fix non-C89 comments

[James Yonan]

David,

A couple issues with the patch:

* sscanf usage doesn't check for buffer overflow.

* You use gw_if_name in some places and gw_ifname in other places.  To 
eliminate confusion it would be best to use a consistent form.


Also, to reiterate, try submitting the patch as an attachment to deal 
with email client munging issues.


Thanks,
James

David Balazic wrote:

Hi!

I sent a patch recently to the openvpn-devel list and got
no reply whatsoever. Did I miss something ? Is there a procedure
that I did not follow ?

That patch is to fix a longstanding bug that users encountered.

Regards,
David

PS: the mail message in question is :
Fix for "Cannot read current default gateway" problem on Linux
http://article.gmane.org/gmane.network.openvpn.devel/2472


-Original Message-
From: Alon Bar-Lev [mailto:alon.bar...@gmail.com] 
Sent: Tuesday, January 27, 2009 5:32 PM

To: openvpn-devel@lists.sourceforge.net
Subject: Re: [Openvpn-devel] [PATCH] Fix non-C89 comments

Sent this to James.
Did not apply.

My queue is at:
http://svn.openvpn.net/projects/openvpn/contrib/alon

On 1/27/09, Matthias Andree 
 wrote:

Hi,

 openvpn uses non-C89 //-style comments in two places. 

Patch to convert

 these to /* ... */ style comments attached.

 Best

 --

Matthias Andree



--


 This SF.net email is sponsored by:
 SourcForge Community
 SourceForge wants to tell your story.
 http://p.sf.net/sfu/sf-spreadtheword
___
 Openvpn-devel mailing list
 Openvpn-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/openvpn-devel




--

This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel



--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH] Fix non-C89 comments

[James Yonan]

Matthias Andree wrote:

On Tue, 27 Jan 2009, Alon Bar-Lev wrote:


Sent this to James.
Did not apply.

My queue is at:
http://svn.openvpn.net/projects/openvpn/contrib/alon


Perhaps the choice of version control system used for OpenVPN could
deserve a second thought -- Mercurial or better Git might support such
models or merge queues much better than Subversion does.


I'm on top of this -- Alon's queue including Jos Vos's [PATCH] Fix 
non-C89 comments has been merged:



r3899 | james | 2009-01-27 12:22:42 -0700 (Tue, 27 Jan 2009) | 2 lines
Changed paths:
   M /branches/BETA21/openvpn/proto.h
   M /branches/BETA21/openvpn/route.c

Fixed some issues with C++ style comments that leaked into the code.


r3900 | james | 2009-01-27 12:32:46 -0700 (Tue, 27 Jan 2009) | 2 lines
Changed paths:
   M /branches/BETA21/openvpn/error.c
   M /branches/BETA21/openvpn/ntlm.c
   M /branches/BETA21/openvpn/pkcs11.c
   M /branches/BETA21/openvpn/win32.h

Fixed some compile-time warnings.


r3901 | james | 2009-01-27 13:05:48 -0700 (Tue, 27 Jan 2009) | 2 lines
Changed paths:
   M /branches/BETA21/openvpn/configure.ac

Updated configure.ac to work on MinGW.


r3902 | james | 2009-01-27 13:10:49 -0700 (Tue, 27 Jan 2009) | 2 lines
Changed paths:
   M /branches/BETA21/openvpn/common.h

Updated common.h types for _WIN64.


r3903 | james | 2009-01-27 14:18:51 -0700 (Tue, 27 Jan 2009) | 3 lines
Changed paths:
   M /branches/BETA21/openvpn/ssl.c

Fixed issue involving an #ifdef in a macro reference that breaks early gcc
compilers.




James

Re: [Openvpn-devel] windows 7 and openvpn

[James Yonan]

I've patched the NSIS installer to omit the Windows version check.

Try this installer:

http://openvpn.net/beta/openvpn-2.1_rc15e-install.exe

James

István Szukács wrote:

Hi folks!


I am wondering if you have ever had success to run openvpn on windows 7. 
The problem is the latest 
installer(http://openvpn.net/release/openvpn-2.1_rc15-install.exe) says 
this version is not supporting windows I try to install 
http://openvpn.se/files/install_packages/openvpn-2.0.9-gui-1.0.3-install.exe, 
works fine except the fact that the tap driver is not signed and because 
of this it remains disabled and you cannot use openvpn(but runs well up 
to the point when initialize the driver).


If you could point me a doc how to make it run on win7 it would be much 
appreciated. If I could help with anything the win7 build let me know



Regards,
Istvan


--
the sun shines for all




--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword




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

Re: [Openvpn-devel] OpenVPN affected? - Incorrect checks for malformed signatures in OpenSSL

[James Yonan]

I don't believe this issue significantly affects OpenVPN.  OpenVPN does 
not use the EVP_VerifyFinal function.  The issue is that some internal 
OpenSSL functions do not properly check the return value of this 
function.  The issue is primarily of concern if you are using DSA or 
ECDSA certificates, however these are not generally used with OpenVPN 
(OpenVPN uses RSA certificates and does not currently support DSA or 
ECDSA certificates).


James

Michael A. Gütlbauer wrote:

Hallo!

I'm sure, you know the "OpenSSL Security Advisory [07-Jan-2009]" 
(http://www.openssl.org/news/secadv_20090107.txt)


Because there's absolutely no information on your website, whether 
OpenVPN is affected and/or a bug-fix will be available, I'd like to ask 
you to do so.


Many thanks!

Michael

Re: [Openvpn-devel] openvpn crashing (both 2.0.9 and 2.1rc13)

[James Yonan]

Nikola Ciprich wrote:

Hello,
we are experiencing openvpn crashes from time to time, usually few times a week.
It happens with both 2.0.9 and 2.1rc13.
I've enabled coredumps, and backtrace looks always the same:

Core was generated by `/usr/sbin/openvpn --daemon --writepid 
/var/run/openvpn/gw.lbox.cz-udp.pid --con'.
Program terminated with signal 11, Segmentation fault.
#0  0x2ae049938c94 in lzo1x_1_15_compress () from /usr/lib64/liblzo.so.1
(gdb) bt
#0  0x2ae049938c94 in lzo1x_1_15_compress () from /usr/lib64/liblzo.so.1
#1  0x00418b26 in lzo_compress (buf=0x704190, work={capacity = 1918, offset = 0, 
len = 0, data = 0x695350 ""},
lzowork=0x704130, frame=) at lzo.c:167
#2  0x0040e0a5 in encrypt_sign (c=0x703840, comp_frag=) at forward.c:420
#3  0x0040ebc9 in process_incoming_tun (c=0x703840) at forward.c:961
#4  0x00428e75 in multi_process_incoming_tun (m=0x7fff6192ff20, 
mpp_flags=5) at multi.c:2196
#5  0x004249f7 in tunnel_server_udp (top=0x7fff61930ae0) at mudp.c:178
#6  0x0042b0f3 in main (argc=8, argv=0x7fff61931698) at openvpn.c:213

It seems to be happening while using either TCP, or UDP, doesn't matter.
Is somebody experiencing similar problem? Could somebody help me to hunt it 
down?
I can provide coredumps and further testing if needed.
Server we're experiencing troubles is currently running 2.6.21 x86_64 kernel.
If somebody could help me, I'd greatly appreciate it.
thanks a lot in advance
with best regards
nik


It looks like the crash is happening in the LZO compression library. 
Which version of LZO are you using?  It would be useful to know where in 
LZO the crash is occurring.  If you build LZO with debugging info (-g 
flag to gcc), you will get more useful info in the backtrace.


James