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

[Victor Wagner]

On 2009.11.12 at 10:01:55 -0700, James Yonan wrote:

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

Problem is that existing behavoir seems to be designed without non-ascii
alphabets in mind.

I think that "preserving existing behavoir" is "exporting alpabetic
characters as they are". Since it is quite hard to distinguish between
"alphabetic" and "non-alphabetic" outside of ASCII range, and no shell
use non-ascii as separators (which is primary reason of remapping),
I've considered safe way to treat all 8-bit characters as alphabetic.

no-name-remapping  has side effects, i.e. disables system method of
script execution. 

So, all non-latin-writting users would face choice - either 
use their native language and loose some functionality of openvpn
or have full fuctionality and loose native languge.

Really, I think than name remapping shouldn't be applied to environment
variables at all. May be for command line arguments should be protected
this way. But people who use environment variables typically are clever
enough to  handle shell special characters.

Moreover, if script is written in some better language than shell (i.e.
perl, tcl on even is a C program, which should be probably considered
worse language, as it is prone of buffer overflows), or for dlopened
plugin same remapping rules are applied.

Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/09 16:37, Victor Wagner wrote:
> On 2009.11.11 at 16:04:12 +0100, David Sommerseth wrote:
>> I completely agree, that under normal circumstances, it should be enough
>> by letting OpenSSL take care of the certificate chain.  But as OpenVPN
>> now do list more certificates already, I was just trying to keep that
>> possibility still open.
>>
>> In the OpenVPN plug-in I've written which does username, password and
>> certificate authentication, I've been playing with an idea of using the
>> certificate chain to apply different "rules" (network, login hours, etc)
>> based on the certificate chain as well.
> 
> I think it is what certificate policies are for (see RFC 5280).
> 
> Unfortinately  policy support is very poorly documented in the OpenSSL
> (although some documentation for certificate chain verification was added 
> in 1.0.0 beta 4 and it is applicable to early versions as well)

I'm not sure we talk about the same thing now.  I am thinking about a
centralised form of setting a policy for a limited range of users
(client certificates).  But these features mentioned in RFC5280 is only
to be used in CA certificates (which is fine enough) and to use this
information in *validation* of the certificates.  It do not go further
than this, as the validation of the contents of these fields needs to be
done by the application (not OpenSSL but OpenVPN, in this context), how
I understand it.

The eurephia plug-in I've been writing will allow you to authenticate
users based on certificate *and* user name.  And depending on the
combination here, the firewall will be applied with a specific rule to
allow a limited access.  With such rules you can limit each certificate
and user name combination down to IP addresses and port numbers which is
available over the VPN connection.

My intention is to extend the current implementation to take into
consideration which certificates is in the certificate chain, which do
not depend on the policy feature RFC5280 mentions, and apply more
general rules for a bigger group of users.  As this will make it a lot
easier for an administrator to administer in bigger environments.
Another thing, you'd normally trust the information you have locally
than the information sent to you from a client.

And in this connection, I'm looking at implementing other restrictions
as well, as when users are allowed to connect and not (login time
restrictions).


kind regards,

David Sommerseth


> So my patch for policy checking allows only to specify
> several policies to accept. It doesn't pass that policy which was found
> in the certificate after all policy mappings found in CA certificates
> were applied to scripts/plugins. 
> 
> There are also attribute certificates which can be used for such
> autorization purposes as well.
> 
> --
> 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr8TLoACgkQDC186MBRfrr8zQCghdLz+8VcvTivdhSfopIDmGQl
nPYAnjUA6mWGfxpCSwzFTocykde4Lepo
=u5dv
-END PGP SIGNATURE-

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] Script interface to trigger events depending on the validity of a certificate

[Victor Wagner]

On 2009.11.11 at 16:04:12 +0100, David Sommerseth wrote:
> I completely agree, that under normal circumstances, it should be enough
> by letting OpenSSL take care of the certificate chain.  But as OpenVPN
> now do list more certificates already, I was just trying to keep that
> possibility still open.
> 
> In the OpenVPN plug-in I've written which does username, password and
> certificate authentication, I've been playing with an idea of using the
> certificate chain to apply different "rules" (network, login hours, etc)
> based on the certificate chain as well.

