In particular, the tls-crypt-v2-verify hook script doesn't even get envvars configured via setenv or setenv-safe, or $config, passed in; only $metadata_file, $metadata_type and $script_type are set.
(In less recent experiments, the iproute script didn't have $script_type, and the ipchange hook didn't have $dev.)
Expected behaviour
Hook scripts should have all the information available to openvpn at the time of their calling passed in in the documented envvars.
Version information (please complete the following information):
OS: Debian sid
OpenVPN version: 2.6.7-1
Additional context
My particular use case is that I tried to follow the openvpn-nl deployment guide which recommends the following:
use tls-crypt-v2
in client metadata, include the fingerprint of the CA used to sign the client cert, as well as the client cert serial
in the tls-crypt-v2-verify script, check that the fingerprint matches what the server expects
in the tls-crypt-v2-verify script, check that the client cert serial is not on the CRL.
(The idea is to reduce the attack surface by performing these checks before exposing the TLS stack to an attacker.)
To implement these checks I'd have to either
hardcode the CA cert fingerprint and the CRL location in the script, OR
parse the location of the CA cert and the CRL out of the configuration (and obtain the path to the configuration by parsing it out of /proc/$PPID/cmdline, since not even $config is available) OR
pass the CA cert fingerprint (or path to the CA cert) and the CRL location to the script as command line arguments, adding redundancy to the configuration.
I checked with the folks in #openvpn-devel and the consensus was that the current behaviour is intentional and is, IMO ironically, meant to "reduce the attack surface".
I don't agree that withholding available information that's not controlled by the client (who is a potential attacker) from hook scripts is a good way of reducing the attack surface. As explained above, the actual result is that it makes the hook scripts more expensive to maintain and/or unnecessarily complex.
Please reconsider the decision to deliberately withhold information from hook scripts.
In particular, the tls-crypt-v2-verify hook script doesn't even get envvars configured via
setenv
orsetenv-safe
, or$config
, passed in; only$metadata_file
,$metadata_type
and$script_type
are set.(In less recent experiments, the
iproute
script didn't have$script_type
, and theipchange
hook didn't have$dev
.)Expected behaviour
Hook scripts should have all the information available to openvpn at the time of their calling passed in in the documented envvars.
Version information (please complete the following information):
Additional context
My particular use case is that I tried to follow the openvpn-nl deployment guide which recommends the following:
(The idea is to reduce the attack surface by performing these checks before exposing the TLS stack to an attacker.)
To implement these checks I'd have to either
/proc/$PPID/cmdline
, since not even$config
is available) ORI checked with the folks in #openvpn-devel and the consensus was that the current behaviour is intentional and is, IMO ironically, meant to "reduce the attack surface".
I don't agree that withholding available information that's not controlled by the client (who is a potential attacker) from hook scripts is a good way of reducing the attack surface. As explained above, the actual result is that it makes the hook scripts more expensive to maintain and/or unnecessarily complex.
Please reconsider the decision to deliberately withhold information from hook scripts.