[v2,7/7] OpenVPN: Moved TLS auth to advanced encryption section
Commit Message
- The TLS authentication has been enhanced with --tls-crypt and with
OpenVPN version 2.5.0 new introduced --tls-crypt-v2 .
- New keys will be shown and can partly be downloaded over the
"Certificate Authorities and -Keys" table.
- The global section has been completely cleaned up from encryption
settings which follows the IPSec WUI style.
Signed-off-by: ummeegge <erik.kapfer@ipfire.org>
---
html/cgi-bin/ovpnmain.cgi | 304 +++++++++++++++++++++++++++++++-------
langs/de/cgi-bin/de.pl | 10 +-
langs/en/cgi-bin/en.pl | 12 +-
langs/es/cgi-bin/es.pl | 10 ++
langs/fr/cgi-bin/fr.pl | 12 +-
langs/it/cgi-bin/it.pl | 7 +-
langs/nl/cgi-bin/nl.pl | 13 +-
langs/pl/cgi-bin/pl.pl | 10 ++
langs/ru/cgi-bin/ru.pl | 11 ++
langs/tr/cgi-bin/tr.pl | 9 ++
10 files changed, 334 insertions(+), 64 deletions(-)
Comments
Hi all,
just wanted to ask if there is still interest in this patch series ?
Best,
Erik
Hello Erik,
Yes, I am very much interested in this.
And I have spent pretty much an hour to make sense out of all of this, and unfortunately have to report that I failed.
I have the problem that I cannot get on top of these things. You are submitting *massive* patchsets, in this case I even believe that the whole things has been submitted a second time, although I do not know if there are any changes.
I could not even find out *what* you are actually trying to do. There are more and more buttons being added and I have not the slightest idea what I am supposed to do with them. I have given my thoughts about the cipher selection and I felt that I have not been heard.
I fear that this is all way too complicated. I cannot review what I do not even understand what the desired outcome is. And failing to understand that either means that it is either way too complicated or I have not read enough anywhere about all of this.
So, could you please summarise for me what you want to achieve here?
Is this supposed to make OpenVPN more compatible, secure, or anything else?
Why do we not talk about this before things are being implemented, or did I just miss the discussion?
-Michael
> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org> wrote:
>
> Hi all,
> just wanted to ask if there is still interest in this patch series ?
>
> Best,
>
> Erik
>
On 12/14/20 7:03 AM, ummeegge wrote:
> Hi all,
> just wanted to ask if there is still interest in this patch series ?
>
> Best,
>
> Erik
>
Hey there, @list. I'm patiently awaiting this series.
Thanks!
Hi Michael,
thanks for looking into this.
Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael Tremer:
> Hello Erik,
>
> Yes, I am very much interested in this.
>
> And I have spent pretty much an hour to make sense out of all of
> this, and unfortunately have to report that I failed.
that´s not good to hear. OK, let me explain... I tried to come up with
a solution where we already have spoken more times about in the past, i
tried to follow up your suggestions, the latest about that topic was
here -->
https://lists.ipfire.org/pipermail/development/2020-October/008441.html
in Oktober to bring up "a select box where multiple algorithms can be
chosen (like in IPsec)". Since --cipher is deprectaed and will be
replaced by --data-ciphers which is a >=2.5.0 option we need another
selection field for the --data-ciphers-fallback which is a replacement
for --cipher and the server uses this directive to talk also to client
which are <2.5.0 .
OpenVPN presses to use cipher negotiation which we have avoid since the
release of 2.4 with --ncp-disable, this option is no also deprecated so
we need to take action on this.
We need to have then two new options, two seletion boxes which are odd
to see in the global section. I tried it in the advanced server section
too and it looks even more confusing with all the other already
existing options, nothing i wanted to do. So i thought your above
linked suggestions are pretty straight forward and the best solution to
build an own crypto section which do have already defaults, nobody
needs to do there anyting, the global section has been cleaned up and
it should be even easier for everone to overview.
It made for me no sense to leave parts of the crypto (TLS-auth and
HMACs) in the global section, especially because there are also even
more algorithms, but also new options for the TLS authentication which
i have all integrated so i moved them also into that place (patch 6/7
and 7/7).
The control-channel cipher selection (patch 5/7) is new and should be
really a part for the advanced ones, therefor no defaults has been set,
it simply won´t appear if nothing has been configured.
I have the problem that I cannot get on top of these things. You are
submitting *massive* patchsets, in this case I even believe that the
whole things has been submitted a second time, although I do not know
if there are any changes.
Yes there are. Old and deprecated ciphers will now be detected and a
warning comes up in the global section to change them as soon as
possible (patch 3/7), also all languages has been translated and has
been included.
Also i wanted to split it in more specific topics for better overview
but it seems that i have been failed.
I could not even find out *what* you are actually trying to do. There
are more and more buttons being added and I have not the slightest idea
what I am supposed to do with them. I have given my thoughts about the
cipher selection and I felt that I have not been heard.
One intention was that you do not need anything to do except you want
to do some advanced crypto stuff. The rest should have already been
made...
I fear that this is all way too complicated. I cannot review what I do
not even understand what the desired outcome is. And failing to
understand that either means that it is either way too complicated or I
have not read enough anywhere about all of this.
Please check out the above linked topic where you have wrote
suggestions that i simply tried to achieve but again, it seems that i
was not successfull with this...
So, could you please summarise for me what you want to achieve here?
Hope i have it done above.
Is this supposed to make OpenVPN more compatible, secure, or anything
else?
Yes both but also easier since the user do not need to do anything but
he should become more security under the hood, the backward and the
forward compatibility should be in a better standing than before and if
someone wants to go into the depth, this is even also possible.
Why do we not talk about this before things are being implemented, or
did I just miss the discussion?
Yes i think you missed some of that, hopefully i could remind you on
some points.
-Michael
Best,
Erik
> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org> wrote:
>
> Hi all,
> just wanted to ask if there is still interest in this patch series ?
>
> Best,
>
> Erik
>
Hi,
> On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org> wrote:
>
> Hi Michael,
> thanks for looking into this.
>
> Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael Tremer:
>> Hello Erik,
>>
>> Yes, I am very much interested in this.
>>
>> And I have spent pretty much an hour to make sense out of all of
>> this, and unfortunately have to report that I failed.
> that´s not good to hear. OK, let me explain... I tried to come up with
> a solution where we already have spoken more times about in the past, i
> tried to follow up your suggestions, the latest about that topic was
> here -->
> https://lists.ipfire.org/pipermail/development/2020-October/008441.html
> in Oktober to bring up "a select box where multiple algorithms can be
> chosen (like in IPsec)". Since --cipher is deprectaed and will be
> replaced by --data-ciphers which is a >=2.5.0 option we need another
> selection field for the --data-ciphers-fallback which is a replacement
> for --cipher and the server uses this directive to talk also to client
> which are <2.5.0 .
Yes, the ciphers. But as far as I understand this, you are offering to select the whole cipher suite. That is something different.
And you are offering different options for TLSv1.3 and lower, which we do not do in IPsec either. You have one selection for both IKEv1 and IKEv2.
> OpenVPN presses to use cipher negotiation which we have avoid since the
> release of 2.4 with --ncp-disable, this option is no also deprecated so
> we need to take action on this.
I will skip my moan about introducing something and then deprecating it shortly after…
I agree that we need to act.
> We need to have then two new options, two seletion boxes which are odd
> to see in the global section. I tried it in the advanced server section
> too and it looks even more confusing with all the other already
> existing options, nothing i wanted to do. So i thought your above
> linked suggestions are pretty straight forward and the best solution to
> build an own crypto section which do have already defaults, nobody
> needs to do there anyting, the global section has been cleaned up and
> it should be even easier for everone to overview.
We have touched this topic multiple times. And I remember the last conclusion as follows:
The average user does not have to touch the advanced options. They have to put in their subnet, select a port and protocol maybe and that is about it. They do not need to think about what cipher to use, because we would have selected a reasonable default. If they want to change something (because of hardware requirements, etc.) they can do that on the advanced page.
I agree that this is all not idea, but adding a third page to this all makes it rather more confusing than less.
> It made for me no sense to leave parts of the crypto (TLS-auth and
> HMACs) in the global section, especially because there are also even
> more algorithms, but also new options for the TLS authentication which
> i have all integrated so i moved them also into that place (patch 6/7
> and 7/7).
I remember that we have agreed to move the existing crypto options to the advanced page.
> The control-channel cipher selection (patch 5/7) is new and should be
> really a part for the advanced ones, therefor no defaults has been set,
> it simply won´t appear if nothing has been configured.
What is the benefit of choosing a different cipher for the control channel?
> I have the problem that I cannot get on top of these things. You are
> submitting *massive* patchsets, in this case I even believe that the
> whole things has been submitted a second time, although I do not know
> if there are any changes.
> Yes there are. Old and deprecated ciphers will now be detected and a
> warning comes up in the global section to change them as soon as
> possible (patch 3/7), also all languages has been translated and has
> been included.
> Also i wanted to split it in more specific topics for better overview
> but it seems that i have been failed.
I do not think that you have failed. I just think that it is not clear what the patch intended to do. So I cannot really look at it and verify if the code actually does what you want it to do.
Could it have been split into even smaller changes? Yes, would that have helped? Maybe. But I do not think that we should waste too much time to reformat the patches. I want the changes to be ready to be merged as soon as possible.
> I could not even find out *what* you are actually trying to do. There
> are more and more buttons being added and I have not the slightest idea
> what I am supposed to do with them. I have given my thoughts about the
> cipher selection and I felt that I have not been heard.
> One intention was that you do not need anything to do except you want
> to do some advanced crypto stuff. The rest should have already been
> made...
>
>
> I fear that this is all way too complicated. I cannot review what I do
> not even understand what the desired outcome is. And failing to
> understand that either means that it is either way too complicated or I
> have not read enough anywhere about all of this.
> Please check out the above linked topic where you have wrote
> suggestions that i simply tried to achieve but again, it seems that i
> was not successfull with this...
So, maybe help me to understand why the user would want to use different ciphers for the control channel and for TLSv1.3/2.
I consider my ciphers as follows:
* Which algorithms do I trust? If I do not trust AES for example, I would unselect it for everything, regardless if that is the control or data channel).
* What does my hardware support? I would want to choose AES if my hardware has acceleration for it.
* Then I would sort them by most secure first (e.g. AES-256, then AES-192 and so on…)
I can replicate that with only one multiple-select box that simply lists:
* AES-256-GCM
* AES-256-CBC
* AES-128-GCM
* AES-128-CBC
* ChaCha20-Poly1305
* Blowfish
* ...
And a second one that has
* SHA512
* SHA384
* SHA256
* …
The code will then have to convert this into the fancy names for the OpenVPN configuration file. But I suppose that should be easy to do.
That way, the user can be certain that they have chosen the right thing for everything in one go.
> So, could you please summarise for me what you want to achieve here?
> Hope i have it done above.
Thank you for that.
I really appreciate all this time that you have invested in this, and the code looks clean. I just think we have been on different pages about what we want it to look and feel like for the user.
> Is this supposed to make OpenVPN more compatible, secure, or anything
> else?
> Yes both but also easier since the user do not need to do anything but
> he should become more security under the hood, the backward and the
> forward compatibility should be in a better standing than before and if
> someone wants to go into the depth, this is even also possible.
I think that you have implemented the “pro” version here. It has all the buttons you need and uses all features of OpenVPN. But it is complicated. So maybe lets hide it from the user that there is a control and data channel. Does the user need to know about this? I do not think so. It will work either way.
> Why do we not talk about this before things are being implemented, or
> did I just miss the discussion?
> Yes i think you missed some of that, hopefully i could remind you on
> some points.
This is good progress :)
-Michael
>
> -Michael
>
> Best,
>
> Erik
>
>
>> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org> wrote:
>>
>> Hi all,
>> just wanted to ask if there is still interest in this patch series ?
>>
>> Best,
>>
>> Erik
>>
>
>
>
Hi Michael,
Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael Tremer:
> Hi,
>
> > On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org> wrote:
> >
> > Hi Michael,
> > thanks for looking into this.
> >
> > Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael Tremer:
> > > Hello Erik,
> > >
> > > Yes, I am very much interested in this.
> > >
> > > And I have spent pretty much an hour to make sense out of all of
> > > this, and unfortunately have to report that I failed.
> > that´s not good to hear. OK, let me explain... I tried to come up
> > with
> > a solution where we already have spoken more times about in the
> > past, i
> > tried to follow up your suggestions, the latest about that topic
> > was
> > here -->
> > https://lists.ipfire.org/pipermail/development/2020-October/008441.html
> > in Oktober to bring up "a select box where multiple algorithms can
> > be
> > chosen (like in IPsec)". Since --cipher is deprectaed and will be
> > replaced by --data-ciphers which is a >=2.5.0 option we need
> > another
> > selection field for the --data-ciphers-fallback which is a
> > replacement
> > for --cipher and the server uses this directive to talk also to
> > client
> > which are <2.5.0 .
>
> Yes, the ciphers. But as far as I understand this, you are offering
> to select the whole cipher suite. That is something different.
>
> And you are offering different options for TLSv1.3 and lower, which
> we do not do in IPsec either. You have one selection for both IKEv1
> and IKEv2.
Yes, i thougt it might be an idea for the advanced section be it is not
really needed since OpenVPN uses his own choice for the control-chanel
if nothing has been configured.
>
> > OpenVPN presses to use cipher negotiation which we have avoid since
> > the
> > release of 2.4 with --ncp-disable, this option is no also
> > deprecated so
> > we need to take action on this.
>
> I will skip my moan about introducing something and then deprecating
> it shortly after…
It was good that we did not act at that time.
>
> I agree that we need to act.
>
> > We need to have then two new options, two seletion boxes which are
> > odd
> > to see in the global section. I tried it in the advanced server
> > section
> > too and it looks even more confusing with all the other already
> > existing options, nothing i wanted to do. So i thought your above
> > linked suggestions are pretty straight forward and the best
> > solution to
> > build an own crypto section which do have already defaults, nobody
> > needs to do there anyting, the global section has been cleaned up
> > and
> > it should be even easier for everone to overview.
>
> We have touched this topic multiple times. And I remember the last
> conclusion as follows:
>
> The average user does not have to touch the advanced options. They
> have to put in their subnet, select a port and protocol maybe and
> that is about it. They do not need to think about what cipher to use,
> because we would have selected a reasonable default. If they want to
> change something (because of hardware requirements, etc.) they can do
> that on the advanced page.
This is exactly what i did.
>
> I agree that this is all not idea, but adding a third page to this
> all makes it rather more confusing than less.
Not sure if i understand you here right. You mentioned above the
advanced page but i understand you here that you do not want a third
one ?
>
> > It made for me no sense to leave parts of the crypto (TLS-auth and
> > HMACs) in the global section, especially because there are also
> > even
> > more algorithms, but also new options for the TLS authentication
> > which
> > i have all integrated so i moved them also into that place (patch
> > 6/7
> > and 7/7).
>
> I remember that we have agreed to move the existing crypto options to
> the advanced page.
Yes, me too and i thought you meant an dedicated crypto page like it is
for IPSec but you meant the advanced server section ? If yes we would
mix then routing logging, DNS/WINS options with MTU related configure
options. Also, the crypto section can have also some additionals like
key lieftime, tls-version (if someone wants only TLSv1.3) and may some
other upcoming stuff.
>
> > The control-channel cipher selection (patch 5/7) is new and should
> > be
> > really a part for the advanced ones, therefor no defaults has been
> > set,
> > it simply won´t appear if nothing has been configured.
>
> What is the benefit of choosing a different cipher for the control
> channel?
This one is not really needed, as mentioned above OpenVPN makes then
this desicion by it´s own.
>
> > I have the problem that I cannot get on top of these things. You
> > are
> > submitting *massive* patchsets, in this case I even believe that
> > the
> > whole things has been submitted a second time, although I do not
> > know
> > if there are any changes.
> > Yes there are. Old and deprecated ciphers will now be detected and
> > a
> > warning comes up in the global section to change them as soon as
> > possible (patch 3/7), also all languages has been translated and
> > has
> > been included.
> > Also i wanted to split it in more specific topics for better
> > overview
> > but it seems that i have been failed.
>
> I do not think that you have failed. I just think that it is not
> clear what the patch intended to do. So I cannot really look at it
> and verify if the code actually does what you want it to do.
>
> Could it have been split into even smaller changes? Yes, would that
> have helped? Maybe. But I do not think that we should waste too much
> time to reformat the patches. I want the changes to be ready to be
> merged as soon as possible.
OK. Let´s go through this then. I have attached also screenshots for
all changes for a better first impression.
>
> > I could not even find out *what* you are actually trying to do.
> > There
> > are more and more buttons being added and I have not the slightest
> > idea
> > what I am supposed to do with them. I have given my thoughts about
> > the
> > cipher selection and I felt that I have not been heard.
> > One intention was that you do not need anything to do except you
> > want
> > to do some advanced crypto stuff. The rest should have already been
> > made...
> >
> >
> > I fear that this is all way too complicated. I cannot review what I
> > do
> > not even understand what the desired outcome is. And failing to
> > understand that either means that it is either way too complicated
> > or I
> > have not read enough anywhere about all of this.
> > Please check out the above linked topic where you have wrote
> > suggestions that i simply tried to achieve but again, it seems that
> > i
> > was not successfull with this...
>
> So, maybe help me to understand why the user would want to use
> different ciphers for the control channel and for TLSv1.3/2.
This is not needed and i can easily let it out but mentioned beneath
OpenVPN decided to give TLSv1.2 another directive then TLSv1.3 therefor
the two boxes.
>
> I consider my ciphers as follows:
>
> * Which algorithms do I trust? If I do not trust AES for example, I
> would unselect it for everything, regardless if that is the control
> or data channel).
>
> * What does my hardware support? I would want to choose AES if my
> hardware has acceleration for it.
>
> * Then I would sort them by most secure first (e.g. AES-256, then
> AES-192 and so on…)
>
> I can replicate that with only one multiple-select box that simply
> lists:
>
> * AES-256-GCM
> * AES-256-CBC
> * AES-128-GCM
> * AES-128-CBC
> * ChaCha20-Poly1305
> * Blowfish
> * ...
This is a problen there is exactly the same, this are two directives. -
-data-cipher does NCP whereby --data-ciphers-fallback substitutes --
cipher. If we leave --data-ciphers-fallback out and work only with --
data-ciphers' clients which do not have this directive can not connect.
Also, client which are <=2.5.0 do not understands both directives and
simply do not starts. To find a way out in this foggy world i delivered
a checkbox while client creation so the user have the possiblity to
bring the new directive into client.ovpn but also old clients can be
changed/updated via the edit menu.
>
> And a second one that has
>
> * SHA512
> * SHA384
> * SHA256
> * …
The HMACs can not be used for negotiation, this is only a single
selection.
>
> The code will then have to convert this into the fancy names for the
> OpenVPN configuration file. But I suppose that should be easy to do.
>
> That way, the user can be certain that they have chosen the right
> thing for everything in one go.
>
> > So, could you please summarise for me what you want to achieve
> > here?
> > Hope i have it done above.
>
> Thank you for that.
>
> I really appreciate all this time that you have invested in this, and
> the code looks clean. I just think we have been on different pages
> about what we want it to look and feel like for the user.
Thank you too. This one really needs a lot of time and testing around
and also with help from Adolf it comes to this where it currently is.
>
> > Is this supposed to make OpenVPN more compatible, secure, or
> > anything
> > else?
> > Yes both but also easier since the user do not need to do anything
> > but
> > he should become more security under the hood, the backward and the
> > forward compatibility should be in a better standing than before
> > and if
> > someone wants to go into the depth, this is even also possible.
>
> I think that you have implemented the “pro” version here. It has all
> the buttons you need and uses all features of OpenVPN. But it is
> complicated. So maybe lets hide it from the user that there is a
> control and data channel. Does the user need to know about this? I do
> not think so. It will work either way.
No there is no must for the control-channel cipher selection... If one
is in, it is sometimes nice to walk through all that ;-).
>
> > Why do we not talk about this before things are being implemented,
> > or
> > did I just miss the discussion?
> > Yes i think you missed some of that, hopefully i could remind you
> > on
> > some points.
>
> This is good progress :)
Happy to here this.
Best,
Erik
>
> -Michael
>
> >
> > -Michael
> >
> > Best,
> >
> > Erik
> >
> >
> > > On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org> wrote:
> > >
> > > Hi all,
> > > just wanted to ask if there is still interest in this patch
> > > series ?
> > >
> > > Best,
> > >
> > > Erik
> > >
> >
> >
> >
>
Hi,
> On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
>
> Hi Michael,
>
> Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael Tremer:
>> Hi,
>>
>>> On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org> wrote:
>>>
>>> Hi Michael,
>>> thanks for looking into this.
>>>
>>> Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael Tremer:
>>>> Hello Erik,
>>>>
>>>> Yes, I am very much interested in this.
>>>>
>>>> And I have spent pretty much an hour to make sense out of all of
>>>> this, and unfortunately have to report that I failed.
>>> that´s not good to hear. OK, let me explain... I tried to come up
>>> with
>>> a solution where we already have spoken more times about in the
>>> past, i
>>> tried to follow up your suggestions, the latest about that topic
>>> was
>>> here -->
>>> https://lists.ipfire.org/pipermail/development/2020-October/008441.html
>>> in Oktober to bring up "a select box where multiple algorithms can
>>> be
>>> chosen (like in IPsec)". Since --cipher is deprectaed and will be
>>> replaced by --data-ciphers which is a >=2.5.0 option we need
>>> another
>>> selection field for the --data-ciphers-fallback which is a
>>> replacement
>>> for --cipher and the server uses this directive to talk also to
>>> client
>>> which are <2.5.0 .
>>
>> Yes, the ciphers. But as far as I understand this, you are offering
>> to select the whole cipher suite. That is something different.
>>
>> And you are offering different options for TLSv1.3 and lower, which
>> we do not do in IPsec either. You have one selection for both IKEv1
>> and IKEv2.
> Yes, i thougt it might be an idea for the advanced section be it is not
> really needed since OpenVPN uses his own choice for the control-chanel
> if nothing has been configured.
That probably isn’t good then. The UI should at least show the user what is being used.
If we want OpenVPN to chose what is best, there should be some option that says “automatic” at least.
>>> OpenVPN presses to use cipher negotiation which we have avoid since
>>> the
>>> release of 2.4 with --ncp-disable, this option is no also
>>> deprecated so
>>> we need to take action on this.
>>
>> I will skip my moan about introducing something and then deprecating
>> it shortly after…
> It was good that we did not act at that time.
In hindsight yes. But we didn’t know back then that things would change again, and we do not know now if things will change another time in the near future.
So, we have to do “best-effort” here.
>>
>> I agree that we need to act.
>>
>>> We need to have then two new options, two seletion boxes which are
>>> odd
>>> to see in the global section. I tried it in the advanced server
>>> section
>>> too and it looks even more confusing with all the other already
>>> existing options, nothing i wanted to do. So i thought your above
>>> linked suggestions are pretty straight forward and the best
>>> solution to
>>> build an own crypto section which do have already defaults, nobody
>>> needs to do there anyting, the global section has been cleaned up
>>> and
>>> it should be even easier for everone to overview.
>>
>> We have touched this topic multiple times. And I remember the last
>> conclusion as follows:
>>
>> The average user does not have to touch the advanced options. They
>> have to put in their subnet, select a port and protocol maybe and
>> that is about it. They do not need to think about what cipher to use,
>> because we would have selected a reasonable default. If they want to
>> change something (because of hardware requirements, etc.) they can do
>> that on the advanced page.
> This is exactly what i did.
Okay. So why is there an extra page then, and not a section on the advanced page?
I like the now cleaner look of the main page which only has the bare necessities.
>>
>> I agree that this is all not idea, but adding a third page to this
>> all makes it rather more confusing than less.
> Not sure if i understand you here right. You mentioned above the
> advanced page but i understand you here that you do not want a third
> one ?
There is the main page, where things can be configured (subnet, port, protocol, …), then advanced options, and now the cryptography options.
They are all the same - in that they directly change the OpenVPN configuration - and we only wanted to split them by two things:
a) Is it likely that the user will change them?
b) Or is this an option that the average user should not touch.
The advanced settings page can be as long as we like. It does not have to be pretty.
>>> It made for me no sense to leave parts of the crypto (TLS-auth and
>>> HMACs) in the global section, especially because there are also
>>> even
>>> more algorithms, but also new options for the TLS authentication
>>> which
>>> i have all integrated so i moved them also into that place (patch
>>> 6/7
>>> and 7/7).
>>
>> I remember that we have agreed to move the existing crypto options to
>> the advanced page.
> Yes, me too and i thought you meant an dedicated crypto page like it is
> for IPSec but you meant the advanced server section ? If yes we would
> mix then routing logging, DNS/WINS options with MTU related configure
> options. Also, the crypto section can have also some additionals like
> key lieftime, tls-version (if someone wants only TLSv1.3) and may some
> other upcoming stuff.
That can all go to the advanced page in my opinion.
>>
>>> The control-channel cipher selection (patch 5/7) is new and should
>>> be
>>> really a part for the advanced ones, therefor no defaults has been
>>> set,
>>> it simply won´t appear if nothing has been configured.
>>
>> What is the benefit of choosing a different cipher for the control
>> channel?
> This one is not really needed, as mentioned above OpenVPN makes then
> this desicion by it´s own.
Okay, but why do we have it then? :)
>>
>>> I have the problem that I cannot get on top of these things. You
>>> are
>>> submitting *massive* patchsets, in this case I even believe that
>>> the
>>> whole things has been submitted a second time, although I do not
>>> know
>>> if there are any changes.
>>> Yes there are. Old and deprecated ciphers will now be detected and
>>> a
>>> warning comes up in the global section to change them as soon as
>>> possible (patch 3/7), also all languages has been translated and
>>> has
>>> been included.
>>> Also i wanted to split it in more specific topics for better
>>> overview
>>> but it seems that i have been failed.
>>
>> I do not think that you have failed. I just think that it is not
>> clear what the patch intended to do. So I cannot really look at it
>> and verify if the code actually does what you want it to do.
>>
>> Could it have been split into even smaller changes? Yes, would that
>> have helped? Maybe. But I do not think that we should waste too much
>> time to reformat the patches. I want the changes to be ready to be
>> merged as soon as possible.
> OK. Let´s go through this then. I have attached also screenshots for
> all changes for a better first impression.
That was very helpful to me.
>>
>>> I could not even find out *what* you are actually trying to do.
>>> There
>>> are more and more buttons being added and I have not the slightest
>>> idea
>>> what I am supposed to do with them. I have given my thoughts about
>>> the
>>> cipher selection and I felt that I have not been heard.
>>> One intention was that you do not need anything to do except you
>>> want
>>> to do some advanced crypto stuff. The rest should have already been
>>> made...
>>>
>>>
>>> I fear that this is all way too complicated. I cannot review what I
>>> do
>>> not even understand what the desired outcome is. And failing to
>>> understand that either means that it is either way too complicated
>>> or I
>>> have not read enough anywhere about all of this.
>>> Please check out the above linked topic where you have wrote
>>> suggestions that i simply tried to achieve but again, it seems that
>>> i
>>> was not successfull with this...
>>
>> So, maybe help me to understand why the user would want to use
>> different ciphers for the control channel and for TLSv1.3/2.
> This is not needed and i can easily let it out but mentioned beneath
> OpenVPN decided to give TLSv1.2 another directive then TLSv1.3 therefor
> the two boxes.
Yes, I think choosing this once is enough.
>> I consider my ciphers as follows:
>>
>> * Which algorithms do I trust? If I do not trust AES for example, I
>> would unselect it for everything, regardless if that is the control
>> or data channel).
>>
>> * What does my hardware support? I would want to choose AES if my
>> hardware has acceleration for it.
>>
>> * Then I would sort them by most secure first (e.g. AES-256, then
>> AES-192 and so on…)
>>
>> I can replicate that with only one multiple-select box that simply
>> lists:
>>
>> * AES-256-GCM
>> * AES-256-CBC
>> * AES-128-GCM
>> * AES-128-CBC
>> * ChaCha20-Poly1305
>> * Blowfish
>> * ...
>
> This is a problen there is exactly the same, this are two directives. -
> -data-cipher does NCP whereby --data-ciphers-fallback substitutes --
> cipher. If we leave --data-ciphers-fallback out and work only with --
> data-ciphers' clients which do not have this directive can not connect.
No no, we want to be compatible with older clients and there should be a dropdown that works just like the old cipher selection.
It should be possible to turn it off though by adding a “disabled” option.
> Also, client which are <=2.5.0 do not understands both directives and
> simply do not starts. To find a way out in this foggy world i delivered
> a checkbox while client creation so the user have the possiblity to
> bring the new directive into client.ovpn but also old clients can be
> changed/updated via the edit menu.
The clients should not have any cipher configuration now since they should automatically negotiate it - which is enabled by default.
>>
>> And a second one that has
>>
>> * SHA512
>> * SHA384
>> * SHA256
>> * …
>
> The HMACs can not be used for negotiation, this is only a single
> selection.
Well, that is bad. That means we still do not have full negotiation?
>> The code will then have to convert this into the fancy names for the
>> OpenVPN configuration file. But I suppose that should be easy to do.
>>
>> That way, the user can be certain that they have chosen the right
>> thing for everything in one go.
>>
>>> So, could you please summarise for me what you want to achieve
>>> here?
>>> Hope i have it done above.
>>
>> Thank you for that.
>>
>> I really appreciate all this time that you have invested in this, and
>> the code looks clean. I just think we have been on different pages
>> about what we want it to look and feel like for the user.
> Thank you too. This one really needs a lot of time and testing around
> and also with help from Adolf it comes to this where it currently is.
Great teamwork!
>
>>
>>> Is this supposed to make OpenVPN more compatible, secure, or
>>> anything
>>> else?
>>> Yes both but also easier since the user do not need to do anything
>>> but
>>> he should become more security under the hood, the backward and the
>>> forward compatibility should be in a better standing than before
>>> and if
>>> someone wants to go into the depth, this is even also possible.
>>
>> I think that you have implemented the “pro” version here. It has all
>> the buttons you need and uses all features of OpenVPN. But it is
>> complicated. So maybe lets hide it from the user that there is a
>> control and data channel. Does the user need to know about this? I do
>> not think so. It will work either way.
>
> No there is no must for the control-channel cipher selection... If one
> is in, it is sometimes nice to walk through all that ;-).
>
>>
>>> Why do we not talk about this before things are being implemented,
>>> or
>>> did I just miss the discussion?
>>> Yes i think you missed some of that, hopefully i could remind you
>>> on
>>> some points.
>>
>> This is good progress :)
>
> Happy to here this.
Okay, so what are the next steps now?
-Michael
>
>
> Best,
>
> Erik
>
>>
>> -Michael
>>
>>>
>>> -Michael
>>>
>>> Best,
>>>
>>> Erik
>>>
>>>
>>>> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org> wrote:
>>>>
>>>> Hi all,
>>>> just wanted to ask if there is still interest in this patch
>>>> series ?
>>>>
>>>> Best,
>>>>
>>>> Erik
>>>>
>>>
>>>
>>>
>>
> <advanced_encryption_with_defaults.png><client_version.png><global_settings.png><deprectaed_ciphers_warning.png>
Hi Michael,
there is currently a lot of other real world stuff around me and my
time is really less since things out there do not get easier these
days, at least for me.
If more time and motivation (which is most important) comes up i will
may go for another try to accomplish this topic with your suggestions.
I would also finish this conversation here since it is hardly
comprehensible and a possible v3 would differs a lot.
If someone else wanted to jump in this topic with solutions i am more
then happy with this.
All the best,
Erik
Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael Tremer:
> Hi,
>
> > On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
> >
> > Hi Michael,
> >
> > Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael Tremer:
> > > Hi,
> > >
> > > > On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org> wrote:
> > > >
> > > > Hi Michael,
> > > > thanks for looking into this.
> > > >
> > > > Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael
> > > > Tremer:
> > > > > Hello Erik,
> > > > >
> > > > > Yes, I am very much interested in this.
> > > > >
> > > > > And I have spent pretty much an hour to make sense out of all
> > > > > of
> > > > > this, and unfortunately have to report that I failed.
> > > > that´s not good to hear. OK, let me explain... I tried to come
> > > > up
> > > > with
> > > > a solution where we already have spoken more times about in the
> > > > past, i
> > > > tried to follow up your suggestions, the latest about that
> > > > topic
> > > > was
> > > > here -->
> > > > https://lists.ipfire.org/pipermail/development/2020-October/008441.html
> > > > in Oktober to bring up "a select box where multiple algorithms
> > > > can
> > > > be
> > > > chosen (like in IPsec)". Since --cipher is deprectaed and will
> > > > be
> > > > replaced by --data-ciphers which is a >=2.5.0 option we need
> > > > another
> > > > selection field for the --data-ciphers-fallback which is a
> > > > replacement
> > > > for --cipher and the server uses this directive to talk also to
> > > > client
> > > > which are <2.5.0 .
> > >
> > > Yes, the ciphers. But as far as I understand this, you are
> > > offering
> > > to select the whole cipher suite. That is something different.
> > >
> > > And you are offering different options for TLSv1.3 and lower,
> > > which
> > > we do not do in IPsec either. You have one selection for both
> > > IKEv1
> > > and IKEv2.
> > Yes, i thougt it might be an idea for the advanced section be it is
> > not
> > really needed since OpenVPN uses his own choice for the control-
> > chanel
> > if nothing has been configured.
>
> That probably isn’t good then. The UI should at least show the user
> what is being used.
>
> If we want OpenVPN to chose what is best, there should be some option
> that says “automatic” at least.
>
> > > > OpenVPN presses to use cipher negotiation which we have avoid
> > > > since
> > > > the
> > > > release of 2.4 with --ncp-disable, this option is no also
> > > > deprecated so
> > > > we need to take action on this.
> > >
> > > I will skip my moan about introducing something and then
> > > deprecating
> > > it shortly after…
> > It was good that we did not act at that time.
>
> In hindsight yes. But we didn’t know back then that things would
> change again, and we do not know now if things will change another
> time in the near future.
>
> So, we have to do “best-effort” here.
>
> > >
> > > I agree that we need to act.
> > >
> > > > We need to have then two new options, two seletion boxes which
> > > > are
> > > > odd
> > > > to see in the global section. I tried it in the advanced server
> > > > section
> > > > too and it looks even more confusing with all the other already
> > > > existing options, nothing i wanted to do. So i thought your
> > > > above
> > > > linked suggestions are pretty straight forward and the best
> > > > solution to
> > > > build an own crypto section which do have already defaults,
> > > > nobody
> > > > needs to do there anyting, the global section has been cleaned
> > > > up
> > > > and
> > > > it should be even easier for everone to overview.
> > >
> > > We have touched this topic multiple times. And I remember the
> > > last
> > > conclusion as follows:
> > >
> > > The average user does not have to touch the advanced options.
> > > They
> > > have to put in their subnet, select a port and protocol maybe and
> > > that is about it. They do not need to think about what cipher to
> > > use,
> > > because we would have selected a reasonable default. If they want
> > > to
> > > change something (because of hardware requirements, etc.) they
> > > can do
> > > that on the advanced page.
> > This is exactly what i did.
>
> Okay. So why is there an extra page then, and not a section on the
> advanced page?
>
> I like the now cleaner look of the main page which only has the bare
> necessities.
>
> > >
> > > I agree that this is all not idea, but adding a third page to
> > > this
> > > all makes it rather more confusing than less.
> > Not sure if i understand you here right. You mentioned above the
> > advanced page but i understand you here that you do not want a
> > third
> > one ?
>
> There is the main page, where things can be configured (subnet, port,
> protocol, …), then advanced options, and now the cryptography
> options.
>
> They are all the same - in that they directly change the OpenVPN
> configuration - and we only wanted to split them by two things:
>
> a) Is it likely that the user will change them?
>
> b) Or is this an option that the average user should not touch.
>
> The advanced settings page can be as long as we like. It does not
> have to be pretty.
>
> > > > It made for me no sense to leave parts of the crypto (TLS-auth
> > > > and
> > > > HMACs) in the global section, especially because there are also
> > > > even
> > > > more algorithms, but also new options for the TLS
> > > > authentication
> > > > which
> > > > i have all integrated so i moved them also into that place
> > > > (patch
> > > > 6/7
> > > > and 7/7).
> > >
> > > I remember that we have agreed to move the existing crypto
> > > options to
> > > the advanced page.
> > Yes, me too and i thought you meant an dedicated crypto page like
> > it is
> > for IPSec but you meant the advanced server section ? If yes we
> > would
> > mix then routing logging, DNS/WINS options with MTU related
> > configure
> > options. Also, the crypto section can have also some additionals
> > like
> > key lieftime, tls-version (if someone wants only TLSv1.3) and may
> > some
> > other upcoming stuff.
>
> That can all go to the advanced page in my opinion.
>
> > >
> > > > The control-channel cipher selection (patch 5/7) is new and
> > > > should
> > > > be
> > > > really a part for the advanced ones, therefor no defaults has
> > > > been
> > > > set,
> > > > it simply won´t appear if nothing has been configured.
> > >
> > > What is the benefit of choosing a different cipher for the
> > > control
> > > channel?
> > This one is not really needed, as mentioned above OpenVPN makes
> > then
> > this desicion by it´s own.
>
> Okay, but why do we have it then? :)
>
> > >
> > > > I have the problem that I cannot get on top of these things.
> > > > You
> > > > are
> > > > submitting *massive* patchsets, in this case I even believe
> > > > that
> > > > the
> > > > whole things has been submitted a second time, although I do
> > > > not
> > > > know
> > > > if there are any changes.
> > > > Yes there are. Old and deprecated ciphers will now be detected
> > > > and
> > > > a
> > > > warning comes up in the global section to change them as soon
> > > > as
> > > > possible (patch 3/7), also all languages has been translated
> > > > and
> > > > has
> > > > been included.
> > > > Also i wanted to split it in more specific topics for better
> > > > overview
> > > > but it seems that i have been failed.
> > >
> > > I do not think that you have failed. I just think that it is not
> > > clear what the patch intended to do. So I cannot really look at
> > > it
> > > and verify if the code actually does what you want it to do.
> > >
> > > Could it have been split into even smaller changes? Yes, would
> > > that
> > > have helped? Maybe. But I do not think that we should waste too
> > > much
> > > time to reformat the patches. I want the changes to be ready to
> > > be
> > > merged as soon as possible.
> > OK. Let´s go through this then. I have attached also screenshots
> > for
> > all changes for a better first impression.
>
> That was very helpful to me.
>
> > >
> > > > I could not even find out *what* you are actually trying to do.
> > > > There
> > > > are more and more buttons being added and I have not the
> > > > slightest
> > > > idea
> > > > what I am supposed to do with them. I have given my thoughts
> > > > about
> > > > the
> > > > cipher selection and I felt that I have not been heard.
> > > > One intention was that you do not need anything to do except
> > > > you
> > > > want
> > > > to do some advanced crypto stuff. The rest should have already
> > > > been
> > > > made...
> > > >
> > > >
> > > > I fear that this is all way too complicated. I cannot review
> > > > what I
> > > > do
> > > > not even understand what the desired outcome is. And failing to
> > > > understand that either means that it is either way too
> > > > complicated
> > > > or I
> > > > have not read enough anywhere about all of this.
> > > > Please check out the above linked topic where you have wrote
> > > > suggestions that i simply tried to achieve but again, it seems
> > > > that
> > > > i
> > > > was not successfull with this...
> > >
> > > So, maybe help me to understand why the user would want to use
> > > different ciphers for the control channel and for TLSv1.3/2.
> > This is not needed and i can easily let it out but mentioned
> > beneath
> > OpenVPN decided to give TLSv1.2 another directive then TLSv1.3
> > therefor
> > the two boxes.
>
> Yes, I think choosing this once is enough.
>
> > > I consider my ciphers as follows:
> > >
> > > * Which algorithms do I trust? If I do not trust AES for example,
> > > I
> > > would unselect it for everything, regardless if that is the
> > > control
> > > or data channel).
> > >
> > > * What does my hardware support? I would want to choose AES if my
> > > hardware has acceleration for it.
> > >
> > > * Then I would sort them by most secure first (e.g. AES-256, then
> > > AES-192 and so on…)
> > >
> > > I can replicate that with only one multiple-select box that
> > > simply
> > > lists:
> > >
> > > * AES-256-GCM
> > > * AES-256-CBC
> > > * AES-128-GCM
> > > * AES-128-CBC
> > > * ChaCha20-Poly1305
> > > * Blowfish
> > > * ...
> >
> > This is a problen there is exactly the same, this are two
> > directives. -
> > -data-cipher does NCP whereby --data-ciphers-fallback substitutes -
> > -
> > cipher. If we leave --data-ciphers-fallback out and work only with
> > --
> > data-ciphers' clients which do not have this directive can not
> > connect.
>
> No no, we want to be compatible with older clients and there should
> be a dropdown that works just like the old cipher selection.
>
> It should be possible to turn it off though by adding a “disabled”
> option.
>
> > Also, client which are <=2.5.0 do not understands both directives
> > and
> > simply do not starts. To find a way out in this foggy world i
> > delivered
> > a checkbox while client creation so the user have the possiblity to
> > bring the new directive into client.ovpn but also old clients can
> > be
> > changed/updated via the edit menu.
>
> The clients should not have any cipher configuration now since they
> should automatically negotiate it - which is enabled by default.
>
> > >
> > > And a second one that has
> > >
> > > * SHA512
> > > * SHA384
> > > * SHA256
> > > * …
> >
> > The HMACs can not be used for negotiation, this is only a single
> > selection.
>
> Well, that is bad. That means we still do not have full negotiation?
>
> > > The code will then have to convert this into the fancy names for
> > > the
> > > OpenVPN configuration file. But I suppose that should be easy to
> > > do.
> > >
> > > That way, the user can be certain that they have chosen the right
> > > thing for everything in one go.
> > >
> > > > So, could you please summarise for me what you want to achieve
> > > > here?
> > > > Hope i have it done above.
> > >
> > > Thank you for that.
> > >
> > > I really appreciate all this time that you have invested in this,
> > > and
> > > the code looks clean. I just think we have been on different
> > > pages
> > > about what we want it to look and feel like for the user.
> > Thank you too. This one really needs a lot of time and testing
> > around
> > and also with help from Adolf it comes to this where it currently
> > is.
>
> Great teamwork!
>
> >
> > >
> > > > Is this supposed to make OpenVPN more compatible, secure, or
> > > > anything
> > > > else?
> > > > Yes both but also easier since the user do not need to do
> > > > anything
> > > > but
> > > > he should become more security under the hood, the backward and
> > > > the
> > > > forward compatibility should be in a better standing than
> > > > before
> > > > and if
> > > > someone wants to go into the depth, this is even also possible.
> > >
> > > I think that you have implemented the “pro” version here. It has
> > > all
> > > the buttons you need and uses all features of OpenVPN. But it is
> > > complicated. So maybe lets hide it from the user that there is a
> > > control and data channel. Does the user need to know about this?
> > > I do
> > > not think so. It will work either way.
> >
> > No there is no must for the control-channel cipher selection... If
> > one
> > is in, it is sometimes nice to walk through all that ;-).
> >
> > >
> > > > Why do we not talk about this before things are being
> > > > implemented,
> > > > or
> > > > did I just miss the discussion?
> > > > Yes i think you missed some of that, hopefully i could remind
> > > > you
> > > > on
> > > > some points.
> > >
> > > This is good progress :)
> >
> > Happy to here this.
>
> Okay, so what are the next steps now?
>
> -Michael
>
> >
> >
> > Best,
> >
> > Erik
> >
> > >
> > > -Michael
> > >
> > > >
> > > > -Michael
> > > >
> > > > Best,
> > > >
> > > > Erik
> > > >
> > > >
> > > > > On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org>
> > > > > wrote:
> > > > >
> > > > > Hi all,
> > > > > just wanted to ask if there is still interest in this patch
> > > > > series ?
> > > > >
> > > > > Best,
> > > > >
> > > > > Erik
> > > > >
> > > >
> > > >
> > > >
> > >
> > <advanced_encryption_with_defaults.png><client_version.png><global_
> > settings.png><deprectaed_ciphers_warning.png>
>
Hi Erik,
I have been keeping an eye on this OpenVPN thread anyway so I am willing to pick this up and see if I can help.
As I am no where near as proficient in OpenVPN as you I may end up needing some guidance but am willing to give it a go and see how things go.
I have a couple of bugs with my name against them that I want to get moving first but then I will pick this topic up if you are okay with that.
Regards,
Adolf.
On 13/01/2021 10:18, ummeegge wrote:
> Hi Michael,
> there is currently a lot of other real world stuff around me and my
> time is really less since things out there do not get easier these
> days, at least for me.
>
> If more time and motivation (which is most important) comes up i will
> may go for another try to accomplish this topic with your suggestions.
> I would also finish this conversation here since it is hardly
> comprehensible and a possible v3 would differs a lot.
>
> If someone else wanted to jump in this topic with solutions i am more
> then happy with this.
>
> All the best,
>
> Erik
>
>
> Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael Tremer:
>> Hi,
>>
>>> On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
>>>
>>> Hi Michael,
>>>
>>> Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael Tremer:
>>>> Hi,
>>>>
>>>>> On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>> thanks for looking into this.
>>>>>
>>>>> Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael
>>>>> Tremer:
>>>>>> Hello Erik,
>>>>>>
>>>>>> Yes, I am very much interested in this.
>>>>>>
>>>>>> And I have spent pretty much an hour to make sense out of all
>>>>>> of
>>>>>> this, and unfortunately have to report that I failed.
>>>>> that´s not good to hear. OK, let me explain... I tried to come
>>>>> up
>>>>> with
>>>>> a solution where we already have spoken more times about in the
>>>>> past, i
>>>>> tried to follow up your suggestions, the latest about that
>>>>> topic
>>>>> was
>>>>> here -->
>>>>> https://lists.ipfire.org/pipermail/development/2020-October/008441.html
>>>>> in Oktober to bring up "a select box where multiple algorithms
>>>>> can
>>>>> be
>>>>> chosen (like in IPsec)". Since --cipher is deprectaed and will
>>>>> be
>>>>> replaced by --data-ciphers which is a >=2.5.0 option we need
>>>>> another
>>>>> selection field for the --data-ciphers-fallback which is a
>>>>> replacement
>>>>> for --cipher and the server uses this directive to talk also to
>>>>> client
>>>>> which are <2.5.0 .
>>>>
>>>> Yes, the ciphers. But as far as I understand this, you are
>>>> offering
>>>> to select the whole cipher suite. That is something different.
>>>>
>>>> And you are offering different options for TLSv1.3 and lower,
>>>> which
>>>> we do not do in IPsec either. You have one selection for both
>>>> IKEv1
>>>> and IKEv2.
>>> Yes, i thougt it might be an idea for the advanced section be it is
>>> not
>>> really needed since OpenVPN uses his own choice for the control-
>>> chanel
>>> if nothing has been configured.
>>
>> That probably isn’t good then. The UI should at least show the user
>> what is being used.
>>
>> If we want OpenVPN to chose what is best, there should be some option
>> that says “automatic” at least.
>>
>>>>> OpenVPN presses to use cipher negotiation which we have avoid
>>>>> since
>>>>> the
>>>>> release of 2.4 with --ncp-disable, this option is no also
>>>>> deprecated so
>>>>> we need to take action on this.
>>>>
>>>> I will skip my moan about introducing something and then
>>>> deprecating
>>>> it shortly after…
>>> It was good that we did not act at that time.
>>
>> In hindsight yes. But we didn’t know back then that things would
>> change again, and we do not know now if things will change another
>> time in the near future.
>>
>> So, we have to do “best-effort” here.
>>
>>>>
>>>> I agree that we need to act.
>>>>
>>>>> We need to have then two new options, two seletion boxes which
>>>>> are
>>>>> odd
>>>>> to see in the global section. I tried it in the advanced server
>>>>> section
>>>>> too and it looks even more confusing with all the other already
>>>>> existing options, nothing i wanted to do. So i thought your
>>>>> above
>>>>> linked suggestions are pretty straight forward and the best
>>>>> solution to
>>>>> build an own crypto section which do have already defaults,
>>>>> nobody
>>>>> needs to do there anyting, the global section has been cleaned
>>>>> up
>>>>> and
>>>>> it should be even easier for everone to overview.
>>>>
>>>> We have touched this topic multiple times. And I remember the
>>>> last
>>>> conclusion as follows:
>>>>
>>>> The average user does not have to touch the advanced options.
>>>> They
>>>> have to put in their subnet, select a port and protocol maybe and
>>>> that is about it. They do not need to think about what cipher to
>>>> use,
>>>> because we would have selected a reasonable default. If they want
>>>> to
>>>> change something (because of hardware requirements, etc.) they
>>>> can do
>>>> that on the advanced page.
>>> This is exactly what i did.
>>
>> Okay. So why is there an extra page then, and not a section on the
>> advanced page?
>>
>> I like the now cleaner look of the main page which only has the bare
>> necessities.
>>
>>>>
>>>> I agree that this is all not idea, but adding a third page to
>>>> this
>>>> all makes it rather more confusing than less.
>>> Not sure if i understand you here right. You mentioned above the
>>> advanced page but i understand you here that you do not want a
>>> third
>>> one ?
>>
>> There is the main page, where things can be configured (subnet, port,
>> protocol, …), then advanced options, and now the cryptography
>> options.
>>
>> They are all the same - in that they directly change the OpenVPN
>> configuration - and we only wanted to split them by two things:
>>
>> a) Is it likely that the user will change them?
>>
>> b) Or is this an option that the average user should not touch.
>>
>> The advanced settings page can be as long as we like. It does not
>> have to be pretty.
>>
>>>>> It made for me no sense to leave parts of the crypto (TLS-auth
>>>>> and
>>>>> HMACs) in the global section, especially because there are also
>>>>> even
>>>>> more algorithms, but also new options for the TLS
>>>>> authentication
>>>>> which
>>>>> i have all integrated so i moved them also into that place
>>>>> (patch
>>>>> 6/7
>>>>> and 7/7).
>>>>
>>>> I remember that we have agreed to move the existing crypto
>>>> options to
>>>> the advanced page.
>>> Yes, me too and i thought you meant an dedicated crypto page like
>>> it is
>>> for IPSec but you meant the advanced server section ? If yes we
>>> would
>>> mix then routing logging, DNS/WINS options with MTU related
>>> configure
>>> options. Also, the crypto section can have also some additionals
>>> like
>>> key lieftime, tls-version (if someone wants only TLSv1.3) and may
>>> some
>>> other upcoming stuff.
>>
>> That can all go to the advanced page in my opinion.
>>
>>>>
>>>>> The control-channel cipher selection (patch 5/7) is new and
>>>>> should
>>>>> be
>>>>> really a part for the advanced ones, therefor no defaults has
>>>>> been
>>>>> set,
>>>>> it simply won´t appear if nothing has been configured.
>>>>
>>>> What is the benefit of choosing a different cipher for the
>>>> control
>>>> channel?
>>> This one is not really needed, as mentioned above OpenVPN makes
>>> then
>>> this desicion by it´s own.
>>
>> Okay, but why do we have it then? :)
>>
>>>>
>>>>> I have the problem that I cannot get on top of these things.
>>>>> You
>>>>> are
>>>>> submitting *massive* patchsets, in this case I even believe
>>>>> that
>>>>> the
>>>>> whole things has been submitted a second time, although I do
>>>>> not
>>>>> know
>>>>> if there are any changes.
>>>>> Yes there are. Old and deprecated ciphers will now be detected
>>>>> and
>>>>> a
>>>>> warning comes up in the global section to change them as soon
>>>>> as
>>>>> possible (patch 3/7), also all languages has been translated
>>>>> and
>>>>> has
>>>>> been included.
>>>>> Also i wanted to split it in more specific topics for better
>>>>> overview
>>>>> but it seems that i have been failed.
>>>>
>>>> I do not think that you have failed. I just think that it is not
>>>> clear what the patch intended to do. So I cannot really look at
>>>> it
>>>> and verify if the code actually does what you want it to do.
>>>>
>>>> Could it have been split into even smaller changes? Yes, would
>>>> that
>>>> have helped? Maybe. But I do not think that we should waste too
>>>> much
>>>> time to reformat the patches. I want the changes to be ready to
>>>> be
>>>> merged as soon as possible.
>>> OK. Let´s go through this then. I have attached also screenshots
>>> for
>>> all changes for a better first impression.
>>
>> That was very helpful to me.
>>
>>>>
>>>>> I could not even find out *what* you are actually trying to do.
>>>>> There
>>>>> are more and more buttons being added and I have not the
>>>>> slightest
>>>>> idea
>>>>> what I am supposed to do with them. I have given my thoughts
>>>>> about
>>>>> the
>>>>> cipher selection and I felt that I have not been heard.
>>>>> One intention was that you do not need anything to do except
>>>>> you
>>>>> want
>>>>> to do some advanced crypto stuff. The rest should have already
>>>>> been
>>>>> made...
>>>>>
>>>>>
>>>>> I fear that this is all way too complicated. I cannot review
>>>>> what I
>>>>> do
>>>>> not even understand what the desired outcome is. And failing to
>>>>> understand that either means that it is either way too
>>>>> complicated
>>>>> or I
>>>>> have not read enough anywhere about all of this.
>>>>> Please check out the above linked topic where you have wrote
>>>>> suggestions that i simply tried to achieve but again, it seems
>>>>> that
>>>>> i
>>>>> was not successfull with this...
>>>>
>>>> So, maybe help me to understand why the user would want to use
>>>> different ciphers for the control channel and for TLSv1.3/2.
>>> This is not needed and i can easily let it out but mentioned
>>> beneath
>>> OpenVPN decided to give TLSv1.2 another directive then TLSv1.3
>>> therefor
>>> the two boxes.
>>
>> Yes, I think choosing this once is enough.
>>
>>>> I consider my ciphers as follows:
>>>>
>>>> * Which algorithms do I trust? If I do not trust AES for example,
>>>> I
>>>> would unselect it for everything, regardless if that is the
>>>> control
>>>> or data channel).
>>>>
>>>> * What does my hardware support? I would want to choose AES if my
>>>> hardware has acceleration for it.
>>>>
>>>> * Then I would sort them by most secure first (e.g. AES-256, then
>>>> AES-192 and so on…)
>>>>
>>>> I can replicate that with only one multiple-select box that
>>>> simply
>>>> lists:
>>>>
>>>> * AES-256-GCM
>>>> * AES-256-CBC
>>>> * AES-128-GCM
>>>> * AES-128-CBC
>>>> * ChaCha20-Poly1305
>>>> * Blowfish
>>>> * ...
>>>
>>> This is a problen there is exactly the same, this are two
>>> directives. -
>>> -data-cipher does NCP whereby --data-ciphers-fallback substitutes -
>>> -
>>> cipher. If we leave --data-ciphers-fallback out and work only with
>>> --
>>> data-ciphers' clients which do not have this directive can not
>>> connect.
>>
>> No no, we want to be compatible with older clients and there should
>> be a dropdown that works just like the old cipher selection.
>>
>> It should be possible to turn it off though by adding a “disabled”
>> option.
>>
>>> Also, client which are <=2.5.0 do not understands both directives
>>> and
>>> simply do not starts. To find a way out in this foggy world i
>>> delivered
>>> a checkbox while client creation so the user have the possiblity to
>>> bring the new directive into client.ovpn but also old clients can
>>> be
>>> changed/updated via the edit menu.
>>
>> The clients should not have any cipher configuration now since they
>> should automatically negotiate it - which is enabled by default.
>>
>>>>
>>>> And a second one that has
>>>>
>>>> * SHA512
>>>> * SHA384
>>>> * SHA256
>>>> * …
>>>
>>> The HMACs can not be used for negotiation, this is only a single
>>> selection.
>>
>> Well, that is bad. That means we still do not have full negotiation?
>>
>>>> The code will then have to convert this into the fancy names for
>>>> the
>>>> OpenVPN configuration file. But I suppose that should be easy to
>>>> do.
>>>>
>>>> That way, the user can be certain that they have chosen the right
>>>> thing for everything in one go.
>>>>
>>>>> So, could you please summarise for me what you want to achieve
>>>>> here?
>>>>> Hope i have it done above.
>>>>
>>>> Thank you for that.
>>>>
>>>> I really appreciate all this time that you have invested in this,
>>>> and
>>>> the code looks clean. I just think we have been on different
>>>> pages
>>>> about what we want it to look and feel like for the user.
>>> Thank you too. This one really needs a lot of time and testing
>>> around
>>> and also with help from Adolf it comes to this where it currently
>>> is.
>>
>> Great teamwork!
>>
>>>
>>>>
>>>>> Is this supposed to make OpenVPN more compatible, secure, or
>>>>> anything
>>>>> else?
>>>>> Yes both but also easier since the user do not need to do
>>>>> anything
>>>>> but
>>>>> he should become more security under the hood, the backward and
>>>>> the
>>>>> forward compatibility should be in a better standing than
>>>>> before
>>>>> and if
>>>>> someone wants to go into the depth, this is even also possible.
>>>>
>>>> I think that you have implemented the “pro” version here. It has
>>>> all
>>>> the buttons you need and uses all features of OpenVPN. But it is
>>>> complicated. So maybe lets hide it from the user that there is a
>>>> control and data channel. Does the user need to know about this?
>>>> I do
>>>> not think so. It will work either way.
>>>
>>> No there is no must for the control-channel cipher selection... If
>>> one
>>> is in, it is sometimes nice to walk through all that ;-).
>>>
>>>>
>>>>> Why do we not talk about this before things are being
>>>>> implemented,
>>>>> or
>>>>> did I just miss the discussion?
>>>>> Yes i think you missed some of that, hopefully i could remind
>>>>> you
>>>>> on
>>>>> some points.
>>>>
>>>> This is good progress :)
>>>
>>> Happy to here this.
>>
>> Okay, so what are the next steps now?
>>
>> -Michael
>>
>>>
>>>
>>> Best,
>>>
>>> Erik
>>>
>>>>
>>>> -Michael
>>>>
>>>>>
>>>>> -Michael
>>>>>
>>>>> Best,
>>>>>
>>>>> Erik
>>>>>
>>>>>
>>>>>> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org>
>>>>>> wrote:
>>>>>>
>>>>>> Hi all,
>>>>>> just wanted to ask if there is still interest in this patch
>>>>>> series ?
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> <advanced_encryption_with_defaults.png><client_version.png><global_
>>> settings.png><deprectaed_ciphers_warning.png>
>>
>
>
Good morning Adolf,
Am Donnerstag, dem 14.01.2021 um 19:50 +0100 schrieb Adolf Belka:
> Hi Erik,
>
> I have been keeping an eye on this OpenVPN thread anyway so I am
> willing to pick this up and see if I can help.
>
> As I am no where near as proficient in OpenVPN as you I may end up
> needing some guidance but am willing to give it a go and see how
> things go.
Will try to help you out if i can.
>
> I have a couple of bugs with my name against them that I want to get
> moving first but then I will pick this topic up if you are okay with
> that.
As mentioned before, i am more then happy with this.
>
> Regards,
>
> Adolf.
Best,
Erik
>
> On 13/01/2021 10:18, ummeegge wrote:
> > Hi Michael,
> > there is currently a lot of other real world stuff around me and my
> > time is really less since things out there do not get easier these
> > days, at least for me.
> >
> > If more time and motivation (which is most important) comes up i
> > will
> > may go for another try to accomplish this topic with your
> > suggestions.
> > I would also finish this conversation here since it is hardly
> > comprehensible and a possible v3 would differs a lot.
> >
> > If someone else wanted to jump in this topic with solutions i am
> > more
> > then happy with this.
> >
> > All the best,
> >
> > Erik
> >
> >
> > Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael Tremer:
> > > Hi,
> > >
> > > > On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
> > > >
> > > > Hi Michael,
> > > >
> > > > Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael
> > > > Tremer:
> > > > > Hi,
> > > > >
> > > > > > On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org>
> > > > > > wrote:
> > > > > >
> > > > > > Hi Michael,
> > > > > > thanks for looking into this.
> > > > > >
> > > > > > Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael
> > > > > > Tremer:
> > > > > > > Hello Erik,
> > > > > > >
> > > > > > > Yes, I am very much interested in this.
> > > > > > >
> > > > > > > And I have spent pretty much an hour to make sense out of
> > > > > > > all
> > > > > > > of
> > > > > > > this, and unfortunately have to report that I failed.
> > > > > > that´s not good to hear. OK, let me explain... I tried to
> > > > > > come
> > > > > > up
> > > > > > with
> > > > > > a solution where we already have spoken more times about in
> > > > > > the
> > > > > > past, i
> > > > > > tried to follow up your suggestions, the latest about that
> > > > > > topic
> > > > > > was
> > > > > > here -->
> > > > > >
> > > > > > https://lists.ipfire.org/pipermail/development/2020-October/008441.html
> > > > > > in Oktober to bring up "a select box where multiple
> > > > > > algorithms
> > > > > > can
> > > > > > be
> > > > > > chosen (like in IPsec)". Since --cipher is deprectaed and
> > > > > > will
> > > > > > be
> > > > > > replaced by --data-ciphers which is a >=2.5.0 option we
> > > > > > need
> > > > > > another
> > > > > > selection field for the --data-ciphers-fallback which is a
> > > > > > replacement
> > > > > > for --cipher and the server uses this directive to talk
> > > > > > also to
> > > > > > client
> > > > > > which are <2.5.0 .
> > > > >
> > > > > Yes, the ciphers. But as far as I understand this, you are
> > > > > offering
> > > > > to select the whole cipher suite. That is something
> > > > > different.
> > > > >
> > > > > And you are offering different options for TLSv1.3 and lower,
> > > > > which
> > > > > we do not do in IPsec either. You have one selection for both
> > > > > IKEv1
> > > > > and IKEv2.
> > > > Yes, i thougt it might be an idea for the advanced section be
> > > > it is
> > > > not
> > > > really needed since OpenVPN uses his own choice for the
> > > > control-
> > > > chanel
> > > > if nothing has been configured.
> > >
> > > That probably isn’t good then. The UI should at least show the
> > > user
> > > what is being used.
> > >
> > > If we want OpenVPN to chose what is best, there should be some
> > > option
> > > that says “automatic” at least.
> > >
> > > > > > OpenVPN presses to use cipher negotiation which we have
> > > > > > avoid
> > > > > > since
> > > > > > the
> > > > > > release of 2.4 with --ncp-disable, this option is no also
> > > > > > deprecated so
> > > > > > we need to take action on this.
> > > > >
> > > > > I will skip my moan about introducing something and then
> > > > > deprecating
> > > > > it shortly after…
> > > > It was good that we did not act at that time.
> > >
> > > In hindsight yes. But we didn’t know back then that things would
> > > change again, and we do not know now if things will change
> > > another
> > > time in the near future.
> > >
> > > So, we have to do “best-effort” here.
> > >
> > > > >
> > > > > I agree that we need to act.
> > > > >
> > > > > > We need to have then two new options, two seletion boxes
> > > > > > which
> > > > > > are
> > > > > > odd
> > > > > > to see in the global section. I tried it in the advanced
> > > > > > server
> > > > > > section
> > > > > > too and it looks even more confusing with all the other
> > > > > > already
> > > > > > existing options, nothing i wanted to do. So i thought your
> > > > > > above
> > > > > > linked suggestions are pretty straight forward and the best
> > > > > > solution to
> > > > > > build an own crypto section which do have already defaults,
> > > > > > nobody
> > > > > > needs to do there anyting, the global section has been
> > > > > > cleaned
> > > > > > up
> > > > > > and
> > > > > > it should be even easier for everone to overview.
> > > > >
> > > > > We have touched this topic multiple times. And I remember the
> > > > > last
> > > > > conclusion as follows:
> > > > >
> > > > > The average user does not have to touch the advanced options.
> > > > > They
> > > > > have to put in their subnet, select a port and protocol maybe
> > > > > and
> > > > > that is about it. They do not need to think about what cipher
> > > > > to
> > > > > use,
> > > > > because we would have selected a reasonable default. If they
> > > > > want
> > > > > to
> > > > > change something (because of hardware requirements, etc.)
> > > > > they
> > > > > can do
> > > > > that on the advanced page.
> > > > This is exactly what i did.
> > >
> > > Okay. So why is there an extra page then, and not a section on
> > > the
> > > advanced page?
> > >
> > > I like the now cleaner look of the main page which only has the
> > > bare
> > > necessities.
> > >
> > > > >
> > > > > I agree that this is all not idea, but adding a third page to
> > > > > this
> > > > > all makes it rather more confusing than less.
> > > > Not sure if i understand you here right. You mentioned above
> > > > the
> > > > advanced page but i understand you here that you do not want a
> > > > third
> > > > one ?
> > >
> > > There is the main page, where things can be configured (subnet,
> > > port,
> > > protocol, …), then advanced options, and now the cryptography
> > > options.
> > >
> > > They are all the same - in that they directly change the OpenVPN
> > > configuration - and we only wanted to split them by two things:
> > >
> > > a) Is it likely that the user will change them?
> > >
> > > b) Or is this an option that the average user should not touch.
> > >
> > > The advanced settings page can be as long as we like. It does not
> > > have to be pretty.
> > >
> > > > > > It made for me no sense to leave parts of the crypto (TLS-
> > > > > > auth
> > > > > > and
> > > > > > HMACs) in the global section, especially because there are
> > > > > > also
> > > > > > even
> > > > > > more algorithms, but also new options for the TLS
> > > > > > authentication
> > > > > > which
> > > > > > i have all integrated so i moved them also into that place
> > > > > > (patch
> > > > > > 6/7
> > > > > > and 7/7).
> > > > >
> > > > > I remember that we have agreed to move the existing crypto
> > > > > options to
> > > > > the advanced page.
> > > > Yes, me too and i thought you meant an dedicated crypto page
> > > > like
> > > > it is
> > > > for IPSec but you meant the advanced server section ? If yes we
> > > > would
> > > > mix then routing logging, DNS/WINS options with MTU related
> > > > configure
> > > > options. Also, the crypto section can have also some
> > > > additionals
> > > > like
> > > > key lieftime, tls-version (if someone wants only TLSv1.3) and
> > > > may
> > > > some
> > > > other upcoming stuff.
> > >
> > > That can all go to the advanced page in my opinion.
> > >
> > > > >
> > > > > > The control-channel cipher selection (patch 5/7) is new and
> > > > > > should
> > > > > > be
> > > > > > really a part for the advanced ones, therefor no defaults
> > > > > > has
> > > > > > been
> > > > > > set,
> > > > > > it simply won´t appear if nothing has been configured.
> > > > >
> > > > > What is the benefit of choosing a different cipher for the
> > > > > control
> > > > > channel?
> > > > This one is not really needed, as mentioned above OpenVPN makes
> > > > then
> > > > this desicion by it´s own.
> > >
> > > Okay, but why do we have it then? :)
> > >
> > > > >
> > > > > > I have the problem that I cannot get on top of these
> > > > > > things.
> > > > > > You
> > > > > > are
> > > > > > submitting *massive* patchsets, in this case I even believe
> > > > > > that
> > > > > > the
> > > > > > whole things has been submitted a second time, although I
> > > > > > do
> > > > > > not
> > > > > > know
> > > > > > if there are any changes.
> > > > > > Yes there are. Old and deprecated ciphers will now be
> > > > > > detected
> > > > > > and
> > > > > > a
> > > > > > warning comes up in the global section to change them as
> > > > > > soon
> > > > > > as
> > > > > > possible (patch 3/7), also all languages has been
> > > > > > translated
> > > > > > and
> > > > > > has
> > > > > > been included.
> > > > > > Also i wanted to split it in more specific topics for
> > > > > > better
> > > > > > overview
> > > > > > but it seems that i have been failed.
> > > > >
> > > > > I do not think that you have failed. I just think that it is
> > > > > not
> > > > > clear what the patch intended to do. So I cannot really look
> > > > > at
> > > > > it
> > > > > and verify if the code actually does what you want it to do.
> > > > >
> > > > > Could it have been split into even smaller changes? Yes,
> > > > > would
> > > > > that
> > > > > have helped? Maybe. But I do not think that we should waste
> > > > > too
> > > > > much
> > > > > time to reformat the patches. I want the changes to be ready
> > > > > to
> > > > > be
> > > > > merged as soon as possible.
> > > > OK. Let´s go through this then. I have attached also
> > > > screenshots
> > > > for
> > > > all changes for a better first impression.
> > >
> > > That was very helpful to me.
> > >
> > > > >
> > > > > > I could not even find out *what* you are actually trying to
> > > > > > do.
> > > > > > There
> > > > > > are more and more buttons being added and I have not the
> > > > > > slightest
> > > > > > idea
> > > > > > what I am supposed to do with them. I have given my
> > > > > > thoughts
> > > > > > about
> > > > > > the
> > > > > > cipher selection and I felt that I have not been heard.
> > > > > > One intention was that you do not need anything to do
> > > > > > except
> > > > > > you
> > > > > > want
> > > > > > to do some advanced crypto stuff. The rest should have
> > > > > > already
> > > > > > been
> > > > > > made...
> > > > > >
> > > > > >
> > > > > > I fear that this is all way too complicated. I cannot
> > > > > > review
> > > > > > what I
> > > > > > do
> > > > > > not even understand what the desired outcome is. And
> > > > > > failing to
> > > > > > understand that either means that it is either way too
> > > > > > complicated
> > > > > > or I
> > > > > > have not read enough anywhere about all of this.
> > > > > > Please check out the above linked topic where you have
> > > > > > wrote
> > > > > > suggestions that i simply tried to achieve but again, it
> > > > > > seems
> > > > > > that
> > > > > > i
> > > > > > was not successfull with this...
> > > > >
> > > > > So, maybe help me to understand why the user would want to
> > > > > use
> > > > > different ciphers for the control channel and for TLSv1.3/2.
> > > > This is not needed and i can easily let it out but mentioned
> > > > beneath
> > > > OpenVPN decided to give TLSv1.2 another directive then TLSv1.3
> > > > therefor
> > > > the two boxes.
> > >
> > > Yes, I think choosing this once is enough.
> > >
> > > > > I consider my ciphers as follows:
> > > > >
> > > > > * Which algorithms do I trust? If I do not trust AES for
> > > > > example,
> > > > > I
> > > > > would unselect it for everything, regardless if that is the
> > > > > control
> > > > > or data channel).
> > > > >
> > > > > * What does my hardware support? I would want to choose AES
> > > > > if my
> > > > > hardware has acceleration for it.
> > > > >
> > > > > * Then I would sort them by most secure first (e.g. AES-256,
> > > > > then
> > > > > AES-192 and so on…)
> > > > >
> > > > > I can replicate that with only one multiple-select box that
> > > > > simply
> > > > > lists:
> > > > >
> > > > > * AES-256-GCM
> > > > > * AES-256-CBC
> > > > > * AES-128-GCM
> > > > > * AES-128-CBC
> > > > > * ChaCha20-Poly1305
> > > > > * Blowfish
> > > > > * ...
> > > >
> > > > This is a problen there is exactly the same, this are two
> > > > directives. -
> > > > -data-cipher does NCP whereby --data-ciphers-fallback
> > > > substitutes -
> > > > -
> > > > cipher. If we leave --data-ciphers-fallback out and work only
> > > > with
> > > > --
> > > > data-ciphers' clients which do not have this directive can not
> > > > connect.
> > >
> > > No no, we want to be compatible with older clients and there
> > > should
> > > be a dropdown that works just like the old cipher selection.
> > >
> > > It should be possible to turn it off though by adding a
> > > “disabled”
> > > option.
> > >
> > > > Also, client which are <=2.5.0 do not understands both
> > > > directives
> > > > and
> > > > simply do not starts. To find a way out in this foggy world i
> > > > delivered
> > > > a checkbox while client creation so the user have the
> > > > possiblity to
> > > > bring the new directive into client.ovpn but also old clients
> > > > can
> > > > be
> > > > changed/updated via the edit menu.
> > >
> > > The clients should not have any cipher configuration now since
> > > they
> > > should automatically negotiate it - which is enabled by default.
> > >
> > > > >
> > > > > And a second one that has
> > > > >
> > > > > * SHA512
> > > > > * SHA384
> > > > > * SHA256
> > > > > * …
> > > >
> > > > The HMACs can not be used for negotiation, this is only a
> > > > single
> > > > selection.
> > >
> > > Well, that is bad. That means we still do not have full
> > > negotiation?
> > >
> > > > > The code will then have to convert this into the fancy names
> > > > > for
> > > > > the
> > > > > OpenVPN configuration file. But I suppose that should be easy
> > > > > to
> > > > > do.
> > > > >
> > > > > That way, the user can be certain that they have chosen the
> > > > > right
> > > > > thing for everything in one go.
> > > > >
> > > > > > So, could you please summarise for me what you want to
> > > > > > achieve
> > > > > > here?
> > > > > > Hope i have it done above.
> > > > >
> > > > > Thank you for that.
> > > > >
> > > > > I really appreciate all this time that you have invested in
> > > > > this,
> > > > > and
> > > > > the code looks clean. I just think we have been on different
> > > > > pages
> > > > > about what we want it to look and feel like for the user.
> > > > Thank you too. This one really needs a lot of time and testing
> > > > around
> > > > and also with help from Adolf it comes to this where it
> > > > currently
> > > > is.
> > >
> > > Great teamwork!
> > >
> > > >
> > > > >
> > > > > > Is this supposed to make OpenVPN more compatible, secure,
> > > > > > or
> > > > > > anything
> > > > > > else?
> > > > > > Yes both but also easier since the user do not need to do
> > > > > > anything
> > > > > > but
> > > > > > he should become more security under the hood, the backward
> > > > > > and
> > > > > > the
> > > > > > forward compatibility should be in a better standing than
> > > > > > before
> > > > > > and if
> > > > > > someone wants to go into the depth, this is even also
> > > > > > possible.
> > > > >
> > > > > I think that you have implemented the “pro” version here. It
> > > > > has
> > > > > all
> > > > > the buttons you need and uses all features of OpenVPN. But it
> > > > > is
> > > > > complicated. So maybe lets hide it from the user that there
> > > > > is a
> > > > > control and data channel. Does the user need to know about
> > > > > this?
> > > > > I do
> > > > > not think so. It will work either way.
> > > >
> > > > No there is no must for the control-channel cipher selection...
> > > > If
> > > > one
> > > > is in, it is sometimes nice to walk through all that ;-).
> > > >
> > > > >
> > > > > > Why do we not talk about this before things are being
> > > > > > implemented,
> > > > > > or
> > > > > > did I just miss the discussion?
> > > > > > Yes i think you missed some of that, hopefully i could
> > > > > > remind
> > > > > > you
> > > > > > on
> > > > > > some points.
> > > > >
> > > > > This is good progress :)
> > > >
> > > > Happy to here this.
> > >
> > > Okay, so what are the next steps now?
> > >
> > > -Michael
> > >
> > > >
> > > >
> > > > Best,
> > > >
> > > > Erik
> > > >
> > > > >
> > > > > -Michael
> > > > >
> > > > > >
> > > > > > -Michael
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Erik
> > > > > >
> > > > > >
> > > > > > > On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > Hi all,
> > > > > > > just wanted to ask if there is still interest in this
> > > > > > > patch
> > > > > > > series ?
> > > > > > >
> > > > > > > Best,
> > > > > > >
> > > > > > > Erik
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > <advanced_encryption_with_defaults.png><client_version.png><glo
> > > > bal_
> > > > settings.png><deprectaed_ciphers_warning.png>
> > >
> >
> >
Hi Erik,
Where can I get hold of your latest version of ovpnmain.cgi
Regards,
Adolf.
On 15/01/2021 05:56, ummeegge wrote:
> Good morning Adolf,
>
> Am Donnerstag, dem 14.01.2021 um 19:50 +0100 schrieb Adolf Belka:
>> Hi Erik,
>>
>> I have been keeping an eye on this OpenVPN thread anyway so I am
>> willing to pick this up and see if I can help.
>>
>> As I am no where near as proficient in OpenVPN as you I may end up
>> needing some guidance but am willing to give it a go and see how
>> things go.
> Will try to help you out if i can.
>
>> I have a couple of bugs with my name against them that I want to get
>> moving first but then I will pick this topic up if you are okay with
>> that.
> As mentioned before, i am more then happy with this.
>
>> Regards,
>>
>> Adolf.
> Best,
>
> Erik
>
>> On 13/01/2021 10:18, ummeegge wrote:
>>> Hi Michael,
>>> there is currently a lot of other real world stuff around me and my
>>> time is really less since things out there do not get easier these
>>> days, at least for me.
>>>
>>> If more time and motivation (which is most important) comes up i
>>> will
>>> may go for another try to accomplish this topic with your
>>> suggestions.
>>> I would also finish this conversation here since it is hardly
>>> comprehensible and a possible v3 would differs a lot.
>>>
>>> If someone else wanted to jump in this topic with solutions i am
>>> more
>>> then happy with this.
>>>
>>> All the best,
>>>
>>> Erik
>>>
>>>
>>> Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael Tremer:
>>>> Hi,
>>>>
>>>>> On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael
>>>>> Tremer:
>>>>>> Hi,
>>>>>>
>>>>>>> On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>> thanks for looking into this.
>>>>>>>
>>>>>>> Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael
>>>>>>> Tremer:
>>>>>>>> Hello Erik,
>>>>>>>>
>>>>>>>> Yes, I am very much interested in this.
>>>>>>>>
>>>>>>>> And I have spent pretty much an hour to make sense out of
>>>>>>>> all
>>>>>>>> of
>>>>>>>> this, and unfortunately have to report that I failed.
>>>>>>> that´s not good to hear. OK, let me explain... I tried to
>>>>>>> come
>>>>>>> up
>>>>>>> with
>>>>>>> a solution where we already have spoken more times about in
>>>>>>> the
>>>>>>> past, i
>>>>>>> tried to follow up your suggestions, the latest about that
>>>>>>> topic
>>>>>>> was
>>>>>>> here -->
>>>>>>>
>>>>>>> https://lists.ipfire.org/pipermail/development/2020-October/008441.html
>>>>>>> in Oktober to bring up "a select box where multiple
>>>>>>> algorithms
>>>>>>> can
>>>>>>> be
>>>>>>> chosen (like in IPsec)". Since --cipher is deprectaed and
>>>>>>> will
>>>>>>> be
>>>>>>> replaced by --data-ciphers which is a >=2.5.0 option we
>>>>>>> need
>>>>>>> another
>>>>>>> selection field for the --data-ciphers-fallback which is a
>>>>>>> replacement
>>>>>>> for --cipher and the server uses this directive to talk
>>>>>>> also to
>>>>>>> client
>>>>>>> which are <2.5.0 .
>>>>>> Yes, the ciphers. But as far as I understand this, you are
>>>>>> offering
>>>>>> to select the whole cipher suite. That is something
>>>>>> different.
>>>>>>
>>>>>> And you are offering different options for TLSv1.3 and lower,
>>>>>> which
>>>>>> we do not do in IPsec either. You have one selection for both
>>>>>> IKEv1
>>>>>> and IKEv2.
>>>>> Yes, i thougt it might be an idea for the advanced section be
>>>>> it is
>>>>> not
>>>>> really needed since OpenVPN uses his own choice for the
>>>>> control-
>>>>> chanel
>>>>> if nothing has been configured.
>>>> That probably isn’t good then. The UI should at least show the
>>>> user
>>>> what is being used.
>>>>
>>>> If we want OpenVPN to chose what is best, there should be some
>>>> option
>>>> that says “automatic” at least.
>>>>
>>>>>>> OpenVPN presses to use cipher negotiation which we have
>>>>>>> avoid
>>>>>>> since
>>>>>>> the
>>>>>>> release of 2.4 with --ncp-disable, this option is no also
>>>>>>> deprecated so
>>>>>>> we need to take action on this.
>>>>>> I will skip my moan about introducing something and then
>>>>>> deprecating
>>>>>> it shortly after…
>>>>> It was good that we did not act at that time.
>>>> In hindsight yes. But we didn’t know back then that things would
>>>> change again, and we do not know now if things will change
>>>> another
>>>> time in the near future.
>>>>
>>>> So, we have to do “best-effort” here.
>>>>
>>>>>> I agree that we need to act.
>>>>>>
>>>>>>> We need to have then two new options, two seletion boxes
>>>>>>> which
>>>>>>> are
>>>>>>> odd
>>>>>>> to see in the global section. I tried it in the advanced
>>>>>>> server
>>>>>>> section
>>>>>>> too and it looks even more confusing with all the other
>>>>>>> already
>>>>>>> existing options, nothing i wanted to do. So i thought your
>>>>>>> above
>>>>>>> linked suggestions are pretty straight forward and the best
>>>>>>> solution to
>>>>>>> build an own crypto section which do have already defaults,
>>>>>>> nobody
>>>>>>> needs to do there anyting, the global section has been
>>>>>>> cleaned
>>>>>>> up
>>>>>>> and
>>>>>>> it should be even easier for everone to overview.
>>>>>> We have touched this topic multiple times. And I remember the
>>>>>> last
>>>>>> conclusion as follows:
>>>>>>
>>>>>> The average user does not have to touch the advanced options.
>>>>>> They
>>>>>> have to put in their subnet, select a port and protocol maybe
>>>>>> and
>>>>>> that is about it. They do not need to think about what cipher
>>>>>> to
>>>>>> use,
>>>>>> because we would have selected a reasonable default. If they
>>>>>> want
>>>>>> to
>>>>>> change something (because of hardware requirements, etc.)
>>>>>> they
>>>>>> can do
>>>>>> that on the advanced page.
>>>>> This is exactly what i did.
>>>> Okay. So why is there an extra page then, and not a section on
>>>> the
>>>> advanced page?
>>>>
>>>> I like the now cleaner look of the main page which only has the
>>>> bare
>>>> necessities.
>>>>
>>>>>> I agree that this is all not idea, but adding a third page to
>>>>>> this
>>>>>> all makes it rather more confusing than less.
>>>>> Not sure if i understand you here right. You mentioned above
>>>>> the
>>>>> advanced page but i understand you here that you do not want a
>>>>> third
>>>>> one ?
>>>> There is the main page, where things can be configured (subnet,
>>>> port,
>>>> protocol, …), then advanced options, and now the cryptography
>>>> options.
>>>>
>>>> They are all the same - in that they directly change the OpenVPN
>>>> configuration - and we only wanted to split them by two things:
>>>>
>>>> a) Is it likely that the user will change them?
>>>>
>>>> b) Or is this an option that the average user should not touch.
>>>>
>>>> The advanced settings page can be as long as we like. It does not
>>>> have to be pretty.
>>>>
>>>>>>> It made for me no sense to leave parts of the crypto (TLS-
>>>>>>> auth
>>>>>>> and
>>>>>>> HMACs) in the global section, especially because there are
>>>>>>> also
>>>>>>> even
>>>>>>> more algorithms, but also new options for the TLS
>>>>>>> authentication
>>>>>>> which
>>>>>>> i have all integrated so i moved them also into that place
>>>>>>> (patch
>>>>>>> 6/7
>>>>>>> and 7/7).
>>>>>> I remember that we have agreed to move the existing crypto
>>>>>> options to
>>>>>> the advanced page.
>>>>> Yes, me too and i thought you meant an dedicated crypto page
>>>>> like
>>>>> it is
>>>>> for IPSec but you meant the advanced server section ? If yes we
>>>>> would
>>>>> mix then routing logging, DNS/WINS options with MTU related
>>>>> configure
>>>>> options. Also, the crypto section can have also some
>>>>> additionals
>>>>> like
>>>>> key lieftime, tls-version (if someone wants only TLSv1.3) and
>>>>> may
>>>>> some
>>>>> other upcoming stuff.
>>>> That can all go to the advanced page in my opinion.
>>>>
>>>>>>> The control-channel cipher selection (patch 5/7) is new and
>>>>>>> should
>>>>>>> be
>>>>>>> really a part for the advanced ones, therefor no defaults
>>>>>>> has
>>>>>>> been
>>>>>>> set,
>>>>>>> it simply won´t appear if nothing has been configured.
>>>>>> What is the benefit of choosing a different cipher for the
>>>>>> control
>>>>>> channel?
>>>>> This one is not really needed, as mentioned above OpenVPN makes
>>>>> then
>>>>> this desicion by it´s own.
>>>> Okay, but why do we have it then? :)
>>>>
>>>>>>> I have the problem that I cannot get on top of these
>>>>>>> things.
>>>>>>> You
>>>>>>> are
>>>>>>> submitting *massive* patchsets, in this case I even believe
>>>>>>> that
>>>>>>> the
>>>>>>> whole things has been submitted a second time, although I
>>>>>>> do
>>>>>>> not
>>>>>>> know
>>>>>>> if there are any changes.
>>>>>>> Yes there are. Old and deprecated ciphers will now be
>>>>>>> detected
>>>>>>> and
>>>>>>> a
>>>>>>> warning comes up in the global section to change them as
>>>>>>> soon
>>>>>>> as
>>>>>>> possible (patch 3/7), also all languages has been
>>>>>>> translated
>>>>>>> and
>>>>>>> has
>>>>>>> been included.
>>>>>>> Also i wanted to split it in more specific topics for
>>>>>>> better
>>>>>>> overview
>>>>>>> but it seems that i have been failed.
>>>>>> I do not think that you have failed. I just think that it is
>>>>>> not
>>>>>> clear what the patch intended to do. So I cannot really look
>>>>>> at
>>>>>> it
>>>>>> and verify if the code actually does what you want it to do.
>>>>>>
>>>>>> Could it have been split into even smaller changes? Yes,
>>>>>> would
>>>>>> that
>>>>>> have helped? Maybe. But I do not think that we should waste
>>>>>> too
>>>>>> much
>>>>>> time to reformat the patches. I want the changes to be ready
>>>>>> to
>>>>>> be
>>>>>> merged as soon as possible.
>>>>> OK. Let´s go through this then. I have attached also
>>>>> screenshots
>>>>> for
>>>>> all changes for a better first impression.
>>>> That was very helpful to me.
>>>>
>>>>>>> I could not even find out *what* you are actually trying to
>>>>>>> do.
>>>>>>> There
>>>>>>> are more and more buttons being added and I have not the
>>>>>>> slightest
>>>>>>> idea
>>>>>>> what I am supposed to do with them. I have given my
>>>>>>> thoughts
>>>>>>> about
>>>>>>> the
>>>>>>> cipher selection and I felt that I have not been heard.
>>>>>>> One intention was that you do not need anything to do
>>>>>>> except
>>>>>>> you
>>>>>>> want
>>>>>>> to do some advanced crypto stuff. The rest should have
>>>>>>> already
>>>>>>> been
>>>>>>> made...
>>>>>>>
>>>>>>>
>>>>>>> I fear that this is all way too complicated. I cannot
>>>>>>> review
>>>>>>> what I
>>>>>>> do
>>>>>>> not even understand what the desired outcome is. And
>>>>>>> failing to
>>>>>>> understand that either means that it is either way too
>>>>>>> complicated
>>>>>>> or I
>>>>>>> have not read enough anywhere about all of this.
>>>>>>> Please check out the above linked topic where you have
>>>>>>> wrote
>>>>>>> suggestions that i simply tried to achieve but again, it
>>>>>>> seems
>>>>>>> that
>>>>>>> i
>>>>>>> was not successfull with this...
>>>>>> So, maybe help me to understand why the user would want to
>>>>>> use
>>>>>> different ciphers for the control channel and for TLSv1.3/2.
>>>>> This is not needed and i can easily let it out but mentioned
>>>>> beneath
>>>>> OpenVPN decided to give TLSv1.2 another directive then TLSv1.3
>>>>> therefor
>>>>> the two boxes.
>>>> Yes, I think choosing this once is enough.
>>>>
>>>>>> I consider my ciphers as follows:
>>>>>>
>>>>>> * Which algorithms do I trust? If I do not trust AES for
>>>>>> example,
>>>>>> I
>>>>>> would unselect it for everything, regardless if that is the
>>>>>> control
>>>>>> or data channel).
>>>>>>
>>>>>> * What does my hardware support? I would want to choose AES
>>>>>> if my
>>>>>> hardware has acceleration for it.
>>>>>>
>>>>>> * Then I would sort them by most secure first (e.g. AES-256,
>>>>>> then
>>>>>> AES-192 and so on…)
>>>>>>
>>>>>> I can replicate that with only one multiple-select box that
>>>>>> simply
>>>>>> lists:
>>>>>>
>>>>>> * AES-256-GCM
>>>>>> * AES-256-CBC
>>>>>> * AES-128-GCM
>>>>>> * AES-128-CBC
>>>>>> * ChaCha20-Poly1305
>>>>>> * Blowfish
>>>>>> * ...
>>>>> This is a problen there is exactly the same, this are two
>>>>> directives. -
>>>>> -data-cipher does NCP whereby --data-ciphers-fallback
>>>>> substitutes -
>>>>> -
>>>>> cipher. If we leave --data-ciphers-fallback out and work only
>>>>> with
>>>>> --
>>>>> data-ciphers' clients which do not have this directive can not
>>>>> connect.
>>>> No no, we want to be compatible with older clients and there
>>>> should
>>>> be a dropdown that works just like the old cipher selection.
>>>>
>>>> It should be possible to turn it off though by adding a
>>>> “disabled”
>>>> option.
>>>>
>>>>> Also, client which are <=2.5.0 do not understands both
>>>>> directives
>>>>> and
>>>>> simply do not starts. To find a way out in this foggy world i
>>>>> delivered
>>>>> a checkbox while client creation so the user have the
>>>>> possiblity to
>>>>> bring the new directive into client.ovpn but also old clients
>>>>> can
>>>>> be
>>>>> changed/updated via the edit menu.
>>>> The clients should not have any cipher configuration now since
>>>> they
>>>> should automatically negotiate it - which is enabled by default.
>>>>
>>>>>> And a second one that has
>>>>>>
>>>>>> * SHA512
>>>>>> * SHA384
>>>>>> * SHA256
>>>>>> * …
>>>>> The HMACs can not be used for negotiation, this is only a
>>>>> single
>>>>> selection.
>>>> Well, that is bad. That means we still do not have full
>>>> negotiation?
>>>>
>>>>>> The code will then have to convert this into the fancy names
>>>>>> for
>>>>>> the
>>>>>> OpenVPN configuration file. But I suppose that should be easy
>>>>>> to
>>>>>> do.
>>>>>>
>>>>>> That way, the user can be certain that they have chosen the
>>>>>> right
>>>>>> thing for everything in one go.
>>>>>>
>>>>>>> So, could you please summarise for me what you want to
>>>>>>> achieve
>>>>>>> here?
>>>>>>> Hope i have it done above.
>>>>>> Thank you for that.
>>>>>>
>>>>>> I really appreciate all this time that you have invested in
>>>>>> this,
>>>>>> and
>>>>>> the code looks clean. I just think we have been on different
>>>>>> pages
>>>>>> about what we want it to look and feel like for the user.
>>>>> Thank you too. This one really needs a lot of time and testing
>>>>> around
>>>>> and also with help from Adolf it comes to this where it
>>>>> currently
>>>>> is.
>>>> Great teamwork!
>>>>
>>>>>>> Is this supposed to make OpenVPN more compatible, secure,
>>>>>>> or
>>>>>>> anything
>>>>>>> else?
>>>>>>> Yes both but also easier since the user do not need to do
>>>>>>> anything
>>>>>>> but
>>>>>>> he should become more security under the hood, the backward
>>>>>>> and
>>>>>>> the
>>>>>>> forward compatibility should be in a better standing than
>>>>>>> before
>>>>>>> and if
>>>>>>> someone wants to go into the depth, this is even also
>>>>>>> possible.
>>>>>> I think that you have implemented the “pro” version here. It
>>>>>> has
>>>>>> all
>>>>>> the buttons you need and uses all features of OpenVPN. But it
>>>>>> is
>>>>>> complicated. So maybe lets hide it from the user that there
>>>>>> is a
>>>>>> control and data channel. Does the user need to know about
>>>>>> this?
>>>>>> I do
>>>>>> not think so. It will work either way.
>>>>> No there is no must for the control-channel cipher selection...
>>>>> If
>>>>> one
>>>>> is in, it is sometimes nice to walk through all that ;-).
>>>>>
>>>>>>> Why do we not talk about this before things are being
>>>>>>> implemented,
>>>>>>> or
>>>>>>> did I just miss the discussion?
>>>>>>> Yes i think you missed some of that, hopefully i could
>>>>>>> remind
>>>>>>> you
>>>>>>> on
>>>>>>> some points.
>>>>>> This is good progress :)
>>>>> Happy to here this.
>>>> Okay, so what are the next steps now?
>>>>
>>>> -Michael
>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Erik
>>>>>
>>>>>> -Michael
>>>>>>
>>>>>>> -Michael
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Erik
>>>>>>>
>>>>>>>
>>>>>>>> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> just wanted to ask if there is still interest in this
>>>>>>>> patch
>>>>>>>> series ?
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Erik
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> <advanced_encryption_with_defaults.png><client_version.png><glo
>>>>> bal_
>>>>> settings.png><deprectaed_ciphers_warning.png>
>>>
>
Hi Adolf,
you can find it with better overview on Patchwork -->
https://patchwork.ipfire.org/patch/3712/
you can get there the specific diffs (button right side) and a list of
the series by clicking on "Related --> Show"
Best,
Erik
Am Freitag, dem 22.01.2021 um 23:08 +0100 schrieb Adolf Belka:
> Hi Erik,
>
> Where can I get hold of your latest version of ovpnmain.cgi
>
> Regards,
>
> Adolf.
>
> On 15/01/2021 05:56, ummeegge wrote:
> > Good morning Adolf,
> >
> > Am Donnerstag, dem 14.01.2021 um 19:50 +0100 schrieb Adolf Belka:
> > > Hi Erik,
> > >
> > > I have been keeping an eye on this OpenVPN thread anyway so I am
> > > willing to pick this up and see if I can help.
> > >
> > > As I am no where near as proficient in OpenVPN as you I may end
> > > up
> > > needing some guidance but am willing to give it a go and see how
> > > things go.
> > Will try to help you out if i can.
> >
> > > I have a couple of bugs with my name against them that I want to
> > > get
> > > moving first but then I will pick this topic up if you are okay
> > > with
> > > that.
> > As mentioned before, i am more then happy with this.
> >
> > > Regards,
> > >
> > > Adolf.
> > Best,
> >
> > Erik
> >
> > > On 13/01/2021 10:18, ummeegge wrote:
> > > > Hi Michael,
> > > > there is currently a lot of other real world stuff around me
> > > > and my
> > > > time is really less since things out there do not get easier
> > > > these
> > > > days, at least for me.
> > > >
> > > > If more time and motivation (which is most important) comes up
> > > > i
> > > > will
> > > > may go for another try to accomplish this topic with your
> > > > suggestions.
> > > > I would also finish this conversation here since it is hardly
> > > > comprehensible and a possible v3 would differs a lot.
> > > >
> > > > If someone else wanted to jump in this topic with solutions i
> > > > am
> > > > more
> > > > then happy with this.
> > > >
> > > > All the best,
> > > >
> > > > Erik
> > > >
> > > >
> > > > Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael
> > > > Tremer:
> > > > > Hi,
> > > > >
> > > > > > On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org>
> > > > > > wrote:
> > > > > >
> > > > > > Hi Michael,
> > > > > >
> > > > > > Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael
> > > > > > Tremer:
> > > > > > > Hi,
> > > > > > >
> > > > > > > > On 14 Dec 2020, at 16:12, ummeegge
> > > > > > > > <ummeegge@ipfire.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > Hi Michael,
> > > > > > > > thanks for looking into this.
> > > > > > > >
> > > > > > > > Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb
> > > > > > > > Michael
> > > > > > > > Tremer:
> > > > > > > > > Hello Erik,
> > > > > > > > >
> > > > > > > > > Yes, I am very much interested in this.
> > > > > > > > >
> > > > > > > > > And I have spent pretty much an hour to make sense
> > > > > > > > > out of
> > > > > > > > > all
> > > > > > > > > of
> > > > > > > > > this, and unfortunately have to report that I failed.
> > > > > > > > that´s not good to hear. OK, let me explain... I tried
> > > > > > > > to
> > > > > > > > come
> > > > > > > > up
> > > > > > > > with
> > > > > > > > a solution where we already have spoken more times
> > > > > > > > about in
> > > > > > > > the
> > > > > > > > past, i
> > > > > > > > tried to follow up your suggestions, the latest about
> > > > > > > > that
> > > > > > > > topic
> > > > > > > > was
> > > > > > > > here -->
> > > > > > > >
> > > > > > > > https://lists.ipfire.org/pipermail/development/2020-October/008441.html
> > > > > > > > in Oktober to bring up "a select box where multiple
> > > > > > > > algorithms
> > > > > > > > can
> > > > > > > > be
> > > > > > > > chosen (like in IPsec)". Since --cipher is deprectaed
> > > > > > > > and
> > > > > > > > will
> > > > > > > > be
> > > > > > > > replaced by --data-ciphers which is a >=2.5.0 option we
> > > > > > > > need
> > > > > > > > another
> > > > > > > > selection field for the --data-ciphers-fallback which
> > > > > > > > is a
> > > > > > > > replacement
> > > > > > > > for --cipher and the server uses this directive to talk
> > > > > > > > also to
> > > > > > > > client
> > > > > > > > which are <2.5.0 .
> > > > > > > Yes, the ciphers. But as far as I understand this, you
> > > > > > > are
> > > > > > > offering
> > > > > > > to select the whole cipher suite. That is something
> > > > > > > different.
> > > > > > >
> > > > > > > And you are offering different options for TLSv1.3 and
> > > > > > > lower,
> > > > > > > which
> > > > > > > we do not do in IPsec either. You have one selection for
> > > > > > > both
> > > > > > > IKEv1
> > > > > > > and IKEv2.
> > > > > > Yes, i thougt it might be an idea for the advanced section
> > > > > > be
> > > > > > it is
> > > > > > not
> > > > > > really needed since OpenVPN uses his own choice for the
> > > > > > control-
> > > > > > chanel
> > > > > > if nothing has been configured.
> > > > > That probably isn’t good then. The UI should at least show
> > > > > the
> > > > > user
> > > > > what is being used.
> > > > >
> > > > > If we want OpenVPN to chose what is best, there should be
> > > > > some
> > > > > option
> > > > > that says “automatic” at least.
> > > > >
> > > > > > > > OpenVPN presses to use cipher negotiation which we have
> > > > > > > > avoid
> > > > > > > > since
> > > > > > > > the
> > > > > > > > release of 2.4 with --ncp-disable, this option is no
> > > > > > > > also
> > > > > > > > deprecated so
> > > > > > > > we need to take action on this.
> > > > > > > I will skip my moan about introducing something and then
> > > > > > > deprecating
> > > > > > > it shortly after…
> > > > > > It was good that we did not act at that time.
> > > > > In hindsight yes. But we didn’t know back then that things
> > > > > would
> > > > > change again, and we do not know now if things will change
> > > > > another
> > > > > time in the near future.
> > > > >
> > > > > So, we have to do “best-effort” here.
> > > > >
> > > > > > > I agree that we need to act.
> > > > > > >
> > > > > > > > We need to have then two new options, two seletion
> > > > > > > > boxes
> > > > > > > > which
> > > > > > > > are
> > > > > > > > odd
> > > > > > > > to see in the global section. I tried it in the
> > > > > > > > advanced
> > > > > > > > server
> > > > > > > > section
> > > > > > > > too and it looks even more confusing with all the other
> > > > > > > > already
> > > > > > > > existing options, nothing i wanted to do. So i thought
> > > > > > > > your
> > > > > > > > above
> > > > > > > > linked suggestions are pretty straight forward and the
> > > > > > > > best
> > > > > > > > solution to
> > > > > > > > build an own crypto section which do have already
> > > > > > > > defaults,
> > > > > > > > nobody
> > > > > > > > needs to do there anyting, the global section has been
> > > > > > > > cleaned
> > > > > > > > up
> > > > > > > > and
> > > > > > > > it should be even easier for everone to overview.
> > > > > > > We have touched this topic multiple times. And I remember
> > > > > > > the
> > > > > > > last
> > > > > > > conclusion as follows:
> > > > > > >
> > > > > > > The average user does not have to touch the advanced
> > > > > > > options.
> > > > > > > They
> > > > > > > have to put in their subnet, select a port and protocol
> > > > > > > maybe
> > > > > > > and
> > > > > > > that is about it. They do not need to think about what
> > > > > > > cipher
> > > > > > > to
> > > > > > > use,
> > > > > > > because we would have selected a reasonable default. If
> > > > > > > they
> > > > > > > want
> > > > > > > to
> > > > > > > change something (because of hardware requirements, etc.)
> > > > > > > they
> > > > > > > can do
> > > > > > > that on the advanced page.
> > > > > > This is exactly what i did.
> > > > > Okay. So why is there an extra page then, and not a section
> > > > > on
> > > > > the
> > > > > advanced page?
> > > > >
> > > > > I like the now cleaner look of the main page which only has
> > > > > the
> > > > > bare
> > > > > necessities.
> > > > >
> > > > > > > I agree that this is all not idea, but adding a third
> > > > > > > page to
> > > > > > > this
> > > > > > > all makes it rather more confusing than less.
> > > > > > Not sure if i understand you here right. You mentioned
> > > > > > above
> > > > > > the
> > > > > > advanced page but i understand you here that you do not
> > > > > > want a
> > > > > > third
> > > > > > one ?
> > > > > There is the main page, where things can be configured
> > > > > (subnet,
> > > > > port,
> > > > > protocol, …), then advanced options, and now the cryptography
> > > > > options.
> > > > >
> > > > > They are all the same - in that they directly change the
> > > > > OpenVPN
> > > > > configuration - and we only wanted to split them by two
> > > > > things:
> > > > >
> > > > > a) Is it likely that the user will change them?
> > > > >
> > > > > b) Or is this an option that the average user should not
> > > > > touch.
> > > > >
> > > > > The advanced settings page can be as long as we like. It does
> > > > > not
> > > > > have to be pretty.
> > > > >
> > > > > > > > It made for me no sense to leave parts of the crypto
> > > > > > > > (TLS-
> > > > > > > > auth
> > > > > > > > and
> > > > > > > > HMACs) in the global section, especially because there
> > > > > > > > are
> > > > > > > > also
> > > > > > > > even
> > > > > > > > more algorithms, but also new options for the TLS
> > > > > > > > authentication
> > > > > > > > which
> > > > > > > > i have all integrated so i moved them also into that
> > > > > > > > place
> > > > > > > > (patch
> > > > > > > > 6/7
> > > > > > > > and 7/7).
> > > > > > > I remember that we have agreed to move the existing
> > > > > > > crypto
> > > > > > > options to
> > > > > > > the advanced page.
> > > > > > Yes, me too and i thought you meant an dedicated crypto
> > > > > > page
> > > > > > like
> > > > > > it is
> > > > > > for IPSec but you meant the advanced server section ? If
> > > > > > yes we
> > > > > > would
> > > > > > mix then routing logging, DNS/WINS options with MTU related
> > > > > > configure
> > > > > > options. Also, the crypto section can have also some
> > > > > > additionals
> > > > > > like
> > > > > > key lieftime, tls-version (if someone wants only TLSv1.3)
> > > > > > and
> > > > > > may
> > > > > > some
> > > > > > other upcoming stuff.
> > > > > That can all go to the advanced page in my opinion.
> > > > >
> > > > > > > > The control-channel cipher selection (patch 5/7) is new
> > > > > > > > and
> > > > > > > > should
> > > > > > > > be
> > > > > > > > really a part for the advanced ones, therefor no
> > > > > > > > defaults
> > > > > > > > has
> > > > > > > > been
> > > > > > > > set,
> > > > > > > > it simply won´t appear if nothing has been configured.
> > > > > > > What is the benefit of choosing a different cipher for
> > > > > > > the
> > > > > > > control
> > > > > > > channel?
> > > > > > This one is not really needed, as mentioned above OpenVPN
> > > > > > makes
> > > > > > then
> > > > > > this desicion by it´s own.
> > > > > Okay, but why do we have it then? :)
> > > > >
> > > > > > > > I have the problem that I cannot get on top of these
> > > > > > > > things.
> > > > > > > > You
> > > > > > > > are
> > > > > > > > submitting *massive* patchsets, in this case I even
> > > > > > > > believe
> > > > > > > > that
> > > > > > > > the
> > > > > > > > whole things has been submitted a second time, although
> > > > > > > > I
> > > > > > > > do
> > > > > > > > not
> > > > > > > > know
> > > > > > > > if there are any changes.
> > > > > > > > Yes there are. Old and deprecated ciphers will now be
> > > > > > > > detected
> > > > > > > > and
> > > > > > > > a
> > > > > > > > warning comes up in the global section to change them
> > > > > > > > as
> > > > > > > > soon
> > > > > > > > as
> > > > > > > > possible (patch 3/7), also all languages has been
> > > > > > > > translated
> > > > > > > > and
> > > > > > > > has
> > > > > > > > been included.
> > > > > > > > Also i wanted to split it in more specific topics for
> > > > > > > > better
> > > > > > > > overview
> > > > > > > > but it seems that i have been failed.
> > > > > > > I do not think that you have failed. I just think that it
> > > > > > > is
> > > > > > > not
> > > > > > > clear what the patch intended to do. So I cannot really
> > > > > > > look
> > > > > > > at
> > > > > > > it
> > > > > > > and verify if the code actually does what you want it to
> > > > > > > do.
> > > > > > >
> > > > > > > Could it have been split into even smaller changes? Yes,
> > > > > > > would
> > > > > > > that
> > > > > > > have helped? Maybe. But I do not think that we should
> > > > > > > waste
> > > > > > > too
> > > > > > > much
> > > > > > > time to reformat the patches. I want the changes to be
> > > > > > > ready
> > > > > > > to
> > > > > > > be
> > > > > > > merged as soon as possible.
> > > > > > OK. Let´s go through this then. I have attached also
> > > > > > screenshots
> > > > > > for
> > > > > > all changes for a better first impression.
> > > > > That was very helpful to me.
> > > > >
> > > > > > > > I could not even find out *what* you are actually
> > > > > > > > trying to
> > > > > > > > do.
> > > > > > > > There
> > > > > > > > are more and more buttons being added and I have not
> > > > > > > > the
> > > > > > > > slightest
> > > > > > > > idea
> > > > > > > > what I am supposed to do with them. I have given my
> > > > > > > > thoughts
> > > > > > > > about
> > > > > > > > the
> > > > > > > > cipher selection and I felt that I have not been heard.
> > > > > > > > One intention was that you do not need anything to do
> > > > > > > > except
> > > > > > > > you
> > > > > > > > want
> > > > > > > > to do some advanced crypto stuff. The rest should have
> > > > > > > > already
> > > > > > > > been
> > > > > > > > made...
> > > > > > > >
> > > > > > > >
> > > > > > > > I fear that this is all way too complicated. I cannot
> > > > > > > > review
> > > > > > > > what I
> > > > > > > > do
> > > > > > > > not even understand what the desired outcome is. And
> > > > > > > > failing to
> > > > > > > > understand that either means that it is either way too
> > > > > > > > complicated
> > > > > > > > or I
> > > > > > > > have not read enough anywhere about all of this.
> > > > > > > > Please check out the above linked topic where you have
> > > > > > > > wrote
> > > > > > > > suggestions that i simply tried to achieve but again,
> > > > > > > > it
> > > > > > > > seems
> > > > > > > > that
> > > > > > > > i
> > > > > > > > was not successfull with this...
> > > > > > > So, maybe help me to understand why the user would want
> > > > > > > to
> > > > > > > use
> > > > > > > different ciphers for the control channel and for
> > > > > > > TLSv1.3/2.
> > > > > > This is not needed and i can easily let it out but
> > > > > > mentioned
> > > > > > beneath
> > > > > > OpenVPN decided to give TLSv1.2 another directive then
> > > > > > TLSv1.3
> > > > > > therefor
> > > > > > the two boxes.
> > > > > Yes, I think choosing this once is enough.
> > > > >
> > > > > > > I consider my ciphers as follows:
> > > > > > >
> > > > > > > * Which algorithms do I trust? If I do not trust AES for
> > > > > > > example,
> > > > > > > I
> > > > > > > would unselect it for everything, regardless if that is
> > > > > > > the
> > > > > > > control
> > > > > > > or data channel).
> > > > > > >
> > > > > > > * What does my hardware support? I would want to choose
> > > > > > > AES
> > > > > > > if my
> > > > > > > hardware has acceleration for it.
> > > > > > >
> > > > > > > * Then I would sort them by most secure first (e.g. AES-
> > > > > > > 256,
> > > > > > > then
> > > > > > > AES-192 and so on…)
> > > > > > >
> > > > > > > I can replicate that with only one multiple-select box
> > > > > > > that
> > > > > > > simply
> > > > > > > lists:
> > > > > > >
> > > > > > > * AES-256-GCM
> > > > > > > * AES-256-CBC
> > > > > > > * AES-128-GCM
> > > > > > > * AES-128-CBC
> > > > > > > * ChaCha20-Poly1305
> > > > > > > * Blowfish
> > > > > > > * ...
> > > > > > This is a problen there is exactly the same, this are two
> > > > > > directives. -
> > > > > > -data-cipher does NCP whereby --data-ciphers-fallback
> > > > > > substitutes -
> > > > > > -
> > > > > > cipher. If we leave --data-ciphers-fallback out and work
> > > > > > only
> > > > > > with
> > > > > > --
> > > > > > data-ciphers' clients which do not have this directive can
> > > > > > not
> > > > > > connect.
> > > > > No no, we want to be compatible with older clients and there
> > > > > should
> > > > > be a dropdown that works just like the old cipher selection.
> > > > >
> > > > > It should be possible to turn it off though by adding a
> > > > > “disabled”
> > > > > option.
> > > > >
> > > > > > Also, client which are <=2.5.0 do not understands both
> > > > > > directives
> > > > > > and
> > > > > > simply do not starts. To find a way out in this foggy world
> > > > > > i
> > > > > > delivered
> > > > > > a checkbox while client creation so the user have the
> > > > > > possiblity to
> > > > > > bring the new directive into client.ovpn but also old
> > > > > > clients
> > > > > > can
> > > > > > be
> > > > > > changed/updated via the edit menu.
> > > > > The clients should not have any cipher configuration now
> > > > > since
> > > > > they
> > > > > should automatically negotiate it - which is enabled by
> > > > > default.
> > > > >
> > > > > > > And a second one that has
> > > > > > >
> > > > > > > * SHA512
> > > > > > > * SHA384
> > > > > > > * SHA256
> > > > > > > * …
> > > > > > The HMACs can not be used for negotiation, this is only a
> > > > > > single
> > > > > > selection.
> > > > > Well, that is bad. That means we still do not have full
> > > > > negotiation?
> > > > >
> > > > > > > The code will then have to convert this into the fancy
> > > > > > > names
> > > > > > > for
> > > > > > > the
> > > > > > > OpenVPN configuration file. But I suppose that should be
> > > > > > > easy
> > > > > > > to
> > > > > > > do.
> > > > > > >
> > > > > > > That way, the user can be certain that they have chosen
> > > > > > > the
> > > > > > > right
> > > > > > > thing for everything in one go.
> > > > > > >
> > > > > > > > So, could you please summarise for me what you want to
> > > > > > > > achieve
> > > > > > > > here?
> > > > > > > > Hope i have it done above.
> > > > > > > Thank you for that.
> > > > > > >
> > > > > > > I really appreciate all this time that you have invested
> > > > > > > in
> > > > > > > this,
> > > > > > > and
> > > > > > > the code looks clean. I just think we have been on
> > > > > > > different
> > > > > > > pages
> > > > > > > about what we want it to look and feel like for the user.
> > > > > > Thank you too. This one really needs a lot of time and
> > > > > > testing
> > > > > > around
> > > > > > and also with help from Adolf it comes to this where it
> > > > > > currently
> > > > > > is.
> > > > > Great teamwork!
> > > > >
> > > > > > > > Is this supposed to make OpenVPN more compatible,
> > > > > > > > secure,
> > > > > > > > or
> > > > > > > > anything
> > > > > > > > else?
> > > > > > > > Yes both but also easier since the user do not need to
> > > > > > > > do
> > > > > > > > anything
> > > > > > > > but
> > > > > > > > he should become more security under the hood, the
> > > > > > > > backward
> > > > > > > > and
> > > > > > > > the
> > > > > > > > forward compatibility should be in a better standing
> > > > > > > > than
> > > > > > > > before
> > > > > > > > and if
> > > > > > > > someone wants to go into the depth, this is even also
> > > > > > > > possible.
> > > > > > > I think that you have implemented the “pro” version here.
> > > > > > > It
> > > > > > > has
> > > > > > > all
> > > > > > > the buttons you need and uses all features of OpenVPN.
> > > > > > > But it
> > > > > > > is
> > > > > > > complicated. So maybe lets hide it from the user that
> > > > > > > there
> > > > > > > is a
> > > > > > > control and data channel. Does the user need to know
> > > > > > > about
> > > > > > > this?
> > > > > > > I do
> > > > > > > not think so. It will work either way.
> > > > > > No there is no must for the control-channel cipher
> > > > > > selection...
> > > > > > If
> > > > > > one
> > > > > > is in, it is sometimes nice to walk through all that ;-).
> > > > > >
> > > > > > > > Why do we not talk about this before things are being
> > > > > > > > implemented,
> > > > > > > > or
> > > > > > > > did I just miss the discussion?
> > > > > > > > Yes i think you missed some of that, hopefully i could
> > > > > > > > remind
> > > > > > > > you
> > > > > > > > on
> > > > > > > > some points.
> > > > > > > This is good progress :)
> > > > > > Happy to here this.
> > > > > Okay, so what are the next steps now?
> > > > >
> > > > > -Michael
> > > > >
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Erik
> > > > > >
> > > > > > > -Michael
> > > > > > >
> > > > > > > > -Michael
> > > > > > > >
> > > > > > > > Best,
> > > > > > > >
> > > > > > > > Erik
> > > > > > > >
> > > > > > > >
> > > > > > > > > On 14 Dec 2020, at 14:03, ummeegge
> > > > > > > > > <ummeegge@ipfire.org>
> > > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > Hi all,
> > > > > > > > > just wanted to ask if there is still interest in this
> > > > > > > > > patch
> > > > > > > > > series ?
> > > > > > > > >
> > > > > > > > > Best,
> > > > > > > > >
> > > > > > > > > Erik
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > <advanced_encryption_with_defaults.png><client_version.png>
> > > > > > <glo
> > > > > > bal_
> > > > > > settings.png><deprectaed_ciphers_warning.png>
> > > >
> >
Hi All,
After some deliberation, I have to say that I will not be able to pick up this OpenVPN topic for the new encryption section coming with OpenVPN 2.5.0
The basis for this decision is that as I have been reviewing ovpnmain.cgi and the changes proposed by Erik, I have come to realise that my capabilities to understand what is going on in the code are just too limited. I have not been able to understand the structure of the existing code well enough to even start to think about proposing changes to the code that would do what is needed but also not have knock on effects.
I am very sorry to be communicating this and I have thought hard about it for some time but even leaving some gaps and then going back to the code after a while has resulted in me continuing to find new code that I didn't understand what it was doing rather than things becoming clearer and eventually I came to this conclusion.
I will still continue to help with testing and to provide update patches for addons and core programs and also work on the simpler bugs where my knowledge is sufficient.
Regards,
Adolf.
On 15/01/2021 05:56, ummeegge wrote:
> Good morning Adolf,
>
> Am Donnerstag, dem 14.01.2021 um 19:50 +0100 schrieb Adolf Belka:
>> Hi Erik,
>>
>> I have been keeping an eye on this OpenVPN thread anyway so I am
>> willing to pick this up and see if I can help.
>>
>> As I am no where near as proficient in OpenVPN as you I may end up
>> needing some guidance but am willing to give it a go and see how
>> things go.
> Will try to help you out if i can.
>
>> I have a couple of bugs with my name against them that I want to get
>> moving first but then I will pick this topic up if you are okay with
>> that.
> As mentioned before, i am more then happy with this.
>
>> Regards,
>>
>> Adolf.
> Best,
>
> Erik
>
>> On 13/01/2021 10:18, ummeegge wrote:
>>> Hi Michael,
>>> there is currently a lot of other real world stuff around me and my
>>> time is really less since things out there do not get easier these
>>> days, at least for me.
>>>
>>> If more time and motivation (which is most important) comes up i
>>> will
>>> may go for another try to accomplish this topic with your
>>> suggestions.
>>> I would also finish this conversation here since it is hardly
>>> comprehensible and a possible v3 would differs a lot.
>>>
>>> If someone else wanted to jump in this topic with solutions i am
>>> more
>>> then happy with this.
>>>
>>> All the best,
>>>
>>> Erik
>>>
>>>
>>> Am Dienstag, dem 29.12.2020 um 11:44 +0100 schrieb Michael Tremer:
>>>> Hi,
>>>>
>>>>> On 16 Dec 2020, at 17:30, ummeegge <ummeegge@ipfire.org> wrote:
>>>>>
>>>>> Hi Michael,
>>>>>
>>>>> Am Dienstag, dem 15.12.2020 um 12:58 +0100 schrieb Michael
>>>>> Tremer:
>>>>>> Hi,
>>>>>>
>>>>>>> On 14 Dec 2020, at 16:12, ummeegge <ummeegge@ipfire.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Michael,
>>>>>>> thanks for looking into this.
>>>>>>>
>>>>>>> Am Montag, dem 14.12.2020 um 14:43 +0100 schrieb Michael
>>>>>>> Tremer:
>>>>>>>> Hello Erik,
>>>>>>>>
>>>>>>>> Yes, I am very much interested in this.
>>>>>>>>
>>>>>>>> And I have spent pretty much an hour to make sense out of
>>>>>>>> all
>>>>>>>> of
>>>>>>>> this, and unfortunately have to report that I failed.
>>>>>>> that´s not good to hear. OK, let me explain... I tried to
>>>>>>> come
>>>>>>> up
>>>>>>> with
>>>>>>> a solution where we already have spoken more times about in
>>>>>>> the
>>>>>>> past, i
>>>>>>> tried to follow up your suggestions, the latest about that
>>>>>>> topic
>>>>>>> was
>>>>>>> here -->
>>>>>>>
>>>>>>> https://lists.ipfire.org/pipermail/development/2020-October/008441.html
>>>>>>> in Oktober to bring up "a select box where multiple
>>>>>>> algorithms
>>>>>>> can
>>>>>>> be
>>>>>>> chosen (like in IPsec)". Since --cipher is deprectaed and
>>>>>>> will
>>>>>>> be
>>>>>>> replaced by --data-ciphers which is a >=2.5.0 option we
>>>>>>> need
>>>>>>> another
>>>>>>> selection field for the --data-ciphers-fallback which is a
>>>>>>> replacement
>>>>>>> for --cipher and the server uses this directive to talk
>>>>>>> also to
>>>>>>> client
>>>>>>> which are <2.5.0 .
>>>>>> Yes, the ciphers. But as far as I understand this, you are
>>>>>> offering
>>>>>> to select the whole cipher suite. That is something
>>>>>> different.
>>>>>>
>>>>>> And you are offering different options for TLSv1.3 and lower,
>>>>>> which
>>>>>> we do not do in IPsec either. You have one selection for both
>>>>>> IKEv1
>>>>>> and IKEv2.
>>>>> Yes, i thougt it might be an idea for the advanced section be
>>>>> it is
>>>>> not
>>>>> really needed since OpenVPN uses his own choice for the
>>>>> control-
>>>>> chanel
>>>>> if nothing has been configured.
>>>> That probably isn’t good then. The UI should at least show the
>>>> user
>>>> what is being used.
>>>>
>>>> If we want OpenVPN to chose what is best, there should be some
>>>> option
>>>> that says “automatic” at least.
>>>>
>>>>>>> OpenVPN presses to use cipher negotiation which we have
>>>>>>> avoid
>>>>>>> since
>>>>>>> the
>>>>>>> release of 2.4 with --ncp-disable, this option is no also
>>>>>>> deprecated so
>>>>>>> we need to take action on this.
>>>>>> I will skip my moan about introducing something and then
>>>>>> deprecating
>>>>>> it shortly after…
>>>>> It was good that we did not act at that time.
>>>> In hindsight yes. But we didn’t know back then that things would
>>>> change again, and we do not know now if things will change
>>>> another
>>>> time in the near future.
>>>>
>>>> So, we have to do “best-effort” here.
>>>>
>>>>>> I agree that we need to act.
>>>>>>
>>>>>>> We need to have then two new options, two seletion boxes
>>>>>>> which
>>>>>>> are
>>>>>>> odd
>>>>>>> to see in the global section. I tried it in the advanced
>>>>>>> server
>>>>>>> section
>>>>>>> too and it looks even more confusing with all the other
>>>>>>> already
>>>>>>> existing options, nothing i wanted to do. So i thought your
>>>>>>> above
>>>>>>> linked suggestions are pretty straight forward and the best
>>>>>>> solution to
>>>>>>> build an own crypto section which do have already defaults,
>>>>>>> nobody
>>>>>>> needs to do there anyting, the global section has been
>>>>>>> cleaned
>>>>>>> up
>>>>>>> and
>>>>>>> it should be even easier for everone to overview.
>>>>>> We have touched this topic multiple times. And I remember the
>>>>>> last
>>>>>> conclusion as follows:
>>>>>>
>>>>>> The average user does not have to touch the advanced options.
>>>>>> They
>>>>>> have to put in their subnet, select a port and protocol maybe
>>>>>> and
>>>>>> that is about it. They do not need to think about what cipher
>>>>>> to
>>>>>> use,
>>>>>> because we would have selected a reasonable default. If they
>>>>>> want
>>>>>> to
>>>>>> change something (because of hardware requirements, etc.)
>>>>>> they
>>>>>> can do
>>>>>> that on the advanced page.
>>>>> This is exactly what i did.
>>>> Okay. So why is there an extra page then, and not a section on
>>>> the
>>>> advanced page?
>>>>
>>>> I like the now cleaner look of the main page which only has the
>>>> bare
>>>> necessities.
>>>>
>>>>>> I agree that this is all not idea, but adding a third page to
>>>>>> this
>>>>>> all makes it rather more confusing than less.
>>>>> Not sure if i understand you here right. You mentioned above
>>>>> the
>>>>> advanced page but i understand you here that you do not want a
>>>>> third
>>>>> one ?
>>>> There is the main page, where things can be configured (subnet,
>>>> port,
>>>> protocol, …), then advanced options, and now the cryptography
>>>> options.
>>>>
>>>> They are all the same - in that they directly change the OpenVPN
>>>> configuration - and we only wanted to split them by two things:
>>>>
>>>> a) Is it likely that the user will change them?
>>>>
>>>> b) Or is this an option that the average user should not touch.
>>>>
>>>> The advanced settings page can be as long as we like. It does not
>>>> have to be pretty.
>>>>
>>>>>>> It made for me no sense to leave parts of the crypto (TLS-
>>>>>>> auth
>>>>>>> and
>>>>>>> HMACs) in the global section, especially because there are
>>>>>>> also
>>>>>>> even
>>>>>>> more algorithms, but also new options for the TLS
>>>>>>> authentication
>>>>>>> which
>>>>>>> i have all integrated so i moved them also into that place
>>>>>>> (patch
>>>>>>> 6/7
>>>>>>> and 7/7).
>>>>>> I remember that we have agreed to move the existing crypto
>>>>>> options to
>>>>>> the advanced page.
>>>>> Yes, me too and i thought you meant an dedicated crypto page
>>>>> like
>>>>> it is
>>>>> for IPSec but you meant the advanced server section ? If yes we
>>>>> would
>>>>> mix then routing logging, DNS/WINS options with MTU related
>>>>> configure
>>>>> options. Also, the crypto section can have also some
>>>>> additionals
>>>>> like
>>>>> key lieftime, tls-version (if someone wants only TLSv1.3) and
>>>>> may
>>>>> some
>>>>> other upcoming stuff.
>>>> That can all go to the advanced page in my opinion.
>>>>
>>>>>>> The control-channel cipher selection (patch 5/7) is new and
>>>>>>> should
>>>>>>> be
>>>>>>> really a part for the advanced ones, therefor no defaults
>>>>>>> has
>>>>>>> been
>>>>>>> set,
>>>>>>> it simply won´t appear if nothing has been configured.
>>>>>> What is the benefit of choosing a different cipher for the
>>>>>> control
>>>>>> channel?
>>>>> This one is not really needed, as mentioned above OpenVPN makes
>>>>> then
>>>>> this desicion by it´s own.
>>>> Okay, but why do we have it then? :)
>>>>
>>>>>>> I have the problem that I cannot get on top of these
>>>>>>> things.
>>>>>>> You
>>>>>>> are
>>>>>>> submitting *massive* patchsets, in this case I even believe
>>>>>>> that
>>>>>>> the
>>>>>>> whole things has been submitted a second time, although I
>>>>>>> do
>>>>>>> not
>>>>>>> know
>>>>>>> if there are any changes.
>>>>>>> Yes there are. Old and deprecated ciphers will now be
>>>>>>> detected
>>>>>>> and
>>>>>>> a
>>>>>>> warning comes up in the global section to change them as
>>>>>>> soon
>>>>>>> as
>>>>>>> possible (patch 3/7), also all languages has been
>>>>>>> translated
>>>>>>> and
>>>>>>> has
>>>>>>> been included.
>>>>>>> Also i wanted to split it in more specific topics for
>>>>>>> better
>>>>>>> overview
>>>>>>> but it seems that i have been failed.
>>>>>> I do not think that you have failed. I just think that it is
>>>>>> not
>>>>>> clear what the patch intended to do. So I cannot really look
>>>>>> at
>>>>>> it
>>>>>> and verify if the code actually does what you want it to do.
>>>>>>
>>>>>> Could it have been split into even smaller changes? Yes,
>>>>>> would
>>>>>> that
>>>>>> have helped? Maybe. But I do not think that we should waste
>>>>>> too
>>>>>> much
>>>>>> time to reformat the patches. I want the changes to be ready
>>>>>> to
>>>>>> be
>>>>>> merged as soon as possible.
>>>>> OK. Let´s go through this then. I have attached also
>>>>> screenshots
>>>>> for
>>>>> all changes for a better first impression.
>>>> That was very helpful to me.
>>>>
>>>>>>> I could not even find out *what* you are actually trying to
>>>>>>> do.
>>>>>>> There
>>>>>>> are more and more buttons being added and I have not the
>>>>>>> slightest
>>>>>>> idea
>>>>>>> what I am supposed to do with them. I have given my
>>>>>>> thoughts
>>>>>>> about
>>>>>>> the
>>>>>>> cipher selection and I felt that I have not been heard.
>>>>>>> One intention was that you do not need anything to do
>>>>>>> except
>>>>>>> you
>>>>>>> want
>>>>>>> to do some advanced crypto stuff. The rest should have
>>>>>>> already
>>>>>>> been
>>>>>>> made...
>>>>>>>
>>>>>>>
>>>>>>> I fear that this is all way too complicated. I cannot
>>>>>>> review
>>>>>>> what I
>>>>>>> do
>>>>>>> not even understand what the desired outcome is. And
>>>>>>> failing to
>>>>>>> understand that either means that it is either way too
>>>>>>> complicated
>>>>>>> or I
>>>>>>> have not read enough anywhere about all of this.
>>>>>>> Please check out the above linked topic where you have
>>>>>>> wrote
>>>>>>> suggestions that i simply tried to achieve but again, it
>>>>>>> seems
>>>>>>> that
>>>>>>> i
>>>>>>> was not successfull with this...
>>>>>> So, maybe help me to understand why the user would want to
>>>>>> use
>>>>>> different ciphers for the control channel and for TLSv1.3/2.
>>>>> This is not needed and i can easily let it out but mentioned
>>>>> beneath
>>>>> OpenVPN decided to give TLSv1.2 another directive then TLSv1.3
>>>>> therefor
>>>>> the two boxes.
>>>> Yes, I think choosing this once is enough.
>>>>
>>>>>> I consider my ciphers as follows:
>>>>>>
>>>>>> * Which algorithms do I trust? If I do not trust AES for
>>>>>> example,
>>>>>> I
>>>>>> would unselect it for everything, regardless if that is the
>>>>>> control
>>>>>> or data channel).
>>>>>>
>>>>>> * What does my hardware support? I would want to choose AES
>>>>>> if my
>>>>>> hardware has acceleration for it.
>>>>>>
>>>>>> * Then I would sort them by most secure first (e.g. AES-256,
>>>>>> then
>>>>>> AES-192 and so on…)
>>>>>>
>>>>>> I can replicate that with only one multiple-select box that
>>>>>> simply
>>>>>> lists:
>>>>>>
>>>>>> * AES-256-GCM
>>>>>> * AES-256-CBC
>>>>>> * AES-128-GCM
>>>>>> * AES-128-CBC
>>>>>> * ChaCha20-Poly1305
>>>>>> * Blowfish
>>>>>> * ...
>>>>> This is a problen there is exactly the same, this are two
>>>>> directives. -
>>>>> -data-cipher does NCP whereby --data-ciphers-fallback
>>>>> substitutes -
>>>>> -
>>>>> cipher. If we leave --data-ciphers-fallback out and work only
>>>>> with
>>>>> --
>>>>> data-ciphers' clients which do not have this directive can not
>>>>> connect.
>>>> No no, we want to be compatible with older clients and there
>>>> should
>>>> be a dropdown that works just like the old cipher selection.
>>>>
>>>> It should be possible to turn it off though by adding a
>>>> “disabled”
>>>> option.
>>>>
>>>>> Also, client which are <=2.5.0 do not understands both
>>>>> directives
>>>>> and
>>>>> simply do not starts. To find a way out in this foggy world i
>>>>> delivered
>>>>> a checkbox while client creation so the user have the
>>>>> possiblity to
>>>>> bring the new directive into client.ovpn but also old clients
>>>>> can
>>>>> be
>>>>> changed/updated via the edit menu.
>>>> The clients should not have any cipher configuration now since
>>>> they
>>>> should automatically negotiate it - which is enabled by default.
>>>>
>>>>>> And a second one that has
>>>>>>
>>>>>> * SHA512
>>>>>> * SHA384
>>>>>> * SHA256
>>>>>> * …
>>>>> The HMACs can not be used for negotiation, this is only a
>>>>> single
>>>>> selection.
>>>> Well, that is bad. That means we still do not have full
>>>> negotiation?
>>>>
>>>>>> The code will then have to convert this into the fancy names
>>>>>> for
>>>>>> the
>>>>>> OpenVPN configuration file. But I suppose that should be easy
>>>>>> to
>>>>>> do.
>>>>>>
>>>>>> That way, the user can be certain that they have chosen the
>>>>>> right
>>>>>> thing for everything in one go.
>>>>>>
>>>>>>> So, could you please summarise for me what you want to
>>>>>>> achieve
>>>>>>> here?
>>>>>>> Hope i have it done above.
>>>>>> Thank you for that.
>>>>>>
>>>>>> I really appreciate all this time that you have invested in
>>>>>> this,
>>>>>> and
>>>>>> the code looks clean. I just think we have been on different
>>>>>> pages
>>>>>> about what we want it to look and feel like for the user.
>>>>> Thank you too. This one really needs a lot of time and testing
>>>>> around
>>>>> and also with help from Adolf it comes to this where it
>>>>> currently
>>>>> is.
>>>> Great teamwork!
>>>>
>>>>>>> Is this supposed to make OpenVPN more compatible, secure,
>>>>>>> or
>>>>>>> anything
>>>>>>> else?
>>>>>>> Yes both but also easier since the user do not need to do
>>>>>>> anything
>>>>>>> but
>>>>>>> he should become more security under the hood, the backward
>>>>>>> and
>>>>>>> the
>>>>>>> forward compatibility should be in a better standing than
>>>>>>> before
>>>>>>> and if
>>>>>>> someone wants to go into the depth, this is even also
>>>>>>> possible.
>>>>>> I think that you have implemented the “pro” version here. It
>>>>>> has
>>>>>> all
>>>>>> the buttons you need and uses all features of OpenVPN. But it
>>>>>> is
>>>>>> complicated. So maybe lets hide it from the user that there
>>>>>> is a
>>>>>> control and data channel. Does the user need to know about
>>>>>> this?
>>>>>> I do
>>>>>> not think so. It will work either way.
>>>>> No there is no must for the control-channel cipher selection...
>>>>> If
>>>>> one
>>>>> is in, it is sometimes nice to walk through all that ;-).
>>>>>
>>>>>>> Why do we not talk about this before things are being
>>>>>>> implemented,
>>>>>>> or
>>>>>>> did I just miss the discussion?
>>>>>>> Yes i think you missed some of that, hopefully i could
>>>>>>> remind
>>>>>>> you
>>>>>>> on
>>>>>>> some points.
>>>>>> This is good progress :)
>>>>> Happy to here this.
>>>> Okay, so what are the next steps now?
>>>>
>>>> -Michael
>>>>
>>>>>
>>>>> Best,
>>>>>
>>>>> Erik
>>>>>
>>>>>> -Michael
>>>>>>
>>>>>>> -Michael
>>>>>>>
>>>>>>> Best,
>>>>>>>
>>>>>>> Erik
>>>>>>>
>>>>>>>
>>>>>>>> On 14 Dec 2020, at 14:03, ummeegge <ummeegge@ipfire.org>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hi all,
>>>>>>>> just wanted to ask if there is still interest in this
>>>>>>>> patch
>>>>>>>> series ?
>>>>>>>>
>>>>>>>> Best,
>>>>>>>>
>>>>>>>> Erik
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>> <advanced_encryption_with_defaults.png><client_version.png><glo
>>>>> bal_
>>>>> settings.png><deprectaed_ciphers_warning.png>
>>>
>
@@ -371,9 +371,19 @@ sub writeserverconf {
# Set TLSv2 as minimum
print CONF "tls-version-min 1.2\n";
- if ($sovpnsettings{'TLSAUTH'} eq 'on') {
- print CONF "tls-auth ${General::swroot}/ovpn/certs/ta.key\n";
- }
+ # TLS control channel authentication
+ if ($sovpnsettings{'TLSAUTH'} ne 'off') {
+ if ($sovpnsettings{'TLSAUTH'} eq 'on') {
+ print CONF "tls-auth ${General::swroot}/ovpn/certs/ta.key\n";
+ }
+ if ($sovpnsettings{'TLSAUTH'} eq 'tls-crypt') {
+ print CONF "tls-crypt ${General::swroot}/ovpn/certs/tc.key\n";
+ }
+ if ($sovpnsettings{'TLSAUTH'} eq 'tls-crypt-v2') {
+ print CONF "tls-crypt-v2 ${General::swroot}/ovpn/certs/tc-v2-server.key\n";
+ }
+ }
+
if ($sovpnsettings{DCOMPLZO} eq 'on') {
print CONF "comp-lzo\n";
}
@@ -959,6 +969,7 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save-enc-options'}) {
&General::readhash("${General::swroot}/ovpn/settings", \%vpnsettings);
$vpnsettings{'DAUTH'} = $cgiparams{'DAUTH'};
+ $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
$vpnsettings{'DCIPHER'} = $cgiparams{'DCIPHER'};
$vpnsettings{'DATACIPHERS'} = $cgiparams{'DATACIPHERS'};
@@ -982,6 +993,39 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save-enc-options'}) {
$vpnsettings{'NCHANNELCIPHERS'} = $cgiparams{'NCHANNELCIPHERS'};
}
+ # Create ta.key for tls-auth if not presant
+ if ($cgiparams{'TLSAUTH'} eq 'on') {
+ if ( ! -e "${General::swroot}/ovpn/certs/ta.key") {
+ system('/usr/sbin/openvpn', '--genkey', '--secret', "${General::swroot}/ovpn/certs/ta.key");
+ if ($?) {
+ $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
+ goto ADV_ENC_ERROR;
+ }
+ }
+ }
+
+ # Create tc.key for tls-crypt if not presant
+ if ($cgiparams{'TLSAUTH'} eq 'tls-crypt') {
+ if ( ! -e "${General::swroot}/ovpn/certs/tc.key") {
+ system('/usr/sbin/openvpn', '--genkey', 'tls-crypt', "${General::swroot}/ovpn/certs/tc.key");
+ if ($?) {
+ $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
+ goto ADV_ENC_ERROR;
+ }
+ }
+ }
+
+ # Create tc-v2-server.key for tls-crypt-v2 server if not presant
+ if ($cgiparams{'TLSAUTH'} eq 'tls-crypt-v2') {
+ if ( ! -e "${General::swroot}/ovpn/certs/tc-v2-server.key") {
+ system('/usr/sbin/openvpn', '--genkey', 'tls-crypt-v2-server', "${General::swroot}/ovpn/certs/tc-v2-server.key");
+ if ($?) {
+ $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
+ goto ADV_ENC_ERROR;
+ }
+ }
+ }
+
&General::writehash("${General::swroot}/ovpn/settings", \%vpnsettings);
&writeserverconf();
}
@@ -1272,17 +1316,6 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save'} && $cgiparams{'TYPE'} eq '' && $cg
goto SETTINGS_ERROR;
}
- # Create ta.key for tls-auth if not presant
- if ($cgiparams{'TLSAUTH'} eq 'on') {
- if ( ! -e "${General::swroot}/ovpn/certs/ta.key") {
- system('/usr/sbin/openvpn', '--genkey', '--secret', "${General::swroot}/ovpn/certs/ta.key");
- if ($?) {
- $errormessage = "$Lang::tr{'openssl produced an error'}: $?";
- goto SETTINGS_ERROR;
- }
- }
- }
-
$vpnsettings{'ENABLED_BLUE'} = $cgiparams{'ENABLED_BLUE'};
$vpnsettings{'ENABLED_ORANGE'} =$cgiparams{'ENABLED_ORANGE'};
$vpnsettings{'ENABLED'} = $cgiparams{'ENABLED'};
@@ -1293,7 +1326,6 @@ if ($cgiparams{'ACTION'} eq $Lang::tr{'save'} && $cgiparams{'TYPE'} eq '' && $cg
$vpnsettings{'DDEST_PORT'} = $cgiparams{'DDEST_PORT'};
$vpnsettings{'DMTU'} = $cgiparams{'DMTU'};
$vpnsettings{'DCOMPLZO'} = $cgiparams{'DCOMPLZO'};
- $vpnsettings{'TLSAUTH'} = $cgiparams{'TLSAUTH'};
#wrtie enable
if ( $vpnsettings{'ENABLED_BLUE'} eq 'on' ) {system("touch ${General::swroot}/ovpn/enable_blue 2>/dev/null");}else{system("unlink ${General::swroot}/ovpn/enable_blue 2>/dev/null");}
@@ -1723,12 +1755,34 @@ END
### Download tls-auth key
###
}elsif ($cgiparams{'ACTION'} eq $Lang::tr{'download tls-auth key'}) {
- if ( -f "${General::swroot}/ovpn/certs/ta.key" ) {
- print "Content-Type: application/octet-stream\r\n";
- print "Content-Disposition: filename=ta.key\r\n\r\n";
- print `/bin/cat ${General::swroot}/ovpn/certs/ta.key`;
- exit(0);
- }
+ if ( -f "${General::swroot}/ovpn/certs/ta.key" ) {
+ print "Content-Type: application/octet-stream\r\n";
+ print "Content-Disposition: filename=ta.key\r\n\r\n";
+ print `/bin/cat ${General::swroot}/ovpn/certs/ta.key`;
+ exit(0);
+ }
+
+###
+### Download tls-crypt key
+###
+} elsif ($cgiparams{'ACTION'} eq $Lang::tr{'download tls-crypt key'}) {
+ if ( -f "${General::swroot}/ovpn/certs/tc.key" ) {
+ print "Content-Type: application/octet-stream\r\n";
+ print "Content-Disposition: filename=tc.key\r\n\r\n";
+ print `/bin/cat ${General::swroot}/ovpn/certs/tc.key`;
+ exit(0);
+ }
+
+###
+### Download tls-crypt-v2 key
+###
+} elsif ($cgiparams{'ACTION'} eq $Lang::tr{'download tls-crypt-v2 key'}) {
+ if ( -f "${General::swroot}/ovpn/certs/tc-v2-server.key" ) {
+ print "Content-Type: application/octet-stream\r\n";
+ print "Content-Disposition: filename=tc-v2-server.key\r\n\r\n";
+ print `/bin/cat ${General::swroot}/ovpn/certs/tc-v2-server.key`;
+ exit(0);
+ }
###
### Form for generating a root certificate
@@ -2451,13 +2505,37 @@ else
print CLIENTCONF "auth $vpnsettings{'DAUTH'}\r\n";
- if ($vpnsettings{'TLSAUTH'} eq 'on') {
- if ($cgiparams{'MODE'} eq 'insecure') {
- print CLIENTCONF ";";
- }
- print CLIENTCONF "tls-auth ta.key\r\n";
- $zip->addFile( "${General::swroot}/ovpn/certs/ta.key", "ta.key") or die "Can't add file ta.key\n";
+ # Comment TLS-Auth directive if 'insecure' mode has been choosen
+ if ($vpnsettings{'TLSAUTH'} eq 'on') {
+ if ($cgiparams{'MODE'} eq 'insecure') {
+ print CLIENTCONF ";";
+ }
+ print CLIENTCONF "tls-auth ta.key\r\n";
+ $zip->addFile( "${General::swroot}/ovpn/certs/ta.key", "ta.key") or die "Can't add file ta.key\n";
}
+
+ # Comment TLS-Crypt directive if 'insecure' mode has been choosen
+ if ($vpnsettings{'TLSAUTH'} eq 'tls-crypt') {
+ if ($cgiparams{'MODE'} eq 'insecure') {
+ print CLIENTCONF ";";
+ }
+ print CLIENTCONF "tls-crypt tc.key\r\n";
+ $zip->addFile( "${General::swroot}/ovpn/certs/tc.key", "tc.key") or die "Can't add file tc.key\n";
+ }
+
+ # Comment TLS-Crypt-v2 directive if 'insecure' mode has been choosen and generate individual key
+ if ($vpnsettings{'TLSAUTH'} eq 'tls-crypt-v2') {
+ if ($cgiparams{'MODE'} eq 'insecure') {
+ print CLIENTCONF ";";
+ }
+ print CLIENTCONF "tls-crypt-v2 tc-v2-client-$confighash{$cgiparams{'KEY'}}[1].key\r\n";
+ # Generate individual tls-crypt-v2 client key
+ my $cryptfile = "$tempdir/tc-v2-client-$confighash{$cgiparams{'KEY'}}[1].key";
+ system('/usr/sbin/openvpn', '--tls-crypt-v2', "${General::swroot}/ovpn/certs/tc-v2-server.key", '--genkey', 'tls-crypt-v2-client', "$cryptfile");
+ # Add individual tls-crypt-v2 client key to client package
+ $zip->addFile( "$cryptfile", "tc-v2-client-$confighash{$cgiparams{'KEY'}}[1].key") or die "Can't add file tc-v2-client-$confighash{$cgiparams{'KEY'}}[1].key\n";
+ }
+
if ($vpnsettings{DCOMPLZO} eq 'on') {
print CLIENTCONF "comp-lzo\r\n";
}
@@ -2514,7 +2592,33 @@ else
print CLIENTCONF "</key>\r\n\r\n";
close(FILE);
- # TLS auth
+ # Create individual tls-crypt-v2 client key and print it to client.conf if 'insecure' has been selected
+ if ($vpnsettings{'TLSAUTH'} eq 'tls-crypt-v2') {
+ my $cryptfile = "$tempdir/tc-v2-client-$confighash{$cgiparams{'KEY'}}[1].key";
+ system('/usr/sbin/openvpn', '--tls-crypt-v2', "${General::swroot}/ovpn/certs/tc-v2-server.key", '--genkey', 'tls-crypt-v2-client', "$cryptfile");
+ open(FILE, "<$cryptfile");
+ print CLIENTCONF "<tls-crypt-v2>\r\n";
+ while (<FILE>) {
+ chomp($_);
+ print CLIENTCONF "$_\r\n";
+ }
+ print CLIENTCONF "</tls-crypt-v2>\r\n\r\n";
+ close(FILE);
+ }
+
+ # Print TLS-Crypt key to client.ovpn if 'insecure' has been selected
+ if ($vpnsettings{'TLSAUTH'} eq 'tls-crypt') {
+ open(FILE, "<${General::swroot}/ovpn/certs/tc.key");
+ print CLIENTCONF "<tls-crypt>\r\n";
+ while (<FILE>) {
+ chomp($_);
+ print CLIENTCONF "$_\r\n";
+ }
+ print CLIENTCONF "</tls-crypt>\r\n\r\n";
+ close(FILE);
+ }
+
+ # Print TLS-Auth key to client.ovpn if 'insecure' has been selected
if ($vpnsettings{'TLSAUTH'} eq 'on') {
open(FILE, "<${General::swroot}/ovpn/certs/ta.key");
print CLIENTCONF "<tls-auth>\r\n";
@@ -2706,6 +2810,50 @@ else
exit(0);
}
+###
+### Display tls-crypt key
+###
+} elsif ($cgiparams{'ACTION'} eq $Lang::tr{'show tls-crypt key'}) {
+
+ if (! -e "${General::swroot}/ovpn/certs/tc.key") {
+ $errormessage = $Lang::tr{'not present'};
+ } else {
+ &Header::showhttpheaders();
+ &Header::openpage($Lang::tr{'ovpn'}, 1, '');
+ &Header::openbigbox('100%', 'LEFT', '', '');
+ &Header::openbox('100%', 'LEFT', "$Lang::tr{'tc key'}");
+ my $output = `/bin/cat ${General::swroot}/ovpn/certs/tc.key`;
+ $output = &Header::cleanhtml($output,"y");
+ print "<pre>$output</pre>\n";
+ &Header::closebox();
+ print "<div align='center'><a href='/cgi-bin/ovpnmain.cgi'>$Lang::tr{'back'}</a></div>";
+ &Header::closebigbox();
+ &Header::closepage();
+ exit(0);
+ }
+
+###
+### Display tls-crypt-v2 server key
+###
+} elsif ($cgiparams{'ACTION'} eq $Lang::tr{'show tls-crypt-v2 key'}) {
+
+ if (! -e "${General::swroot}/ovpn/certs/tc-v2-server.key") {
+ $errormessage = $Lang::tr{'not present'};
+ } else {
+ &Header::showhttpheaders();
+ &Header::openpage($Lang::tr{'ovpn'}, 1, '');
+ &Header::openbigbox('100%', 'LEFT', '', '');
+ &Header::openbox('100%', 'LEFT', "$Lang::tr{'tc v2 key'}");
+ my $output = `/bin/cat ${General::swroot}/ovpn/certs/tc-v2-server.key`;
+ $output = &Header::cleanhtml($output,"y");
+ print "<pre>$output</pre>\n";
+ &Header::closebox();
+ print "<div align='center'><a href='/cgi-bin/ovpnmain.cgi'>$Lang::tr{'back'}</a></div>";
+ &Header::closebigbox();
+ &Header::closepage();
+ exit(0);
+ }
+
###
### Display Certificate Revoke List
###
@@ -2758,9 +2906,6 @@ ADV_ERROR:
if ($cgiparams{'LOG_VERB'} eq '') {
$cgiparams{'LOG_VERB'} = '3';
}
- if ($cgiparams{'TLSAUTH'} eq '') {
- $cgiparams{'TLSAUTH'} = 'off';
- }
$checked{'CLIENT2CLIENT'}{'off'} = '';
$checked{'CLIENT2CLIENT'}{'on'} = '';
$checked{'CLIENT2CLIENT'}{$cgiparams{'CLIENT2CLIENT'}} = 'CHECKED';
@@ -2981,6 +3126,7 @@ END
}
$confighash{$key}[39] = $cgiparams{'DAUTH'};
$confighash{$key}[40] = $cgiparams{'DCIPHER'};
+ $confighash{$key}[41] = $cgiparams{'TLSAUTH'};
$confighash{$key}[42] = $cgiparams{'DATACIPHERS'};
$confighash{$key}[43] = $cgiparams{'CHANNELCIPHERS'};
$confighash{$key}[44] = $cgiparams{'NCHANNELCIPHERS'};
@@ -3004,6 +3150,17 @@ ADV_ENC_ERROR:
@temp = split('\|', $cgiparams{'DAUTH'});
foreach my $key (@temp) {$checked{'DAUTH'}{$key} = "selected='selected'"; }
+ # Set default for TLS control authentication
+ if ($cgiparams{'TLSAUTH'} eq '') {
+ $cgiparams{'TLSAUTH'} = 'tls-crypt'; #[41]
+ }
+ $checked{'TLSAUTH'}{'on'} = '';
+ $checked{'TLSAUTH'}{'off'} = '';
+ $checked{'TLSAUTH'}{'tls-crypt'} = '';
+ $checked{'TLSAUTH'}{'tls-crypt-v2'} = '';
+ @temp = split('\|', $cgiparams{'TLSAUTH'});
+ foreach my $key (@temp) {$checked{'TLSAUTH'}{$key} = "selected='selected'"; }
+
# Set default for data-cipher-fallback (the old --cipher directive)
if ($cgiparams{'DCIPHER'} eq '') {
$cgiparams{'DCIPHER'} = 'AES-256-CBC'; #[40]
@@ -3058,12 +3215,14 @@ ADV_ENC_ERROR:
if ($cgiparams{'ACTION'} eq $Lang::tr{'save-enc-options'}) {
$confighash{$cgiparams{'KEY'}}[39] = $cgiparams{'DAUTH'};
$confighash{$cgiparams{'KEY'}}[40] = $cgiparams{'DCIPHER'};
+ $confighash{$cgiparams{'KEY'}}[41] = $cgiparams{'TLSAUTH'};
$confighash{$cgiparams{'KEY'}}[42] = $cgiparams{'DATACIPHERS'};
$confighash{$cgiparams{'KEY'}}[43] = $cgiparams{'CHANNELCIPHERS'};
$confighash{$cgiparams{'KEY'}}[44] = $cgiparams{'NCHANNELCIPHERS'};
} else {
$cgiparams{'DAUTH'} = $vpnsettings{'DAUTH'};
$cgiparams{'DCIPHER'} = $vpnsettings{'DCIPHER'};
+ $cgiparams{'TLSAUTH'} = $vpnsettings{'TLSAUTH'};
$cgiparams{'DATACIPHERS'} = $vpnsettings{'DATACIPHERS'};
$cgiparams{'CHANNELCIPHERS'} = $vpnsettings{'CHANNELCIPHERS'};
$cgiparams{'NCHANNELCIPHERS'} = $vpnsettings{'NCHANNELCIPHERS'};
@@ -3175,6 +3334,7 @@ ADV_ENC_ERROR:
<tr>
<th width="15%"></th>
<th>$Lang::tr{'ovpn ha'}</th>
+ <th>$Lang::tr{'ovpn tls auth'}</th>
</tr>
</thead>
<tbody>
@@ -3193,6 +3353,14 @@ ADV_ENC_ERROR:
<option value='whirlpool' $checked{'DAUTH'}{'whirlpool'}>Whirlpool (512 $Lang::tr{'bit'})</option>
<option value='SHA1' $checked{'DAUTH'}{'SHA1'}>SHA1 160 $Lang::tr{'bit'}, $Lang::tr{'vpn weak'}</option>
</select>
+
+ <td class='boldbase'>
+ <select name='TLSAUTH' size='6' style='width: 100%' style="margin-right:-17px" size="11">
+ <option value='tls-crypt-v2' $checked{'TLSAUTH'}{'tls-crypt-v2'}>TLS-Crypt-v2</option>
+ <option value='tls-crypt' $checked{'TLSAUTH'}{'tls-crypt'}>TLS-Crypt</option>
+ <option value='on' $checked{'TLSAUTH'}{'on'}>TLS-Auth</option>
+ <option value='off' $checked{'TLSAUTH'}{'off'}>Off</option>
+ </select>
</td>
</tr>
</tbody>
@@ -3972,7 +4140,6 @@ if ($confighash{$cgiparams{'KEY'}}) {
$cgiparams{'CCD_WINS'} = $confighash{$cgiparams{'KEY'}}[37];
$cgiparams{'DAUTH'} = $confighash{$cgiparams{'KEY'}}[39];
$cgiparams{'DCIPHER'} = $confighash{$cgiparams{'KEY'}}[40];
- $cgiparams{'TLSAUTH'} = $confighash{$cgiparams{'KEY'}}[41];
# Index from [39] to [44] has been reserved by advanced encryption
$cgiparams{'CLIENTVERSION'} = $confighash{$cgiparams{'KEY'}}[45];
} elsif ($cgiparams{'ACTION'} eq $Lang::tr{'save'}) {
@@ -4890,10 +5057,6 @@ if ($cgiparams{'TYPE'} eq 'net') {
$checked{'MSSFIX'}{'on'} = '';
$checked{'MSSFIX'}{$cgiparams{'MSSFIX'}} = 'CHECKED';
- $checked{'TLSAUTH'}{'off'} = '';
- $checked{'TLSAUTH'}{'on'} = '';
- $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
-
if (1) {
&Header::showhttpheaders();
&Header::openpage($Lang::tr{'ovpn'}, 1, '');
@@ -5439,9 +5602,6 @@ END
if ($cgiparams{'MSSFIX'} eq '') {
$cgiparams{'MSSFIX'} = 'off';
}
- if ($cgiparams{'TLSAUTH'} eq '') {
- $cgiparams{'TLSAUTH'} = 'off';
- }
if ($cgiparams{'DOVPN_SUBNET'} eq '') {
$cgiparams{'DOVPN_SUBNET'} = '10.' . int(rand(256)) . '.' . int(rand(256)) . '.0/255.255.255.0';
}
@@ -5459,10 +5619,6 @@ END
$selected{'DPROTOCOL'}{'tcp'} = '';
$selected{'DPROTOCOL'}{$cgiparams{'DPROTOCOL'}} = 'SELECTED';
- $checked{'TLSAUTH'}{'off'} = '';
- $checked{'TLSAUTH'}{'on'} = '';
- $checked{'TLSAUTH'}{$cgiparams{'TLSAUTH'}} = 'CHECKED';
-
$checked{'DCOMPLZO'}{'off'} = '';
$checked{'DCOMPLZO'}{'on'} = '';
$checked{'DCOMPLZO'}{$cgiparams{'DCOMPLZO'}} = 'CHECKED';
@@ -5565,17 +5721,6 @@ END
<td> <input type='TEXT' name='DMTU' VALUE='$cgiparams{'DMTU'}' size='5' /></td>
</tr>
- <tr><td colspan='4'><br></td></tr>
- <tr>
- <td class'base'><b>$Lang::tr{'ovpn crypt options'}:</b></td>
- </tr>
- <tr><td colspan='1'><br></td></tr>
-
- <tr>
- <td class='base'>$Lang::tr{'ovpn tls auth'}</td>
- <td><input type='checkbox' name='TLSAUTH' $checked{'TLSAUTH'}{'on'} /></td>
- </tr>
-
<tr><td colspan='4'><br><br></td></tr>
END
;
@@ -5874,6 +6019,10 @@ END
my $col3="bgcolor='$color{'color22'}'";
# ta.key line
my $col4="bgcolor='$color{'color20'}'";
+ # tc-v2.key line
+ my $col5="bgcolor='$color{'color22'}'";
+ # tc.key
+ my $col6="bgcolor='$color{'color20'}'";
if (-f "${General::swroot}/ovpn/ca/cacert.pem") {
my $casubject = `/usr/bin/openssl x509 -text -in ${General::swroot}/ovpn/ca/cacert.pem`;
@@ -6003,7 +6152,7 @@ END
# Nothing
print <<END;
<tr>
- <td width='25%' class='base' $col4>$Lang::tr{'ta key'}:</td>
+ <td width='25%' class='base' $col4>$Lang::tr{'ta key'}</td>
<td class='base' $col4>$Lang::tr{'not present'}</td>
<td colspan='3' $col4> </td>
</tr>
@@ -6011,6 +6160,51 @@ END
;
}
+ # Adding tc-v2.key to chart
+ if (-f "${General::swroot}/ovpn/certs/tc-v2-server.key") {
+ my $tcvsubject = `/bin/cat ${General::swroot}/ovpn/certs/tc-v2-server.key`;
+ $tcvsubject =~ /-----BEGIN (.*)-----[\n]/;
+ $tcvsubject = $1;
+ print <<END;
+
+ <tr>
+ <td class='base' $col5>$Lang::tr{'tc v2 key'}</td>
+ <td class='base' $col5>$tcvsubject</td>
+ <form method='post' name='frmtcv2key'><td width='3%' align='center' $col5>
+ <input type='hidden' name='ACTION' value='$Lang::tr{'show tls-crypt-v2 key'}' />
+ <input type='image' name='$Lang::tr{'edit'}' src='/images/info.gif' alt='$Lang::tr{'show tls-crypt-v2 key'}' title='$Lang::tr{'show tls-crypt-v2 key key'}' width='20' height='20' border='0' />
+ </form>
+ <form method='post' name='frmtckey'><td width='3%' align='center' $col5>
+ <td width='4%' $col5> </td>
+ </tr>
+END
+;
+ }
+
+ # Adding tc.key to chart
+ if (-f "${General::swroot}/ovpn/certs/tc.key") {
+ my $tcsubject = `/bin/cat ${General::swroot}/ovpn/certs/tc.key`;
+ $tcsubject =~ /# (.*)[\n]/;
+ $tcsubject = $1;
+ print <<END;
+
+ <tr>
+ <td class='base' $col6>$Lang::tr{'tc key'}</td>
+ <td class='base' $col6>$tcsubject</td>
+ <form method='post' name='frmtckey'><td width='3%' align='center' $col6>
+ <input type='hidden' name='ACTION' value='$Lang::tr{'show tls-crypt key'}' />
+ <input type='image' name='$Lang::tr{'edit'}' src='/images/info.gif' alt='$Lang::tr{'show tls-crypt key'}' title='$Lang::tr{'show tls-crypt key'}' width='20' height='20' border='0' />
+ </form>
+ <form method='post' name='frmtckey'><td width='3%' align='center' $col6>
+ <input type='image' name='$Lang::tr{'download tls-crypt key'}' src='/images/media-floppy.png' alt='$Lang::tr{'download tls-crypt key'}' title='$Lang::tr{'download tls-crypt key'}' border='0' />
+ <input type='hidden' name='ACTION' value='$Lang::tr{'download tls-crypt key'}' />
+ </form>
+ <td width='4%' $col6> </td>
+ </tr>
+END
+;
+ }
+
if (! -f "${General::swroot}/ovpn/ca/cacert.pem") {
print "<tr><td colspan='5' align='center'><form method='post'>";
print "<input type='submit' name='ACTION' value='$Lang::tr{'generate root/host certificates'}' />";
@@ -894,6 +894,9 @@
'download new ruleset' => 'Neuen Regelsatz herunterladen',
'download pkcs12 file' => 'PKCS12-Datei herunterladen',
'download root certificate' => 'Root-Zertifikat herunterladen',
+'download tls-auth key' => 'TLS-Auth Schlüssel herunterladen',
+'download tls-crypt key' => 'TLS-Crypt Schlüssel herunterladen',
+'download tls-crypt-v2 key' => 'TLS-Crypt-v2 Schlüssel herunterladen',
'download tls-auth key' => 'tls-auth Key herunterladen',
'dpd action' => 'Aktion für Erkennung toter Gegenstellen (Dead Peer Detection)',
'dpd delay' => 'Verzögerung',
@@ -1951,7 +1954,7 @@
'ovpn subnet' => 'OpenVPN-Subnetz:',
'ovpn subnet is invalid' => 'Das OpenVPN-Subnetz ist ungültig.',
'ovpn subnet overlap' => 'OpenVPNSubnetz überschneidet sich mit ',
-'ovpn tls auth' => 'TLS-Kanalabsicherung:',
+'ovpn tls auth' => 'TLS-Kanalabsicherung',
'ovpn warning 64 bit block cipher' => 'Diser Algorithmus ist unsicher und wird bald entfernt. <br>Bitte ändern Sie dies so schnell wie möglich!</br>',
'ovpn warning algorithm' => 'Folgender Algorithmus wurde konfiguriert',
'ovpn warning rfc3280' => 'Das Host Zertifikat ist nicht RFC3280 Regelkonform. <br>Bitte IPFire auf die letzte Version updaten und generieren sie ein neues Root und Host Zertifikat so bald wie möglich.</br><br>Es müssen dann alle OpenVPN clients erneuert werden!</br>',
@@ -2226,6 +2229,9 @@
'show last x lines' => 'die letzten x Zeilen anzeigen',
'show root certificate' => 'Root-Zertifikat anzeigen',
'show share options' => 'Anzeige der Freigabeeinstellungen',
+'show tls-auth key' => 'TLS-Auth Schlüssel anzeigen',
+'show tls-crypt key' => 'TLS-Crypt Schlüssel anzeigen',
+'show tls-crypt-v2 key' => 'TLS-Crypt-v2 Schlüssel anzeigen',
'shuffle' => 'Zufall',
'shutdown' => 'Herunterfahren',
'shutdown ask' => 'Herunterfahren?',
@@ -2352,6 +2358,8 @@
'system logs' => 'Systemprotokolldateien',
'system status information' => 'System-Statusinformationen',
'ta key' => 'TLS-Authentifizierungsschlüssel',
+'tc key' => 'TLS-Kryptografie-Schlüssel',
+'tc v2 key' => 'TLS-Kryptografie-Schlüssel-Version2',
'taa zombieload2' => 'TSX Async Abort / ZombieLoad v2',
'tcp more reliable' => 'TCP (zuverlässiger)',
'telephone not set' => 'Telefonnummer nicht angegeben.',
@@ -918,7 +918,9 @@
'download new ruleset' => 'Download new ruleset',
'download pkcs12 file' => 'Download PKCS12 file',
'download root certificate' => 'Download root certificate',
-'download tls-auth key' => 'Download tls-auth key',
+'download tls-auth key' => 'Download TLS-Auth key',
+'download tls-crypt key' => 'Download TLS-Crypt key',
+'download tls-crypt-v2 key' => 'Download TLS-Crypt-v2 server key',
'dpd action' => 'Action',
'dpd delay' => 'Delay',
'dpd timeout' => 'Timeout',
@@ -1983,7 +1985,7 @@
'ovpn subnet' => 'OpenVPN subnet:',
'ovpn subnet is invalid' => 'OpenVPN subnet is invalid.',
'ovpn subnet overlap' => 'OpenVPN Subnet overlaps with : ',
-'ovpn tls auth' => 'TLS Channel Protection:',
+'ovpn tls auth' => 'TLS Channel Protection',
'ovpn warning 64 bit block cipher' => 'This encryption algorithm is broken and will soon be removed. <br>Please change this as soon as possible!</br>',
'ovpn warning algorithm' => 'You configured the algorithm',
'ovpn warning rfc3280' => 'Your host certificate is not RFC3280 compliant. <br>Please update to the latest IPFire version and generate as soon as possible a new root and host certificate.</br><br>All OpenVPN clients needs then to be renewed!</br>',
@@ -2262,7 +2264,9 @@
'show lines' => 'Show lines',
'show root certificate' => 'Show root certificate',
'show share options' => 'Show shares options',
-'show tls-auth key' => 'Show tls-auth key',
+'show tls-auth key' => 'Show TLS-Auth key',
+'show tls-crypt key' => 'Show TLS-Crypt key',
+'show tls-crypt-v2 key' => 'Show TLS-Crypt-v2 key',
'shuffle' => 'Shuffle',
'shutdown' => 'Shutdown',
'shutdown ask' => 'Shutdown?',
@@ -2390,6 +2394,8 @@
'system logs' => 'System Logs',
'system status information' => 'System Status Information',
'ta key' => 'TLS-Authentification-Key',
+'tc key' => 'TLS-Cryptografic-Key',
+'tc v2 key' => 'TLS-Cryptografic-Key-version2',
'taa zombieload2' => 'TSX Async Abort / ZombieLoad v2',
'tcp more reliable' => 'TCP (more reliable)',
'telephone not set' => 'Telephone not set.',
@@ -717,6 +717,9 @@
'download new ruleset' => 'Descargar nuevo grupo de reglas',
'download pkcs12 file' => 'Descargar archivo PKCS12',
'download root certificate' => 'Descargar certificado root',
+'download tls-auth key' => 'Descargar llave TLS-Auth',
+'download tls-crypt key' => 'Descargar llave TLS-Crypt',
+'download tls-crypt-v2 key' => 'Descargar llave servidor TLS-Crypt-v2',
'dpd action' => 'Acción al detectar Dead Peer',
'driver' => 'Driver',
'drop input' => 'Registrar paquetes descartados',
@@ -1352,6 +1355,7 @@
'ovpn subnet' => 'Subred de OpenVPN (ej. 10.0.10.0/255.255.255.0',
'ovpn subnet is invalid' => 'Subred de OpenVPN no es válida.',
'ovpn subnet overlap' => 'La subred de OpenVPN se traslapa con:',
+'ovpn tls auth' => 'Protección Canal TLS',
'ovpn warning 64 bit block cipher' => 'Este algoritmo de cifrado del está roto y pronto se eliminará. <br>¡Por favor, cambie esto lo antes posible!</br>',
'ovpn warning algorithm' => 'Se configuró el siguiente algoritmo',
'ovpn_fastio' => 'Fast-IO',
@@ -1596,6 +1600,9 @@
'show lines' => 'Mostrar líneas',
'show root certificate' => 'Mostrar certificado root',
'show share options' => 'Mostrar opciones de recursos compartidos',
+'show tls-auth key' => 'Mostrar llave TLS-Auth',
+'show tls-crypt key' => 'Mostrar llave TLS-Crypt',
+'show tls-crypt-v2 key' => 'Mostrar llave TLS-Crypt-v2',
'shuffle' => 'Al azar',
'shutdown' => 'Apagar',
'shutdown ask' => '¿Apagar?',
@@ -1698,6 +1705,9 @@
'system log viewer' => 'Visor de registros (logs) del sistema',
'system logs' => 'Registros del sistema',
'system status information' => 'Información de status del sistema',
+'ta key' => 'Clave de Autentificación-TLS',
+'tc key' => 'Clave Criptográfica-TLS',
+'tc v2 key' => 'Clave Criptográfica-TLS versión 2',
'telephone not set' => 'Teléfono no establecido.',
'template' => 'Preestablecido',
'template warning' => 'Tiene dos opciones para establecer QoS. La primera, presionar el botón Guardar y generar clases y reglas por ud. mismo. La segunda, presione el botón preestablecidos y las clases y reglas se generarán a partir de una plantilla',
@@ -921,7 +921,9 @@
'download new ruleset' => 'Télécharger de nouvelles règles',
'download pkcs12 file' => 'Télécharger le fichier PKCS12',
'download root certificate' => 'Télécharger le certificat Root',
-'download tls-auth key' => 'Télécharger la clé tls-auth',
+'download tls-auth key' => 'Télécharger la clé TLS-Auth',
+'download tls-crypt key' => 'Télécharger la clef TLS-Crypt',
+'download tls-crypt-v2 key' => 'Télécharger la clef server TLS-Crypt-v2',
'dpd action' => 'Détection du pair mort',
'dpd delay' => 'Retard',
'dpd timeout' => 'Délai dépassé',
@@ -1984,7 +1986,7 @@
'ovpn subnet' => 'Sous-réseau OpenVPN',
'ovpn subnet is invalid' => 'Sous-réseau OpenVPN non valide.',
'ovpn subnet overlap' => 'Le sous-réseau OpenVPN se chevauche avec : ',
-'ovpn tls auth' => 'Protection du canal TLS :',
+'ovpn tls auth' => 'Protection du canal TLS',
'ovpn warning 64 bit block cipher' => 'Ce L\'algorithme de chiffage du n\'est plus sûr et sera bientôt supprimé. <br>Veuillez changer cela dès que possible!</br>',
'ovpn warning algorithm' => 'L\'algorithme suivant a été configuré',
'ovpn warning rfc3280' => 'Votre certificat d\'hôte n\'est pas conforme avec la RFC3280.<br>Veuillez mettre à jour la dernière version d\'IPFire et générer dès que possible un nouveau certificat racine et hôte.</br><br>Tous les clients OpenVPN doivent ensuite être renouvelés !</br>',
@@ -2266,7 +2268,9 @@
'show lines' => 'Montrer les lignes',
'show root certificate' => 'Afficher le certificat root',
'show share options' => 'Montrer les options partagées',
-'show tls-auth key' => 'Afficher clef tls-auth',
+'show tls-auth key' => 'Afficher clef TLS-Auth',
+'show tls-crypt key' => 'Montrer la clef TLS-Crypt',
+'show tls-crypt-v2 key' => 'Montrer la clef TLS-Crypt-v2',
'shuffle' => 'Mélanger',
'shutdown' => 'Arrêter',
'shutdown ask' => 'Arrêter ?',
@@ -2394,6 +2398,8 @@
'system logs' => 'Rapports système',
'system status information' => 'Informations sur le statut du système',
'ta key' => 'Clé d\'authentification TLS',
+'tc key' => 'Clef de chiffrage TLS',
+'tc v2 key' => 'Clef de chiffrage TLS version2',
'taa zombieload2' => 'TSX Async Abort / ZombieLoad v2',
'tcp more reliable' => 'TCP (plus fiable)',
'telephone not set' => 'Numéro de téléphone non défini.',
@@ -1739,6 +1739,7 @@
'ovpn subnet' => 'OpenVPN subnet (e.g. 10.0.10.0/255.255.255.0)',
'ovpn subnet is invalid' => 'OpenVPN subnet is invalid.',
'ovpn subnet overlap' => 'OpenVPN Subnet overlaps with : ',
+'ovpn tls auth' => 'Protezione del canale TLS',
'ovpn warning 64 bit block cipher' => 'L\'algoritmo di crittografia è insicuro e verrà presto disinstallato.<br>Si prega di cambiare il più presto possibile!</br>',
'ovpn warning algorithm' => 'È stato configurato il seguente algoritmo',
'ovpn_fastio' => 'Fast-IO',
@@ -1994,7 +1995,9 @@
'show lines' => 'Show lines',
'show root certificate' => 'Show root certificate',
'show share options' => 'Show shares options',
-'show tls-auth key' => 'Show tls-auth key',
+'show tls-auth key' => 'Mostra la chiave TLS-Auth',
+'show tls-crypt key' => 'Mostra la chiave TLS-Crypt',
+'show tls-crypt-v2 key' => 'Mostra la chiave TLS-Crypt v2',
'shuffle' => 'Shuffle',
'shutdown' => 'Spegni',
'shutdown ask' => 'Spegni?',
@@ -2107,6 +2110,8 @@
'system logs' => 'Log di Sistema',
'system status information' => 'Informazioni e stato del sistema',
'ta key' => 'TLS-Authentification-Key',
+'tc key' => 'Chiave-Crittografica-TLS',
+'tc v2 key' => 'Chiave-Crittografica-TLS-v2',
'telephone not set' => 'Telephone not set.',
'template' => 'Preset',
'template warning' => 'Ci sono due opzioni per impostare il Qos. La prima: si preme il pulsante Salva e poi si generano le classi e le regole da soli. La seconda: si preme il tasto di preset e le classi e le regole saranno automaticamente generate da un modello.',
@@ -794,6 +794,9 @@
'download new ruleset' => 'Download nieuwe regelset',
'download pkcs12 file' => 'Download PKCS12 bestand',
'download root certificate' => 'Download root certificaat',
+'download tls-auth key' => 'Download TLS-Auth sleutel',
+'download tls-crypt key' => 'Download TLS-Crypt sleutel',
+'download tls-crypt-v2 key' => 'Download TLS-Crypt-v2 server sleutel',
'dpd action' => 'Dead peer-detectie actie',
'dpd delay' => 'Vertraging',
'dpd timeout' => 'Timeout',
@@ -1660,12 +1663,13 @@
'ovpn' => 'OpenVPN',
'ovpn con stat' => 'OpenVPN connectiestatistieken',
'ovpn config' => 'OVPN-Configuratie',
+'ovpn crypt options' => 'Cryptografische opties',
'ovpn channel encryption' => 'Control-kanaal versleuteling',
'ovpn control channel v2' => 'Controle-Kanaal TLSv2',
'ovpn control channel v3' => 'Controle-Kanaal TLSv3',
'ovpn data encryption' => 'Datakanaalversleuteling',
'ovpn data channel authentication' => 'Gegevens en kanaal verificatie',
-'ovpn data channel' => 'Data-kanaal',
+'ovpn data channel' => 'Data-Kanaal',
'ovpn data channel fallback' => 'Data-Kanaal terugval',
'ovpn device' => 'OpenVPN apparaat:',
'ovpn dl' => 'OVPN-Configuratie download',
@@ -1693,6 +1697,7 @@
'ovpn subnet' => 'OpenVPN subnet (bijv. 10.0.10.0/255.255.255.0)',
'ovpn subnet is invalid' => 'OpenVPN subnet is ongeldig.',
'ovpn subnet overlap' => 'OpenVPN subnet overlapt met : ',
+'ovpn tls auth' => 'TLS Kanaal bescherming',
'ovpn warning 64 bit block cipher' => 'Dit encryptie algoritme is verbroken en zal binnenkort worden verwijderd. <br>Verander dit zo snel mogelijk!</br>',
'ovpn warning algorithm' => 'U hebt het algoritme geconfigureerd',
'ovpn warning rfc3280' => 'Uw gastheercertificaat is niet RFC3280-conform. <br>Please-update naar de nieuwste IPFire-versie en genereer zo snel mogelijk een nieuw root- en host-certificaat.</br><br>Alle OpenVPN-clients moeten dan vernieuwd worden!</br>',
@@ -1948,6 +1953,9 @@
'show lines' => 'Toon regels',
'show root certificate' => 'Toon root certificaat',
'show share options' => 'Toon shares opties',
+'show tls-auth key' => 'Toon TLS-Auth sleutel',
+'show tls-crypt key' => 'Toon TLS-Crypt sleutel',
+'show tls-crypt-v2 key' => 'Toon TLS-Crypt-v2 sleutel',
'shuffle' => 'Willekeurige volgorde',
'shutdown' => 'Afsluiten',
'shutdown ask' => 'Afsluiten?',
@@ -2057,6 +2065,9 @@
'system log viewer' => 'Systeem Log Viewer',
'system logs' => 'Systeem logs',
'system status information' => 'Systeem Status Informatie',
+'ta key' => 'TLS-Authentificatie-sleutel',
+'tc key' => 'TLS-Cryptografische-sleutel',
+'tc v2 key' => 'TLS-Cryptografische sleutel-versie2',
'telephone not set' => 'Telefoon niet ingesteld.',
'template' => 'Vooringesteld',
'template warning' => 'U heeft twee opties voor QoS. Bij de eerste klikt u op de knop opslaan en genereert u zelf de klassen en regels. Voor de tweede klikt u op de "vooringesteld" knop en worden de regels middels een sjabloon voor u ingesteld.',
@@ -719,6 +719,9 @@
'download new ruleset' => 'Pobierz nowy zestaw reguł',
'download pkcs12 file' => 'Pobierz plik PKCS12',
'download root certificate' => 'Pobierz certyfikat root',
+'download tls-auth key' => 'Pobierz klucz TLS-Auth',
+'download tls-crypt key' => 'Pobierz klucz TLS-Crypt',
+'download tls-crypt-v2 key' => 'Pobierz klucz serwera TLS-Crypt-v2',
'dpd action' => 'Dead Peer Detection action',
'driver' => 'Sterownik',
'drop input' => 'Loguj odrzucone pakiety wejściowe (input packets)',
@@ -1365,6 +1368,7 @@
'ovpn subnet' => 'Podsieć OpenVPN (np. 10.0.10.0/255.255.255.0)',
'ovpn subnet is invalid' => 'Podsieć OpenVPN jest niepoprawna.',
'ovpn subnet overlap' => 'Podsieć OpenVPN zachodzi na : ',
+'ovpn tls auth' => 'Ochrona Kanału-TLS',
'ovpn warning 64 bit block cipher' => 'Szyfr danych wymaga co najmniej jednego szyfru. <br>Proszę to zmienić jak najszybciej!</br>',
'ovpn warning algorithm' => 'Skonfigurowałeś algorytm',
'ovpn_fastio' => 'Fast-IO',
@@ -1609,6 +1613,9 @@
'show lines' => 'Pokaż linie',
'show root certificate' => 'Pokaż certyfikat root',
'show share options' => 'Pokaż opcje zasobu',
+'show tls-auth key' => 'Pokaż klucz TLS-Auth',
+'show tls-crypt key' => 'Pokaż klucz TLS-Crypt',
+'show tls-crypt-v2 key' => 'Pokaż klucz TLS-Crypt-v2',
'shuffle' => 'Losowo',
'shutdown' => 'Wyłącz',
'shutdown ask' => 'Wyłączyć?',
@@ -1712,6 +1719,9 @@
'system log viewer' => 'Przegląd logów systemu',
'system logs' => 'Logi systemu',
'system status information' => 'Informacje o stanie systemu',
+'ta key' => 'TLS-Klucz-Uwierzytelniający',
+'tc key' => 'TLS-Klucz-Kryptograficzny',
+'tc v2 key' => 'TLS-Klucz-Kryptograficzny-wersja2',
'telephone not set' => 'Telephone not set.',
'template' => 'Schemat',
'template warning' => 'Masz 2 możliwości skonfigurowania QoS. Pierwsza to naciśnięcie przycisku zapisz i skonfigurowanie klas i reguł samodzielnie. Druga to wciśnięcie przycisku schemat aby utworzyć klasy i reguły ze schematu.',
@@ -714,6 +714,9 @@
'download new ruleset' => 'Загрузить новые правила',
'download pkcs12 file' => 'Загрузить PKCS12 файл',
'download root certificate' => 'Загрузить root сертификат',
+'download tls-auth key' => 'Скачать TLS-Auth ключ',
+'download tls-crypt key' => 'Скачать TLS-Crypt ключ',
+'download tls-crypt-v2 key' => 'Скачать серверный ключ TLS-Crypt-v2',
'dpd action' => 'Действие при обнаружении Dead Peer',
'driver' => 'Драйвер',
'drop input' => 'Записывать сброшенные входящие пакеты',
@@ -1339,6 +1342,7 @@
'ovpn channel encryption' => 'Шифрование каналов управления',
'ovpn control channel v2' => 'Канал-управления TLSv2',
'ovpn control channel v3' => 'Канал-управления TLSv3',
+'ovpn crypt options' => 'Криптографические опции',
'ovpn data encryption' => 'шифрование-каналов данных',
'ovpn data channel authentication' => 'Аутентификация данных и каналов',
'ovpn data channel' => 'Информационный-канал',
@@ -1359,6 +1363,7 @@
'ovpn subnet' => 'Подсеть OpenVPN (e.g. 10.0.10.0/255.255.255.0)',
'ovpn subnet is invalid' => 'Подсеть OpenVPN задана неверно.',
'ovpn subnet overlap' => 'Подсеть OpenVPN пересекается с: ',
+'ovpn tls auth' => 'Защита канала TLS',
'ovpn warning 64 bit block cipher' => 'Этот алгоритм шифрования сломан и вскоре будет удален. <br>Пожалуйста, измените это как можно скорее!</br>',
'ovpn warning algorithm' => 'Вы настроили алгоритм',
'ovpn_fastio' => 'Fast-IO',
@@ -1603,6 +1608,9 @@
'show lines' => 'Показать строки',
'show root certificate' => 'Показать root сертификат',
'show share options' => 'Показать настройки общих ресурсов',
+'show tls-auth key' => 'Показать ключ TLS-Auth',
+'show tls-crypt key' => 'Показать ключ TLS-Crypt',
+'show tls-crypt-v2 key' => 'Показать ключ TLS-Crypt-клавиша-v2',
'shuffle' => 'Перемешать',
'shutdown' => 'Выключить',
'shutdown ask' => 'Выключить?',
@@ -1706,6 +1714,9 @@
'system log viewer' => 'System Log Viewer',
'system logs' => 'Системные журналы',
'system status information' => 'System Status Information',
+'ta key' => 'TLS-Аутентификация-Кей',
+'tc key' => 'TLS-криптографический-ключ',
+'tc v2 key' => 'TLS-криптографическая-версия2',
'telephone not set' => 'Telephone not set.',
'template' => 'Задать',
'template warning' => 'У Вас есть две опции для установки Qos. Первая - нажать кнопку сохранения и сгенерировать классы и правила самостоятельно. Вторая - задать правила по шаблону.',
@@ -879,6 +879,9 @@
'download new ruleset' => 'Yeni Kural Kümesi İndir',
'download pkcs12 file' => 'PKCS12 dosyasını indir',
'download root certificate' => 'Root sertifikasını indir',
+'download tls-auth key' => 'TLS-Auth anahtarını indirin',
+'download tls-crypt key' => 'TLS-Crypt anahtarını indirin',
+'download tls-crypt-v2 key' => 'TLS-Crypt-v2 sunucu anahtarını indirin',
'download tls-auth key' => 'Tls kimlik doğrulama anahtarını indir',
'dpd action' => 'Hareketsiz eş algılama eylemi',
'dpd delay' => 'Gecikme',
@@ -1884,6 +1887,7 @@
'ovpn subnet' => 'OpenVPN alt ağı (örneğin 10.0.10.0/255.255.255.0)',
'ovpn subnet is invalid' => 'Geçersiz OpenVPN alt ağı.',
'ovpn subnet overlap' => 'OpenVPN alt ağı ile örtüşenler: ',
+'ovpn tls auth' => 'TLS Kanal Koruması',
'ovpn warning 64 bit block cipher' => 'Bu şifreleme algoritması bozuldu ve yakında kaldırılacak. <br> Lütfen bunu mümkün olan en kısa sürede değiştirin!</br>',
'ovpn warning algorithm' => 'Algoritmayı sen yapılandırdın',
'ovpn_fastio' => 'Hızlı-IO',
@@ -2148,6 +2152,9 @@
'show root certificate' => 'Root sertifikasını göster',
'show share options' => 'Paylaşım seçeneklerini göster',
'show tls-auth key' => 'Tls kimlik doğrulama anahtarını göster',
+'show tls-auth key' => 'TLS-Auth anahtarını göster',
+'show tls-crypt key' => 'TLS-Crypt anahtarını göster',
+'show tls-crypt-v2 key' => 'TLS-Crypt-v2 anahtarını göster',
'shuffle' => 'Karma',
'shutdown' => 'Kapat',
'shutdown ask' => 'Kapat?',
@@ -2260,6 +2267,8 @@
'system logs' => 'Sistem Günlükleri',
'system status information' => 'Sistem Durum Bilgisi',
'ta key' => 'TLS Kimlik Doğrulama Anahtarı',
+'tc key' => 'TLS-Şifreleme-Anahtarı',
+'tc v2 key' => 'TLS-Şifreleme-Anahtarı-versiyon 2',
'tcp more reliable' => 'TCP (daha güvenli)',
'telephone not set' => 'Telefon ayarlanmamış.',
'template' => 'Ön Ayar',