public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
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:12:31 +0100	[thread overview]
Message-ID: <02A91AD1-28F5-4FD7-9E58-246F4E6DED16@ipfire.org> (raw)
In-Reply-To: <3af89cd55d28e489b235d6035e5620ec8868485e.camel@ipfire.org>

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



> On 12 Oct 2023, at 07:06, ummeegge <ummeegge(a)ipfire.org> 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
>> 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!

We generally do not expect people to read the logs like this. And even if people did notice in the past, there is no way how they could have changed their configuration through the web UI to make it go away...

> 
>> This patch can be found in here --> 
>> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=dd11f42776f1b60660f4e862d6e847e746b9411b
>> 
>>> 
>>> 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.
>>>>>> 
>>> 
>> 
> 


  parent reply	other threads:[~2023-10-14 12:12 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
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 [this message]
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=02A91AD1-28F5-4FD7-9E58-246F4E6DED16@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