Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[James Yonan]

> >>Thinking ahead, the challenge/response sequence for passing
> >> authentication info should be open-ended to provide for future
> >> implementation of alternative authentication methods such as Radius,
> >> LDAP, NT Auth, etc.
> >
> > Please don't do too much of that. I've seen this auth featuritis creeping
> > in ntp and ups tools(!). Results ain't pretty...

I don't think that supplying a generalized authentication mechanism (that's 
method agnostic) will add very much complexity.

The way I see this working is that the SSL/TLS authentication still provides 
the real security.  But after SSL/TLS authentication has occurred, one still 
might want to submit some sort of credentials string to the server (obtained 
via GUI from the user) to determine the common name which will be assigned to 
the client.  In any case, OpenVPN on the server is probably going to 
interface with an authentication library which will handle all the details.

> > Reconfiguration of openvpn can always be done by editing config file
> > and restarting openvpn daemon. Simple. Elegant. No additional coding
> > - no risk of introducing bugs.
> >
> > This can be done via systray app, too.
>
> I can understand your concerns, and mostly you are right. However, there
> is one quite important scenario - at least as I see it - where you need
> the core daemon and the GUI running in different accounts: whenever the
> key or secret has to be looked away from the user while it shall still
> be possible for her/him to start/stop VPN connections. One reason for
> this may be that the key is bound to the device and not the user. The
> other one is security. Through this separation, malicious programs
> running in the context of the user can not so easily access the secret.
>
> And for those who don't trust this new interface (which will surely need
> a careful implementation): what about adding a configure switch and
> putting the respective code in some #ifdefs?

I agree -- the management interface should not be implicitly enabled by 
default.  You will need to specify the "management" config option to turn it 
on.

James

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Jan Kiszka]

James Yonan wrote:


...
Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the 
daemon via a "send auth credentials" command


The basic mechanism of operation to enable the management interface would be 
to pass an option like this in the config file:


  management 127.0.0.1 20001



I would like to have some mechanism to fork an openvpn instance and let 
the new process use a specific configuration file. This would allow to 
start only certain VPN tunnels depending on what the user selects in the 
GUI.


Jan


smime.p7s
Description: S/MIME Cryptographic Signature

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Denis Vlasenko]

On Saturday 03 July 2004 23:01, James Yonan wrote:
>   management 127.0.0.1 20001
>
> This will cause OpenVPN to listen on 127.0.0.1:20001 as its management
> interface port.
>
> It's important, of course, that the management port always be local, since
> we are using it to potentially pass passwords and other sensitive data that
> should never actually touch a real network interface.
>
> Thinking ahead, the challenge/response sequence for passing authentication
> info should be open-ended to provide for future implementation of
> alternative authentication methods such as Radius, LDAP, NT Auth, etc.

Please don't do too much of that. I've seen this auth featuritis creeping
in ntp and ups tools(!). Results ain't pretty...

Reconfiguration of openvpn can always be done by editing config file
and restarting openvpn daemon. Simple. Elegant. No additional coding
- no risk of introducing bugs.

This can be done via systray app, too.
--
vda

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Mathias Sundman]

On Sat, 3 Jul 2004, James Yonan wrote:


There are no hooks as of yet to control a running OpenVPN instance (other
than sending signals).

While I initially thought that named pipes might be the appropriate
channel for this, I'm wondering if if might make more sense (for
portability) to use a local TCP/IP socket as the control channel, such as
127.0.0.0:[some port].

Then for testing purposes, you could just telnet to the socket.

I am thinking the interface should consist of a standard ascii command
response loop, such as is used by SMTP.

Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them
to the daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would
be to pass an option like this in the config file:

 management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management
interface port.


One little wonder though, is it good to have a bi-directional protocol
over a single socket. Ofcource replys to command can go over the same
channel, but if both the server and the client is allowed to "start the
conversation", how do we handle the case when both the server and client
sends a command at the same time.


TCP connections are always full duplex so both sides can send and receive at
the same time without collision issues.

Having said that, the application needs to support bidirectionality, by always
having a listen queued on the port for possible incoming data.

On Windows, the best way to do this is to use the WSAAsyncSelect or
WSAEventSelect functions.  WSAAsyncSelect is particularly useful for Windows
GUI-based programs because it gives you notification of incoming data on a
TCP socket through the standard Windows message notification mechanism.


How will we know if what we recieve is an answer to our command, or a
command from the server?


The unsolicited notification from the server would have a specific prefix that
indicates that it is an asynchronous notification from the server, as opposed
to a response to a client->server command.

For example, the server would say something like this:

NOTIFY:NEED_AUTH,USER,PASS

The "ASYNC" indicates that the message is an asynchronous notification.

NEED_AUTH is the command, and USER/PASS indicates that the GUI should prompt
the user for and return both username and password.

