Hi,
I think a nice solution would be to rebuild the X509_STORE of the
SSL_CTX when a SIGHUP ou SIGUSR1 arrived. But I do not understand yet
enough the code of OpenVPN :
- where can I add an action when a SIGUSR1 or SIGHUP is handled ?
- how can I get the (list of ?) SSL_CTX object ?
Do you think that it is a good idea, and do you think that it is feasible ?
Because of OpenVPN's security architecture, it is very common for a
privilege downgrade or chroot to occur after initialization. This means
that it may not be possible to re-read a file after initialization.
This is a major reason why OpenVPN handles CRLs the way it does now: so
that (a) the OpenVPN daemon need not be restarted after a CRL update, and
(b) the CRL file itself can be located in the chroot jail without
requiring that the private key or any other files reside there as well.
Ok, I see the issue :
CRL are in the "--capath" directory, so in the chroot jail. But CA
certificates can be presents in this directory too. It can be a problem
if an attacker managed to add a false CA & CRL in this directory : the
CA will be directly accepted by openvpn, so the signed certificates will
be accepted too, without any restart.
In fact, I think that all openssl systems with a "--CAPath" option must
have read access to the directory. So it's not a pure openvpn "bug"...
(note: a very nice feature could be to be able to add CRLs via the new
managment port...)
Can you explain me very quickly where and how I can add a
"x509_stores_reset()" function in openvpn, that it will be executed when
a sigusr1 is received? I'm sorry but I do not clearly understand the
signal managment in "sig.c".
Having said all that, I think --capath + X509_V_FLAG_CRL_CHECK is a good
idea, as a more full-featured alternative to --crl-verify, when people
don't mind needing to restart the daemon to re-read the CRL files.
Restart OpenVPN is a problem for me : our tunnels are used for
"real-time" apps (hundreds of Windows TSE clients), I cannot stop them
and break all TSE clients in case of a simple revocation... :-(
The ultimate solution will be OCSP, but... we are in 2005 ;-)
Thank you for your attention about this issue.
--
Thomas NOEL <thomas.n...@auf.org> http://www.auf.org/
Coordinateur des infrastructures techniques
Agence universitaire de la Francophonie (AUF)
Services centraux Paris - 4 place de la Sorbonne - 75005 Paris
Tél: +33 (0)1 44 41 18 18, poste 1822 Tlc: +33(0)1 44 41 18 19
> Merci d'éviter de m'envoyer des documents Word ou PowerPoint
> cf http://www.gnu.org/philosophy/no-word-attachments.fr.html
