Information available to hook scripts is too limited
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 14.6k
- Forks
- 3.4k
- PR merge metrics
- No merged PRs in 30d
Description
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$configis 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing how OpenVPN constructs the environment for the tls-crypt-v2-verify hook, then compare it with the documented hook environment variables and the other hooks mentioned, including iproute and ipchange. Done means the relevant information available at each hook call is exposed through documented environment variables without weakening the intended security boundary.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- networking, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100