[Openvpn-devel] A proposal to add management client version

[selva . nair]

From: Selva Nair 

RFC: only compile-tested

- Allow "version" command from client to management to set
  the version of management interface supported by the client
  by specifying an optional parameter.

  If no parameter is specified the current the version of OpenVPN
  and its management interface is returned (current behaviour).

  The client version defaults to 1 which is the current version of
  the Management Interface.

This will allow adding new features to the management interface without
breaking existing clients.

---
 doc/management-notes.txt |  6 +-
 src/openvpn/manage.c | 17 -
 src/openvpn/manage.h |  4 +---
 3 files changed, 22 insertions(+), 5 deletions(-)

diff --git a/doc/management-notes.txt b/doc/management-notes.txt
index a9ba18a..e437966 100644
--- a/doc/management-notes.txt
+++ b/doc/management-notes.txt
@@ -430,8 +430,12 @@ Command examples:
 COMMAND -- version
 --
 
-Show the current OpenVPN and Management Interface versions.
+Set the version of Management Interface supported by the client or
+show the current OpenVPN and Management Interface versions.
 
+Command examples:
+  version 1.1 -- Change management version of client to 1.1 (default = 1)
+  version -- Show the version of OpenVPN and its Management Interface
 
 COMMAND -- auth-retry
 -
