openvpn-devel Mailing List for OpenVPN

 On 6-2-2012 8:22, Jan Just Keijser wrote: > as David mentioned: is BlowFish support finished ;) ? Almost! :).. > my wiki page on comparing OpenSSL vs NSS vs GnuTLS vs PolarSSL when > used in Curl can be found here: > > http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Funny_Curly_things > Did you actually have problems reading in key files with extra text data in the last version? If so, can you share? They should parse without a problem.. 

hi all, attached is my elliptic curve patch, to add support for using ECDSA curves in combination with SHA256/SHA512 signed certificates; currently you can do either ECDSA with SHA1-signed certificates, or no ECDSA but SHA256/SHA512 signed certs . The error message seen is SSL3_CLIENT_GET_HELLO:no shared cipher This patch overcomes this. With the patch you should see for the control channel: Control Channel: TLSv1, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-SHA Two new parameters are added to OpenVPN --show-curves to list the available elliptic curves, and --ecdh <name> to select a curve name. TODO: this code is currently only enabled using '#ifdef USE_SSL_EC' ; I've manually added a line #define USE_SSL_EC 1 to config.h after a './configure' step. I'm not familiar enough with autoconf and friends to turn it into an .ac script: - you need OpenSSL 1.0+ WITH EC support enabled (RedHat , for example, disables it by default) - PolarSSL does not support it (yet). It would be great if somebody can help me sort the autoconf thing out. The patch was tested on Fedora 14 64bit using a git cloned repo , but without the latest buffer.c patch. cheers, JJK 

> -----Original Message----- > From: Jan Just Keijser [mailto:ja...@ni...] > > I agree with Gert: > I spent most of my train journey yesterday figuring out what the next > assert failure/segfault was , caused by this buffer.c change; > env_set_create is one, log_history_add was also giving me problems, etc > etc. > With the 2.2.2 version of gc_malloc my Elliptic Curve patch works like > a charm (in the git version of OpenVPN). > > The idea behind this change is good, but it needs a LOT of testing > before we can proceed. > I agree. Gc_malloc is very low in the stack, and there are a lot of potential places that this could go wrong. Hunting them down is going to be a challenge. I'll see what I can do in the next few evenings. If I see it spiralling out of control I'll let you know. Adriaan 

Welcome Paul, Paul Bakker wrote: > Hi OpenVPN Devel.. > > As promised ;) I'm now subscribed to the OpenVPN devel list. > > So if you need me for any questions related to PolarSSL, just mail.. > > as David mentioned: is BlowFish support finished ;) ? my wiki page on comparing OpenSSL vs NSS vs GnuTLS vs PolarSSL when used in Curl can be found here: http://www.nikhef.nl/pub/projects/grid/gridwiki/index.php/Funny_Curly_things share and enjoy, JJK 

Hi, David Sommerseth wrote: > On 05/02/12 16:57, Gert Doering wrote: > >> Hi, >> >> On Sun, Feb 05, 2012 at 12:51:25PM +0100, Adriaan de Jong wrote: >> >>> Signed-off-by: Adriaan de Jong<de...@fo...> >>> --- >>> buffer.c | 29 ++++++++++------------------- >>> 1 files changed, 10 insertions(+), 19 deletions(-) >>> >>> diff --git a/buffer.c b/buffer.c >>> index 2f8e4b8..c39bbcb 100644 >>> --- a/buffer.c >>> +++ b/buffer.c >>> @@ -310,28 +310,19 @@ gc_malloc (size_t size, bool clear, struct gc_arena *a) >>> #endif >>> { >>> void *ret; >>> - if (a) >>> - { >>> - struct gc_entry *e; >>> >> NACK on that. We discovered that there are use cases where "second-level" >> callers pass NULL, seemingly on purpose to allocate global memory instead >> of "in the GC". >> >> main(), in openvpn.c: >> >> /* initialize environmental variable store */ >> c.es = env_set_create (NULL); >> >> ... which calls into misc.c: >> >> struct env_set * >> env_set_create (struct gc_arena *gc) >> { >> struct env_set *es; >> ALLOC_OBJ_CLEAR_GC (es, struct env_set, gc); >> es->list = NULL; >> es->gc = gc; >> return es; >> } >> >> ... and boom, assert() fail. >> >> >> Adriaan saw the crash ("my nice OpenBSD test run!!!") and promised to work >> on this on the way back in the train. >> > > But should this actually call gc_malloc() in this case? gc_malloc is > for things which are supposed to be tackled by the garbage collector. > > Things aren't too easy here - but I'd rather see us cleaning up this > instead of making gc_malloc() vague in its purpose. > > $ git grep env_set_create > init.c: c->c2.es = env_set_create (NULL); > manage.c: struct env_set *es = env_set_create (&gc); > misc.c:env_set_create (struct gc_arena *gc) > misc.h:struct env_set *env_set_create (struct gc_arena *gc); > multi.c: es = env_set_create (&gc); > openvpn.c: c.es = env_set_create (NULL); > > There are two places where env_set_create() is called with NULL. Let's > rather see if we can provide a gc_arena pointer those places instead. > Or do something which is more clear in regards to memory allocation in > env_set_create(). > I agree with Gert: I spent most of my train journey yesterday figuring out what the next assert failure/segfault was , caused by this buffer.c change; env_set_create is one, log_history_add was also giving me problems, etc etc. With the 2.2.2 version of gc_malloc my Elliptic Curve patch works like a charm (in the git version of OpenVPN). The idea behind this change is good, but it needs a LOT of testing before we can proceed. cheers, JJK PS was great fun to meet you guys yesterday!