Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

2012/2/29 Carsten Krüger :
>> Years back I wrote a simple .net to do to this...
>
> Could you please share?
> I found that openvpn.exe is extremly unstable on non perfectly friendly
> behaving client ...

I use [1], a simple perl/kde UI for Linux.
I deleted the .net as I did not maintain it, but it should be simple
for you to convert, or simply run the perl, and write kdialog
replacement.

Alon.

[1] http://sites.google.com/site/alonbarlev/openvpn-pkcs11

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Alon,

> Right. This is long existing feature, just that in Windows people
> expect to work using UI...

I don't expect a UI but usefull documentation.
management-notes.txt isn't even bundled with windows binaries :-(

I use openvpn since version 1 on windows and wasn't aware that the
management interface is working.
Why isn't there at least an example of how to use it?

For example Astaro has a windows client that seems to be not aware of
the management interface.

The guy who wrote http://openvpn.jowisoftware.de/ seems to don't
understand the management interface, too.
He uses the management interface for communication but than spawns
openvpn.exe itself instead of useing the windows service.

I would have deployed openvpn to ~300 employees, if users didn't need
admin privileges.

> Years back I wrote a simple .net to do to this...

Could you please share?
I found that openvpn.exe is extremly unstable on non perfectly friendly
behaving client ...
Now I use the Non-Sucking Service Manager ( http://nssm.cc/ ) instead of 
openvpnserv.exe
to spawn openvpn.exe
It restarts openvpn.exe automatically if it's crashed.

Why is it possible to send "signal SIGTERM" to openvpn.exe via
management interface?
A client could "crash" openvpn on intention.

Why isn't a clear connect/disconnect semantic included?
"hold" and "signal SIGUSR1" ???!!?!?


@openvpn officials:
If non-admin openvpn is working on windows I could have bought OpenVPN Access 
Server instead of Cisco.
I wouldn't like to know how much money OpenVPN Technologies, Inc lost because 
of the lack of good documentation.

Please please please release immediately a minimal command line client (connect,
disconnect, ask for username) with example server.conf & client.conf
People have to be aware that it's working!

greetings
Carsten

Re: [Openvpn-devel] [PATCH 00/35] build revolution

[Alon Bar-Lev]

Hello,

I think I finished.
David, tell me if you want me to send the patches to the list.
I think these are way too long.

I will be happy if people can test this.

Modified OpenVPN repository[1], build system re-write + cleanups.
Build automation repository[2], provides cross compile, msvc and
completely re-written installer.
TAP-Windows as own repository[3], output is standalone tap installer[8].
Easy-RSA as own repository[4], output is plain tarball.
OpenVPN-GUI repository[5], build system re-write.

Installers are available[6][7], unsigned but should work.
I am interested especially in win64 installations.
The standalone tap installation[8] should be used for problem isolation
 if the embed tap installer within openvpn installer fails.

To create windows installer use:
$ git clone https://github.com/alonbl/openvpn-build
$ cd openvpn-build/windows-nsis
$ ./build-complete

Alon

[1] https://github.com/alonbl/openvpn (build)
[2] https://github.com/alonbl/openvpn-build
[3] https://github.com/alonbl/tap-windows
[4] https://github.com/alonbl/easy-rsa
[5] https://github.com/alonbl/openvpn-gui (build)
[6] 
https://github.com/downloads/alonbl/openvpn/openvpn-install-2.3_alpha1-I000-x86_64.exe
[7] 
https://github.com/downloads/alonbl/openvpn/openvpn-install-2.3_alpha1-I000-i686.exe
[8] https://github.com/downloads/alonbl/tap-windows/tap-windows-9.9.exe

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

2012/2/28 Carsten Krüger :
> Hello Alon,
>
>> This is *THE* missing functionality in Windows environment.
>> It seems that nobody interested in developing proper UI using
>> management interface for Windows.
>> Same goes to proper smartcard support.
>
> I found that openvpn management interface works as I'd like it.
>
> Add the following lines to client.ovpn
> 
> management localhost 1000
> management-query-passwords
> auth-retry interact
> management-hold
> 
> and start the service.
>
> Use putty to connect to localhost port 1000, format RAW
>
> |>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
> |>HOLD:Waiting for hold release
> |hold release
> |SUCCESS: hold release succeeded
> |>PASSWORD:Need 'Auth' username/password
> |username Auth here_comes_my_username
> |SUCCESS: 'Auth' username entered, but not yet verified
> |password Auth here_comes_my_mypassword
> |SUCCESS: 'Auth' password entered, but not yet verified
>
> et voila openvpn connects.
>
> I'd like to cry, how long did this works?
>
> I found this in changelog:
> 2004.11.28 -- Version 2.0-beta18
>
> * Added management interface.  See new --management-*
>  options or the full management interface documentation
>  in management/management-notes.txt in the tarball.
>

Right. This is long existing feature, just that in Windows people
expect to work using UI...
Years back I wrote a simple .net to do to this...

Alon.

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello,

> et voila openvpn connects.

Use this to disconnect:
|forget-passwords
|SUCCESS: Passwords were forgotten
|signal SIGUSR1
|SUCCESS: signal SIGUSR1 thrown
|>HOLD:Waiting for hold release

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Alon,

> This is *THE* missing functionality in Windows environment.
> It seems that nobody interested in developing proper UI using
> management interface for Windows.
> Same goes to proper smartcard support.

I found that openvpn management interface works as I'd like it.

Add the following lines to client.ovpn

management localhost 1000
management-query-passwords
auth-retry interact
management-hold

and start the service.

Use putty to connect to localhost port 1000, format RAW

|>INFO:OpenVPN Management Interface Version 1 -- type 'help' for more info
|>HOLD:Waiting for hold release
|hold release
|SUCCESS: hold release succeeded
|>PASSWORD:Need 'Auth' username/password
|username Auth here_comes_my_username
|SUCCESS: 'Auth' username entered, but not yet verified
|password Auth here_comes_my_mypassword
|SUCCESS: 'Auth' password entered, but not yet verified

et voila openvpn connects.

I'd like to cry, how long did this works?

I found this in changelog:
2004.11.28 -- Version 2.0-beta18

* Added management interface.  See new --management-*
  options or the full management interface documentation
  in management/management-notes.txt in the tarball.


greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Gert Doering]

Hi,

On Tue, Feb 28, 2012 at 06:31:03PM +0100, Carsten Krüger wrote:
> Are there any chances to get full non-admin support for windows in version 
> 2.3 final?

Work is going on on full privilege separation for windows.

It's not done yet, so we'll see whether it will make 2.3 (which was the
initial plan) or 2.4.

I'll let the author comment on more details if he wants to :-)  (thus
not naming anyone - it's not me, though).

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


