OpenVPN Support Forum

Hello,

I'm using OpenVPN in a distributed server with a read-only filesystem. Each time a computing node spawns a process, it imports all my OpenVPN settings from a distributed RQLite database.

The RQLite database is itself distributed among multiple computing nodes, so ideally the system has no single point of failure (I mean outages, not bugs or security breaches.)

Converting database entries to command line options and temporary RAM-backed files is not a problem if done once at OpenVPN start time - after all OpenVPN only reads these files once before dropping privileges.

But Certificate Revocation Lists (CRLs) are posing a problem, I need to keep updating the CRL file from the database and this is fraught with dangers and difficulties. The filesystem is complicated to get right, especially in a security sensitive environment. Files can be half-written when OpenVPN reads them. A "fake" filesystem like FUSE or WinFSP is better, but still a security liability. I would prefer that OpenVPN calls a script that returns the current CRL through STDOUT, named pipe, temporary file, or similar. At least I can flush the file before returning from the script to make sure it's not torn in the middle. I think this could be a useful feature for anyone running OpenVPN in a read-only filesystem environment.

I am willing to make the changes myself (I'm looking at tls_ctx_reload_crl() in ssl.c) but I'd want to know if this patch will get incorporated into OpenVPN, before I invest the effort.

Hi,

I would suggest to send your wish to the mailing list:
https://sourceforge.net/projects/openvp ... nvpn-users
and/or join irc channel #openvpn on libera.chat

ePluribusUnum wrote: ↑

Mon Sep 26, 2022 7:19 pm

I would prefer that OpenVPN calls a script that returns the current CRL through STDOUT, named pipe, temporary file, or similar. At least I can flush the file before returning from the script to make sure it's not torn in the middle. I think this could be a useful feature for anyone running OpenVPN in a read-only filesystem environment.

If you have a reproducable bug then you can raise an issue here:

https://community.openvpn.net/openvpn/report [login required]

Or you could document it here on the form.

It looks like you are asking for your server to terminate in the event of a corrupted CRL file ?

I'm trying to update the CRL file atomically, so OpenVPN never reads a partially updated file. I know I can use renameat2() in Linux in instantaneously swap in a new file overtop an old one, but the easier cross platform solution is just to have an option to call a script that returns the CRL list, in addition to being able to read it in from a file.

I'll check with the mailing list

You have a problem copying a file. It makes no difference that it is a CRL.

Fix your copying method.

ePluribusUnum wrote: ↑

Tue Sep 27, 2022 3:12 pm

the easier cross platform solution is just to have an option to call a script that returns the CRL list

The script will have to read the list from somewhere else, no? How do you atomically update this "somewhere else"? IMHO you are just moving the problem.

This said, renaming a temporary file seems the most reasonable approach to me

ordex wrote: ↑

Tue Sep 27, 2022 8:51 pm

ePluribusUnum wrote: ↑

Tue Sep 27, 2022 3:12 pm

the easier cross platform solution is just to have an option to call a script that returns the CRL list

The script will have to read the list from somewhere else, no? How do you atomically update this "somewhere else"? IMHO you are just moving the problem.

This said, renaming a temporary file seems the most reasonable approach to me

The something else is a transactional database, so yes I can update it atomically using the SQL "START TRANSACTION" semantics.

The filesystem is surprisingly complicated, which means increased attack surface. The nuances and caveats vary OS to OS, version to version. Assuming a read-only hard drive mount (eg. an embedded IOT application), it requires mounting an entire tmpfs filesystem just for this one little thing. I'm not even sure how that's done on Windows. It might be okay for a prototype, but isn't great for production.

The other thing to consider is that the CRL is verified at client connection time, so anything introducing latency here will result in slowing down the server while authenticating clients, and new clients may queue up.

I presume you know this, but wanted to thrown in this aspect when thinking about alternative methods.

ordex wrote: ↑

Tue Sep 27, 2022 8:51 pm

ePluribusUnum wrote: ↑

Tue Sep 27, 2022 3:12 pm

the easier cross platform solution is just to have an option to call a script that returns the CRL list

The script will have to read the list from somewhere else, no? How do you atomically update this "somewhere else"? IMHO you are just moving the problem.

This said, renaming a temporary file seems the most reasonable approach to me

I'm guessing that this would be a new option called --update-crl <SCRIPT>

I think the current --tls-verify could be abused.

TinCanTech wrote: ↑

Tue Sep 27, 2022 9:47 pm

I think the current --tls-verify could be abused.

Yeah, this is probably a good idea. In --tls-verify it is possible to define any custom logic that will decide to accept or reject a certificate.