public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: Adolf Belka <adolf.belka@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Status update on openvpn work
Date: Wed, 11 Oct 2023 17:53:32 +0200	[thread overview]
Message-ID: <717b0e5a-6d7a-49f5-8de7-3a7d4bbb4264@ipfire.org> (raw)
In-Reply-To: <38c71efa59af4c9e3fafa8d3862b145cd6458204.camel@ipfire.org>

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

Hi Erik,


On 11/10/2023 16:20, ummeegge wrote:
> Hi Adolf,
>
> Am Montag, dem 09.10.2023 um 19:26 +0200 schrieb Adolf Belka:
>> Hi All,
>>
>> I thought it was too good to be true.
>>
>> Before creating a client connection with something like BlowFish I
>> thought I would just test the server settings with selecting BF in
>> the data-ciphers-fallback selection box.
> Have disabled all the 64 bit block cipher in my previouse patches since
> the cipher negotiaton managed the whole thing. I think AEAD ciphers are
> since OpenSSL-1.0.1 available so if AES-GCM is available in --data-
> ciphers, the clients will use them even BF-CBC is set in client.ovpn .
> We have had a conversation about this also with some tests which you
> can find in here -->
> https://community.ipfire.org/t/openvpn-2-6-development-version/8603/3
Thanks for the feedback and the link to our conversation at the 
beginning of this year.

So even if the user has BF-CBC set in the client.ovpn, with the server 
having server negotiation in this update then the client will end up 
getting connected with an available cipher from the data-ciphers list.
I will do a test of that then on my system

If my understanding is correct, then why do we need to still leave the 
weak ciphers in the data-fallback list. Those could also be removed, 
they are blocked anyway.

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?

Regards,

Adolf.

>> 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.
>>>

-- 
Sent from my laptop


  reply	other threads:[~2023-10-11 15:53 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 [this message]
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
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=717b0e5a-6d7a-49f5-8de7-3a7d4bbb4264@ipfire.org \
    --to=adolf.belka@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