diff --git a/src/openvpn/manage.c b/src/openvpn/manage.c
index 650f9e0..d695b76 100644
--- a/src/openvpn/manage.c
+++ b/src/openvpn/manage.c
@@ -123,7 +123,7 @@ man_help(void)
 msg(M_CLIENT, "test n : Produce n lines of output for 
testing/debugging.");
 msg(M_CLIENT, "username type u: Enter username u for a queried 
OpenVPN username.");
 msg(M_CLIENT, "verb [n]   : Set log verbosity level to n, or 
show if n is absent.");
-msg(M_CLIENT, "version: Show current version number.");
+msg(M_CLIENT, "version [x]: Set client's version or show 
current version number of daemon.");
 msg(M_CLIENT, "END");
 }
 
@@ -1241,6 +1241,15 @@ man_network_change(struct management *man, bool 
samenetwork)
 #endif
 
 static void
+set_client_version(struct management *man, const char *version)
+{
+if (version)
+{
+man->connection.client_version = strtof(version, NULL);
+}
+}
+
+static void
 man_dispatch_command(struct management *man, struct status_output *so, const 
char **p, const int nparms)
 {
 struct gc_arena gc = gc_new();
@@ -1255,6 +1264,10 @@ man_dispatch_command(struct management *man, struct 
status_output *so, const cha
 {
 man_help();
 }
+else if (streq(p[0], "version") && p[1])
+{
+set_client_version(man, p[1]);
+}
 else if (streq(p[0], "version"))
 {
 msg(M_CLIENT, "OpenVPN Version: %s", title_string);
@@ -2508,6 +2521,8 @@ man_connection_init(struct management *man)
 man->connection.es = event_set_init(&maxevents, EVENT_METHOD_FAST);
 }
 
+man->connection.client_version = 1; /* default version */
+
 /*
  * Listen/connect socket
  */
diff --git a/src/openvpn/manage.h b/src/openvpn/manage.h
index 364488f..dc37b8c 100644
--- a/src/openvpn/manage.h
+++ b/src/openvpn/manage.h
@@ -311,13 +311,11 @@ struct man_connection {
 int up_query_mode;
 struct user_pass up_query;
 
 #ifdef MANAGMENT_EXTERNAL_KEY
 struct buffer_list *rsa_sig;
 #endif
 #ifdef TARGET_ANDROID
 int fdtosend;
 int lastfdreceived;
 #endif
+float client_version;
 };
 
 struct management
-- 
2.1.4


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/3] Allow external EC key through --management-external-key

[Selva Nair]

> The client could do that when it gets the version message or any time
> later.


Sorry for the type: read that as

The client could do that when it gets the welcome message or any time later.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[David Sommerseth]

On 22/01/18 17:05, Steffan Karger wrote:
> Hi,
> 
> Didn't we have this discussion before?  Gert basically NAK'd removing
> support for a library version in a dot-release, which I think is valid
> reasoning (even though I really would like to drop 0.9.8).
> 
> Anyway, to fill in the facts:
[...snip...]
>> To me it then gets crucial that users needing openssl-0.9.8 have
>> access to a maintained distribution of that particular OpenSSL
>> version.  Otherwise, we're deluding OpenVPN users it is safe to use
>> openssl-0.9.8.
> 
> SLES11 supports 0.9.8 upto 2022:

Ahh!  Sorry!  I once again have forgotten about the pesky SLES11.  On the
other hand, SLES 11 officially ends 31 March 2019 for normal users.  To reach
the 2022 date, you need cash out extra for a separate support agreement.

For RHEL something similar is also possible with RHEL 5. but we considered the
user base willing to do so to be fairly small - also as these agreements tends
to be fairly costly unless you really have to.  SUSE wants to have a chat with
your before revealing any prices, so I can't tell if its the same here.  But
whenever sales wants to get in touch with you to go further, that is seldom a
sign of a reasonable and affordable price.

Regardless ... we should probably document this once and for all more
properly.  Both for OpenSSL and mbed TLS.  We could add it to this draft [1]
and make that draft more official.

[1] 


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/3] Allow external EC key through --management-external-key

[Selva Nair]

Hi,

On Mon, Jan 22, 2018 at 12:18 PM, David Sommerseth
 wrote:
> On 22/01/18 16:27, Selva Nair wrote:
>> - Present patch: connection process appears stuck (but UI is still
>> responsive) and logs show the daemon is waiting for signature
>>
>> - This proposal: connection fails with: "External EC cert/key not
>> supported in this config. Try using --management-external-key 2"
>> User edits the config option and the connection process appears stuck .
>>
>> I suppose the latter is a bit better.
>
> Well, it should probably be tweaked slightly better.  First of all, if run via
> a GUI front-end, it's the GUI which should set this argument.  We could
> consider to add a "fail-safe" on this option, so once set - it can't be
> changed again.  The more advanced rabbit whole fix would be that the command
> line provided --management-external-key option overrides whatever is in the
> configuration file; doing this will require more work though.

Problem with GUI specifying the option is that it has to first check
whether the config uses management-external-key (this option
interferes with --key, --pkcs12 etc.). Probably not an issue with most
UI's out there but Windows GUI doesn't currently parse the config at
all. That said, Windows GUI doesn't support management-external-key so
that's not a strong argument.

>
> This will make the VPN connection will still fail, but it won't be stuck any
> more.  The user may complain "but I did add that option!?" which then is a
> better starting point for support cases ... "Yes, it is most likely ignored as
> your user interface is not capable of this feature".
>
> Another alternative is to extend an already longer error log entry, by
> mentioning "also ensure that your management interface front-end supports
> version 2."

What about extending the current "version" command with an argument
where the client states the version of "management-speak" that it
supports. Current management version is 1, we increase it to 1.1 and
unless the client says "version 1.1" or more we do not send PK_SIGN.
The client could do that when it gets the version message or any time
later. The response to version command (current management version and
openvpn daemon's version stays the same). No full-fledged cap
negotiation, but good enough.

The UX would be much better that way.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/3] Allow external EC key through --management-external-key

[David Sommerseth]

On 22/01/18 16:27, Selva Nair wrote:
> - Present patch: connection process appears stuck (but UI is still
> responsive) and logs show the daemon is waiting for signature
> 
> - This proposal: connection fails with: "External EC cert/key not
> supported in this config. Try using --management-external-key 2"
> User edits the config option and the connection process appears stuck .
> 
> I suppose the latter is a bit better.

Well, it should probably be tweaked slightly better.  First of all, if run via
a GUI front-end, it's the GUI which should set this argument.  We could
consider to add a "fail-safe" on this option, so once set - it can't be
changed again.  The more advanced rabbit whole fix would be that the command
line provided --management-external-key option overrides whatever is in the
configuration file; doing this will require more work though.

This will make the VPN connection will still fail, but it won't be stuck any
more.  The user may complain "but I did add that option!?" which then is a
better starting point for support cases ... "Yes, it is most likely ignored as
your user interface is not capable of this feature".

Another alternative is to extend an already longer error log entry, by
mentioning "also ensure that your management interface front-end supports
version 2."


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

[Openvpn-devel] reg. TLS 1.2 with cryptoapicert

[Selva Nair]

Hi,

If there is any chance of the cryptoapi patch getting into  2.4.5,
please note that it needs this patch first:
https://patchwork.openvpn.net/patch/205/ (the same as #201 merged into
master, but with ifdefs for openssl-0.9.8 and 1.0.0)

Thanks,

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Selva Nair]

Hi,

On Mon, Jan 22, 2018 at 11:21 AM, Gert Doering  wrote:
> Hi,
>
> On Mon, Jan 22, 2018 at 05:05:35PM +0100, Steffan Karger wrote:
>> > So if we don't have really strong arguments keeping support for
>> > this old version, we should carefully consider our options.
>>
>> We already removed support for < 1.0.1 in the master branch.  Maybe
>> just make sure we can get 2.5 out, and move forward that way :)
>
> So, what's missing for 2.5?  :-)
>
> I can see "tls crypt v2", "refactor route.c and tun.c", "netlink"
> here - what else?

