Hi Selva,
On 05/05/21 15:29, Selva Nair wrote:
On Wed, May 5, 2021 at 4:00 AM Jan Just Keijser <janj...@nikhef.nl> wrote:
On 05/05/21 07:18, selva.n...@gmail.com wrote:
From: Selva Nair <selva.n...@gmail.com>
If either --cert or --key is specified as a PKCS#11 uri, try to
load the certificate and key from any accessible PKCS#11 device.
This does not require linking with any pkcs11 library, but needs
pkcs11 engine to be available on the target machine.
In its simplest form, just have
--cert pkcs11:token=...;serial=... etc..
Either do not specify --key, or use the same uri for --key.
That's all what is required if pkcs11 engine is installed in the
right location and optionally set up to load any necessary provider
libraries (e.g., via openssl.cnf or via PKCS11_MODULE_PATH).
If both cert and key are specified, the last entry takes precedence
and is used to locate both the certificate and key. Use of different
uri's for the cert and key are not supported -- at least not in
this version. Specifying --cert as a file and --key as a uri or
vice versa is treated as a usage error.
If the engine cannot be automatically loaded or a custom engine object
has to be loaded, the engine name or shared libraryx may be embedded
in the PKCS#11 uri. The module shared object path also may be so
embedded. For example,
pkcs11:token=..;serial=...;engine=pkcs11.so;provider=libsofthsm2.so
will use engine with id=pkcs11 and load libsofthsm2.so.
Full path to the libraries may be included as required. These extra,
optional attributes in the URI are stripped before presented to the
PKCS#11 subsystem. Do not include type=cert or type=private in the uri
as the same uri is used for both certificate and private key.
Requires building with OpenSSL engine support although the pkcs11 or
a compatible engine and provider libraries are required only at
run time.
Great patch, but I see one possible security issue upsream with the
ability to specify the pkcs11 driver:
Right now, Linux tools like NetworkManager-openvpn allow a non-root user
to specify certain parameters, like cert, key etc in either a GUI or a
config file.
These tools will *all* need to be updated to take into account (or most
likely : BLOCK) the use of
cert pkcs11: ....
as otherwise a rogue user can specify a pkcs11 driver with a backdoor,
which NetworkManager would then happily pass on to the openvpn which
runs as root ....
I had first had --pkcs11-id used for this but currently all pkcs11
related options are conditional on ENABLE_PKCS11 which depends on
pkcs11-helper. Allowing a subset of those options leads to messy
ifdefs which I didn't like.
Maybe I'll have to resurrect that idea or require --script-security 2
for this? In either case the core code will stay the same -- will wait
for a review and/or more comments before changing anything.
wouldn't it make more sense to use the (existing) "--engine" parameter
for this? this is closely related to OpenSSL engines (even though the
pkcs11 module is not loaded directly) .
That way it will be fairly easy for tools like NetworkManager-openvpn to
filter out any unwanted stuff.
Also, another option would be to allow the loading of a pkcs11 module
but *only* from predefined locations (e.g. /usr/lib or /usr/lib64) .
This predefined location would then need to be configured at compile time.
JM2CW,
JJK
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
