Server code modification to allow the cipher to be optional

[Alikson]

The goal is to have an Open VPN Server that allows clients to connect with or without a cipher.
Currently if a server is configured to use a cipher and a client with cipher set to "none" is trying to connect we get this warning in the log and the client is not able to connect:
"WARNING: 'cipher' is used inconsistently, local='cipher AES-128-CBC', remote='cipher [null-cipher]'".

So we want to modify the code of the server to allow clients with "none" cipher to connect as if the server was also configured not to use cipher and if a client with a matching cipher is connecting, it would also be able to connect.

We've considered using different ports for both types of clients, but we already have 8 instances of Open VPN servers running on different ports, and because of redundancy we have identical setup on 6 hosts. So doubling number of ports is no small task. Also if you consider fallback procedures, it makes changing the code seem more attractive.

Before we spend too much time trying to do this, is there anyone who can imagine the amount of work it would mean? Is it a relatively easy thing to do or a tremendous task? Is it more like tweaking the code here and there or more like changing the whole ideology of the product?

Is there anyone who'd be willing to do this for us?

All suggestions are welcome.
Thank you.

[janjust]

interesting question - I'd repost it on the #openvpn-devel IRC channel for better response.

First of all, changes like this ARE planned for OpenVPN 3.0, but there is no timeline for that at all at this moment.

It should be possible to do this, even without breaking the OpenVPN protocol, but the change is not trivial; you'd have to move the cipher (and digest) used from a global 'struct' to a session 'struct' and adjust all code to grab the cipher+digest from that. Someone who is familar with the OpenVPN codebase should be to do this in a few days time. I don't have the time to do it, unfortunately, but I think this is a very useful change. I could even foresee some negotation, e.g. on the server you specify

Code: Select all

cipher AES-256-CBC:AES-128-CBC:BF-CBC:NONE

and when a client connects and presents a similar list of ciphers than a choice can be made; you could even add stuff like

Code: Select all

cipher *

to accept any cipher.

But now I am getting ahead of things, I *think* it should be possible to do this by moving the cipher+digest to the session variables, but I may be completely wrong , of course.

[dazo]

Yes! This question pops up from time to time. And yes, this is something we seriously need to improve.

Unfortunately, JJK is 100% correct. This is slated for OpenVPN 3, because we need to do a big rewrite of OpenVPN to make it more flexible on the code base, to make it easier to implement new features.

In regards to the SSL change, I'm not too familiar with the SSL code in OpenVPN. But again what JJK says makes a lot of sense, and is most likely straight to the point. The whole SSL code in OpenVPN needs to be refactored to enable algorithm negotiation.

OpenVPN 3 is still being discussed and no time line is set for it yet. There is a roadmap [1] of how we would like things to look like, and that's the most concrete we are now. Having that said, all the 2.x releases which will come (we know for sure a 2.4 release will come and 2.3 is getting more and more ready for alpha/beta releases) will bring us all closer to OpenVPN 3. We will work to get the 2.x code base more and more modularised, which will make the move to OpenVPN 3 smoother. And the SSL layer has already gotten a good rewrite in 2.3 (including an improved in-code documentation) - making it much more modular, so a further development here definitely possible.

If somebody manages to look at the code, this could even be included in a 2.5 release or 2.4 if it happens soonish.


kind regards,

David Sommerseth


[1] https://community.openvpn.net/openvpn/wiki/RoadMap