From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] OpenVPN: Introduce Negotiable Crypto Parameters for roadwarriors
Date: Mon, 27 Aug 2018 18:21:26 +0200 [thread overview]
Message-ID: <59a05756148e6f0758adbd8d6ff623696eb2a4d2.camel@ipfire.org> (raw)
In-Reply-To: <7f184b772169ab424a16323454c063955bddd89d.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 5858 bytes --]
Hi Michael,
Am Montag, den 27.08.2018, 08:20 +0100 schrieb Michael Tremer:
> > > > >
> > I think this is also the reason why Fedora did used 256-CBC in
> > second
> > place in their list. If --ncp-ciphers is activated and the client
> > is
> > 2.4 ready but uses old OpenSSL libs the second cipher 256-CBC
> > should
> > match in mostly cases but uses also the longest possible keysize.
>
> So I had a little thought about all of this and I guess I have
> figured out what
> my problem is with the current approach:
>
> * NCP generally is a good idea. We should *encourage* people to
> use/activate it
> and make sure that they use the strongest cipher possible.+
Think so.
>
> * Hardcoding is, however, a very bad idea. I would agree that AES-
> 256-GCM/CBC is
> good enough for everyone right now. But we don't know what is
> happening further
> down the line.
That´s true but a good point in there is that this configuration is
only presant on server side so the old problem to make changes on
client and server side do not appears anymore which is different to
mostly other directives.
>
> So my suggestion is to add a menu just like we have in the "advanced"
> section of
> every IPsec connection. A dropdown where you can select multiple
> ciphers at the
> same time. That should be the ncp-ciphers list.
Since OpenVPN have the reputation of an easy to use VPN i´ am not sure
if this is a good idea. People with not that background knowledge
(e.g. what is the difference between CBC and GCM) might have there a
problem with a good decision. As outlined before, the first Cipher if
it is a Galois/counter mode should be used meanwhile in possibly more
than 50% of the machines out there, the second one, if CBC, is a 99%er
so the whole selection like for IPSec becomes overkill in my opinion
even there is also no possiblity to select integrity, or Grouptypes.
> And there should be an extra
> dropdown for the legacy "cipher" option.
The old cipher drop down is still presant and is also needed to deliver
a cipher for those clients which do not understand --ncp-cipher (all
clients below 2.4).
>
> Defaults should be AES-256-GCM, AES-256-CBC. The legacy cipher option
> should be
> empty if possible
Won´t leave it empty othewise all clients below 2.4 won´t work anymore.
The NCP stuff comes with v2.4.
> or AES-256-GCM for new setups.
We can become there also problems if older OpenSSL libs are in usage.
As far as i remember GCM has been delivered with OpenSSL-1.0.1 (not
100% sure with this) so we would strip all systems below out (if no
internal OpenSSL are in usage via e.g. a OpenVPN client software). AES-
256-CBC is the current default value for the "legacy" cipher drop down
which should match all the old ones out there too and should also
provide a good state of security.
>
> * That would allow loads of flexibility to the users and they would
> be able to
> deselect certain things. So if CBC gets broken (hypothetically),
> people can
> deselect those and they are done. That's better than having an option
> called
> "strong" that is hardcoded to AES-256-* and "fast" that is AES-128-*
> or so.
I guess i would do it in that way. If (hypothetically) CBC gets broken,
we can change this settings centrally via updates since the server
pushes this directives and the clients do not see that in their
configuration.
IPFire is and was always fast to fix seriouse problems ;-) and such
problem can be fixed via ovpnmain.cgi for all existing clients which
uses NCP.
>
> I thought we would get around it to implement this, because it
> probably is a
> little bit more to write (especially checking for valid input). But I
> guess
> there is ultimately no easy option.
I think there is one. Currently i´d have only a checkbox to switch this
one 'off' or 'on'. If 'on' it provides AES-256-GCM if the other side do
supports it. OpenVPN defaults are AES-256-GCM:AES-128-GCM that´s it for
them.
I think it is nice to have a little menu with 2 or 3 different
selection possibilities (strong, fast, legacy) but like in IPSec
advanced settings would sprinkle the frame in my opinion. Let´s start
with this if we have ECC fully implemented and TLS1.3 arives in OpenVPN
:D .
>
> > > Should we have blowfish enabled? That's a good question. Should
> > > the
> > > last option rather not be what the user has selected on the web
> > > UI?
> >
> > BF-CBC on that place is also shown as an example configuration on
> > OpenVPN itself
> >
>
> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalo
> finsecureciphers:Cipherswithcipherblock-
> sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2
> > whereby it seems that this is only a temporary solution for very
> > old
> > clients to migrate also via the help of --ncp-ciphers step by step
> > to
> > other configurations without to change the whole at once.
> > I think there might be rare cases that the last cipher in the list
> > will
> > be used especially if AES-CBC comes before which mostly systems
> > should
> > have.
> > BF-CBC is a 64 bit block cipher (Sweet32 and 64MB reneg-bytes
> > problem)
> > and is meanwhile deprecated but OpenVPN will also remove it with
> > OpenVPN-2.4.6 (same with DES, CAST5 and IDEA).
>
> LOL. Great idea. There are tons of deployments out there that will
> just break
> because of no way for the client to negotiate a cipher.
Yes, rough days ahead :D. Here is the official one --> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Removalofinsecureciphers:Cipherswithcipherblock-sizelessthan128bitsmostcommonlyBFDESCAST5IDEAandRC2 .
>
> Not sure when ncp-ciphers was introduced, but I have never seen that
> anywhere.
NCP comes with v2.4
Best,
Erik
next prev parent reply other threads:[~2018-08-27 16:21 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-06 7:25 Erik Kapfer
2018-08-07 13:10 ` Michael Tremer
2018-08-07 16:19 ` ummeegge
2018-08-08 7:55 ` Michael Tremer
2018-08-08 10:32 ` ummeegge
2018-08-14 11:11 ` ummeegge
2018-08-14 11:21 ` Michael Tremer
2018-08-27 7:20 ` Michael Tremer
2018-08-27 16:21 ` ummeegge [this message]
2018-08-28 10:21 ` Michael Tremer
2018-08-28 19:35 ` ummeegge
2018-08-29 10:33 ` Michael Tremer
2018-08-29 21:49 ` ummeegge
2018-08-30 7:35 ` Michael Tremer
2018-08-30 10:31 ` ummeegge
2018-08-30 11:59 ` Michael Tremer
2018-08-30 14:02 ` ummeegge
2018-08-30 14:08 ` Michael Tremer
2018-09-05 15:22 ` Kienker, Fred
2018-09-09 12:46 ` Michael Tremer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=59a05756148e6f0758adbd8d6ff623696eb2a4d2.camel@ipfire.org \
--to=ummeegge@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox