All of lore.kernel.org
 help / color / mirror / Atom feed
* [Openvpn-devel] [PATCH] Deprecate --keysize
@ 2017-07-01 11:29 Steffan Karger
  2017-08-14 10:36 ` David Sommerseth
  2017-08-15 13:48 ` [Openvpn-devel] [PATCH applied] " David Sommerseth
  0 siblings, 2 replies; 10+ messages in thread
From: Steffan Karger @ 2017-07-01 11:29 UTC (permalink / raw)
  To: openvpn-devel

The --keysize option can only be used with already deprecated ciphers,
such as CAST5, RC2 or BF.  Deviating from the default keysize is
generally not a good idea (see man page text), and otherwise only
complicates our code.

(If this patch is accepted, I'll send a follow-up patch to remove the
option from the master branch.)

Signed-off-by: Steffan Karger <steffan@...1856...>
---
 Changes.rst           | 1 +
 doc/openvpn.8         | 4 ++++
 src/openvpn/options.c | 5 +++++
 3 files changed, 10 insertions(+)

diff --git a/Changes.rst b/Changes.rst
index 39d83a2d..fdb56752 100644
--- a/Changes.rst
+++ b/Changes.rst
@@ -313,6 +313,7 @@ Deprecated features
 -------------------
 - ``--no-replay`` is deprecated and will be removed in OpenVPN 2.5.
 
+- ``--keysize`` is deprecated and will be removed in OpenVPN 2.5.
 
 Version 2.4.3
 =============
diff --git a/doc/openvpn.8 b/doc/openvpn.8
index 3600b8fa..c373c2af 100644
--- a/doc/openvpn.8
+++ b/doc/openvpn.8
@@ -4217,6 +4217,10 @@ negotiation.
 .\"*********************************************************
 .TP
 .B \-\-keysize n
+
+.B DEPRECATED
+This option will be removed in OpenVPN 2.5.
+
 Size of cipher key in bits (optional).
 If unspecified, defaults to cipher-specific default.  The
 .B \-\-show\-ciphers
diff --git a/src/openvpn/options.c b/src/openvpn/options.c
index 5246cb5a..95fdcc77 100644
--- a/src/openvpn/options.c
+++ b/src/openvpn/options.c
@@ -2489,6 +2489,11 @@ options_postprocess_verify_ce(const struct options *options, const struct connec
         msg(M_WARN, "WARNING: --no-replay is DEPRECATED and will be removed in 2.5");
     }
 
+    if (options->keysize)
+    {
+        msg(M_WARN, "WARNING: --keysize is DEPRECATED and will be removed in 2.5");
+    }
+
     /*
      * Check consistency of replay options
      */
-- 
2.11.0



^ permalink raw reply related	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-07-01 11:29 [Openvpn-devel] [PATCH] Deprecate --keysize Steffan Karger
@ 2017-08-14 10:36 ` David Sommerseth
  2017-08-14 11:17   ` Steffan Karger
  2017-08-15  8:26   ` 
  2017-08-15 13:48 ` [Openvpn-devel] [PATCH applied] " David Sommerseth
  1 sibling, 2 replies; 10+ messages in thread
From: David Sommerseth @ 2017-08-14 10:36 UTC (permalink / raw)
  To: Steffan Karger <steffan@


