To start with - I really, really appreciate the work that's gone into the 
program.
I've released stuff myself, and it's not an easy process, especially for 
something
as complex and with so much functionality as openvpn.  I get that.

But from a user's perspective - anything that can make the horror known as 
openvpn configuration easier would improve openvpn's adoption considerably.

Here's a true tale.  I'm writing a little thing to use openvpn.  I'd like to 
think I know 
networks a bit - more on the theory at times than implementation, but whatever.

OpenVPN ranks up there with pgp and openssh for the most fucked up and 
mysterious configurations I've ever seen (it is not a coincidence that they're
all crypto programs, I believe.)  It is legendary among non-openvpn people to
be ridiculously difficult.   I'm actually pretty sure that if one is an openvpn 
person
who knows you're doing it's not that bad, or even makes some internal sense.  
But I'd wager that high-ninety% of your user base doesn't fall into that camp.  
Well, of your potential user base, that is, most don't get that far.

I am not saying this to say "everything is fuxx3d up" or something.  I'm telling
you because it took me a couple of days to get even the most basic thing really
working on a not-terribly-complex setup.  And while I understand the conceptual
matters of your program, honestly, I fear to set it up, and have little faith 
that even
if I get it running it'll do what I want it to.

I'm not even complaining for myself - I'm a big guy, I can take care of myself, 
and take it or leave it - but for others…..

I'll channel the Lorax for your users - please, stop adding features, and add 
usability - having the ability to have options that really don't mean much to 
most and are simply designed to enhance performance or tweak security… 
just make the defaults reasonable and have it work, or have the client auto-
suck up server stuff unless you want to turn on the "open-vpn-conf-hard=true"
option or whatever.  I'd love to have an openvpn lite or whatever that just
works, is maybe kinda slow, but secure enough according to you folks the
experts, etc… then I'll dance a jig and toast you from seattle.  I think we're
in a different world than when OpenVPN was made, and more and more 
people are hungry for - dare I say need? - the sort of security and protection
it can offer (shamefully, against my own government!)

Again - please, don't take my critique as some sort of personal slight or 
damnation of the fine work you folks have done.  I really do appreciate the 
stuff, and I'm trying to use it (lol), but there seems to be a layer or two of 
complexity that seems needlessly exposed and nearly mandated to configure, 
synchronize with all your clients, and understand  that I feel, at least, 
prevents 
further adoption of your cryptological magic.

My 2 cents, and respectfully yours -

dan

p.s.  Your documentation is voluminous and at times awe-inspiring, but
for a casual setter-upper, too overpowering.  I'm sure the answers are in there
somewhere… but I'm much more likely to search google than your docs for
an answer, FWIW.

On Aug 4, 2013, at 11:47 AM, James Yonan <[email protected]> wrote:

> We've recently merged some patches allowing OpenVPN to negotiate certain 
> settings (such as compression), but unfortunately at this time neither 
> cipher nor auth directives can be negotiated in the 2.x branch.
> 
> The 3.0 branch has fixed this somewhat by having the client support 
> cipher and auth directives that are pushed by the server (*).
> 
> However, to make cipher/auth negotiation really work, there are a few 
> more things that are needed.  For one, the client would need to push a 
> list of supported cipher/auth methods, so the server can choose a 
> mutually supported combination.  Another possibility is to have OpenVPN 
> leverage on the preexisting TLS ciphersuite negotiation, so as to use 
> the same cipher/auth settings as TLS.
> 
> Some of this was discussed recently in the TLS versioning thread on 
> openvpn-devel:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=1CED409804E2164C8104F9E623B08B901455DE1C69%40FOXDFT02.FOX.local&forum_name=openvpn-devel
> 
> James
> 
> *  The 3.0 branch is currently used by the OpenVPN Connect clients for 
> Android and iOS.  Source core for the core is available from 
> http://staging.openvpn.net/openvpn3/
> 
> On 01/08/2013 09:07, Jan Just Keijser wrote:
>> Hi Gert,
>> 
>> Gert Doering wrote:
>>> Hi,
>>> 
>>> On Thu, Aug 01, 2013 at 12:02:55PM +0200, Jan Just Keijser wrote:
>>> 
>>>> It should be possible to add negotiation without completely breaking
>>>> backwards compatibility; right now, when a server pushes an option to
>>>> the client that is unrecognized the client will print a warning but it
>>>> will not abort. This could be used to push a 'negotation request' - if
>>>> the client responds then a negotation phase can start , during which the
>>>> encryption key, hashing cipher, MTU settings etc can be negotiated. If
>>>> the client does not respond the server would need to assume that it's a
>>>> 2.3 or older client.
>>>> 
>>> 
>>> Maybe I'm a bit naive, but since the data layer cipher is independent of
>>> the TLS cipher anyway, can't we just "push cipher xxx"?
>>> 
>>> Or is push/pull crypted with the data layer cipher?
>>> 
>>> 
>> good question and one that I've asked myself as well -  there seems to
>> be something funny going on with the data layer cipher (or auth parm) .
>> I remember that I tried making the cipher and auth settings pushable and
>> failed miserably. The flow of when and how the data cipher (and digest)
>> are set up seems to be complicated and may happen (partially) *before*
>> the options are pushed.
>> Perhaps someone else (JamesY?) can comment on this.
>> 
>> cheers,
>> 
>> JJK
>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> 
>> 
>> 
>> _______________________________________________
>> Openvpn-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/openvpn-devel
>> 
> 
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent 
> caught up. So what steps can you take to put your SQL databases under 
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> Openvpn-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openvpn-users


------------------------------------------------------------------------------
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Reply via email to