pgp3z3UrI0sjm.pgp
Description: PGP signature

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 19:42, Alon Bar-Lev wrote:
> 2012/2/28 David Sommerseth :
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA1
>> 
>> On 28/02/12 19:17, Carsten Krüger wrote:
>>> Hello Alon,
>>> 
>>> ABL> This is *THE* missing functionality in Windows environment.
>>> ABL> It seems that nobody interested in developing proper UI using
>>> ABL> management interface for Windows. ABL> Same goes to proper
>>> smartcard support.
>>> 
>>> Developing the UI (command line) would be trivial but to my
>>> knowledge (I'm reading the mailinglist for last 7 years) there is
>>> no management interface in openvpn that would allow this.
>>> 
>> 
>> Have you seen this document?  (management/management-notes.txt) 
>> 
>>
>>
>> 
Especially look for all the 'pkcs11' prefixed calls, like
>> pkcs11-id-count, pkcs11-id-get.  Further James implemented a new
>> feature for the management interface where you can pass the
>> certificate this way too.  Unfortunately, as Alon pointed out, this
>> has not yet been documented well - except in the commit log.
> 
> These features are mine. I wrote these and the whole PKCS#11
> layer, and many other... like the ability to wrap the iproute2. They
> are good, but not great. Why? Because the openvpn daemon it-self loads
> the PKCS#11 provider. This is a security violation. The PKCS#11
> provider should be loaded by the UI, so the daemon cannot interact
> with it at will.

Agreed!  And I remember this was part of the discussions at FOSDEM.  How
should the GUI communicate in regards to the PKCS#11 layer, and how to
provide the proper information towards the core OpenVPN process.  We were
not aware of the --management-external-key at that point, but I think
this is the natural way to look now.


kind regards,

David Sommerseth

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

iEYEARECAAYFAk9NIykACgkQDC186MBRfrqdvQCgpOTCxegtLzCPaQ6eOnxfuCOA
v58AnA2d/xD1/zhXZRj/SWqplv/t//mV
=cDMr
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 19:29, Carsten Krüger wrote:
> Hello David,
> 
>> The solution we've ended up with is a OpenVPN service helper which
>> runs some code parts with admin rights and the OpenVPN binary
>> itself (openvpn.exe) will run completely unprivileged.  Those two
>> instances will communicate via named pipes, to set up the proper
>> routes and other networking parameters.
> 
> Why named pipes?
> 
> Why don't extend this 
> http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html
>
> 
that it works without admin privileges?

Heiko can probably give a much better answer, but if I remember right,
the argument was this:  Think of a multi-user setup (like a Terminal
Server), the management interface will be accessible for all users on
that server.

Named pipes will be available only for that single user, so the attack
vector in an abuse scenario, compared to the management interface, is
more limited.  And considering this pipe will do privileged network
setup, it should be restricted as much as possible.  I don't recall now
if there was even more restrictions you could apply to these pipes as well.

And how this is implemented, the OpenVPN Service will be started
automatically.  The GUI contacts the Service and the service starts the
OpenVPN process with the privileges of the GUI user (IIRC, it was some
neat Windows functions which allows to create processes with privileges
based upon the user credentials of the other side of the named pipe).
And again, the only code pieces in the Service are those related to
network configuration.  The rest of the Service code runs unprivileged.

This service should be able to (for now only in theory; it has not been
tested yet) handle more users simultaneously.

However, the management interface will be used in addition too, at least
in the very beginning, where the logging is transferred back to the GUI
and so on.  I don't recall now all the GUI would do via this interface.


kind regards,

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

iEYEARECAAYFAk9NIhAACgkQDC186MBRfrpPJwCfYlbHHIGZtb8TQj2v7ZJKCcxw
NFEAmQGuOczRPZzMswO5lDxJEdgtEDs+
=L5DL
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

2012/2/28 David Sommerseth :
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 28/02/12 19:17, Carsten Krüger wrote:
>> Hello Alon,
>>
>> ABL> This is *THE* missing functionality in Windows environment. ABL>
>> It seems that nobody interested in developing proper UI using ABL>
>> management interface for Windows. ABL> Same goes to proper smartcard
>> support.
>>
>> Developing the UI (command line) would be trivial but to my knowledge
>> (I'm reading the mailinglist for last 7 years) there is no management
>> interface in openvpn that would allow this.
>>
>
> Have you seen this document?  (management/management-notes.txt)
> 
>
> Especially look for all the 'pkcs11' prefixed calls, like
> pkcs11-id-count, pkcs11-id-get.  Further James implemented a new feature
> for the management interface where you can pass the certificate this way
> too.  Unfortunately, as Alon pointed out, this has not yet been
> documented well - except in the commit log.

These features are mine. I wrote these and the whole PKCS#11 layer,
and many other... like the ability to wrap the iproute2.
They are good, but not great.
Why? Because the openvpn daemon it-self loads the PKCS#11 provider.
This is a security violation.
The PKCS#11 provider should be loaded by the UI, so the daemon cannot
interact with it at will.
It also makes the security openvpn weaker, as foreign library is loaded into
the openvpn process.
And at Windows 7+ there is a problem, a service cannot access the
smartcard readers of the users.
And... even if it can (XP), you cannot use smartcard in remote desktop
session.

Alon.

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

On Tue, Feb 28, 2012 at 8:25 PM, David Sommerseth
 wrote:
>> This is *THE* missing functionality in Windows environment. It seems
>> that nobody interested in developing proper UI using management
>> interface for Windows. Same goes to proper smartcard support.
>
> I believe Jan Just Keijser and Heiko talked about this as well at FOSDEM,
> how to provide a better integrated PKCS#11 support in the Windows GUI.
> So I would expect this to progress too.  And of course, the new GUI Heiko
> writes is using the management interface too, anything else would be
> plain stupid these days.

Right. I don't know what he is writing.
Anyway, the message I sent today regarding the external key is the root.
Adding functionality to set the certificate via the management have the
potential to resolve the whole issue.

> Even though, the new communication pipe between the "helper service" and
> openvpn.exe  might gain more features with time, which might cover much
> of what the management interface provides today too.  But we're _not_
> trying to kill the management interface.

There is no need for the helper service.
Nobody care if the openvpn daemon is running in privilege mode.
The problem is the user interaction.
So I would have avoided to invest resources at the daemon side and invest
resources at proper UI.

>> In Linux I am using OpenVPN using unprivileged user (completely!) the
>> daemon runs under my own user, see[1].
>
> This new communication pipe should also become available for the *nix
> platform too.  Which again should make it easier to implement something
> which does not depend on a safe sudo setup too.  Maybe even some
> integration against NetworkManager via DBus for the Linux platform?

dbus is way too fragile, it is good for desktop... not for core components.
And... requiring network manager (large piece of software) only for iproute2
replacement is redundant.
The management interface is great.
Again, the main problem is not the daemon but the user.
I went one step farther and wrapped the iproute2... this is optional.

> I'm at least playing with the idea that OpenVPN itself shouldn't
> necessarily need to know much about how to configure the TUN/TAP device
> and routes for all different platforms.  Rather write platform specific
> "service helpers" which does that job via the the communication pipe.
>
> This would make the OpenVPN code base simpler and perhaps even easier to
> support more platforms, like Android - and maybe even iPhone and the new
> Windows Mobile?

Well, this can be done now, just wrap the iproute with suid program to
do whatever
you like, this is the wrapper. The tap device can be accessed using
non-privileged
user, so all that is left is the iproute2 delegation.

This does not require special code or effort.

Bottom line: the management interface is great. One missing functionality is
setting certificate.
Effort should be invested in proper UI to leverage the management interface.
Running openvpn *DAEMON* as completely unprivileged is 2nd priority.
On Linux it can be done by simply wrapping the iproute2 executable, using
sudo/dbus whatever to achieve same functionality.
On Windows a similar solution may be provided.

Alon.

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 19:17, Carsten Krüger wrote:
> Hello Alon,
> 
> ABL> This is *THE* missing functionality in Windows environment. ABL>
> It seems that nobody interested in developing proper UI using ABL>
> management interface for Windows. ABL> Same goes to proper smartcard
> support.
> 
> Developing the UI (command line) would be trivial but to my knowledge 
> (I'm reading the mailinglist for last 7 years) there is no management 
> interface in openvpn that would allow this.
> 

Have you seen this document?  (management/management-notes.txt)


Especially look for all the 'pkcs11' prefixed calls, like
pkcs11-id-count, pkcs11-id-get.  Further James implemented a new feature
for the management interface where you can pass the certificate this way
too.  Unfortunately, as Alon pointed out, this has not yet been
documented well - except in the commit log.



So things are happening here too.


kind regards,

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

iEYEARECAAYFAk9NHVwACgkQDC186MBRfrr/qgCdF2BT+TqE+h2x/Aqoin271bc0
wfAAn2va1LDzeRo9Km8eQqmYWlsvFJ4E
=dhKu
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello David,

> The solution we've ended up with is a OpenVPN service helper which runs
> some code parts with admin rights and the OpenVPN binary itself
> (openvpn.exe) will run completely unprivileged.  Those two instances will
> communicate via named pipes, to set up the proper routes and other
> networking parameters.

Why named pipes?

Why don't extend this
http://openvpn.net/index.php/open-source/documentation/miscellaneous/79-management-interface.html
that it works without admin privileges?

> The time of complaining will come to an end with 2.3 :)  Heiko
> demonstrated his prototype at FOSDEM a few weeks ago.  And it really
> looked very impressive.  But there are some changes to the openvpn code
> base which needs to be applied, in addition to be synced with the GUI
> code base.  So we decided to postpone this particular feature to a later
> alpha release - instead of postponing the first alpha release even more.
>  Just to give Heiko a bit better time to complete his code.  But there
> are so many requesting this feature, we really can't ignore it any more.

> And Heiko is free to flog me if I've said and/or promised too much :)

great 

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 19:07, Alon Bar-Lev wrote:
> 2012/2/28 Carsten Krüger :
>>> * New OpenVPN-GUI
>> 
>> Are there any chances to get full non-admin support for windows in
>> version 2.3 final?
>> 
>> I mean strict seperation between OpenVPN service running with local
>> system privileges (can modify routes, etc.) and usermode part
>> (command line, maybe GUI) that interacts with user (start/stop
>> tunnel, ask for passphrase, pin for smartcard, etc.).
>> 
>> In companies that have security in mind it's impossible to allow 
>> roadwarriors to connect via openvpn because they would need admin 
>> privileges. Give them only the privilege to start/stop the openvpn
>> service didn't help because they can't supply credentials.
>> 
>> I'm complaining about this show stoppper for ~4 years :-(
>> 
>> I personally like openvpn very much and would like to deploy it for 
>> our users but I've to buy Cisco because the windows client is
>> better.
> 
> This is *THE* missing functionality in Windows environment. It seems
> that nobody interested in developing proper UI using management
> interface for Windows. Same goes to proper smartcard support.

I believe Jan Just Keijser and Heiko talked about this as well at FOSDEM,
how to provide a better integrated PKCS#11 support in the Windows GUI.
So I would expect this to progress too.  And of course, the new GUI Heiko
writes is using the management interface too, anything else would be
plain stupid these days.

Even though, the new communication pipe between the "helper service" and
openvpn.exe  might gain more features with time, which might cover much
of what the management interface provides today too.  But we're _not_
trying to kill the management interface.

> In Linux I am using OpenVPN using unprivileged user (completely!) the 
> daemon runs under my own user, see[1].

This new communication pipe should also become available for the *nix
platform too.  Which again should make it easier to implement something
which does not depend on a safe sudo setup too.  Maybe even some
integration against NetworkManager via DBus for the Linux platform?

I'm at least playing with the idea that OpenVPN itself shouldn't
necessarily need to know much about how to configure the TUN/TAP device
and routes for all different platforms.  Rather write platform specific
"service helpers" which does that job via the the communication pipe.

This would make the OpenVPN code base simpler and perhaps even easier to
support more platforms, like Android - and maybe even iPhone and the new
Windows Mobile?


kind regards,

David Sommerseth

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

iEYEARECAAYFAk9NHBQACgkQDC186MBRfrrs8ACfT93nLXZ727QLP24FFs/C5hw0
CSMAn0ECng3+celO1axW27gzyNq6aEJw
=tGiN
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Alon,

ABL> This is *THE* missing functionality in Windows environment.
ABL> It seems that nobody interested in developing proper UI using
ABL> management interface for Windows.
ABL> Same goes to proper smartcard support.

Developing the UI (command line) would be trivial but to my knowledge
(I'm reading the mailinglist for last 7 years) there is no management
interface in openvpn that would allow this.

ABL> In Linux I am using OpenVPN using unprivileged user (completely!) the
ABL> daemon runs under my own user, see[1].

With su this is trivial :-)

greetings
Carsten

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 18:31, Carsten Krüger wrote:
> Hello Samuli,
> 
>> The OpenVPN community project team is proud to release OpenVPN 
>> 2.3-alpha1. It can be downloaded from here:
> 
>> 
> 
>> This release includes a few new major features:
> 
>> * Complete IPv6 support, both transport and payload * Optional
>> PolarSSL support (build time configuration) * Improved plug-in API
>> (v3) which can more easily be expanded in the future: includes
>> support for direct access to X.509 certificate data in plug-ins *
>> Several improvements to the management interface * One-to-one NAT to
>> circumvent IP address conflicts between local and remote networks *
>> New OpenVPN-GUI
> 
> Are there any chances to get full non-admin support for windows in
> version 2.3 final?
> 
> I mean strict seperation between OpenVPN service running with local
> system privileges (can modify routes, etc.) and usermode part (command
> line, maybe GUI) that interacts with user (start/stop tunnel, ask for
> passphrase, pin for smartcard, etc.).

This is definitely in the pipe for v2.3.  I don't know how far Heiko have
come on that since last time we discussed it on the #openvpn-devel
channel, but he is really progressing very well here.

The solution we've ended up with is a OpenVPN service helper which runs
some code parts with admin rights and the OpenVPN binary itself
(openvpn.exe) will run completely unprivileged.  Those two instances will
communicate via named pipes, to set up the proper routes and other
networking parameters.

> In companies that have security in mind it's impossible to allow 
> roadwarriors to connect via openvpn because they would need admin 
> privileges. Give them only the privilege to start/stop the openvpn
> service didn't help because they can't supply credentials.
> 
> I'm complaining about this show stoppper for ~4 years :-(
> 
> I personally like openvpn very much and would like to deploy it for 
> our users but I've to buy Cisco because the windows client is better.

The time of complaining will come to an end with 2.3 :)  Heiko
demonstrated his prototype at FOSDEM a few weeks ago.  And it really
looked very impressive.  But there are some changes to the openvpn code
base which needs to be applied, in addition to be synced with the GUI
code base.  So we decided to postpone this particular feature to a later
alpha release - instead of postponing the first alpha release even more.
 Just to give Heiko a bit better time to complete his code.  But there
are so many requesting this feature, we really can't ignore it any more.


And Heiko is free to flog me if I've said and/or promised too much :)


kind regards,

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

iEYEARECAAYFAk9NGL4ACgkQDC186MBRfrqyBQCePJd6rZ32WeDk09s9xQcNnTTh
J6AAn2vDkemZkTZcou3Mctor47hi+y3W
=VlJA
-END PGP SIGNATURE-

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Alon Bar-Lev]