[-- Attachment #1.1: Type: text/plain, Size: 4081 bytes --]

On 01/07/17 13:29, Steffan Karger wrote:
> The --keysize option can only be used with already deprecated ciphers,
> such as CAST5, RC2 or BF.  Deviating from the default keysize is
> generally not a good idea (see man page text), and otherwise only
> complicates our code.>
> (If this patch is accepted, I'll send a follow-up patch to remove the
> option from the master branch.)

I agree to the wanted intention of this change.  But, it hits badly if
we remove --keysize on configurations still enforcing BF-CBC with
--keysize 256.  I don't have any numbers of how many users uses it; but
I know many have preferred BF-CBC for a long time - at least before
SWEET32 came and hit us all.  Bare in mind that BF-CBC was the default
since 2002-ish (probably even longer, if considering the OpenVPN v1.x
branch). And many have added --cipher BF-CBC in their configs despite it
was the default.

As long as BF-CBC is available, we cannot remove --keysize.  And to
remove BF-CBC support, I think that needs a bit longer timespan than
v2.5.  Users *must* be far better prepared for that and we need to make
loud and clear announcements with such a change.

Yes, in all this, I know that NCP is a nice rescue.  As long as everyone
either runs v2.4 everywhere or deploys --ncp-ciphers and starts the
migration.  But I've lost confidence that the vast majority of our users
pays closely attention to such feature changes - thus they won't notice
until it stops working.  We need to PUSH this information into their
faces, with large posters carrying promises of rainbow coloured unicorns
if they comply today(!).  In addition to adding clear warnings in the
log files for a looong time.

So I propose:

- We add the warning about removing --keysize for both v2.4 and v2.5.

- Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
  bits will be *removed* in v2.6

- When removing those ciphers in v2.6, we can remove --keysize together
  with the ciphers, as it will no longer be valid.  But --keysize needs
  to be a NOP for some time (with a warning it has no effect), to avoid
  OpenVPN stopping to run on upgrades.

- Ensure these changes are synchronised within OpenVPN 3 as well

- Start a new wiki page: "How-To: Migrate to secure and modern
  OpenVPN configurations" where we list all deprecated features/options
  and their replacement (including examples).  We also need to have a
  description on the reasoning for deprecating and removing these
  options.

- And the most tricky one: Get some publicity that OpenVPN is going to
  deprecate and remove support for weak ciphers out to the public.  Not
  just on crypto focused sites, but more broadly reaching "media
  channels".   (I believe we can facilitate some of the PR work done by
  the company, but we do need more than that).  Channels/sites I'm
  pondering on:

   ~ An official Press Release by the company? (Samuli and I can check)
   ~ twitter (via the @OpenVPN account)
   ~ reddit? (and similar sites)
   ~ LWN.net
   ~ arstechnica
   ~ ThreatPost
   ~ OS Distribution channels (blog posts, mailing lists, etc)
   ~ Our own wiki and web pages
   ~ others?

  The first round is to clearly state that BF-CBC, CAST and RC2 are
  deprecated and their support will be removed in a coming release (not
  mentioning version, on purpose!).  Users are strongly advised to
  upgrade to OpenVPN v2.4 or server and client side instantly, to
  benefit from NCP (byt more less-tech worded) and to point at the
  "How-To" described above.

  And then we try to re-iterate this once again with the release of
  v2.5 and v2.6.


I know and understand this hurts security focused people, and probably
in even more those who understand crypto very well.  But my personal
experience is that the average users are usually less understanding than
security minded people.  (Yes, I've burnt my, and other's, fingers
within the Fedora community with the v2.4 upgrade)


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-14 10:36 ` David Sommerseth
@ 2017-08-14 11:17   ` Steffan Karger
  2017-08-14 11:27     ` David Sommerseth
  2017-08-15  8:26   ` 
  1 sibling, 1 reply; 10+ messages in thread
From: Steffan Karger @ 2017-08-14 11:17 UTC (permalink / raw)
  To: openvpn-devel