I think it is what certificate policies are for (see RFC 5280).

Unfortinately  policy support is very poorly documented in the OpenSSL
(although some documentation for certificate chain verification was added 
in 1.0.0 beta 4 and it is applicable to early versions as well)

So my patch for policy checking allows only to specify
several policies to accept. It doesn't pass that policy which was found
in the certificate after all policy mappings found in CA certificates
were applied to scripts/plugins. 

There are also attribute certificates which can be used for such
autorization purposes as well.

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

[Matt Wilks]

Yes indeed.  Much appreciated James.

Matt.

Dunc wrote:

I see,

Thanks very much for clearing that up James.

Cheers,

Dunc



James Yonan wrote:

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



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


--
Matt Wilks   Colossians 2:6-7
University of TorontoInformation Security, I+TS
(416) 978-3328   m...@madhaus.cns.utoronto.ca
4 Bancroft Ave., Rm. 102 Toronto, ON  M5S 1C1

[Openvpn-devel] [PATCH] providing certificate SHA1 fingerprint in environment table

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi,

I've rebased and rewritten the patch which gives SHA1
fingerprints/digests of the certificates in the environment table for
plug-ins and scripts.

The patch can be downloaded here:


The rewriten patch makes now use of the code practice which is found
other places in OpenVPN, and it is not as intrusive as earlier.


kind regards,

David Sommerseth

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr8DrMACgkQDC186MBRfrpToACgkyo1iv0qut6nJm+xeYJ4FE8T
aIQAn0BKTA1Q4h/3arAn6UYsuTHCf/XA
=7QOo
-END PGP SIGNATURE-

[Openvpn-devel] [PATCH] openvpn over ipv6 support v0.4.10, rebased to 2.1_rc21

[JuanJo Ciarlante]

Hi,
I rebased the latest incarnation of the ipv6 patch (0.4.10)
to openvpn 2.1_rc21 release.

Changes from v0.4.9..v0.4.10:
* All platforms:
 - implemented redirect-gateway support for ipv4 on ipv6 endpoints
 - several src cleanups (no actual code changes)
 - doc updates
* win32:
 - expanded usage of proto_is_udp(), proto_is_tcp()
 - replaced some memset(, 0, sizeof obj) by openvpn's CLEAR(obj)
* openbsd:
 - there's no IFF_MULTICAST, #ifdef'd around it (not specific to ipv6-patch)

Available from my git repo[1], also as patch over 2.1_rc21 [2].
There's also a win32 x-compiled binary (YMMV), built
w/openssl-0.9.8l from source [3].

[1] http://github.com/jjo/openvpn-ipv6/
[2] 
http://cloud.github.com/downloads/jjo/openvpn-ipv6/openvpn-2.1_rc21-ipv6-0.4.10.uncached.patch.gz
 mehh... there is some staleness in github that keeps serving a
failed 1st upload,
 I temp added the ".uncached"; will let it "drain" and try to
serve the orig filename
 in a few hours.
[3] 
http://cloud.github.com/downloads/jjo/openvpn-ipv6/openvpn.exe-2.1_rc21-ipv6-0.4.10.zip

-- 
--JuanJo ; echo j...@gomosglep.com | sed 's/[SPAM]//g'

Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 12/11/09 12:51, Till Maas wrote:
> On Wed, Nov 11, 2009 at 01:26:04PM +0100, David Sommerseth wrote:
> 
>> 1) The certificate is first dumped to file.  Would it be possible to
>> pass it only via environment table, to avoid the file stage?  The reason
>> for this is primarily security (not to write more to disk than what you
>> really need on disk), and secondarily - SELinux - avoiding writing data
>> to disk you are more sure that SELinux or other MACs will not interfere
>> and deny the write requests.  This is especially crucial if OpenVPN is
>> run in as a contained user (which most daemons really do)
> 
> As far as I understand the tls-verify option, the script will be run
> once for every certificate in the chain. Therefore just passing the
> cert to stdin of the script should be a feasible solution.