2012/2/28 Carsten Krüger :
>>  * New OpenVPN-GUI
>
> Are there any chances to get full non-admin support for windows in version 
> 2.3 final?
>
> I mean strict seperation between OpenVPN service running with local system
> privileges (can modify routes, etc.) and usermode part (command line, maybe 
> GUI) that
> interacts with user (start/stop tunnel, ask for passphrase, pin for 
> smartcard, etc.).
>
> In companies that have security in mind it's impossible to allow
> roadwarriors to connect via openvpn because they would need admin
> privileges.
> Give them only the privilege to start/stop the openvpn service didn't help 
> because they can't supply credentials.
>
> I'm complaining about this show stoppper for ~4 years :-(
>
> I personally like openvpn very much and would like to deploy it for
> our users but I've to buy Cisco because the windows client is better.

This is *THE* missing functionality in Windows environment.
It seems that nobody interested in developing proper UI using
management interface for Windows.
Same goes to proper smartcard support.

In Linux I am using OpenVPN using unprivileged user (completely!) the
daemon runs under my own user, see[1].

Alon.

[1] http://en.gentoo-wiki.com/wiki/OpenVPN_Non_Root

Re: [Openvpn-devel] [Openvpn-users] OpenVPN 2.3-alpha1 released

[Carsten Krüger]

Hello Samuli,

> The OpenVPN community project team is proud to release OpenVPN
> 2.3-alpha1. It can be downloaded from here:

> 

> This release includes a few new major features:

>  * Complete IPv6 support, both transport and payload
>  * Optional PolarSSL support (build time configuration)
>  * Improved plug-in API (v3) which can more easily be expanded in the
>future: includes support for direct access to X.509 certificate data in
>plug-ins
>  * Several improvements to the management interface
>  * One-to-one NAT to circumvent IP address conflicts between local and
>remote networks
>  * New OpenVPN-GUI

Are there any chances to get full non-admin support for windows in version 2.3 
final?

I mean strict seperation between OpenVPN service running with local system
privileges (can modify routes, etc.) and usermode part (command line, maybe 
GUI) that
interacts with user (start/stop tunnel, ask for passphrase, pin for smartcard, 
etc.).

In companies that have security in mind it's impossible to allow
roadwarriors to connect via openvpn because they would need admin
privileges.
Give them only the privilege to start/stop the openvpn service didn't help 
because they can't supply credentials.

I'm complaining about this show stoppper for ~4 years :-(

I personally like openvpn very much and would like to deploy it for
our users but I've to buy Cisco because the windows client is better.

greetings
Carsten

Re: [Openvpn-devel] [PATCH 1/2] Added support for new PolarSSL 1.1 RNG

[Fabian Knittel]

Hi Adriaan,

I only found a minor nit:

2012/2/28 Adriaan de Jong :
> --- a/ssl.c
> +++ b/ssl.c
> @@ -385,6 +385,11 @@ init_ssl (const struct options *options, struct 
> tls_root_ctx *new_ctx)
>       tls_ctx_restrict_ciphers(new_ctx, options->cipher_list);
>     }
>
> +#ifdef USE_POLARSSL
> +  /* Fox-IT hardening: Personalise the random by mixing in the certificate */
> +  tls_ctx_personalise_random (new_ctx);
> +#endif

Unless it's intentional, the "Fox-IT hardening" string is probably
from an earlier, internal iteration?

The rest looks fine AFAICT. :)

Cheers
Fabian

[Openvpn-devel] Another undocumented feature: management-external-key

[Alon Bar-Lev]

Hello David,

Please also work to document this commit (management-notes, man).
It is extrenely important feature, for example it can be used to move
the whole smartcard
interaction to the UI.

This feature should be extended to provide X.509 certificate as well,
it is incomplete without this.

Alon

---

commit cf69617bbea45a15423c4188daa9386debcbe1ec
Author: James Yonan 
List-Post: openvpn-devel@lists.sourceforge.net
Date:   Thu Dec 9 11:21:04 2010 +

Added "management-external-key" option.  This option can be used
instead of "key" in client mode, and allows the client to run
without the need to load the actual private key.  When the SSL
protocol needs to perform an RSA sign operation, the data to
be signed will be sent to the management interface via a
notification as follows:

  >RSA_SIGN:[BASE64_DATA]

The management interface client should then sign BASE64_DATA
using the private key and return the signature as follows:

  rsa-sig
  [BASE64_SIG_LINE]
  .
  .
  .
  END

This capability is intended to allow the use of arbitrary
cryptographic service providers with OpenVPN via the
management interface.

Re: [Openvpn-devel] OpenVPN 2.3-alpha1 released

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 17:32, Mr Dash Four wrote:
> 
>> * Improved plug-in API (v3) which can more easily be expanded in
>> the future: includes support for direct access to X.509 certificate
>> data in plug-ins [...] * One-to-one NAT to circumvent IP address
>> conflicts between local and remote networks
>> 
> Is there any help/doc/wiki where I could get more information/learn
> more about these new features?

For the plug-in API ... look at openvpn-plugin.h ... look for
openvpn_plugin_*_v3.  Especially openvpn_plugin_open_v3() and
openvpn_plugin_func_v3().  If fact, most of the openvpn-plugin.h is a
pretty comprehensive reference for the plugin API.  For a working
example, look at plugin/examples/log_v3.c.

For the --client-nat ... look at the man new page.



kind regards,

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

iEYEARECAAYFAk9NCO0ACgkQDC186MBRfrpXDQCghQoK0eW927kHqHtzri5KOdme
p2IAn0WIwLjrv5rTwWtA7FcFzo5IKLbU
=zu4J
-END PGP SIGNATURE-

Re: [Openvpn-devel] OpenVPN 2.3-alpha1 released

[Mr Dash Four]

 * Improved plug-in API (v3) which can more easily be expanded in the
   future: includes support for direct access to X.509 certificate data in
   plug-ins
[...]
 * One-to-one NAT to circumvent IP address conflicts between local and
   remote networks
  
Is there any help/doc/wiki where I could get more information/learn more 
about these new features?

