Support for IKEv2 OCSP Extensions (RFC 4806)
Support for the IKEv2 OCSP extensions (RFC 4806) has been added, which allows peers to request and send OCSP responses together with their certificate chain directly in IKEv2.
OCSP responses for local certificates are retrieved via revocation plugin, either from the cache or fetched from an OCSP server. The feature can be controlled via <conn>.ocsp setting in swanctl.conf. By default, OCSP responses are sent if the peer requests any and a response can be retrieved.
When establishing an IKE_SA, both peers may send OCSP responses, and, as with OCSP in general, OCSP signing may be delegated to a designated OCSP signer, which is illustrated by the ikev2/ocsp-rfc4806-both and ikev2/ocsp-rfc4806-signer test scenarios, respectively.
If sending requests is enabled, the implementation generally sends an empty OCSP certificate request payload. Only if self-signed OCSP signer certificates are found locally will their public key's hash be added to the payload. Such certificates must either have the OCSPSigning extended key usage flag set, or be placed in the x509ocsp directory so that they are flagged when loaded. See the ikev2/ocsp-rfc4806-local test scenario for an example.
Improved X.509 Name Constraints Validation
Validation of X.509 name constraints has been refactored to align with RFC 5280. This fixes several limitations of the previous implementation. Name constraints are now correctly propagated from the root of the certificate chain so that intermediate CA certificates don't have to explicitly inherit the name constraints of their parents anymore. The latter previously prevented adding constraints in an intermediate CA certificate that's followed by another that doesn't contain any name constraints. This is perfectly fine as the set of constraints specified by the parent continue to apply to that intermediate CA certificate and the children it issues.
Identities also don't have to match all name constraints of the same type anymore, which prevented actually encoding multiple constraints of the same type because e.g. for the permitted name constraints for example.org and example.com no acceptable certificates could be issued as any SAN with one domain would get rejected by the other constraint. In compliance with the RFC, matching a single constraint is now enough.
Also resolved is an issue with name constraints for IP addresses (added with 5.9.12), which were previously only supported for a single level.
Managed Configurations in Android App
Our Android app now supports managed configurations via enterprise mobility management (EMM) systems. Besides configuring global settings and VPN profiles (with settings similar to those supported in profile files, including certificates), this also provides management options for disabling certain features of the app (e.g. to prevent users from creating and/or importing custom profiles or to only display managed profiles).
Other Notable Features and Fixes
- Added support for PSS padding for smartcard-based RSA signatures to the pkcs11 plugin, using either on-chip or external data hashing.
- Added keyid and certid handles to the
pki --ocspcommand so that keys and/or certificates can be stored on a smartcard or in a TPM 2.0 device - The dhcp plugin has been ported to FreeBSD/macOS. The code for BPF handling has been refactored and is now shared between dhcp and farp plugin.
- The openssl plugin is now compatible to AWS-LC, a crypto library based on code from BoringSSL and OpenSSL.
- Overflows of unique identifiers (e.g. Netlink sequence numbers or reqids) are now handled gracefully.
- Fail SA installation on Linux if replay protection is disabled while ESN is enabled, which the kernel currently doesn't support.