How did we get to 2.5 from openssl-0.9.8? Anyway, I'm happy to see
that 0.9.8 is not widely used and slacking while testing patches will
be excused..

OK, the thread yielded to the more exciting 2.5 discussion :)

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Antonio Quartulli]

On 23/01/18 00:21, Gert Doering wrote:
> Hi,
> 
> On Mon, Jan 22, 2018 at 05:05:35PM +0100, Steffan Karger wrote:
>>> So if we don't have really strong arguments keeping support for
>>> this old version, we should carefully consider our options.
>>
>> We already removed support for < 1.0.1 in the master branch.  Maybe
>> just make sure we can get 2.5 out, and move forward that way :)
> 
> So, what's missing for 2.5?  :-)
> 
> I can see "tls crypt v2", "refactor route.c and tun.c", "netlink" 
> here - what else?

not sure hijacking this thread is the right thing to do (other people
interested in this topic may not see the discussion here).

However, we had other points: like multiport/socket support, the
transport API, 

More here:
https://community.openvpn.net/openvpn/wiki/KarlsruheHackathon2017#results


Cheers,

-- 
Antonio Quartulli



signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Gert Doering]

Hi,

On Mon, Jan 22, 2018 at 05:05:35PM +0100, Steffan Karger wrote:
> > So if we don't have really strong arguments keeping support for
> > this old version, we should carefully consider our options.
> 
> We already removed support for < 1.0.1 in the master branch.  Maybe
> just make sure we can get 2.5 out, and move forward that way :)

So, what's missing for 2.5?  :-)

I can see "tls crypt v2", "refactor route.c and tun.c", "netlink" 
here - what else?

gert

-- 
now what should I write here...

Gert Doering - Munich, Germany g...@greenie.muc.de


signature.asc
Description: PGP signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Steffan Karger]

Hi,

Didn't we have this discussion before?  Gert basically NAK'd removing
support for a library version in a dot-release, which I think is valid
reasoning (even though I really would like to drop 0.9.8).

Anyway, to fill in the facts:

On 22-01-18 15:55, David Sommerseth wrote:
> On 22/01/18 15:12, Simon Matter wrote:
>>> On 20/01/18 18:22, Selva Nair wrote:
 Does openvpn-vagrant include any VM provisioning with
 openssl-0.9.8? Until recently I had access to a few old
 debian boxes but now all updated and 0.9.8 testing is getting
 harder.
>>> 
>>> Let me rather twist this question around ... Do we want to
>>> support OpenSSL 0.9.8?  Are there any Linux distributions or
>>> other OSes out there in the wild which is still supported which
>>> are also based on openssl-0.9.8?
>> 
>> If it's possible without too many headaches, I'd appreciate if 
>> openssl-0.9.8 support would be kept in during the 2.4 series.
> 
> Can you elaborate more on your use case?  Keeping something just to
> keep something is kind of a poor argument.  But of course, it goes
> the other way around too, we shouldn't kick it out just to kick it
> out either.
> 
> Currently, I'm mostly concerned that keeping the support span from
> 0.9.8 to 1.1.x can lead to maintenance challenges in the longer run
> - especially if the use cases are poor.
> 
> To me it then gets crucial that users needing openssl-0.9.8 have
> access to a maintained distribution of that particular OpenSSL
> version.  Otherwise, we're deluding OpenVPN users it is safe to use
> openssl-0.9.8.

SLES11 supports 0.9.8 upto 2022:

https://www.suse.com/LinuxPackages/packageRouter.jsp?product=server&version=11&service_pack=&architecture=i386&package_name=openssl