But this will not work for --plugin.  A plug-in written in C will not
have access to stdin/stdout for such exchanges.  That's my concern.

>> 2) If an attacker sends a certificate with his certificate and 999 CA
>> certificates in a chain, what will happen?  What happens if the disk
>> goes full or the certificate cannot be written?
> 
> According to the manpage, the tls-verify script won't be executed,
> because the attacker already need to have passed all other verifications
> steps except the check against the CRL list.

True!  I didn't think about that when I thought about this scenario, but
this really covers it.


kind regards,

David Sommerseth


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7/tMACgkQDC186MBRfrrUJwCgrSVYrvlu3v9ZQlQOcg/oAwwk
OxsAnjN+a0OeSIH0Um/3ICbQBRGNLOEh
=ZEbM
-END PGP SIGNATURE-

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

[Dunc]

I see,

Thanks very much for clearing that up James.

Cheers,

Dunc



James Yonan wrote:
> 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

Re: [Openvpn-devel] Script interface to trigger events depending on the validity of a certificate

[Till Maas]

On Wed, Nov 11, 2009 at 01:26:04PM +0100, David Sommerseth wrote:

> 1) The certificate is first dumped to file.  Would it be possible to
> pass it only via environment table, to avoid the file stage?  The reason
> for this is primarily security (not to write more to disk than what you
> really need on disk), and secondarily - SELinux - avoiding writing data
> to disk you are more sure that SELinux or other MACs will not interfere
> and deny the write requests.  This is especially crucial if OpenVPN is
> run in as a contained user (which most daemons really do)

As far as I understand the tls-verify option, the script will be run
once for every certificate in the chain. Therefore just passing the
cert to stdin of the script should be a feasible solution.

> 2) If an attacker sends a certificate with his certificate and 999 CA
> certificates in a chain, what will happen?  What happens if the disk
> goes full or the certificate cannot be written?

According to the manpage, the tls-verify script won't be executed,
because the attacker already need to have passed all other verifications
steps except the check against the CRL list.

Regards
Till


pgpJibvg1L_BB.pgp
Description: PGP signature

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

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

[Dunc]

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] Where to report bugs?

[Olaf Fraczyk]

Hello,

I have posted an email to this list regarding 2.1 rc20 and multiple
network interfaces. It was at October 29.
As I see no reply, please tell me where is the place to put bug reports.

Regards,

Olaf Frączyk

-- 
Olaf Frączyk 
NAVI
http://www.navi.pl
http://www.ntp.navi.pl

[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] Script interface to trigger events depending on the validity of a certificate

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 11/11/09 22:15, Karl O. Pinc wrote:
> On 11/11/2009 06:26:04 AM, David Sommerseth wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 11/11/09 12:06, Mathieu GIANNECCHINI wrote:
>>> Victor Wagner a écrit :
> 
 But if entire certificate would be available, it would be possible
>> to
 extract any information from it (or hash it with any algorithm)
>> from the
 script using openssl command line utility or some binding or
>> OpenSSL
 libraries to the choosen script language.
> 
>> Indeed!  And you're about to get my vote for this implementation ...
>> but
>> I have two concerns.
> 
>> 2) If an attacker sends a certificate with his certificate and 999 CA
>> certificates in a chain, what will happen?  What happens if the disk
>> goes full or the certificate cannot be written?
> 
> You're a lot less likely to fill the disk than you are to run out
> of RAM.

Indeed true, but its also a scenario to consider.  If the certificates
cannot be written to either memory or disk, proper error handling must
make sure the situation is handled correctly.  And running openvpn on
embedded systems with small filesystems or RAM disks can cause this
error as well.


kind regards,

David Sommerseth
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkr7zycACgkQDC186MBRfrryuACgjw9Je6aQWGNeCbWQRDWfGdCg
x7QAoI5ETmIDWNXhycJN5TrRbydM1Tij
=HrZ/
-END PGP SIGNATURE-

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