mbox series

[Openvpn-devel,0/1] CRL reloading issue with mbedTLS and chroot

Message ID E1lSHvL-0007TM-Ii@sfs-ml-2.v29.lw.sourceforge.com
Headers show
Series CRL reloading issue with mbedTLS and chroot | expand

Message

Maximilian Fillinger April 2, 2021, 12:24 a.m. UTC 
There is an issue with the mbedTLS version of OpenVPN where a CRL file
wouldn't be used when running in a chroot. This is due to a combination
of two bugs found by Adam Lukosek at Compumatica.

1) With mbedTLS, if the CRL file can't be opened during initialization,
   OpenVPN will read the file when it becomes available later, but it
   will not actually use it. This situation is likely to happen when
   running in a chroot because...

2) When a file needs to be opened both pre- and post-chroot, OpenVPN
   will try to open the path outside of the chroot directory. For
   example, let's say we have the CRL file in "/chroot/crl.pem", and we
   run OpenVPN with "--chroot /chroot/" and "--crl-verify /crl.pem".
   During option validation, OpenVPN will check that "/chroot/crl.pem"
   exists. Pre-chroot, it will try to open "/crl.pem", which fails.
   Post-chroot, it opens the file.

In my patch, I fix issue 1). I don't find it very elegant, but the only
other solution I saw was to add function arguments to ssl_backend.h
functions that are only relevant for mbedTLS. I'd be happy to hear other
suggestions!

I think that issue 2) should be addressed as well. Reloading CRLs does
work with OpenSSL, but there's still a possibility that OpenVPN reads
different files pre- and post-chroot.
(E.g., imagine a user updates "/crl.pem" but forgets "/chroot/crl.pem".)

I would like to always prefix the chroot-path when opening a file that
needs to be available post-chroot during init. However, this might break
some existing setups. Does that seem like a good idea to you?


Finally, I noticed a behavior that seems inconsistent to me: When
OpenVPN cannot parse a CRL file, it will reject all connection attempts.
When it cannot stat a CRL file, it will continue without a CRL. Is there
a reason why it has to work that way?

I saw this behavior with both mbedTLS and OpenSSL. My patch accidentally
fixed it for mbedTLS.

Maximilian Fillinger (1):
  Let mbedtls_ssl_configs find reloaded CRLs

 src/openvpn/ssl.c         | 11 +++++++++++
 src/openvpn/ssl_mbedtls.c | 13 +++++++++++++
 src/openvpn/ssl_mbedtls.h |  3 +++
 3 files changed, 27 insertions(+)