[Openvpn-devel] [PATCH 1/2] Added support for new PolarSSL 1.1 RNG

[Adriaan de Jong]

This patch, while retaining PolarSSL 1.0 support, introduces the PolarSSL 1.1 
DRBG. This RNG adds a number of features, including support for personalisation 
strings and multiple entropy sources.

Personalisation strings have been implemented, based on PID, program name, 
place within memory, and a hash of the user's certificate.

The entropy sources used are the platform default ones. Which ones these are 
depends on how PolarSSL was built, but usually this includes:

 - /dev/urandom or the Windows CryptoAPI RNG
 - the HAVEGE RNG
 - the output of PolarSSL's hardclock() call (usually RDTSC)

Finally, this patch moves to only one instance of the RNG  per OpenVPN 
instance, instead of one per keystate

Signed-off-by: Adriaan de Jong 
Signed-off-by: Eelse-jan Stutvoet 
---
 crypto_polarssl.c |   84 ++--
 crypto_polarssl.h |   25 
 ssl.c |5 +++
 ssl_backend.h |   10 ++
 ssl_polarssl.c|   44 +--
 ssl_polarssl.h|2 -
 6 files changed, 148 insertions(+), 22 deletions(-)

diff --git a/crypto_polarssl.c b/crypto_polarssl.c
index e7470d5..8eb47db 100644
--- a/crypto_polarssl.c
+++ b/crypto_polarssl.c
@@ -36,12 +36,18 @@
 #include "buffer.h"
 #include "integer.h"
 #include "crypto_backend.h"
+#include "otime.h"
+#include "misc.h"

 #include 
 #include 
 #include 
 #include 

+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+#include 
+#endif
+
 /*
  *
  * Hardware engine support. Allows loading/unloading of engines.
@@ -143,7 +149,6 @@ show_available_engines ()
   "available\n");
 }

-
 /*
  *
  * Random number functions, used in cases where we want
@@ -153,29 +158,88 @@ show_available_engines ()
  *
  */

-int
-rand_bytes (uint8_t *output, int len)
+/*
+ * Initialise the given ctr_drbg context, using a personalisation string and an
+ * entropy gathering function.
+ */
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+ctr_drbg_context * rand_ctx_get()
+{
+  static entropy_context ec = {0};
+  static ctr_drbg_context cd_ctx = {0};
+  static bool rand_initialised = false;
+
+  if (!rand_initialised)
+{
+  struct gc_arena gc = gc_new();
+  struct buffer pers_string = alloc_buf_gc(100, );
+
+  /*
+   * Personalisation string, should be as unique as possible (see NIST
+   * 800-90 section 8.7.1). We have very little information at this stage.
+   * Include Program Name, memory address of the context and PID.
+   */
+  buf_printf(_string, "OpenVPN %0u %p %s", openvpn_getpid(), _ctx, 
time_string(0, 0, 0, ));
+
+  /* Initialise PolarSSL RNG, and built-in entropy sources */
+  entropy_init();
+
+  if (0 != ctr_drbg_init(_ctx, entropy_func, , BPTR(_string), 
BLEN(_string)))
+msg (M_FATAL, "Failed to initialize random generator");
+
+  gc_free();
+  rand_initialised = true;
+  }
+
+  return _ctx;
+}
+
+#else /* (POLARSSL_VERSION_NUMBER < 0x0101) */
+
+havege_state * rand_ctx_get()
 {
   static havege_state hs = {0};
-  static bool hs_initialised = false;
-  const int int_size = sizeof(int);
+  static bool rand_initialised = false;

-  if (!hs_initialised)
+  if (!rand_initialised)
 {
   /* Initialise PolarSSL RNG */
   havege_init();
-  hs_initialised = true;
+  rand_initialised = true;
 }

+  return 
+}
+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
+int
+rand_bytes (uint8_t *output, int len)
+{
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+  ctr_drbg_context *rng_ctx = rand_ctx_get();
+#else /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+  havege_state *rng_ctx = rand_ctx_get();
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
   while (len > 0)
 {
-  const int blen   = min_int (len, int_size);
-  const int rand_int   = havege_rand();
-
+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+  const size_t blen = min_int (len, CTR_DRBG_MAX_REQUEST);
+  if (0 != ctr_drbg_random(rng_ctx, output, blen))
+   return 0;
+
+#else /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+  const size_t blen = min_int (len, sizeof(int));
+  const int rand_int = havege_rand(rng_ctx);
   memcpy (output, _int, blen);
+
+#endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */
+
   output += blen;
   len -= blen;
 }
+
   return 1;
 }

diff --git a/crypto_polarssl.h b/crypto_polarssl.h
index 358483a..2f303db 100644
--- a/crypto_polarssl.h
+++ b/crypto_polarssl.h
@@ -30,9 +30,16 @@
 #ifndef CRYPTO_POLARSSL_H_
 #define CRYPTO_POLARSSL_H_

+#include 
 #include 
 #include 

+#if (POLARSSL_VERSION_NUMBER >= 0x0101)
+#  include 
+#else
+#  include 
+#endif
+
 /** Generic cipher key type %context. */
 typedef cipher_info_t cipher_kt_t;

@@ -71,4 +78,22 @@ typedef md_context_t hmac_ctx_t;
 #define SHA_DIGEST_LENGTH  20
 #define DES_KEY_LENGTH 8

+/**
+ * Returns a singleton instance of the PolarSSL random number generator.
+ *
+ * For PolarSSL 

[Openvpn-devel] [PATCH 2/2] Added a configuration option to enable prediction resistance in the PolarSSL random number generator.

[Adriaan de Jong]

Signed-off-by: Eelse-jan Stutvoet 
Signed-off-by: Adriaan de Jong 
---
 crypto_polarssl.c |9 +
 crypto_polarssl.h |7 +++
 init.c|6 ++
 openvpn.8 |   14 ++
 options.c |   22 ++
 options.h |3 +++
 syshead.h |8 
 7 files changed, 69 insertions(+), 0 deletions(-)

diff --git a/crypto_polarssl.c b/crypto_polarssl.c
index 8eb47db..b37c8b2 100644
--- a/crypto_polarssl.c
+++ b/crypto_polarssl.c
@@ -213,6 +213,15 @@ havege_state * rand_ctx_get()

 #endif /* (POLARSSL_VERSION_NUMBER >= 0x0101) */

+#ifdef ENABLE_PREDICTION_RESISTANCE
+void rand_ctx_enable_prediction_resistance()
+{
+  ctr_drbg_context *cd_ctx = rand_ctx_get();
+
+  ctr_drbg_set_prediction_resistance(cd_ctx, 1);
+}
+#endif /* ENABLE_PREDICTION_RESISTANCE */
+
 int
 rand_bytes (uint8_t *output, int len)
 {
diff --git a/crypto_polarssl.h b/crypto_polarssl.h
index 2f303db..6152878 100644
--- a/crypto_polarssl.h
+++ b/crypto_polarssl.h
@@ -96,4 +96,11 @@ ctr_drbg_context * rand_ctx_get();
 havege_state * rand_ctx_get();
 #endif

+#ifdef ENABLE_PREDICTION_RESISTANCE
+/**
+ * Enable prediction resistance on the random number generator.
+ */
+void rand_ctx_enable_prediction_resistance();
+#endif
+
 #endif /* CRYPTO_POLARSSL_H_ */
diff --git a/init.c b/init.c
index fb8fe00..5259690 100644
--- a/init.c
+++ b/init.c
@@ -2002,6 +2002,12 @@ init_crypto_pre (struct context *c, const unsigned int 
flags)

   if (c->options.mute_replay_warnings)
 c->c2.crypto_options.flags |= CO_MUTE_REPLAY_WARNINGS;
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  if (c->options.use_prediction_resistance)
+rand_ctx_enable_prediction_resistance();
+#endif
+
 }

 /*
diff --git a/openvpn.8 b/openvpn.8
index 53d6bdb..ee46de6 100644
--- a/openvpn.8
+++ b/openvpn.8
@@ -3846,6 +3846,20 @@ space-saving optimization that uses the unique 
identifier for
 datagram replay protection as the IV.
 .\"*
 .TP
+.B \-\-use-prediction-resistance
+Enable prediction resistance on PolarSSL's RNG.
+
+Enabling prediction resistance causes the RNG to reseed in each
+call for random. Reseeding this often can quickly deplete the kernel
+entropy pool.
+
+If you need this option, please consider running a daemon that adds
+entropy to the kernel pool.
+
+Note that this option only works with PolarSSL versions greater
+than 1.1.
+.\"*
+.TP
 .B \-\-test-crypto
 Do a self-test of OpenVPN's crypto options by encrypting and
 decrypting test packets using the data channel encryption options
diff --git a/options.c b/options.c
index 5e972b1..c2896da 100644
--- a/options.c
+++ b/options.c
@@ -537,6 +537,10 @@ static const char usage_message[] =
   "  using file.\n"
   "--test-crypto   : Run a self-test of crypto features enabled.\n"
   "  For debugging only.\n"
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  "--use-prediction-resistance: Enable prediction resistance on the random\n"
+  " number generator.\n"
+#endif
 #ifdef USE_SSL
   "\n"
   "TLS Key Negotiation Options:\n"
@@ -829,6 +833,9 @@ init_options (struct options *o, const bool init_gc)
   o->replay_time = DEFAULT_TIME_BACKTRACK;
   o->use_iv = true;
   o->key_direction = KEY_DIRECTION_BIDIRECTIONAL;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  o->use_prediction_resistance = false;
+#endif
 #ifdef USE_SSL
   o->key_method = 2;
   o->tls_timeout = 2;
@@ -1573,6 +1580,9 @@ show_settings (const struct options *o)
   SHOW_STR (packet_id_file);
   SHOW_BOOL (use_iv);
   SHOW_BOOL (test_crypto);
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  SHOW_BOOL (use_prediction_resistance);
+#endif

 #ifdef USE_SSL
   SHOW_BOOL (tls_server);
@@ -3000,6 +3010,11 @@ options_string (const struct options *o,
  buf_printf (, ",no-replay");
if (!o->use_iv)
  buf_printf (, ",no-iv");
+
+#ifdef ENABLE_PREDICTION_RESISTANCE
+if (o->use_prediction_resistance)
+  buf_printf (, ",use-prediction-resistance");
+#endif
   }

 #ifdef USE_SSL
@@ -6401,6 +6416,13 @@ add_option (struct options *options,
   options->keysize = keysize;
 }
 #endif
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  else if (streq (p[0], "use-prediction-resistance"))
+{
+  VERIFY_PERMISSION (OPT_P_GENERAL);
+  options->use_prediction_resistance = true;
+}
+#endif
 #ifdef USE_SSL
   else if (streq (p[0], "show-tls"))
 {
diff --git a/options.h b/options.h
index 6af4b3a..4794a08 100644
--- a/options.h
+++ b/options.h
@@ -520,6 +520,9 @@ struct options
   const char *packet_id_file;
   bool use_iv;
   bool test_crypto;
+#ifdef ENABLE_PREDICTION_RESISTANCE
+  bool use_prediction_resistance;
+#endif

 #ifdef USE_SSL
   /* TLS (control channel) parms */