https://www.suse.com/lifecycle/

> So if we don't have really strong arguments keeping support for
> this old version, we should carefully consider our options.

We already removed support for < 1.0.1 in the master branch.  Maybe
just make sure we can get 2.5 out, and move forward that way :)

-Steffan

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/3] Allow external EC key through --management-external-key

[Selva Nair]

On Mon, Jan 22, 2018 at 8:21 AM, David Sommerseth
 wrote:
>
> On 18/01/18 16:49, Selva Nair wrote:
> > Hi
> >
> > On Wed, Jan 17, 2018 at 3:53 AM, Steffan Karger  > > wrote:
> >
> > Hi,
> >
> > On 17-01-18 05:24, Selva Nair wrote:
> > > Also I'm toying with the idea of renaming ecdsa-sig/ECDSA-SIGN by
> > > pkey-sig/PKEY-SIGN so that eventually we may be able to use it for
> > > all types of keys and retire rsa-sig. Any thoughts on that?
> >
> > This was my first though when looking at these patches.  Haven't looked
> > at the code yet, but functionally I think that's the way to go.  Even if
> > it were that Ed25519 / Ed448 sigs are technically not ECDSA sigs.
> >
> >
> > I was waiting for the chatlog before finalizing v2. Looks like there are a
> > number of opinions
> > that seem to converge towards the same view.
> >
> > This is what I have in my current v2 ready to go out:
> >
> > (i) Current behaviour for rsa signatures stays for now: daemon sends
> >>RSA_SIGN  client responds
> > with rsa-sig
> > (ii) Daemon sends >PK_SIG client responds with pk-sig [*]
> > Initially this will be used only for EC, but trivial to switch RSA to this 
> > in
> > future.
> > So document that new mgmt clients should be prepared to handle all supported
> > key types via >PK_SIGN/pk-sig and >RSA_SIGN will be eventually removed.
> >
> > As a nice side effect, clients are allowed to respond with pk-sig even if 
> > the
> > challenge was
> >>RSA_SIGN. As a not so nice side effect, the daemon will reply with "SUCCESS
> > rsa-sign
> > succeeded" because that's what it asked for -- I suppose we can live with 
> > that.
> >
> > We can deprecate and remove >RSA_SIGN at a later date by a hard switch when
> > all known clients are capable of handling >PK_SIGN
> >
> > Does this sound like an acceptable solution?
> >
> > Question: while at it should we alter the syntax to
> >>PK_SIGN,xxx,
> >
> > where xxx will be empty for now, but it reserves space for extra info that 
> > may
> > come handy for some future signature types (like use PSS padding for RSA or
> > use PureEdDSA or whatever).
>
> Hi,
>
> I've discussed this quickly with James quite recently.  We are concerned about
> breaking existing front-end integrations by doing too much funky stuff with
> RSA_SIGN for EC support.  That in particular touches the signal renaming to
> PK_SIGN.
>
> So we have another suggestion.  For external keys to be used,
> --management-external-key is needed.  Add an optional argument to this option,
> which indicates a version.  If this argument is not provided, everything works
> as it is today - without EC support.  If using: --management-external-key 2
> ... for version 2, do a hard-shift to PK_SIGN with RSA and EC support.
>
> This way we ensure we don't break any existing implementations, we can allow a
> period of transition to the new version, and we can in the future when we are
> sure PK_SIGN works well and has seen deployment elsewhere start a deprecation
> process if the legacy version 1.  But we're not put in a situation where
> anything changes suddenly and abruptly.
>
> Any thoughts?


This is similar to what Arne proposed while reviewing version 1 of the
patch. But I was not excited about encoding client capability into a
config option. On further thought, this may offer a little less
unpleasant UX to some users and I'm ok with it.

I guess tunnelblick supports this options so Jonathan (and Arne) may
have more insight.

The current patch also allows a delayed deprecation of RSA_SIGN giving
time for clients to prepare to handle PK_SIGN. But the UX differs a
little:

- lay user: everything just works always if the provider/admin is good;
or someone fixes things for them.

- client developers: as long as we deprecate commands/options
responsibly (no hard switching), and document it, they/we will cope

So its about average/advanced users changing their RSA cert to EC with
--management-external-key and a client that doesn't yet support
PK_SIGN:

- Present patch: connection process appears stuck (but UI is still
responsive) and logs show the daemon is waiting for signature

