Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stronger authentication support in Windows #257

Open
tmclean-feith opened this issue Apr 17, 2022 · 2 comments
Open

Stronger authentication support in Windows #257

tmclean-feith opened this issue Apr 17, 2022 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@tmclean-feith
Copy link

tmclean-feith commented Apr 17, 2022

When working with Windows environments the connector endpoint can be secured with TLS, however this provides little in the way of useful authentication, authorization, or auditing. The only authentication supported is the authentication key provided via the shell application or via the Windows registry (in cleartext) when using the KSP.

It looks like one can specify client certificate authentication for Linux environments when using the pkcs11 module. It would be useful to have a similar form of strong authentication in Windows environments, such as Client Certificate (mTLS) or Kerberos authentication. Ideally this would work in both the shell application as well as the KSP.

@qpernil
Copy link
Contributor

qpernil commented Apr 27, 2022

Mutual authentication with HTTPS only occurs if the server requires client certificates. yubihsm-connector itself has no support for requiring client certificates, so if this is desired then one must use some kind of reverse proxy, such as nginx, in front of the connector. If that is the case the curl-based http(s) client used in the client library used by yubihsm-shell and yubihsm-pkcs11 supports specifying client certificates to use if requested by the server. Again, note that the mutual authentication is triggered by the server (the reverse proxy in this case), not by providing these settings on the client. The windows client library uses WinHttp, the built-in http client library of Windows itself. As such it may support using client certificates configured in Windows, but no direct support is provided by the yubihsm client libraries on Windows.

It should also be noted that authentication by a proxy is not end-to-end, as it terminates in the proxy. The proxy is however not part of the trusted environment as the HSM uses a cryptographic protocol end-to-end between the client library and the HSM itself. Unlike TLS this protocol always performs mutual authentication. This protocol requires each party to have a pair of symmetric keys, which are then used to generate unique session keys for each session that is established. In the current release the client keys are derived from the password provided to the libraries, but future releases may support other means of providing the keys, such as using CryptoApi on Windows etc.

@qpernil
Copy link
Contributor

qpernil commented Sep 22, 2022

All of the the above being said, it is not unreasonable to implement https with client certificates support in the WinHttp backend, something that at first glance looks doable. Im putting that in as a feature request. Thx.

@qpernil qpernil added the enhancement New feature or request label Sep 22, 2022
@qpernil qpernil self-assigned this Sep 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

No branches or pull requests

2 participants