diff --git a/syshead.h b/syshead.h
index 0235abd..6c8329b 100644
--- a/syshead.h
+++ b/syshead.h
@@ 

[Openvpn-devel] [PATCH] Fixed off-by-one in serial length calculation

[Adriaan de Jong]

The serial length was one digit too short, resulting in missing digits at the 
end of the certificate's stringified serial number.

Signed-off-by: Adriaan de Jong 
---
 ssl_verify_polarssl.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ssl_verify_polarssl.c b/ssl_verify_polarssl.c
index 2ba0a5c..4206578 100644
--- a/ssl_verify_polarssl.c
+++ b/ssl_verify_polarssl.c
@@ -121,7 +121,7 @@ x509_get_serial (x509_cert *cert, struct gc_arena *gc)
   int ret = 0;
   int i = 0;
   char *buf = NULL;
-  size_t len = cert->serial.len * 3;
+  size_t len = cert->serial.len * 3 + 1;

   buf = gc_malloc(len, true, gc);

-- 
1.7.5.4

[Openvpn-devel] Temporarily delaying patch acceptances

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


Hi all,

As you all probably know, Alon Bar-Lev is doing a revolution to our build
system.  The more I look at these changes, the more I like them, and it
shows how overdue this process was.

Alon's patches changes so much inside the source tree, that applying
patches to the current master branch (which does not have Alon's stuff in
yet) will make it very hard to pull in Alon's changes afterwards.

However, patches made on the current master should be fairly easier to
integrate when Alon's work is done.  The patches mostly just needs to be
applied in other directories than at the root source tree.

So I'm having my focus on Alon's changes right now.  And patches which
will come until his stuff has reached the master branch.  If you want to
make this happen faster, please test, test, test, test and test Alon's
working branch - and report issues.  But beware, Alon's tree is moving
very fast forward.

In the meantime, I'm very much thankful for the time and energy Alon has
put into this.  He is surely has proven to know a lot about autotools and
build chains.  And I'm looking forward to get his stuff upstream.

I'll follow up on this mail when things starts to get moving forward.  If
you notice that some of your patches have not been applied at that point,
you may poke me about it.  But until Alon's work is completed, they will
be in my little patch queue.


kind regards,

David Sommerseth

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

iEYEARECAAYFAk9M5d8ACgkQDC186MBRfrqu+gCfZCPpFi0bpt7mqgiTrde8rQZV
UUAAnRzMdRm6necdZn9vtVLzH8IsOul8
=o92D
-END PGP SIGNATURE-

[Openvpn-devel] OpenVPN 2.3-alpha1 released

[Samuli Seppänen]

The OpenVPN community project team is proud to release OpenVPN
2.3-alpha1. It can be downloaded from here:



This release includes a few new major features:

 * Complete IPv6 support, both transport and payload
 * Optional PolarSSL support (build time configuration)
 * Improved plug-in API (v3) which can more easily be expanded in the
   future: includes support for direct access to X.509 certificate data in
   plug-ins
 * Several improvements to the management interface
 * One-to-one NAT to circumvent IP address conflicts between local and
   remote networks
 * New OpenVPN-GUI

Note that a few changes have been made which may affect existing
installations. A list of new features and the changelog are available here:



The changelog is also attached to this email.

For generic help use these support channels:

- Official documentation:

- Wiki: 
- Forums: 
- User mailing list: 
- User IRC channel: #openvpn at irc.freenode.net

Please report bugs and ask development questions here:

- Bug tracker and Wiki: 
- Developer mailing list: 
- Developer IRC channel: #openvpn-devel at irc.freenode.net (requires
  Freenode registration)

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

irc freenode net: mattock




2012.02.21 -- Version 2.3-alpha1
Adriaan de Jong (127):
  Added Doxygen doxyfile
  Changed configure to accept --with-ssl-type=openssl
  Refactored to rand_bytes for OpenSSL-independency
  Refactored OpenSSL-specific constants
  Refactored maximum cipher and hmac length constants
  Refactored show_available_* functions
  Refactored SSL_clear_error()
  Refactored crypto initialisation functions
  Refactored DES key manipulation functions
  Refactored NTLM DES key generation
  Refactored message digest type functions
  Refactored message digest functions
  Refactored HMAC functions
  Refactored cipher key types
  Refactored cipher functions
  Added PRNG doxygen
  Refactored: Moved crypto.h inline functions to end of file
  Removed stale OpenSSL defines from crypto.h
  Added a check for Openssl or PolarSSL defines
  Refactored: Added stubs for new files
  Refactored SSL initialisation functions
  Refactored TLS_PRF to new hmac and md primitives
  Refactored tls_show_available_ciphers
  Refactored get_highest_preference_tls_cipher
  Refactored root SSL context initialisation
  Refactored new external key code
  Refactored DH paramater loading
  Refactored root TLS option settings
  Refactored PKCS#12 key loading
  Refactored PKCS#11 loading
  Refactored windows cert loading
  Refactored load certificate functions
  Refactored private key loading code
  Refactored external key loading from management
  Refactored CA and extra certs code
  Refactored cipher restriction code
  Refactored tls_options, key_state, and key_source data structures
  Refactored initalisation of key_states
  Refactored key_state free code
  Refactored print_details
  Refactored key_state read code (including bio_read())
  Refactored key_state write functions
  Refactored: Moved BIO debug functions to OpenSSL backend
  Refactored: removed ks and ks_lame macro for clarity
  Refactored: moved write_empty_string function back
  Refactored Doxygen for tls_multi functions
  Migrated data structures needed by verification functions to ssl_common.h
  Refactored client_config_dir_exclusive function
  Refactored certificate hash lock checks
  Refactored common name locking functions
  Refactored username and password authentication code
  Add some extra comments
  Refactored: split verify_callback into two parts
  Added function to extract and verify the subject from a certificate
  Added function to verify and extract the username
  Refactored: removed global x509_username_field
  Refactored: separated environment setup during verification
  Refactored: Netscape certificate type verification
  Refactored key usage verification code
  Refactored EKU verification
  Refactored tls-remote checking
  Refactored tls-verify-plugin code
  Refactored tls-verify script code
  Refactored CRL checks
  Minor cleanup in verify_cert:
  Refactored: Moved verify_cert to ssl_verify
  Cleaned up ssl.h
  Refactored: made M_SSL dependent on USE_OPENSSL
  Refactored: renamed X509 functions from verify_*
  Separated OpenSSL-specific parts of the PKCS#11 driver
  Modified base64 code in preparation for PolarSSL 

Re: [Openvpn-devel] [PATCH] Bogus check for negative values on an unsigned number.

[Gert Doering]

Hi,

On Fri, Feb 17, 2012 at 10:58:16PM +0100, Gert Doering wrote:
> [ on ir->netbits and ir6->netbits, signed int vs. unsigned int ]
> 
> Thanks for reporting this.  I'll look into it.

I've dug a bit further into the code, and the IPv4 and IPv6 code differ
here - IPv4 flags "a host iroute" with ir->netbits = -1, while for IPv6,
a "host iroute" is just a /128.

The difference shows up in 

 - options.c, option_iroute() vs. option_iroute_ipv6()
 - push.c in checking "if < 0 then make it a /32":

if (network == ir->network && netmask == netbits_to_netmask (ir->netbits >= 
0 ? ir->netbits : 32))

 - multi.c, in pretty-printing host routes "without the /32":

  if (ir->netbits >= 0)