- This proposal: connection fails with: "External EC cert/key not
supported in this config. Try using --management-external-key 2"
User edits the config option and the connection process appears stuck .

I suppose the latter is a bit better.

Selva

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Jonathan K. Bullard]

Hi,

On Mon, Jan 22, 2018 at 7:33 AM, David Sommerseth
 wrote:
> Let me rather twist this question around ... Do we want to support OpenSSL
> 0.9.8?  Are there any Linux distributions or other OSes out there in the wild
> which is still supported which are also based on openssl-0.9.8?
>
> Officially we dropped RHEL 5 support and moved to RHEL 6 as the oldest Linux
> distribution we support OpenVPN on.  RHEL 6 ships with an openssl-1.0.1e 
> baseline.
>
> For the other platforms ... In Windows, we define what we want to use - as we
> need to embed OpenSSL in our own package.  I believe most of the current
> stable *BSDs and derivatives are on an OpenSSL 1.x base (or the LibreSSL fork)
> too (but I don't know that for a fact yet).  I expect Tunnelblick and macOS
> users to use a far newer OpenSSL library too.

Dropping 0.9.8 isn't a problem for Tunnelblick, which embeds OpenSSL 1.0.2.

However, 0.9.8 (patched by Apple, as I understand it) is included in
macOS up through Sierra. So people using command-line openVPN would
have problems unless they've replaced OpenSSL.

(Apple's latest system, "High Sierra" symlinks openvpn to LibreSSL,
which opens a different can of worms : )

Best regards,

Jon Bullard

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[David Sommerseth]

On 22/01/18 15:12, Simon Matter wrote:
>> On 20/01/18 18:22, Selva Nair wrote:
>>> Hi,
>>>
>>> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
>>> Until recently I had access to a few old debian boxes but now all
>>> updated and 0.9.8 testing is getting harder.
>>
>> Let me rather twist this question around ... Do we want to support OpenSSL
>> 0.9.8?  Are there any Linux distributions or other OSes out there in the
>> wild
>> which is still supported which are also based on openssl-0.9.8?
> 
> If it's possible without too many headaches, I'd appreciate if
> openssl-0.9.8 support would be kept in during the 2.4 series.

Can you elaborate more on your use case?  Keeping something just to keep
something is kind of a poor argument.  But of course, it goes the other way
around too, we shouldn't kick it out just to kick it out either.

Currently, I'm mostly concerned that keeping the support span from 0.9.8 to
1.1.x can lead to maintenance challenges in the longer run - especially if the
use cases are poor.

To me it then gets crucial that users needing openssl-0.9.8 have access to a
maintained distribution of that particular OpenSSL version.  Otherwise, we're
deluding OpenVPN users it is safe to use openssl-0.9.8.

So if we don't have really strong arguments keeping support for this old
version, we should carefully consider our options.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Simon Matter]

> On 20/01/18 18:22, Selva Nair wrote:
>> Hi,
>>
>> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
>> Until recently I had access to a few old debian boxes but now all
>> updated and 0.9.8 testing is getting harder.
>
> Let me rather twist this question around ... Do we want to support OpenSSL
> 0.9.8?  Are there any Linux distributions or other OSes out there in the
> wild
> which is still supported which are also based on openssl-0.9.8?

If it's possible without too many headaches, I'd appreciate if
openssl-0.9.8 support would be kept in during the 2.4 series.

Regards,
Simon


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] [PATCH 2/3] Allow external EC key through --management-external-key

[David Sommerseth]