Then the GUI would reply back:

AUTH_USER [username]
AUTH_PASS [password]


Okay. The NOTIFY prefix solves my wonder. I was aware that TCP connections 
are fullduplex, it was just the overlying protocol I was worried about.




In addition to the information given by SIGUSR2 I'd would like to be able
to get current state of the the link. We should be able to define several
STATEs during the establishing of the connection. Like:

STATE_WAIT_FIRST_RESPONE - When we have tried to connect to the remote
peer but still not recieved any answer.

STATE_WAIT_AUTH - We have recieved some answer from the remove peer, but
not yet fully authenticated. (This state will never happend when using
static keys.)

STATE_WAIT_PUSH - We wait for options to be pushed from the server.

STATE_WAIT_SETIP - We are waiting for the system to set the ip address.

STATE_WAIT_APPLY_SETTINGS - We are waiting for the system to set other
pushed parameters like routes.

STATE_CONNECTED - We are fully connected!


We already have something like this in ssl.h (see "key negotiation states"),
but your idea expands beyond this.

I think the states are a good idea.  The state info, like the request for auth
credentials, will be an asynchronous server -> client notification.

For example:

NOTIFY:STATE,STATE_CONNECTED


I think it would be good both if the server sent NOTIFY messages when the 
state is change, and if there was a query command the client can issue to 
receive the current state. One use of the latter is that it would allow 
the gui to hook into an already running process (started by the service 
wrapper perhaps), and check the current state.



--
_
Mathias Sundman  (^)   ASCII Ribbon Campaign
NILINGS ABXNO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28  / \   NO Word docs in e-mail

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Mathias Sundman]

On Sat, 3 Jul 2004, James Yonan wrote:


On Saturday 03 July 2004 15:13, Brandon Knitter wrote:

Where do I start?  Are the namedpipe hooks into the OpenVPN service built?
I'm not too familiar with named pipes on Windows (done a bit on *nix), but
I'm sure it can't be too hard.  I guess what I'd need to know are the
command to send to the named pipe, and also what I can get from the named
pipe in regards to status and such.


There are no hooks as of yet to control a running OpenVPN instance (other than
sending signals).

While I initially thought that named pipes might be the appropriate channel
for this, I'm wondering if if might make more sense (for portability) to use
a local TCP/IP socket as the control channel, such as 127.0.0.0:[some port].

Then for testing purposes, you could just telnet to the socket.

I am thinking the interface should consist of a standard ascii command
response loop, such as is used by SMTP.

Possible client -> server commands:

(1) send auth credentials
(2) get status (as in SIGUSR2)
(3) send signal (SIGHUP, SIGUSR1, or SIGUSR2, SIGTERM)

And server -> client commands:

(1) need auth credentials -- GUI should query the user then return them to the
daemon via a "send auth credentials" command

The basic mechanism of operation to enable the management interface would be
to pass an option like this in the config file:

 management 127.0.0.1 20001

This will cause OpenVPN to listen on 127.0.0.1:20001 as its management
interface port.

It's important, of course, that the management port always be local, since we
are using it to potentially pass passwords and other sensitive data that
should never actually touch a real network interface.

Thinking ahead, the challenge/response sequence for passing authentication
info should be open-ended to provide for future implementation of alternative
authentication methods such as Radius, LDAP, NT Auth, etc.

This is all just a proposal, no code has been written yet, comments are
welcome.


This sounds good to me, and will allow us to start with a basic set of 
"commands", and add more as we find the need for a specific function.


One little wonder though, is it good to have a bi-directional protocol 
over a single socket. Ofcource replys to command can go over the same 
channel, but if both the server and the client is allowed to "start the 
conversation", how do we handle the case when both the server and client

sends a command at the same time.

How will we know if what we recieve is an answer to our command, or a 
command from the server?



In addition to the information given by SIGUSR2 I'd would like to be able 
to get current state of the the link. We should be able to define several 
STATEs during the establishing of the connection. Like:


STATE_WAIT_FIRST_RESPONE - When we have tried to connect to the remote 
peer but still not recieved any answer.


STATE_WAIT_AUTH - We have recieved some answer from the remove peer, but 
not yet fully authenticated. (This state will never happend when using 
static keys.)


STATE_WAIT_PUSH - We wait for options to be pushed from the server.

STATE_WAIT_SETIP - We are waiting for the system to set the ip address.

STATE_WAIT_APPLY_SETTINGS - We are waiting for the system to set other 
pushed parameters like routes.


STATE_CONNECTED - We are fully connected!


I have not though through the absolute meaing of those states or if the 
names are any good, but it gives you an idea of what kind of information 
I'd like to get.


The reason for several states during the init is ofcource that it will 
allow me to set timeout values for every step and report to the user at 
what step the connection failed.


I suppose it will be best if the gui client query the server for the 
current state.


