From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Status update on openvpn work
Date: Sat, 14 Oct 2023 13:19:34 +0100 [thread overview]
Message-ID: <4BCA2F43-E9B4-4EC2-BA4B-1EA004305317@ipfire.org> (raw)
In-Reply-To: <de3710bf39496420f58b33ec3a8c2a18b35ee36d.camel@ipfire.org>
[-- Attachment #1: Type: text/plain, Size: 9954 bytes --]
Hello,
Although not ideal, I think it is acceptable for a RW client to renegotiate once every 24 hours. It is simply not practical to do this more often than once a day when using OTP.
But we would potentially set the default back to 1hr, and check if we can set reneg-sec to 24h in the CCD for connections that have OTP enabled?!
-Michael
> On 12 Oct 2023, at 12:30, ummeegge <ummeegge(a)ipfire.org> wrote:
>
> Your welcome.
> If you are in state of completing the blog post you can send it again
> to overread it so we all can speak about it, as an offer from me.
>
> I would really also recommend to make the cipher renegotiation
> configurable via WUI. Since the release of 2FA it has been hardcoded
> -->
> https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/ovpnmain.cgi;h=eb89c5095569ccd691772a4fb9f314ecd3fd1257;hb=refs/heads/next#l368
> to 48 hours which in a practical way or in fact disables the PFS also
> for users which do not use 2FA whereby the OpenVPN default, also with
> potential secure ciphers, are configured to 1 hour to renegotiate a new
> session key.
>
> Best,
>
> Erik
>
> Am Donnerstag, dem 12.10.2023 um 11:36 +0200 schrieb Adolf Belka:
>> Hi Erik,
>>
>> On 12/10/2023 08:06, ummeegge wrote:
>>> Am Donnerstag, dem 12.10.2023 um 07:56 +0200 schrieb ummeegge:
>>>>> OpenVPN plan to remove those weak ciphers completely in version
>>>>> 2.7
>>>>> If a user at that time still had a client with say BF-CBC would
>>>>> the
>>>>> negotiation still work then or would it fail because OpenVPN no
>>>>> longer
>>>>> recognises the old weak cipher?
>>>> This is true according to the OpenVPN 'Deprecated Option' wiki --
>>>>>
>>>> https://community.openvpn.net/openvpn/wiki/DeprecatedOptions#Policy:Migrateawayfromdeprecatedciphers.Status:Inprogress
>> I had seen that overall page before but obviously not read the
>> details
>> well enough of that specific entry. The entry makes it clear that
>> from
>> openvpn-2.7 onwards the 64 bit ciphers will no longer be accepted
>> even
>> as data-fallback ones.
>>>> that´s causes, beneath the OpenSSL-3.x decision, to leave the
>>>> deprecated ciphers out of the Roadwarrior list (N2N is another
>>>> thing
>>>> since it do no understands cipher negotiation) but pushed at that
>>>> time
>>>> an idea to bring on some warnings for the users before the IPFire
>>>> decision to leave the broken ciphers out of any list since the
>>>> server
>>>> can not see what client configuration is in place.
>>> To correct this statement, mostly users do not see/recognize such
>>> warnings in the OpenVPN logs, the server does see it!
>> I see what you are saying. The users tend not to look at their logs
>> and
>> so will miss the message about the 64 bit BF-CBC etc being removed
>> from
>> 2.7 onwards.
>>
>> So having the 64 bit ciphers in the data-fallback table but not
>> allowing
>> them to be used and instead giving a warning message about the cipher
>> being removed in the future is a way to make the changes more visible
>> that the user needs to do and the potential timing scenario.
>>
>> I think I will also need to put together a supporting info blog post
>> on
>> the openvpn changes that will come with the IPFire updates being
>> worked
>> on and the future ones with openvpn-2.7
>>>> This patch can be found in here -->
>>>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f42776f1b60660f4e862d6e847e746b9411b
>> Thanks for the clarification.
>>
>> Regards,
>> Adolf.
>>>>> Regards,
>>>>>
>>>>> Adolf.
>>>> Best,
>>>>
>>>> Erik
>>>>
>>>>>>> Then pressed Start OpenVPN Server and nothing happened.
>>>>>>> Checked
>>>>>>> the
>>>>>>> logs and there is the openssl error
>>>>>>>
>>>>>>> OpenSSL: error:0308010C:digital envelope
>>>>>>> routines::unsupported
>>>>>>>
>>>>>>> which occurs because Openssl-3.x doesn't support the older
>>>>>>> ciphers
>>>>>>> like BF unless legacy is selected. In this case I think it
>>>>>>> is
>>>>>>> the
>>>>>>> OpenVPN server conf file that requires the
>>>>>>>
>>>>>>> providers legacy default
>>>>>>>
>>>>>>> to be included, rather than the client conf file.
>>>>>>>
>>>>>>> Still it does feel like two steps forward and one backwards
>>>>>>> so
>>>>>>> overall still making progress.
>>>>>>>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Adolf.
>>>>>> Best,
>>>>>>
>>>>>> Erik
>>>>>>> On 09/10/2023 14:05, Adolf Belka wrote:
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>>
>>>>>>>> Over the last week I have been working on the openvpn
>>>>>>>> update
>>>>>>>> using
>>>>>>>> Erik's previous patches as my starting point.
>>>>>>>>
>>>>>>>> My first attempt to try and be able to understand the
>>>>>>>> changes
>>>>>>>> from
>>>>>>>> each patch to figure out what I needed to do proved
>>>>>>>> difficult
>>>>>>>> for
>>>>>>>> me to work with.
>>>>>>>>
>>>>>>>> What I then did was take the current ovpnmain.cgi and
>>>>>>>> apply
>>>>>>>> all
>>>>>>>> of
>>>>>>>> Erik's patches to it.
>>>>>>>>
>>>>>>>> Then I have gone through that new version of ovpnmain.cgi
>>>>>>>> and
>>>>>>>> made
>>>>>>>> the changes based on previous discussions with Michael.
>>>>>>>>
>>>>>>>> So I have removed the b2sum options that were present for
>>>>>>>> the
>>>>>>>> Data
>>>>>>>> and Channel Authentication.
>>>>>>>>
>>>>>>>> I also moved all the cryptographic options from an
>>>>>>>> additional
>>>>>>>> advanced cryptographic options button into the Advanced
>>>>>>>> Server
>>>>>>>> options button.
>>>>>>>>
>>>>>>>> I was successful in doing all the above and then tested
>>>>>>>> the
>>>>>>>> ovpnmain.cgi out with a vm using the existing openvpn-
>>>>>>>> 2.5.9
>>>>>>>> version
>>>>>>>> for openvpn.
>>>>>>>>
>>>>>>>> My old profile for my laptop which had a ciphers entry
>>>>>>>> worked
>>>>>>>> without any problem. My laptop was working withy openvpn-
>>>>>>>> 2.6.6
>>>>>>>>
>>>>>>>> I then created a new profile using the new ovpnmain.cgi
>>>>>>>> using
>>>>>>>> the
>>>>>>>> negotiation option which ended up with a data-ciphers
>>>>>>>> line.
>>>>>>>> That
>>>>>>>> also worked in making a successful openvpn tunnel with my
>>>>>>>> laptop
>>>>>>>> without any issues.
>>>>>>>>
>>>>>>>> I then downgraded my laptop to openvpn-2.4.8 and had to
>>>>>>>> install
>>>>>>>> openvpn-1.1.1 to make that work.
>>>>>>>>
>>>>>>>> With that client version on my laptop both the old and
>>>>>>>> new
>>>>>>>> profiles
>>>>>>>> connected with a tunnel with no problems.
>>>>>>>>
>>>>>>>> I then tried downgrading my laptop to openvpn-2.3.14 but
>>>>>>>> to
>>>>>>>> make
>>>>>>>> this work I would have had to downgrade the laptop to
>>>>>>>> openssl-
>>>>>>>> 1.0.0
>>>>>>>> which I was not willing to do as that is very old and
>>>>>>>> very
>>>>>>>> insecure.
>>>>>>>>
>>>>>>>> The oldest openvpn version working with openssl-1.1.1 is
>>>>>>>> 2.4.0
>>>>>>>> which is nearly 7 years old.
>>>>>>>>
>>>>>>>> That version also worked with both the old and new laptop
>>>>>>>> profiles.
>>>>>>>>
>>>>>>>> I then tested out the openvpn server on my IPFire vm with
>>>>>>>> a
>>>>>>>> 2.6.0
>>>>>>>> and 2.6.6 version of openvpn.
>>>>>>>>
>>>>>>>> Both these openvpn versions worked with both the old and
>>>>>>>> new
>>>>>>>> laptop
>>>>>>>> connection profiles with my laptop on version 2.4.0 and
>>>>>>>> on
>>>>>>>> 2.6.6
>>>>>>>>
>>>>>>>> All the above was using network manager with its openvpn
>>>>>>>> plugin
>>>>>>>> option on the laptop for making the openvpn tunnel
>>>>>>>> connections.
>>>>>>>>
>>>>>>>> As far as I can tell everything is working fine when
>>>>>>>> negotiation is
>>>>>>>> specified on the server. Old profiles that just use the
>>>>>>>> cipher
>>>>>>>> option also work fine. Therefore my plan is to only use
>>>>>>>> the
>>>>>>>> negotiation option and not make it selectable for older
>>>>>>>> clients.
>>>>>>>> The data-ciphers-fallback option in the server seems to
>>>>>>>> be
>>>>>>>> doing
>>>>>>>> its job.
>>>>>>>>
>>>>>>>> The negotiation option on the server was able to connect
>>>>>>>> to a
>>>>>>>> 2.4.0
>>>>>>>> client on my laptop.
>>>>>>>>
>>>>>>>> According to the OpenVPN wiki on cipher negotiation the
>>>>>>>> data-
>>>>>>>> ciphers-fallback option will work with 2.4.x and 2.3.x
>>>>>>>> clients.
>>>>>>>> As
>>>>>>>> the 2.3.x clients need to be using openssl-1.0.0 then I
>>>>>>>> think
>>>>>>>> if
>>>>>>>> those clients work then fine but nothing further back.
>>>>>>>>
>>>>>>>> Overall, I am very happy with what I have succeeded in
>>>>>>>> doing
>>>>>>>> so
>>>>>>>> far. I achieved things much quicker than I had expected.
>>>>>>>>
>>>>>>>> I will now try and see about creating a profile on a CU
>>>>>>>> 179
>>>>>>>> based
>>>>>>>> system that uses one of the old insecure ciphers such as
>>>>>>>> Blow
>>>>>>>> Fish
>>>>>>>> and restore that into my evaluation vm and see how that
>>>>>>>> works
>>>>>>>> with
>>>>>>>> my laptop when I have it downgraded to openvpn-2.4.0
>>>>>>>>
>>>>>>>> I already know that if the laptop is at openvpn-2.6.6
>>>>>>>> then it
>>>>>>>> will
>>>>>>>> not accept a blowfish cipher (or another weak cipher such
>>>>>>>> as
>>>>>>>> DES)
>>>>>>>> as that is something I tested in the past.
>>>>>>>>
>>>>>>>> If that also works then my plan will be to take the
>>>>>>>> updated
>>>>>>>> ovpnmain.cgi and split the changes into a new range of
>>>>>>>> patches
>>>>>>>> and
>>>>>>>> then submit them for consideration.
>>>>>>>>
>>>>>>>> That will probably end up later in November as I will be
>>>>>>>> busy
>>>>>>>> with
>>>>>>>> personal things at the end of October / beginning of
>>>>>>>> November.
>>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>> Adolf.
>>>>>>>>
>>
>
next prev parent reply other threads:[~2023-10-14 12:19 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-09 12:05 Adolf Belka
2023-10-09 17:26 ` Adolf Belka
2023-10-11 14:20 ` ummeegge
2023-10-11 15:53 ` Adolf Belka
2023-10-11 20:15 ` Adolf Belka
2023-10-12 5:56 ` ummeegge
2023-10-12 6:06 ` ummeegge
2023-10-12 9:36 ` Adolf Belka
2023-10-12 11:30 ` ummeegge
2023-10-13 12:52 ` Adolf Belka
2023-10-14 12:20 ` Michael Tremer
2023-10-14 13:15 ` Adolf Belka
2023-10-18 9:05 ` ummeegge
2023-10-18 18:48 ` Michael Tremer
2023-10-18 19:39 ` Adolf Belka
2023-10-19 8:02 ` ummeegge
2023-10-19 10:28 ` Adolf Belka
2023-11-17 8:25 ` ummeegge
2023-10-19 8:07 ` ummeegge
2023-10-14 12:19 ` Michael Tremer [this message]
2023-10-18 9:15 ` ummeegge
2023-10-14 12:13 ` Michael Tremer
2023-10-14 14:21 ` Adolf Belka
2023-10-14 12:12 ` Michael Tremer
2023-10-14 12:11 ` Michael Tremer
2023-10-14 14:17 ` Adolf Belka
2023-10-15 10:45 ` Michael Tremer
2023-10-14 12:10 ` Michael Tremer
2023-10-18 9:18 ` ummeegge
2023-10-14 12:08 ` Michael Tremer
2023-10-14 14:12 ` Adolf Belka
2023-10-15 10:44 ` Michael Tremer
2023-10-15 12:43 ` Adolf Belka
2023-10-16 10:02 ` Michael Tremer
2023-10-19 10:37 ` Adolf Belka
2023-10-14 12:05 ` Michael Tremer
2023-10-14 13:57 ` Adolf Belka
2023-10-15 13:43 ` Adolf Belka
2023-10-16 10:05 ` Michael Tremer
2023-10-18 9:29 ` ummeegge
2023-10-18 9:55 ` Adolf Belka
2023-10-18 10:26 ` ummeegge
2023-10-19 10:42 ` Adolf Belka
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4BCA2F43-E9B4-4EC2-BA4B-1EA004305317@ipfire.org \
--to=michael.tremer@ipfire.org \
--cc=development@lists.ipfire.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox