Re: OpenVPN-2.7.1

[Michael Tremer <michael.tremer@ipfire.org>]

Hello Adolf,

Thanks for raising this.

I suppose we should be fine. I would just leave what we have in our configuration right now and eventually remove it. By then, it should already not be used by any client at all. At the moment, I cannot think of a client implementation that would so old that it would rely on plain old DH to work. But it wouldn’t do us any harm to leave it in there since we already have it.

I just merged the branch. Thanks for working on this. I am not feeling very scared about this update, but it is yet another large one very briefly after the previous 2.6 release in IPFire. Fingers crossed that we caught everything right the first time and that we will now be able to earn the fruits of our hard work.

Best,
-Michael

> On 11 Apr 2026, at 13:02, Adolf Belka <adolf.belka@ipfire.org> wrote:
> 
> Hi Michael & Erik,
> 
> I have submitted a patch set for the update to openvpn-2.7.1
> 
> One thing I noticed when scanning through the changelog notes is the following two entries.
> 
> ** Use of --dh dh2048.pem in all sample configs has been replaced with --dh none. The dh2048.pem file has been removed.
> 
> ** --dh none is now the default if --dh is not specified. Modern TLS implementations will prefer ECDH and other more modern algorithms anyway. And finite field Diffie Hellman is in the proces of being deprecated (see draft-ietf-tls-deprecate-obsolete-kex)
> 
> We are not using dh2048, we are using ffdhe4096 which looks to me like it might be a finite field Diffie Hellman. If that is the case then at some time in the future it looks like it will be deprecated. Looking through that draft ietf document I was unable to determine if this deprecation will only apply to 2048 that is mentioned in the openvpn-2.7.0 changelog or if it will also apply to our use of 4096 bit.
> 
> I thought I would flag it so that others more knowledgeable than me could decide.
> 
> I thought it would be good to know early if this was going to affect us so that it can be decided how to manage that before it becomes a requirement (if that is in fact the case).
> 
> Regards,
> 
> Adolf.
> 
>