/Mathias

--
_
Mathias Sundman  (^)   ASCII Ribbon Campaign
NILINGS ABXNO HTML/RTF in e-mail
Tel: +46-(0)8-666 32 28  / \   NO Word docs in e-mail

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Brandon Knitter]

Hey there.  James and I had a prior discussion about the systray app offline,
but I thought I'd just poke my head in here.  I'm not a strong Windows
application programmer, but I've been doing a lot of C# these days.

With that in mind, I was gonna whip together a quickie little systray app in C#
which could control the openvpn server.  I know that C# adds the rather large
.NET framework runtime installation, so my app could be considered a prototype
if you would like!

Where do I start?  Are the namedpipe hooks into the OpenVPN service built?  I'm
not too familiar with named pipes on Windows (done a bit on *nix), but I'm sure
it can't be too hard.  I guess what I'd need to know are the command to send to
the named pipe, and also what I can get from the named pipe in regards to status
and such.

Any suggestions?

-- 
-bk


Quoting James Yonan :

> > James, do you put any preferance in what language/environment a gui for
> > OpenVPN is developed in, if you would distribute it together with the main
> > application in the future?
> 
> These are my current thoughts on this:
> 
> * Preferably, the language development tools and environment are open source,
> 
> so there's no impediment to anyone building from source.
> 
> * The total size of included libraries should be reasonable, so it doesn't 
> excessively push up the size of the Windows self-installing exe.
> 
> Having said that, I'm certainly going to be pragmatic here -- if someone puts
> 
> together a great GUI agent that requires Visual C++ to build, I'm not going 
> to belabor the point.
> 
> On the other hand if it's written in Visual Basic and increases the Windows 
> package size by 10 MB then I'm going to have to think twice about actually 
> bundling it.  But if it's up to standard, I'd still link to it from the 
> website in a heartbeat.
> 
> James
> 
> 
> ---
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
> digital self defense, top technical experts, no vendor pitches, 
> unmatched networking opportunities. Visit www.blackhat.com
> ___
> Openvpn-devel mailing list
> Openvpn-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
> 
> 

Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[Jan Kiszka]

Mathias Sundman wrote:

...
No, I'm not used to OO languages, unfortunally. The reasons why I 
started to write this in C was:


1) I only know how to code in C, VisualBasic and Assembler. Assembler is 
out of the question, and I'm tired of VBs dependency for a bunch of 
DLLs. I like beeing able to compile just one compact exe file and not 
need to create an installation package just to get the application 
working on another machine.




Ok, as far as I remember, you need one additional library for wxWindows. 
MFC, on the other hand, already comes with Windows. The binaries of both 
approaches will be very compact, while you may create larger programs 
when hacking all the standard work (messsage processing etc.) on your own.


2) The egoistic one! I've though of learning to develop windows gui 
applications in C for a long time, but never really got to it. Now I saw 
an opportunity to write something useful and learn something I've wanted 
to learn at the same time.


3) OpenVPN is written in traditional C, so if I for any reason would 
like to integrate the gui into the openvpn binary, that would be very 
easy if the gui itself was written in C.




I personally think that using different languages for different tasks in 
a project should be no problem, especially as C++ fits better to GUI 
modules. But I'm not the project manager :).


4) I like traditional C, and dislike object oriented languages! Don't 
ask me why, it's just my personal taste, and I can fully understand that 
other prefer OO languages...




I'm also hacking most of my software in C - because it's kernel code or 
command line tools. But for GUI stuff, OO is definitely better suited 
and more efficient (due to re-use of components).


I do agree with you though that makeing it portable would have been 
prefered, but just like you, I don't got that much spare time, so I'm 
not sure that I want to spend it learning yet another development 
environment.




Before discouraging you from doing anything at all, I would suggest that 
you start with a basic GUI tool (and feel a bit of the effort ;) ). If 
the interface to the OpenVPN core is specified and stable, extending the 
GUI capabilities can be done later as well - if required.


Jan


smime.p7s
Description: S/MIME Cryptographic Signature

Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken

[James Yonan]

> I would furthermore suggest to discuss the required interface between
> the GUI and the OpenVPN daemon on this list. Starting and stopping would
> be possibly by just running the main binary, but I think a more
> sophisticated status and diagnosis interface requires some other
> mechanism (e.g. a local socket). Such an interface could furthermore
> prevent that the actual user who switches some configuration or just
> checks the status must own superuser privileges to start/stop a OpenVPN
> service and - even worse - read the secret key files.

Yes, I would like to see some kind of interface for control of OpenVPN from 
external programs.

The mechanism of the interface would be a socket on *nix or a named pipe on 
Windows.

The interface would primarily be for interaction with a GUI agent and would 
allow for:

* Stop/Restart control
* Get status (like SIGUSR2)
* Provide authentication info

James