[-- Attachment #1.1: Type: text/plain, Size: 2507 bytes --]

Hi,

On 14-08-17 12:36, David Sommerseth wrote:
> On 01/07/17 13:29, Steffan Karger wrote:
>> The --keysize option can only be used with already deprecated ciphers,
>> such as CAST5, RC2 or BF.  Deviating from the default keysize is
>> generally not a good idea (see man page text), and otherwise only
>> complicates our code.>
>> (If this patch is accepted, I'll send a follow-up patch to remove the
>> option from the master branch.)
> 
> I agree to the wanted intention of this change.  But, it hits badly if
> we remove --keysize on configurations still enforcing BF-CBC with
> --keysize 256.  I don't have any numbers of how many users uses it; but
> I know many have preferred BF-CBC for a long time - at least before
> SWEET32 came and hit us all.  Bare in mind that BF-CBC was the default
> since 2002-ish (probably even longer, if considering the OpenVPN v1.x
> branch). And many have added --cipher BF-CBC in their configs despite it
> was the default.
> 
> As long as BF-CBC is available, we cannot remove --keysize.  And to
> remove BF-CBC support, I think that needs a bit longer timespan than
> v2.5.  Users *must* be far better prepared for that and we need to make
> loud and clear announcements with such a change.
> 
> Yes, in all this, I know that NCP is a nice rescue.  As long as everyone
> either runs v2.4 everywhere or deploys --ncp-ciphers and starts the
> migration.  But I've lost confidence that the vast majority of our users
> pays closely attention to such feature changes - thus they won't notice
> until it stops working.  We need to PUSH this information into their
> faces, with large posters carrying promises of rainbow coloured unicorns
> if they comply today(!).  In addition to adding clear warnings in the
> log files for a looong time.
> 
> So I propose:
> 
> - We add the warning about removing --keysize for both v2.4 and v2.5.
> 
> - Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
>   bits will be *removed* in v2.6
> 
> - When removing those ciphers in v2.6, we can remove --keysize together
>   with the ciphers, as it will no longer be valid.  But --keysize needs
>   to be a NOP for some time (with a warning it has no effect), to avoid
>   OpenVPN stopping to run on upgrades.

Okay.  Instead of sending the keysize removal patch, I'll send a patch
that warns that small block ciphers will be removed in 2.6.

Can you then do s/2.5/2.6/ on the patch, or shall I send a v2?

-Steffan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-14 11:17   ` Steffan Karger
@ 2017-08-14 11:27     ` David Sommerseth
  0 siblings, 0 replies; 10+ messages in thread
From: David Sommerseth @ 2017-08-14 11:27 UTC (permalink / raw)
  To: Steffan Karger <steffan.karger@


[-- Attachment #1.1: Type: text/plain, Size: 3056 bytes --]

On 14/08/17 13:17, Steffan Karger wrote:
> Hi,
> 
> On 14-08-17 12:36, David Sommerseth wrote:
>> On 01/07/17 13:29, Steffan Karger wrote:
>>> The --keysize option can only be used with already deprecated ciphers,
>>> such as CAST5, RC2 or BF.  Deviating from the default keysize is
>>> generally not a good idea (see man page text), and otherwise only
>>> complicates our code.>
>>> (If this patch is accepted, I'll send a follow-up patch to remove the
>>> option from the master branch.)
>>
>> I agree to the wanted intention of this change.  But, it hits badly if
>> we remove --keysize on configurations still enforcing BF-CBC with
>> --keysize 256.  I don't have any numbers of how many users uses it; but
>> I know many have preferred BF-CBC for a long time - at least before
>> SWEET32 came and hit us all.  Bare in mind that BF-CBC was the default
>> since 2002-ish (probably even longer, if considering the OpenVPN v1.x
>> branch). And many have added --cipher BF-CBC in their configs despite it
>> was the default.
>>
>> As long as BF-CBC is available, we cannot remove --keysize.  And to
>> remove BF-CBC support, I think that needs a bit longer timespan than
>> v2.5.  Users *must* be far better prepared for that and we need to make
>> loud and clear announcements with such a change.
>>
>> Yes, in all this, I know that NCP is a nice rescue.  As long as everyone
>> either runs v2.4 everywhere or deploys --ncp-ciphers and starts the
>> migration.  But I've lost confidence that the vast majority of our users
>> pays closely attention to such feature changes - thus they won't notice
>> until it stops working.  We need to PUSH this information into their
>> faces, with large posters carrying promises of rainbow coloured unicorns
>> if they comply today(!).  In addition to adding clear warnings in the
>> log files for a looong time.
>>
>> So I propose:
>>
>> - We add the warning about removing --keysize for both v2.4 and v2.5.
>>
>> - Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
>>   bits will be *removed* in v2.6
>>
>> - When removing those ciphers in v2.6, we can remove --keysize together
>>   with the ciphers, as it will no longer be valid.  But --keysize needs
>>   to be a NOP for some time (with a warning it has no effect), to avoid
>>   OpenVPN stopping to run on upgrades.
> 
> Okay.  Instead of sending the keysize removal patch, I'll send a patch
> that warns that small block ciphers will be removed in 2.6.
>
> Can you then do s/2.5/2.6/ on the patch, or shall I send a v2?

Yes, I can do that.  I'll also remove the remark ("If this is
accepted...") from the commit message too, commit to master and
cherry-pick to release/2.4.  I'll also use the term "OpenVPN v2.6"
everywhere, to be more precise in the statements.

But we will need to get started on the planning of the public stunts
too.  Getting a wiki page in place would be a nice starting point though.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-14 10:36 ` David Sommerseth
  2017-08-14 11:17   ` Steffan Karger
@ 2017-08-15  8:26   ` 
  2017-08-15  8:32     ` Antonio Quartulli
  1 sibling, 1 reply; 10+ messages in thread
From:  @ 2017-08-15  8:26 UTC (permalink / raw)
  To: openvpn-devel@lists.sourceforge.net

[-- Attachment #1: Type: text/plain, Size: 4826 bytes --]

2017-08-14 15:36 GMT+05:00 David Sommerseth <
openvpn@...2080...>:

> On 01/07/17 13:29, Steffan Karger wrote:
> > The --keysize option can only be used with already deprecated ciphers,
> > such as CAST5, RC2 or BF.  Deviating from the default keysize is
> > generally not a good idea (see man page text), and otherwise only
> > complicates our code.>
> > (If this patch is accepted, I'll send a follow-up patch to remove the
> > option from the master branch.)
>
> I agree to the wanted intention of this change.  But, it hits badly if
> we remove --keysize on configurations still enforcing BF-CBC with
> --keysize 256.  I don't have any numbers of how many users uses it; but
> I know many have preferred BF-CBC for a long time - at least before
> SWEET32 came and hit us all.  Bare in mind that BF-CBC was the default
> since 2002-ish (probably even longer, if considering the OpenVPN v1.x
> branch). And many have added --cipher BF-CBC in their configs despite it
> was the default.
>
> As long as BF-CBC is available, we cannot remove --keysize.  And to
> remove BF-CBC support, I think that needs a bit longer timespan than
> v2.5.  Users *must* be far better prepared for that and we need to make
> loud and clear announcements with such a change.
>
> Yes, in all this, I know that NCP is a nice rescue.  As long as everyone
> either runs v2.4 everywhere or deploys --ncp-ciphers and starts the
> migration.  But I've lost confidence that the vast majority of our users
> pays closely attention to such feature changes - thus they won't notice
> until it stops working.  We need to PUSH this information into their
> faces, with large posters carrying promises of rainbow coloured unicorns
> if they comply today(!).  In addition to adding clear warnings in the
> log files for a looong time.
>
> So I propose:
>
> - We add the warning about removing --keysize for both v2.4 and v2.5.
>
> - Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
>   bits will be *removed* in v2.6
>
> - When removing those ciphers in v2.6, we can remove --keysize together
>   with the ciphers, as it will no longer be valid.  But --keysize needs
>   to be a NOP for some time (with a warning it has no effect), to avoid
>   OpenVPN stopping to run on upgrades.
>
> - Ensure these changes are synchronised within OpenVPN 3 as well
>
> - Start a new wiki page: "How-To: Migrate to secure and modern
>   OpenVPN configurations" where we list all deprecated features/options
>   and their replacement (including examples).  We also need to have a
>   description on the reasoning for deprecating and removing these
>   options.
>

there are special cases like Mikrotik openvpn (pretty popular), where
user simply use what hardware vendor installed (without possibility to
recompile).

should we contact such hardware vendors as well ?


>
> - And the most tricky one: Get some publicity that OpenVPN is going to
>   deprecate and remove support for weak ciphers out to the public.  Not
>   just on crypto focused sites, but more broadly reaching "media
>   channels".   (I believe we can facilitate some of the PR work done by
>   the company, but we do need more than that).  Channels/sites I'm
>   pondering on:
>
>    ~ An official Press Release by the company? (Samuli and I can check)
>    ~ twitter (via the @OpenVPN account)
>    ~ reddit? (and similar sites)
>    ~ LWN.net
>    ~ arstechnica
>    ~ ThreatPost
>    ~ OS Distribution channels (blog posts, mailing lists, etc)
>    ~ Our own wiki and web pages
>    ~ others?
>
>   The first round is to clearly state that BF-CBC, CAST and RC2 are
>   deprecated and their support will be removed in a coming release (not
>   mentioning version, on purpose!).  Users are strongly advised to
>   upgrade to OpenVPN v2.4 or server and client side instantly, to
>   benefit from NCP (byt more less-tech worded) and to point at the
>   "How-To" described above.
>
>   And then we try to re-iterate this once again with the release of
>   v2.5 and v2.6.
>
>
> I know and understand this hurts security focused people, and probably
> in even more those who understand crypto very well.  But my personal
> experience is that the average users are usually less understanding than
> security minded people.  (Yes, I've burnt my, and other's, fingers
> within the Fedora community with the v2.4 upgrade)
>
>
> --
> kind regards,
>
> David Sommerseth
> OpenVPN Technologies, Inc
>
>
>
> ------------------------------------------------------------
> ------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6093 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-15  8:26   ` 
@ 2017-08-15  8:32     ` Antonio Quartulli
  2017-08-15  9:17       ` 
  0 siblings, 1 reply; 10+ messages in thread
From: Antonio Quartulli @ 2017-08-15  8:32 UTC (permalink / raw)



[-- Attachment #1.1: Type: text/plain, Size: 1720 bytes --]



On 15/08/17 16:26, Илья Шипицин wrote:
> 2017-08-14 15:36 GMT+05:00 David Sommerseth <
> openvpn@...2080...>:
> 
>> On 01/07/17 13:29, Steffan Karger wrote:
>>
>> So I propose:
>>
>> - We add the warning about removing --keysize for both v2.4 and v2.5.
>>
>> - Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
>>   bits will be *removed* in v2.6
>>
>> - When removing those ciphers in v2.6, we can remove --keysize together
>>   with the ciphers, as it will no longer be valid.  But --keysize needs
>>   to be a NOP for some time (with a warning it has no effect), to avoid
>>   OpenVPN stopping to run on upgrades.
>>
>> - Ensure these changes are synchronised within OpenVPN 3 as well
>>
>> - Start a new wiki page: "How-To: Migrate to secure and modern
>>   OpenVPN configurations" where we list all deprecated features/options
>>   and their replacement (including examples).  We also need to have a
>>   description on the reasoning for deprecating and removing these
>>   options.
>>
> 
> there are special cases like Mikrotik openvpn (pretty popular), where
> user simply use what hardware vendor installed (without possibility to
> recompile).
> 
> should we contact such hardware vendors as well ?

there might be an non-predictable number of vendors shipping their own
openvpn version. We can't contact them all. It's their responsibility to
stay behind the changes in what they ship.

If they don't, their users will complain aloud with them ;)

On top of that, this does not prevent users from using their own config,
right? So they can still configure the client to avoid deprecated options.


Cheers,

-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-15  8:32     ` Antonio Quartulli
@ 2017-08-15  9:17       ` 
  2017-08-15  9:29         ` David Sommerseth
  0 siblings, 1 reply; 10+ messages in thread
From:  @ 2017-08-15  9:17 UTC (permalink / raw)
  To: Antonio Quartulli <a@; +Cc: openvpn-devel@lists.sourceforge.net

[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]

2017-08-15 13:32 GMT+05:00 Antonio Quartulli <a@...2181...>:

>
>
> On 15/08/17 16:26, Илья Шипицин wrote:
> > 2017-08-14 15:36 GMT+05:00 David Sommerseth <
> > openvpn@...2080...>:
> >
> >> On 01/07/17 13:29, Steffan Karger wrote:
> >>
> >> So I propose:
> >>
> >> - We add the warning about removing --keysize for both v2.4 and v2.5.
> >>
> >> - Add a warning in v2.4 and v2.5 that ciphers with block sizes < 128
> >>   bits will be *removed* in v2.6
> >>
> >> - When removing those ciphers in v2.6, we can remove --keysize together
> >>   with the ciphers, as it will no longer be valid.  But --keysize needs
> >>   to be a NOP for some time (with a warning it has no effect), to avoid
> >>   OpenVPN stopping to run on upgrades.
> >>
> >> - Ensure these changes are synchronised within OpenVPN 3 as well
> >>
> >> - Start a new wiki page: "How-To: Migrate to secure and modern
> >>   OpenVPN configurations" where we list all deprecated features/options
> >>   and their replacement (including examples).  We also need to have a
> >>   description on the reasoning for deprecating and removing these
> >>   options.
> >>
> >
> > there are special cases like Mikrotik openvpn (pretty popular), where
> > user simply use what hardware vendor installed (without possibility to
> > recompile).
> >
> > should we contact such hardware vendors as well ?
>
> there might be an non-predictable number of vendors shipping their own
> openvpn version. We can't contact them all. It's their responsibility to
> stay behind the changes in what they ship.
>
> If they don't, their users will complain aloud with them ;)
>
> On top of that, this does not prevent users from using their own config,
> right? So they can still configure the client to avoid deprecated options.
>

you cannot use regular openvpn config with Mikrotik
https://wiki.mikrotik.com/wiki/OpenVPN

you can use mikrotik configuration options


>
>
> Cheers,
>
> --
> Antonio Quartulli
>
>

[-- Attachment #2: Type: text/html, Size: 3049 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-15  9:17       ` 
@ 2017-08-15  9:29         ` David Sommerseth
  2017-08-15 11:16           ` Arne Schwabe
  0 siblings, 1 reply; 10+ messages in thread
From: David Sommerseth @ 2017-08-15  9:29 UTC (permalink / raw)
  Cc: openvpn-devel@lists.sourceforge.net


[-- Attachment #1.1: Type: text/plain, Size: 1340 bytes --]

On 15/08/17 11:17, Илья Шипицин wrote:
[...]
>     > there are special cases like Mikrotik openvpn (pretty popular), where
>     > user simply use what hardware vendor installed (without possibility to
>     > recompile).
>     >
>     > should we contact such hardware vendors as well ?
> 
>     there might be an non-predictable number of vendors shipping their own
>     openvpn version. We can't contact them all. It's their responsibility to
>     stay behind the changes in what they ship.
> 
>     If they don't, their users will complain aloud with them ;)
> 
>     On top of that, this does not prevent users from using their own config,
>     right? So they can still configure the client to avoid deprecated
>     options.
> 
> 
> you cannot use regular openvpn config with Mikrotik
> https://wiki.mikrotik.com/wiki/OpenVPN
> 
> you can use mikrotik configuration options

Which just emphasizes even more that Mikrotik needs to do their own
homework on their own.  Their config syntax is completely alien to us,
so we have no direct influence on how their syntax ends up as a
configuration OpenVPN is capable of understanding.  And _we_ shouldn't
care how Mikrotik does that, it's their own implementation design.


-- 
kind regards,

David Sommerseth
OpenVPN Technologies, Inc



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH] Deprecate --keysize
  2017-08-15  9:29         ` David Sommerseth
@ 2017-08-15 11:16           ` Arne Schwabe
  0 siblings, 0 replies; 10+ messages in thread
From: Arne Schwabe @ 2017-08-15 11:16 UTC (permalink / raw)
  To: openvpn-devel

Am 15.08.17 um 11:29 schrieb David Sommerseth:
> On 15/08/17 11:17, Илья Шипицин wrote:
> [...]
>>     > there are special cases like Mikrotik openvpn (pretty popular), where
>>     > user simply use what hardware vendor installed (without possibility to
>>     > recompile).
>>     >
>>     > should we contact such hardware vendors as well ?
>>
>>     there might be an non-predictable number of vendors shipping their own
>>     openvpn version. We can't contact them all. It's their responsibility to
>>     stay behind the changes in what they ship.
>>
>>     If they don't, their users will complain aloud with them ;)
>>
>>     On top of that, this does not prevent users from using their own config,
>>     right? So they can still configure the client to avoid deprecated
>>     options.
>>
>>
>> you cannot use regular openvpn config with Mikrotik
>> https://wiki.mikrotik.com/wiki/OpenVPN
>>
>> you can use mikrotik configuration options
> 
> Which just emphasizes even more that Mikrotik needs to do their own
> homework on their own.  Their config syntax is completely alien to us,
> so we have no direct influence on how their syntax ends up as a
> configuration OpenVPN is capable of understanding.  And _we_ shouldn't
> care how Mikrotik does that, it's their own implementation design.
> 

Also Mikrotek broke at least two times with my app. First when we
enabled TLS 1.1+ and second time when we disabled non PFS ciphers. I
have enough of their crappy OpenVPN/SSL support.

Arne



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [Openvpn-devel] [PATCH applied] Deprecate --keysize
  2017-07-01 11:29 [Openvpn-devel] [PATCH] Deprecate --keysize Steffan Karger
  2017-08-14 10:36 ` David Sommerseth
@ 2017-08-15 13:48 ` David Sommerseth
  1 sibling, 0 replies; 10+ messages in thread
From: David Sommerseth @ 2017-08-15 13:48 UTC (permalink / raw)
  To: steffan@; +Cc: openvpn-devel

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

ACK.  The patch have been slightly adopted to git master and applied to
release/2.4.  In addition, the final deprecation was moved to v2.6.

Your patch has been applied to the following branches

commit ad178f01444d61e48fca83c4f0bc5d82270cee87  (master)
commit e2ab4958528a352c3ddad02446c10814afe68f6b  (release/2.4)
Author: Steffan Karger
Date:   Sat Jul 1 13:29:51 2017 +0200

     Deprecate --keysize

     Signed-off-by: Steffan Karger <steffan@...1856...>
     Acked-by: David Sommerseth <davids@...515...>
     Message-Id: <20170701112951.19119-1-steffan@...1856...>
     URL: https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15004.html
     Signed-off-by: David Sommerseth <davids@...515...>


- --
kind regards,

David Sommerseth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBCgAGBQJZkvu0AAoJEIbPlEyWcf3ygK0QAIVaDf3bnuxx1HhiOZVj6tho
GejAD1sq3dSW3SRYfbvLtOpnr+LPVfbAvR203EeOJhj+2s3oaqrabI8GFH2r+xy4
NMgX1flrnjhv5bn1dJStDGNLAF//htb/YD9HxuOOgFuhqoHPsO8kzlULUzW+8PkZ
hDgqWAm/IPUKJb2sfTUMat4CZxjE6Bf7qpsR8Znt0ilcaUzxwlwkRIeP/buC4zNJ
MT3zzDfwGzEM6mxcNiNromc9TQl4Jjvpf6oNcYkDUu/RkUNvha3XsI39xr/FXFLS
/VaQuOs4cZl0fzlP217hMl4IZ3f0EYT7jUHHBNMz+sPfB+e9F9BKktoKS8qGV185
uIC20+YQsfkKHJKM32XqRoi7OFjIevbljrSS8QSqOx6hx28rDRAkrvcIGrvrEGPu
Og7XHM5KwvtsNo09ScZOhJEfdh3zWYlq7gdnXT1iCySwG4iQ2oAiiQj37wDcXwcG
lrKW6ekk8RGxB/BZkSNo0oSPDlftIE/Yg81JNwcCHmUMDSsQzlHJTA4EYyhBFMic
q4+OtqNp9n7xnUYzQxWpzKPUXZ8TYXTh4AQFVrHnYpLz2NJpytYjOiRZ+7kVa1oN
rHz51ifHfo7Xj9jI7GAhUcMEZIjmjaiPBbC6b5MbJvkTgDrEUo+Jq8ps2/456rVR
sx+X4/sifcGMFuoh235b
=UleN
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2017-08-15 13:48 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-07-01 11:29 [Openvpn-devel] [PATCH] Deprecate --keysize Steffan Karger
2017-08-14 10:36 ` David Sommerseth
2017-08-14 11:17   ` Steffan Karger
2017-08-14 11:27     ` David Sommerseth
2017-08-15  8:26   ` 
2017-08-15  8:32     ` Antonio Quartulli
2017-08-15  9:17       ` 
2017-08-15  9:29         ` David Sommerseth
2017-08-15 11:16           ` Arne Schwabe
2017-08-15 13:48 ` [Openvpn-devel] [PATCH applied] " David Sommerseth

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.