[Openvpn-devel] [Patch] revoke scripts were broken
Hi all, here is a tiny patch to make revoke-crt and make-crl work seamlessly within the easy-rsa environment. Seems that no one used it before ;) Jan PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] diff -Nur /tmp/openvpn-2.0_beta6/easy-rsa/make-crl openvpn-2.0_beta6/easy-rsa/make-crl --- /tmp/openvpn-2.0_beta6/easy-rsa/make-crl2004-06-15 02:01:13.0 +0200 +++ openvpn-2.0_beta6/easy-rsa/make-crl 2004-06-29 16:50:09.836098144 +0200 @@ -12,7 +12,7 @@ if test $KEY_DIR; then cd $KEY_DIR && \ - openssl ca -gencrl -out $1 + openssl ca -gencrl -out $1 -config $KEY_CONFIG else echo you must define KEY_DIR fi diff -Nur /tmp/openvpn-2.0_beta6/easy-rsa/revoke-crt openvpn-2.0_beta6/easy-rsa/revoke-crt --- /tmp/openvpn-2.0_beta6/easy-rsa/revoke-crt 2004-06-15 02:01:13.0 +0200 +++ openvpn-2.0_beta6/easy-rsa/revoke-crt 2004-06-29 16:50:21.703294056 +0200 @@ -12,7 +12,7 @@ if test $KEY_DIR; then cd $KEY_DIR && \ - openssl ca -revoke $1 + openssl ca -revoke $1 -config $KEY_CONFIG else echo you must define KEY_DIR fi
Re: [Openvpn-devel] [Patch] revoke scripts were broken
On Tue, 29 Jun 2004, Jan Kiszka wrote: PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though! I don't want to bother this list with basic C programming issues though, but if someone is used to classic C programming and message handeling in windows, please contact me offlist if you got a spare minute. A pointer to a good mailing-list for discussion about classic C programming in windows would be appreciated too. -- _ 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: [Openvpn-devel] [Patch] revoke scripts were broken
Mathias Sundman wrote: On Tue, 29 Jun 2004, Jan Kiszka wrote: PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? Just a thought, I'm not saying I have the time for doing it - unfortunately. [If you reply, please add a CC, I'm not on the list] I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though! I don't want to bother this list with basic C programming issues though, but if someone is used to classic C programming and message handeling in windows, please contact me offlist if you got a spare minute. A pointer to a good mailing-list for discussion about classic C programming in windows would be appreciated too. While considering a similar interface for some other project, I once took a closer look at wxWindows (http://www.wxwindows.org). Before you start hacking your own message handling routines in C or switching over to the Windows-only MFC library, this project may be worth some thoughts because A) it capsulates most of the annoying GUI work, and B) it opens to possiblity to port your work later to Linux as well! I think not only Windows users would appreciate a simple management interface for OpenVPN clients very much... The only problem so far: You have to consider writing your program object-oriented, i.e. in C++. Did you ever worked with some OO languages (Java e.g.)? 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. Comments are welcome! Jan
Re: [Openvpn-devel] [Patch] revoke scripts were broken
On Tuesday 29 June 2004 11:06, Jan Kiszka wrote: > Hi all, > > here is a tiny patch to make revoke-crt and make-crl work seamlessly > within the easy-rsa environment. Seems that no one used it before ;) Thanks, I've merged for inclusion in beta8. James
Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
> 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
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
On Wed, 30 Jun 2004, Jan Kiszka wrote: PS: Has anyone ever thought about some small GUI (taskbar icon with some dialogs) for Windows, KDE, etc. to make the handling of multiple configurations and the status display easier in a roadwarrior scenario? I just started working on such an application last night. I'm kinda new to C programming in Windows so I ran into a little annoying problem right away though! While considering a similar interface for some other project, I once took a closer look at wxWindows (http://www.wxwindows.org). Before you start hacking your own message handling routines in C or switching over to the Windows-only MFC library, this project may be worth some thoughts because A) it capsulates most of the annoying GUI work, and B) it opens to possiblity to port your work later to Linux as well! I think not only Windows users would appreciate a simple management interface for OpenVPN clients very much... The only problem so far: You have to consider writing your program object-oriented, i.e. in C++. Did you ever worked with some OO languages (Java e.g.)? 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. 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. 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 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. 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? On Wed, 30 Jun 2004, James Yonan wrote: 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 That's great news. That was one of my concerns the other night, how to communicate with OpenVPN to check the status. -- _ 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 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
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
> 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
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
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
On Saturday 03 July 2004 15:13, Brandon Knitter wrote: > 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. 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. James
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
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
On Saturday 03 July 2004 16:40, Mathias Sundman wrote: > 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. 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] > 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 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
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
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
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
Denis Vlasenko wrote: 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. 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? Jan smime.p7s Description: S/MIME Cryptographic Signature
Re: Interface with GUI agent, was: Re: [Openvpn-devel] [Patch] revoke scripts were broken
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
> >>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
On Sunday 04 July 2004 04:37, Jan Kiszka wrote: > >>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. > > 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 Easy. openvpn shall start in admin account, then read the key, and *then* change its uid to the uid killable by user. -- vda