msg (D_MULTI_LOW, "MULTI: internal route %s/%d -> %s",
...
  else
msg (D_MULTI_LOW, "MULTI: internal route %s -> %s",

   (which I blindly copied for IPv6, not noticing that ir6->netbits cannot
be negative anyway)

 - mroute.c, in the mroute_helper_{add,del}_iroute[6]() helpers that you've
   found


Now I'm wondering which way forward is cleaner - make ip->netbits an 
"unsigned" as well, changing all the places where "<0 == host route" to 
be "/32 = host" (mostly prettyprinting I think, but need to understand
the mroute stuff better), or live with artificial IPv4/IPv6 asymmetry 
here...

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


pgpVDlUwsdlTN.pgp
Description: PGP signature

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[Adriaan de Jong]

On 02/28/2012 12:48 PM, David Sommerseth wrote:
> On 28/02/12 12:40, Igor Novgorodov wrote:
>> On 28.02.2012 15:34, David Sommerseth wrote:


>> And when building with SSL support, it won't be called here, but
>> in ssl_openssl.c in tls_init_lib() instead.
> 
> Indeed.  This looks good.  So unless Adriaan see some other
> concerns.
> 
> Again, sorry about the noise!
> 

Ack! Thanks, that looks good.

Adriaan

Re: [Openvpn-devel] openvpn windows gui

[Alon Bar-Lev]

2012/2/28 Jan Just Keijser :
> Samuli Seppänen wrote:

 We should probably write an installer.

>>>
>>> I'm not sure if it's the best idea to make each and every GUI project out
>>> there write it's own installer, when it's mostly a single executable that
>>> needs to be replaced to package it with upstream openvpn. The pragmatic way
>>> to do it would be to leave the GUI stuff in openvpn itself, but I guess you
>>> guys like the idea of bundling installers with other installers, right?
>>>
>>> Heiko
>>
>>
>> Right :). The primary benefit I see in having separate installers for
>> the OpenVPN-GUI, TAP-driver and easy-rsa is the possibility of
>> installing and upgrading each component separately more easily. It might
>> even be possible (=have not checked) to have the "OpenVPN Windows
>> installer bundle" fetch the latest dependency installers from predefined
>> URLs prior to installation and fallback to included ones if that fails.
>> Not sure if we want do that, but it's an option.
>>
>>
>
> e, it would be nice to keep/have a "single click install" option - one
> of the nice features of the current OpenVPN installer is that you get
> everything in one download. Also, it will ensure that there is at least one
> set of components that works together.
>
> JM2CW,
>
> JJK
>
>

The new Installer installs easy-rsa and openvpn-gui.
Soon also the tap.

Alon.

Re: [Openvpn-devel] openvpn windows gui

[Jan Just Keijser]

Samuli Seppänen wrote:

We should probably write an installer.
  
I'm not sure if it's the best idea to make each and every GUI project out 
there write it's own installer, when it's mostly a single executable that 
needs to be replaced to package it with upstream openvpn. The pragmatic way to 
do it would be to leave the GUI stuff in openvpn itself, but I guess you guys 
like the idea of bundling installers with other installers, right?


Heiko 



Right :). The primary benefit I see in having separate installers for
the OpenVPN-GUI, TAP-driver and easy-rsa is the possibility of
installing and upgrading each component separately more easily. It might
even be possible (=have not checked) to have the "OpenVPN Windows
installer bundle" fetch the latest dependency installers from predefined
URLs prior to installation and fallback to included ones if that fails.
Not sure if we want do that, but it's an option.

  
e, it would be nice to keep/have a "single click install" option - 
one of the nice features of the current OpenVPN installer is that you 
get everything in one download. Also, it will ensure that there is at 
least one set of components that works together.


JM2CW,

JJK

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 12:40, Igor Novgorodov wrote:
> On 28.02.2012 15:34, David Sommerseth wrote:
>> On 28/02/12 12:16, Igor Novgorodov wrote:
>>> On 28.02.2012 14:39, David Sommerseth wrote:
 On 28/02/12 06:54, Igor Novgorodov wrote:
[...snip...]
 Right now, this patch makes me really concerned and scared.
 For this to be accepted, a lot of testing must be done - and
 most likely by people understanding the darker sides of crypto
 far better than I.  We can't risk that we're regressing on a
 well proved and tested encryption layer. There are people
 located in not so democratic countries who use OpenVPN to access
 a not-restricted/censored Internet - and their safety may rely
 on the security OpenVPN provides.
>>> I agree fully. So if we just move these calls into
>>> crypto_openssl.c, no regression would occur i think.
>> Agreed, I think it makes sense to move all native OpenSSL calls
>> into *_openssl.[ch] files.
>> 
>> I'm still not convinced about this part though.
>> 
>> +#ifndef USE_SSL +#ifndef ENABLE_SMALL +  ERR_load_crypto_strings
>> (); +#endif +  OpenSSL_add_all_algorithms (); +#endif
>> 
>> OpenSSL_add_algorithms() is also needed for *non-SSL* stuff.  It is 
>> populates the internal OpenSSL lookup tables, so you can lookup
>> strings like "MD5", "SHA512", "AES256", etc,  etc via
>> EVP_get_digestbyname() and EVP_get_cipherbyname() which will return
>> the proper EVP_* objects back. And neither of these are strictly
>> SSL, they are all crypto related.  SSL depends on the crypto part,
>> but the crypto doesn't need SSL.
> Well, it's the #ifNdef directive used, so when building *without* SSL 
> support, the OpenSSL_add_all_algorithms() will be called here, in
> crypto_openssl.c

Duh!  Sorry!!!  I didn't see the 'n' in the #ifndef.  Thanks for
highlighting that.  It all makes sense now.

> And when building with SSL support, it won't be called here, but in 
> ssl_openssl.c in tls_init_lib() instead.

Indeed.  This looks good.  So unless Adriaan see some other concerns.

Again, sorry about the noise!


kind regards,

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

iEYEARECAAYFAk9Mvv8ACgkQDC186MBRfrq/fgCeJRL5uESQF8aK+qaGxb0rRyw9
V0cAn0k3HXnDa5X8hxfgRNDuwAjsXggY
=SqO3
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[Igor Novgorodov]

On 28.02.2012 15:34, David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 12:16, Igor Novgorodov wrote:

On 28.02.2012 14:39, David Sommerseth wrote:

On 28/02/12 06:54, Igor Novgorodov wrote:

Then maybe we should move these calls to crypto_openssl.c into
crypto_init_lib() function to make crypto.c library-independent?
And why OpenSSL_add_all_algorithms() and stuff is called only
when USE_SSL is not defined?

And if these calls are for 0.9.8, maybe add a check for OpenSSL
version?

Remember that OpenSSL covers two parts.  One part is the SSL stuff,
the other part is the crypto layer.  So even if the SSL stuff isn't
used, the crypto stuff most likely is.  In the crypto stuff, also
all the hashing algorithms are included.  However, using SSL without
crypto doesn't make sense.  If it's not needed any more by OpenSSL
1.0.0, then make it version dependent.  Can probably be done at
compile time.

Well, i'm no expert in OpenSSL programming, but looking through
internet, i haven't found an evidence that this stuff should not be
called during initialization in OpenSSL 1.0.x

So, just to make OpenVPN possible to build with --ssl-type=polarssl
and --disable-ssl, i propose the attached patch that moves calls to
these functions into crypto_openssl.c


Removing the ERR_load_crypto_strings() call will most likely break
the error logging too, which is used by the msg() function.  It will
not make the crypto/SSL errors more understandable, how I understand
it.

May I suggest that both ERR_load_crypto_strings() and
SSL_load_error_strings() (gotta love the consistency of function
naming) is loaded by default, unless ENABLE_SMALL is defined?

I agree, added the check for ENABLE_SMALL in ssl_openssl.c and
crypto_openssl.c to the attached patch.


Right now, this patch makes me really concerned and scared.  For
this to be accepted, a lot of testing must be done - and most likely
by people understanding the darker sides of crypto far better than
I.  We can't risk that we're regressing on a well proved and tested
encryption layer. There are people located in not so democratic
countries who use OpenVPN to access a not-restricted/censored
Internet - and their safety may rely on the security OpenVPN
provides.

I agree fully. So if we just move these calls into crypto_openssl.c,
no regression would occur i think.

Agreed, I think it makes sense to move all native OpenSSL calls into
*_openssl.[ch] files.

I'm still not convinced about this part though.

+#ifndef USE_SSL
+#ifndef ENABLE_SMALL
+  ERR_load_crypto_strings ();
+#endif
+  OpenSSL_add_all_algorithms ();
+#endif

OpenSSL_add_algorithms() is also needed for *non-SSL* stuff.  It is
populates the internal OpenSSL lookup tables, so you can lookup strings
like "MD5", "SHA512", "AES256", etc,  etc via EVP_get_digestbyname() and
EVP_get_cipherbyname() which will return the proper EVP_* objects back.
  And neither of these are strictly SSL, they are all crypto related.  SSL
depends on the crypto part, but the crypto doesn't need SSL.
Well, it's the #ifNdef directive used, so when building *without* SSL 
support, the

OpenSSL_add_all_algorithms() will be called here, in crypto_openssl.c

And when building with SSL support, it won't be called here, but in 
ssl_openssl.c in tls_init_lib() instead.


Looks fine to me.


Adriaan, what do you think?


kind regards,

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