On 18/01/18 16:49, Selva Nair wrote:
> Hi
> 
> On Wed, Jan 17, 2018 at 3:53 AM, Steffan Karger  > wrote:
> 
> Hi,
> 
> On 17-01-18 05:24, Selva Nair wrote:
> > Also I'm toying with the idea of renaming ecdsa-sig/ECDSA-SIGN by
> > pkey-sig/PKEY-SIGN so that eventually we may be able to use it for
> > all types of keys and retire rsa-sig. Any thoughts on that?
> 
> This was my first though when looking at these patches.  Haven't looked
> at the code yet, but functionally I think that's the way to go.  Even if
> it were that Ed25519 / Ed448 sigs are technically not ECDSA sigs.
> 
> 
> I was waiting for the chatlog before finalizing v2. Looks like there are a
> number of opinions
> that seem to converge towards the same view.
> 
> This is what I have in my current v2 ready to go out:
> 
> (i) Current behaviour for rsa signatures stays for now: daemon sends
>>RSA_SIGN  client responds
> with rsa-sig
> (ii) Daemon sends >PK_SIG client responds with pk-sig [*] 
> Initially this will be used only for EC, but trivial to switch RSA to this in
> future.
> So document that new mgmt clients should be prepared to handle all supported
> key types via >PK_SIGN/pk-sig and >RSA_SIGN will be eventually removed.
> 
> As a nice side effect, clients are allowed to respond with pk-sig even if the
> challenge was
>>RSA_SIGN. As a not so nice side effect, the daemon will reply with "SUCCESS
> rsa-sign
> succeeded" because that's what it asked for -- I suppose we can live with 
> that.
> 
> We can deprecate and remove >RSA_SIGN at a later date by a hard switch when
> all known clients are capable of handling >PK_SIGN
> 
> Does this sound like an acceptable solution?
> 
> Question: while at it should we alter the syntax to
>>PK_SIGN,xxx,
> 
> where xxx will be empty for now, but it reserves space for extra info that may
> come handy for some future signature types (like use PSS padding for RSA or
> use PureEdDSA or whatever). 

Hi,

I've discussed this quickly with James quite recently.  We are concerned about
breaking existing front-end integrations by doing too much funky stuff with
RSA_SIGN for EC support.  That in particular touches the signal renaming to
PK_SIGN.

So we have another suggestion.  For external keys to be used,
--management-external-key is needed.  Add an optional argument to this option,
which indicates a version.  If this argument is not provided, everything works
as it is today - without EC support.  If using: --management-external-key 2
... for version 2, do a hard-shift to PK_SIGN with RSA and EC support.

This way we ensure we don't break any existing implementations, we can allow a
period of transition to the new version, and we can in the future when we are
sure PK_SIGN works well and has seen deployment elsewhere start a deprecation
process if the legacy version 1.  But we're not put in a situation where
anything changes suddenly and abruptly.

Any thoughts?


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[David Sommerseth]

On 20/01/18 18:22, Selva Nair wrote:
> Hi,
> 
> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
> Until recently I had access to a few old debian boxes but now all
> updated and 0.9.8 testing is getting harder.

Let me rather twist this question around ... Do we want to support OpenSSL
0.9.8?  Are there any Linux distributions or other OSes out there in the wild
which is still supported which are also based on openssl-0.9.8?

Officially we dropped RHEL 5 support and moved to RHEL 6 as the oldest Linux
distribution we support OpenVPN on.  RHEL 6 ships with an openssl-1.0.1e 
baseline.

For the other platforms ... In Windows, we define what we want to use - as we
need to embed OpenSSL in our own package.  I believe most of the current
stable *BSDs and derivatives are on an OpenSSL 1.x base (or the LibreSSL fork)
too (but I don't know that for a fact yet).  I expect Tunnelblick and macOS
users to use a far newer OpenSSL library too.

I would rather see us moving to officially drop 0.9.8 unless there are really
strong arguments and evidence of someone maintaining openssl-0.9.8 with
security backports.


-- 
kind regards,

David Sommerseth
OpenVPN Inc




signature.asc
Description: OpenPGP digital signature
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Re: [Openvpn-devel] On testing with openssl 0.9.8

[Samuli Seppänen]

Hi,

Il 20/01/2018 19:22, Selva Nair ha scritto:
> Hi,
> 
> Does openvpn-vagrant include any VM provisioning with openssl-0.9.8?
> Until recently I had access to a few old debian boxes but now all
> updated and 0.9.8 testing is getting harder.
> 
> Selva

Right now openvpn-vagrant[*] contains only fairly recent operating systems:

grep "vm.define" Vagrantfile
  config.vm.define "centos-7" do |box|
  config.vm.define "debian-9" do |box|
  config.vm.define "freebsd-11" do |box|
  config.vm.define "openbsd-6" do |box|
  config.vm.define "solaris-113" do |box|
  config.vm.define "ubuntu-1604" do |box|
  config.vm.define "openvpn-build" do |box|
  config.vm.define "netbsd-7" do |box|

If you want, I can easily add a new VM (say, Ubuntu 12.04), which has
OpenSSL 0.9.8.

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

irc freenode net: mattock


[*] 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel