[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] ipv6 env vars to client scripts

[Samuli Seppänen]

> Hi,
>
> On Thu, Apr 17, 2014 at 03:07:29PM +0300, Lev Stipakov wrote:
>> Are there any plans to support ipv6 env vars in
>> client-connect/disconnect scripts?
>>
>> There are at least 2 tickes on that feature:
>>
>> https://community.openvpn.net/openvpn/ticket/230
>> https://community.openvpn.net/openvpn/ticket/369
>>
>> Is there anything that prevents merging any of suggested patches to
>> the master branch?
> "Lack of time"
>
> gert
I will translate this: "They will be merged eventually" :).

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

irc freenode net: mattock

Re: [Openvpn-devel] ipv6 env vars to client scripts

[Gert Doering]

Hi,

On Thu, Apr 17, 2014 at 03:07:29PM +0300, Lev Stipakov wrote:
> Are there any plans to support ipv6 env vars in
> client-connect/disconnect scripts?
> 
> There are at least 2 tickes on that feature:
> 
> https://community.openvpn.net/openvpn/ticket/230
> https://community.openvpn.net/openvpn/ticket/369
> 
> Is there anything that prevents merging any of suggested patches to
> the master branch?

"Lack of time"

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


pgp7URITcawa_.pgp
Description: PGP signature

[Openvpn-devel] ipv6 env vars to client scripts

[Lev Stipakov]

Hello,

Are there any plans to support ipv6 env vars in
client-connect/disconnect scripts?

There are at least 2 tickes on that feature:

https://community.openvpn.net/openvpn/ticket/230
https://community.openvpn.net/openvpn/ticket/369

Is there anything that prevents merging any of suggested patches to
the master branch?

-- 
-Lev

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

Re: [Openvpn-devel] possible socks authentication issue?

[Gert Doering]

Hi,

On Wed, Apr 16, 2014 at 05:37:16PM -0600, James Yonan wrote:
> 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?

commit 2903eba5dfe35c981329a833845e24de3882161a
Author: Yawning Angel 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Mon Mar 10 03:47:58 2014 +

Fix SOCKSv5 method selection
...
URL: http://article.gmane.org/gmane.network.openvpn.devel/8488

:-)

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


pgpxHIAHVh_yC.pgp
Description: PGP signature

Re: [Openvpn-devel] possible socks authentication issue?

[Eric Crist]

There are recent patches on the devel list. 

> On Apr 16, 2014, at 6:37 PM, James Yonan  wrote:
> 
> 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
> 
> --
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] [PATCH] Channel Binding Key based on Keying Material Exporters [RFC 5705]

[Daniel Kubec]

Channel Binding Key based on TLS Keying Material Exporters [RFC 5705 ] allow
additional keying material to be derived from existing TLS channel. This
exported keying material can then be used for a variety of purposes.

TLS allows client and server to establish keying material for use in the
upper layers between the TLS end-points. Channel Bindings is straitforward
and well-defined mechanism how to authenticate other layers.

Following two attributes were added primary for the possible plugins
extensions.

Attributes

tls_channel_id:   Identifies TLS Sessions across (re)negotiation
tls_binding_key: Secret crypto derivate based on Keying Material Exporters

Configuration

TLS Binding Key is generated when *.ovpn contains following for each
TLS negotiation.

example.ovpn:
{
# Channel Binding based on TLS Keying Material Exporter [RFC 5705]
#
# Note that exporter labels have the potential to collide with existing PRF
# labels.  In order to prevent this, labels SHOULD begin with "EXPORTER".
# This is not a MUST because there are existing uses that have labels
which do
# not begin with this prefix.
keying-material-exporter-label "EXPORTER_OPENVPN"

# Export len bytes of keying material (min. 20)
keying-material-exporter-length 20
}

Changes

This patch stays on top of crypto layer and that's reason why it will work
for
both crypto backends (openssl/polarssl).

TLS_FINAL Plugin was called in key_method_2_read() before server_random was
generated for the TLS server end-point and that's the reason why it's
called at
2 places now. key_method_2_read() for server and key_method_2_write() for
client.

Use Cases:

1) Authentication of upper layers (like Kerberos etc)

2) Authentication of VPN's TLS channel using QRCODE and device such as
   smartphones.

   (Instead of user/pass dialog TLS VPN client could show for example QRCODE
based on keying material derivate)

3) Authentication of Binding Key in confidental side-channel can be also used
   and avoid/detect MITM (MITM provides his public key and that's reason why
   authentication of binding key will fail)

openvpn-binding-key.patch
Description: Binary data

[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