iEYEARECAAYFAk9Mu80ACgkQDC186MBRfrpj2QCfYPpJa8CbFNZwJvGbyAHIpLBI
dgwAn2P2QD6YKq2qU9N6MaKhTl2OX94M
=ticZ
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 12:16, Igor Novgorodov wrote:
> On 28.02.2012 14:39, David Sommerseth wrote:
>> On 28/02/12 06:54, Igor Novgorodov wrote:
>>> Then maybe we should move these calls to crypto_openssl.c into 
>>> crypto_init_lib() function to make crypto.c library-independent?
>>> And why OpenSSL_add_all_algorithms() and stuff is called only
>>> when USE_SSL is not defined?
>>> 
>>> And if these calls are for 0.9.8, maybe add a check for OpenSSL 
>>> version?
>> Remember that OpenSSL covers two parts.  One part is the SSL stuff,
>> the other part is the crypto layer.  So even if the SSL stuff isn't
>> used, the crypto stuff most likely is.  In the crypto stuff, also
>> all the hashing algorithms are included.  However, using SSL without
>> crypto doesn't make sense.  If it's not needed any more by OpenSSL
>> 1.0.0, then make it version dependent.  Can probably be done at
>> compile time.
> Well, i'm no expert in OpenSSL programming, but looking through
> internet, i haven't found an evidence that this stuff should not be
> called during initialization in OpenSSL 1.0.x
> 
> So, just to make OpenVPN possible to build with --ssl-type=polarssl
> and --disable-ssl, i propose the attached patch that moves calls to
> these functions into crypto_openssl.c
> 
>> Removing the ERR_load_crypto_strings() call will most likely break
>> the error logging too, which is used by the msg() function.  It will
>> not make the crypto/SSL errors more understandable, how I understand
>> it.
>> 
>> May I suggest that both ERR_load_crypto_strings() and 
>> SSL_load_error_strings() (gotta love the consistency of function
>> naming) is loaded by default, unless ENABLE_SMALL is defined?
> I agree, added the check for ENABLE_SMALL in ssl_openssl.c and 
> crypto_openssl.c to the attached patch.
> 
>> Right now, this patch makes me really concerned and scared.  For
>> this to be accepted, a lot of testing must be done - and most likely
>> by people understanding the darker sides of crypto far better than
>> I.  We can't risk that we're regressing on a well proved and tested
>> encryption layer. There are people located in not so democratic
>> countries who use OpenVPN to access a not-restricted/censored
>> Internet - and their safety may rely on the security OpenVPN
>> provides.
> 
> I agree fully. So if we just move these calls into crypto_openssl.c,
> no regression would occur i think.

Agreed, I think it makes sense to move all native OpenSSL calls into
*_openssl.[ch] files.

I'm still not convinced about this part though.

+#ifndef USE_SSL
+#ifndef ENABLE_SMALL
+  ERR_load_crypto_strings ();
+#endif
+  OpenSSL_add_all_algorithms ();
+#endif

OpenSSL_add_algorithms() is also needed for *non-SSL* stuff.  It is
populates the internal OpenSSL lookup tables, so you can lookup strings
like "MD5", "SHA512", "AES256", etc,  etc via EVP_get_digestbyname() and
EVP_get_cipherbyname() which will return the proper EVP_* objects back.
 And neither of these are strictly SSL, they are all crypto related.  SSL
depends on the crypto part, but the crypto doesn't need SSL.

Adriaan, what do you think?


kind regards,

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

iEYEARECAAYFAk9Mu80ACgkQDC186MBRfrpj2QCfYPpJa8CbFNZwJvGbyAHIpLBI
dgwAn2P2QD6YKq2qU9N6MaKhTl2OX94M
=ticZ
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[Igor Novgorodov]

On 28.02.2012 14:39, David Sommerseth wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 06:54, Igor Novgorodov wrote:

Then maybe we should move these calls to crypto_openssl.c into
crypto_init_lib() function to make crypto.c library-independent? And
why OpenSSL_add_all_algorithms() and stuff is called only when
USE_SSL is not defined?

And if these calls are for 0.9.8, maybe add a check for OpenSSL
version?

Remember that OpenSSL covers two parts.  One part is the SSL stuff, the
other part is the crypto layer.  So even if the SSL stuff isn't used, the
crypto stuff most likely is.  In the crypto stuff, also all the hashing
algorithms are included.  However, using SSL without crypto doesn't make
sense.  If it's not needed any more by OpenSSL 1.0.0, then make it
version dependent.  Can probably be done at compile time.
Well, i'm no expert in OpenSSL programming, but looking through 
internet, i haven't
found an evidence that this stuff should not be called during 
initialization in OpenSSL 1.0.x


So, just to make OpenVPN possible to build with --ssl-type=polarssl and 
--disable-ssl,
i propose the attached patch that moves calls to these functions into 
crypto_openssl.c



Removing the ERR_load_crypto_strings() call will most likely break the
error logging too, which is used by the msg() function.  It will not make
the crypto/SSL errors more understandable, how I understand it.

May I suggest that both ERR_load_crypto_strings() and
SSL_load_error_strings() (gotta love the consistency of function naming)
is loaded by default, unless ENABLE_SMALL is defined?
I agree, added the check for ENABLE_SMALL in ssl_openssl.c and 
crypto_openssl.c to the attached patch.



Right now, this patch makes me really concerned and scared.  For this to
be accepted, a lot of testing must be done - and most likely by people
understanding the darker sides of crypto far better than I.  We can't
risk that we're regressing on a well proved and tested encryption layer.
  There are people located in not so democratic countries who use OpenVPN
to access a not-restricted/censored Internet - and their safety may rely
on the security OpenVPN provides.
I agree fully. So if we just move these calls into crypto_openssl.c, no 
regression would occur

i think.



kind regards,

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

iEYEARECAAYFAk9MrvEACgkQDC186MBRfroaSgCdGkPFPLK7D9XKiJa30lkfWmaV
BJkAnAyAg+GbYmA3OrQ3HmNL+4AQTisq
=kilG
-END PGP SIGNATURE-


--- openvpn/crypto.c2012-02-27 23:10:53.613624010 +0400
+++ openvpn.mod/crypto.c2012-02-27 23:45:02.128929211 +0400
@@ -1378,8 +1378,6 @@
 void
 init_ssl_lib (void)
 {
-  ERR_load_crypto_strings ();
-  OpenSSL_add_all_algorithms ();
   crypto_init_lib ();
 }

@@ -1388,8 +1386,6 @@
 {
   crypto_uninit_lib ();
   prng_uninit();
-  EVP_cleanup ();
-  ERR_free_strings ();
 }

 #endif /* USE_SSL */
--- openvpn/crypto_openssl.c2012-02-27 23:10:53.613624010 +0400
+++ openvpn.mod/crypto_openssl.c2012-02-28 15:10:54.924689605 +0400
@@ -249,11 +249,19 @@
 void
 crypto_init_lib (void)
 {
+#ifndef USE_SSL
+#ifndef ENABLE_SMALL
+  ERR_load_crypto_strings ();
+#endif
+  OpenSSL_add_all_algorithms ();
+#endif
+
   /*
* If you build the OpenSSL library and OpenVPN with
* CRYPTO_MDEBUG, you will get a listing of OpenSSL
* memory leaks on program termination.
*/
+
 #ifdef CRYPTO_MDEBUG
   CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_ON);
 #endif
@@ -262,6 +270,13 @@
 void
 crypto_uninit_lib (void)
 {
+#ifndef USE_SSL
+  EVP_cleanup ();
+#ifndef ENABLE_SMALL
+  ERR_free_strings ();
+#endif
+#endif
+
 #ifdef CRYPTO_MDEBUG
   FILE* fp = fopen ("sdlog", "w");
   ASSERT (fp);
--- openvpn/ssl_openssl.c   2012-02-27 23:10:53.623623694 +0400
+++ openvpn.mod/ssl_openssl.c   2012-02-28 15:11:44.243156781 +0400
@@ -63,7 +63,9 @@
 tls_init_lib()
 {
   SSL_library_init();
+#ifndef ENABLE_SMALL
   SSL_load_error_strings();
+#endif
   OpenSSL_add_all_algorithms ();

   mydata_index = SSL_get_ex_new_index(0, "struct session *", NULL, NULL, NULL);
@@ -74,7 +76,9 @@
 tls_free_lib()
 {
   EVP_cleanup();
+#ifndef ENABLE_SMALL
   ERR_free_strings();
+#endif
 }

 void

Re: [Openvpn-devel] static build

[Samuli Seppänen]

>> Mr Dash Four: could you try following the steps Alon gave in his earlier
>> mail to see if it works for you? The buildsystem fetches the
>> dependencies from standard URLs, see "openvpn-build/generic/build.vars".
>>   
> Except that they are not "standard", at least not all of them.
> The Alon's version of "openvpn 2.3_alpha1" is very different from 
> "openvpn 2.3_alpha1" downloaded from the official openvpn git repository 
> using the same tag! If you do not believe me - take a look for yourself.

I hear you. as you probably know, Alon's been working on major overhaul
of the buildsystem, which affects tons of source code files. In these
cases forking the project temporarily into a separate Git repository is
a standard practice. His patches are now being reviewed and merged into
the official Git repository.

That said, I agree the naming is misleading.

> To conclude this, I am very happy that I was finally able to produce 
> openvpn, which is statically-linked so that I could avoid all bionic 
> dependencies or depending on any other android-based stuff. Now I can, 
> hopefully, use this on my android device without further problems, 
> fingers crossed!

Good to hear you got it working!

Take care,

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

irc freenode net: mattock

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[David Sommerseth]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 28/02/12 06:54, Igor Novgorodov wrote:
> Then maybe we should move these calls to crypto_openssl.c into 
> crypto_init_lib() function to make crypto.c library-independent? And 
> why OpenSSL_add_all_algorithms() and stuff is called only when
> USE_SSL is not defined?
> 
> And if these calls are for 0.9.8, maybe add a check for OpenSSL 
> version?

Remember that OpenSSL covers two parts.  One part is the SSL stuff, the
other part is the crypto layer.  So even if the SSL stuff isn't used, the
crypto stuff most likely is.  In the crypto stuff, also all the hashing
algorithms are included.  However, using SSL without crypto doesn't make
sense.  If it's not needed any more by OpenSSL 1.0.0, then make it
version dependent.  Can probably be done at compile time.

Removing the ERR_load_crypto_strings() call will most likely break the
error logging too, which is used by the msg() function.  It will not make
the crypto/SSL errors more understandable, how I understand it.

May I suggest that both ERR_load_crypto_strings() and
SSL_load_error_strings() (gotta love the consistency of function naming)
is loaded by default, unless ENABLE_SMALL is defined?

Right now, this patch makes me really concerned and scared.  For this to
be accepted, a lot of testing must be done - and most likely by people
understanding the darker sides of crypto far better than I.  We can't
risk that we're regressing on a well proved and tested encryption layer.
 There are people located in not so democratic countries who use OpenVPN
to access a not-restricted/censored Internet - and their safety may rely
on the security OpenVPN provides.


kind regards,

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

iEYEARECAAYFAk9MrvEACgkQDC186MBRfroaSgCdGkPFPLK7D9XKiJa30lkfWmaV
BJkAnAyAg+GbYmA3OrQ3HmNL+4AQTisq
=kilG
-END PGP SIGNATURE-

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[Alon Bar-Lev]

Hmmm
I really can't tell... maybe can be removed until someone reports an issue...
I just remember that there were cases it was needed and cases it wasn't.
It will not hurt to call these in any case.

On Tue, Feb 28, 2012 at 7:54 AM, Igor Novgorodov  wrote:
> Then maybe we should move these calls to crypto_openssl.c into
> crypto_init_lib() function to make crypto.c library-independent?
> And why OpenSSL_add_all_algorithms() and stuff is called only when USE_SSL
> is not defined?
>
> And if these calls are for 0.9.8, maybe add a check for OpenSSL version?
>
>
> On 28.02.2012 0:10, Alon Bar-Lev wrote:
>>
>> These are needed for 0.9.8 as far as I remember.
>> On Mon, Feb 27, 2012 at 10:06 PM, Igor Novgorodov  wrote:
>>>
>>> The attached patch removes deprecated(?) calls to OpenSSL functions from
>>> crypro.c,
>>> which are called when USE_SSL is not defined.
>>>
>>> I'm not so deep into OpenVPN, so maybe these functions are needed, but i
>>> thought that all crypto-lib
>>> dependent functions should be moved to the corresponding crypto_LIB.c
>>> files.
>>>
>>> If they are needed, we should #ifdef them, so that PolarSSL-based build
>>> won't break on it.
>>>
>>>
>>> --
>>> Try before you buy = See our experts in action!
>>> The most comprehensive online learning library for Microsoft developers
>>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>>> Metro Style Apps, more. Free future releases when you subscribe now!
>>> http://p.sf.net/sfu/learndevnow-dev2
>>> ___
>>> Openvpn-devel mailing list
>>> Openvpn-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>>>
>

Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL 1.1.x branch

[Adriaan de Jong]

Hi Fabian and Igor,

Thanks for your patch! As the Havege random number generator has some known 
issues on a (limited) set of virtual machines, there's a brand new RNG in 
PolarSSL. I'm currently working on a more complete support patch for PolarSSL's 
new RNG. 

Instead of calling Havege directly, this patch calls the NIST DRBG which uses 
both Havege and the platform RNG as entropy sources (/dev/urandom).
 
For the moment, I'd prefer to include that here, instead of these more limited 
patches.

Kind regards,

Adriaan

> -Original Message-
> From: fab...@lettink.de [mailto:fab...@lettink.de] On Behalf Of Fabian
> Knittel
> Sent: dinsdag 28 februari 2012 8:40
> To: Igor Novgorodov
> Cc: Adriaan de Jong; openvpn-devel@lists.sourceforge.net
> Subject: Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL
> 1.1.x branch
> 
> Hi Igor,
> 
> 2012/2/28 Igor Novgorodov :
> > On 28.02.2012 1:37, Fabian Knittel wrote:
> >> Your patch removes the code that causes havege_init() to only be
> >> called once. You never want to initialise your PRNG more than once,
> >> otherwise you increase the risk that your randomness is predictable.
> >> So please revert that part of your patch.
> >
> > Yes, my fault. I didn't notice that the variable was static, so i
> > though that it was local-scope only and removed the check... The
> fixed
> > patch is attached
> 
> Thanks!
> 
> >> ([...], although I haven't tested it and don't have any experience
> >> with PolarSSL.)
> 
> Maybe Adriaan or someone else can take a quick peek and give a full-
> hearted ACK?
> 
> Cheers
> Fabian

Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL 1.1.x branch

[Fabian Knittel]

Hi Igor,

2012/2/28 Igor Novgorodov :
> On 28.02.2012 1:37, Fabian Knittel wrote:
>> Your patch removes the code that causes havege_init() to only be
>> called once. You never want to initialise your PRNG more than once,
>> otherwise you increase the risk that your randomness is predictable.
>> So please revert that part of your patch.
>
> Yes, my fault. I didn't notice that the variable was static, so i though
> that it was local-scope only and removed the check... The fixed patch is 
> attached

Thanks!

>> ([...], although I haven't tested it and don't have any
>> experience with PolarSSL.)

Maybe Adriaan or someone else can take a quick peek and give a full-hearted ACK?

Cheers
Fabian

Re: [Openvpn-devel] [PATCH 02/02] Remove calls to OpenSSL when building with --disable-ssl

[Igor Novgorodov]

Then maybe we should move these calls to crypto_openssl.c into 
crypto_init_lib() function to make crypto.c library-independent?
And why OpenSSL_add_all_algorithms() and stuff is called only when 
USE_SSL is not defined?


And if these calls are for 0.9.8, maybe add a check for OpenSSL version?

On 28.02.2012 0:10, Alon Bar-Lev wrote:

These are needed for 0.9.8 as far as I remember.
On Mon, Feb 27, 2012 at 10:06 PM, Igor Novgorodov  wrote:

The attached patch removes deprecated(?) calls to OpenSSL functions from
crypro.c,
which are called when USE_SSL is not defined.

I'm not so deep into OpenVPN, so maybe these functions are needed, but i
thought that all crypto-lib
dependent functions should be moved to the corresponding crypto_LIB.c files.

If they are needed, we should #ifdef them, so that PolarSSL-based build
won't break on it.

--
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 01/02] Add support for PolarSSL 1.1.x branch

[Igor Novgorodov]

On 28.02.2012 1:37, Fabian Knittel wrote:

Hi Igor,

2012/2/27 Igor Novgorodov:

The attached patch adds checking for PolarSSL version on crypto_polarssl.c
and depending on which version we are using (1.0.x or 1.1.x) chooses a new
shiny havege_random() function, or an old ugly while{} loop hack to generate
randomness.

Your patch removes the code that causes havege_init() to only be
called once. You never want to initialise your PRNG more than once,
otherwise you increase the risk that your randomness is predictable.
So please revert that part of your patch.
Yes, my fault. I didn't notice that the variable was static, so i though 
that it

was local-scope only and removed the check... The fixed patch is attached


(The rest looks fine, although I haven't tested it and don't have any
experience with PolarSSL.)

Cheers
Fabian



--- a/crypto_polarssl.c
+++ b/crypto_polarssl.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /*
  *
@@ -158,7 +159,6 @@
 {
   static havege_state hs = {0};
   static bool hs_initialised = false;
-  const int int_size = sizeof(int);
 
   if (!hs_initialised)
 {
@@ -167,15 +167,21 @@
   hs_initialised = true;
 }
 
+#if (POLARSSL_VERSION_MAJOR >= 1 && POLARSSL_VERSION_MINOR >= 1)
+  havege_random(, output, len);
+#else
+  const int int_size = sizeof(int);
+
   while (len > 0)
 {
-  const int blen   = min_int (len, int_size);
-  const int rand_int   = havege_rand();
+  const int blen= min_int (len, int_size);
+  const int rand_int= havege_rand();
 
   memcpy (output, _int, blen);
   output += blen;
   len -= blen;
 }
+#endif
   return 1;
 }
 

Re: [Openvpn-devel] openvpn windows gui

[Alon Bar-Lev]

On Mon, Feb 27, 2012 at 6:18 PM, Alon Bar-Lev  wrote:
> Will be ready in a few hours.

Done [1].
Tarball is available.
Please review/pull.

Basically you need to modify the --with-crypto...
With:
./configure CFLAGS="-Ixxx/include" LDFLAGS="-Lxxx/lib"
Where xxx is the openssl location.
The build script now also builds the gui, so you use it...

I added --enable-deponly to allow "make dist" at Linux.

[1] https://github.com/alonbl/openvpn-gui
[2] https://github.com/alonbl/openvpn-build