Openssl Error OpenVPN 2.4.9 Windows 10

[krudas74]

I am using the Virtual Smart Card on my TPM Chip to have my private key there unexportable. Since I changed to version 2.4.9 I got this errors:
OpenSSL: error:C506D064:microsoft cryptoapi:NCryptSignHash:Diese Smartcard unterstützt das angeforderte Feature nicht. (smartcard does not support feature)
OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
If I go back to 2.4.8. it works well without any changes

[Selva Nair]

This is likely because your card doesn't support pss padded signature (RSA-PSS) which is required for TLS 1.3 and may be the default even for TLS 1.2 in OpenSSL 1.1.1.

Log with verb=4 will show more info including the signature algorithm being used.

[Gert Döring]

@selva: I'm tempted to close this ("no response in two months").

I'm curious, though, if OpenVPN could be made to fall back to the older padding (under some conditons)? While I merged all these patches, I still do not understand any of this... so asking very naively.

[Selva Nair]

Yes, ideally we should be restricting the sigalgs in ssl_ctx to a list of algorithms supported by the card. We leave it at default and OpenSSL presents to the server a list that it internally supports. That's not quite right thing to do when the signature is provided by an external library or hardware.

Not hard to do if there is a reliable API to query the crypto provider what algorithms the card can handle (I haven't checked). A much easier path would be to add an option like --sigalgs-list and allow the user to restrict the signature algorithms.

In this particular case, TLS 1.1 (and 1.2 with OpenSSL 1.1.0 and older) should work out of the box, TLS 1.2 + OpenSSL 1.1.1 could be made to work with changes like above, 1.3 cannot work.

[kwinz]

I have the exact same issue as the bug reporter. And the same use-case. My client certificate is secured by the TPM backed Virtual Smartcard.
Please don't close this issue without fixing it. I would gladly provide more information.

[kwinz]

I had a chat with someone from mysmartlogon.com today (highly recommend their software by the way) and here are his thoughts for how to query the crypto provider in Windows for what algorithms the card can handle:

I don't remember if there is a CAPI property to retrieve PSS compatibility or not.
It may be supported but it has to be tested (​https://docs.microsoft.com/en-us/windows/win32/api/wincrypt/nf-wincrypt-cryptgetkeyparam KP_PADDING)

(​https://docs.microsoft.com/en-us/windows/win32/api/ncrypt/nf-ncrypt-ncryptenumalgorithms for CNG ?)

What I'm sure, is that at lower level, querying it is supported for minidiriver
See the minidriver spec (​https://download.microsoft.com/download/3/3/2/332fd70b-f04d-470a-a135-040350b9563f/sc-minidriver_specs_v7.07.docx) fonction 4.5.4 CardGetProperty? option CP_PADDING_SCHEMES( CARD_PADDING_PSS)

If someone wants to take a shot at it.

[krudas74]

So there is no solution from OpenVPN site to see at the end of the tunnel?

[Selva Nair]

Replying to krudas74:

So there is no solution from OpenVPN site to see at the end of the tunnel?

Use hardware that supports RSA-PSS which is required for TLS 1.3. Or downgrade TLS version in the configuration.

[kwinz]

Replying to Selva Nair:

Or downgrade TLS version in the configuration.

How? I can select TLS 1.2 yes, but that's not sufficient since OpenVPN also tries to use RSA-PSS with TLS 1.2. Is there now an option "like --sigalgs-list to allow the user to restrict the signature algorithms"?

[Selva Nair]

If your openvpn is built with OpenSSL 1.1.1 (version 2.4.9+ and 2.5.x Windows binary releases are), you will need to use --tls-version-max 1.1 If that is not acceptable, the only option is to use hardware that supports RSA-PSS. I am not aware of any plans to change this.

[kwinz]

Replying to Selva Nair:

If your openvpn is built with OpenSSL 1.1.1 (version 2.4.9+ and 2.5.x Windows binary releases are), you will need to use --tls-version-max 1.1 If that is not acceptable, the only option is to use hardware that supports RSA-PSS. I am not aware of any plans to change this.

Let me change the advertised sigalgs for negotiation. It can't be that big of a change, since it just replaces this string, though I appreciate that every change is an effort. This is a much better solution than using TLS 1.1.

[kwinz]

​https://datatracker.ietf.org/doc/rfc8996/

Let me change the advertised sigalgs used for negotiation with TLS 1.2. So that the client is advertising something it actually supports. Sounds like the right solution.

[Selva Nair]

If you are keen, you can restrict the signature algorithms in openssl.cnf.

Our releases only include OpenSSL dll's not openssl.cnf. So you will have to generate one or copy from somewhere and modify. I copied from a Linux host. To restict sigalgs to, say, RSA-PKCS1 with sha256 hash, add the following to the system_default section.

SignatureAlgorithms = RSA+SHA256

In my case the default section was named [system_default_sect]. I'm assuming your hardware does support those algorithms. You could add more by separating with a colon (see openssl docs). Note that inconsistent values would cause the TLS handshake to timeout.

The default location of config file compiled into OpenSSL may not work on Windows. So define an env variable named OPENSSL_CONF with value equal to the location of openssl.cnf. E.g.,

reg add HKCU\Environment /v OPENSSL_CONF /t REG_SZ /d "C:\Program Files\OpenVPN\bin\openssl.cnf"

Logout and login back for the env to take effect, start the connection with --tls-version-max 1.2.

The above assumes you are running from the GUI which starts OpenVPN as user. If using the automatic service for boot-time startup, the env variable will have to be set system-wide -- I haven't tested.

[Gert Döring]

This seems like there is not much we can do to fix this in OpenVPN, so I remove the "milestone" from the ticket ("milestone" = "we want this fixed by this version").

So the ticket is more to document the issue and find possible workarounds.

(If I misunderstood and there might be a way to do a code change to fix this, feel free to add a proper milestone - 2.4.11 or 2.5.3 - back)

[krudas74]

What also worked for me is to add this to the .ovpn file
tls-version-min 1.2
tls-version-max 1.2
Having done this I could also connect with the newer clients (right now its 2.5.4-I601)

[kwinz]

Replying to Selva Nair:

If you are keen, you can restrict the signature algorithms in openssl.cnf.

Dear Selva,

I had high hopes that your solution would solve the problem but it doesn't. To test it I updated to latest OpenVPN GUI: OpenVPN 2.5.4 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 20 2021

I copied the /etc/ssl/openssl.cnf from an Ubuntu 20.04.3 LTS installation and placed it in C:\Program Files\OpenVPN\bin\openssl.cnf

[ system_default_sect ] didn't exist yet in openssl.cnf so I created a new section with this name and added SignatureAlgorithms = RSA+SHA256. I also tried adding ClientSignatureAlgorithms = RSA+SHA256 but that didn't make a difference. I also added this setting to other sections but that also didn't make a difference.

Then I called reg add HKCU\Environment /v OPENSSL_CONF /t REG_SZ /d "C:\Program Files\OpenVPN\bin\openssl.cnf". Double checked that it created the registry key and that it points to the correct file. Logged off my user and back in.
Restarted OpenVPN GUI. Added the following lines to my client.ovpn config file:

tls-version-min 1.2
tls-version-max 1.2

since the GUI application doesn't take --tls-version-max 1.2 as a command line parameter directly and I didn't know how else to pass it.
Then I reconnected, it asked my for my virtual smart card pin twice, but still fails with:

21-11-09 11:46:29 us=343000 PKCS#11: Cannot perform signature 112:'CKR_MECHANISM_INVALID'
2021-11-09 11:46:29 us=343000 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
2021-11-09 11:46:29 us=343000 TLS_ERROR: BIO read tls_read_plaintext error

I am not sure what is the problem or how to debug this. Even though the logfile was set to verbosity 11, I don't see any mention of openssl.cnf or anything about algorithms in the logfile. How can I make sure that it is actually respecting the openssl.cnf and loading the correct SignatureAlgorithms settings?

Here is a sipp from the errors from more verbose log:
I am not sure if this contains my PIN number somehow, will change after posting this just in case:

2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_certificate_validateSession return rv=0-'CKR_OK'
2021-11-09 11:50:28 us=718000 PKCS#11: __pkcs11h_certificate_doPrivateOperation init rv=112
2021-11-09 11:50:28 us=718000 PKCS#11: Private key operation failed rv=112-'CKR_MECHANISM_INVALID'
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_certificate_resetSession entry certificate=0000027923A443D0, public_only=0, session_mutex_locked=1
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_login entry session=0000027923AE5F20, is_publicOnly=0, readonly=1, user_data=0000000000000000, mask_prompt=00000003
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_logout entry session=0000027923AE5F20
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_logout return
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_reset entry session=0000027923AE5F20, user_data=0000000000000000, mask_prompt=00000003, p_slot=000000FCD74FDB20
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_reset Expected token manufacturerID='www.mysmartlogon.com' model='PKCS#15 emulated', serialNumber='8ef553487aadf787', label='GIDS card (UserPIN)'
2021-11-09 11:50:28 us=718000 PKCS#11: _pkcs11h_session_getSlotList entry provider=0000027923A4C5F0, token_present=1, pSlotList=000000FCD74FD9C0, pulCount=000000FCD74FD9B4
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_session_getSlotList return rv=0-'CKR_OK' *pulCount=1
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_token_getTokenId entry p_token_id=000000FCD74FD9B8
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_token_newTokenId entry p_token_id=000000FCD74FD988
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_token_newTokenId return rv=0-'CKR_OK', *p_token_id=0000027923B0D760
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_token_getTokenId return rv=0-'CKR_OK', *p_token_id=0000027923B0D760
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_session_reset Found token manufacturerID='www.mysmartlogon.com' model='PKCS#15 emulated', serialNumber='8ef553487aadf787', label='GIDS card (UserPIN)'
2021-11-09 11:50:28 us=734000 PKCS#11: pkcs11h_token_freeTokenId entry certificate_id=0000027923B0D760
2021-11-09 11:50:28 us=734000 PKCS#11: pkcs11h_token_freeTokenId return
2021-11-09 11:50:28 us=734000 PKCS#11: _pkcs11h_session_reset return rv=0-'CKR_OK', *p_slot=0
2021-11-09 11:50:28 us=734000 PKCS#11: Calling pin_prompt hook for 'GIDS card (UserPIN)'
2021-11-09 11:50:35 us=343000 MANAGEMENT: CMD 'password [...]'
2021-11-09 11:50:35 us=343000 PKCS#11: pin_prompt hook return rv=0
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_login C_Login rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_login return rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_getObjectById entry session=0000027923AE5F20, class=3, id=0000027923A68190, id_size=1, p_handle=0000027923A443E8
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate entry session=0000027923AE5F20
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate session->pin_expire_time=0, time=1636455035
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate return rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_findObjects entry session=0000027923AE5F20, filter=000000FCD74FDF50, filter_attrs=2, p_objects=000000FCD74FDFA0, p_objects_found=000000FCD74FDF90
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_findObjects return rv=0-'CKR_OK', *p_objects_found=1
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_getObjectById return rv=0-'CKR_OK', *p_handle=23ae5da0
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_certificate_resetSession return rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_certificate_validateSession entry certificate=0000027923A443D0
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate entry session=0000027923AE5F20
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate session->pin_expire_time=0, time=1636455035
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_session_validate return rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: _pkcs11h_certificate_validateSession return rv=0-'CKR_OK'
2021-11-09 11:50:35 us=968000 PKCS#11: __pkcs11h_certificate_doPrivateOperation init rv=112
2021-11-09 11:50:35 us=968000 PKCS#11: __pkcs11h_certificate_doPrivateOperation return rv=112-'CKR_MECHANISM_INVALID', *p_target_size=100
2021-11-09 11:50:35 us=968000 PKCS#11: pkcs11h_certificate_sign return rv=112-'CKR_MECHANISM_INVALID', *p_target_size=100
2021-11-09 11:50:35 us=968000 PKCS#11: pkcs11h_certificate_signAny return rv=112-'CKR_MECHANISM_INVALID', *p_target_size=100
2021-11-09 11:50:35 us=968000 PKCS#11: Cannot perform signature 112:'CKR_MECHANISM_INVALID'
2021-11-09 11:50:35 us=968000 PKCS#11: __pkcs11h_openssl_rsa_enc - return rv=112-'CKR_MECHANISM_INVALID'
2021-11-09 11:50:35 us=968000 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
2021-11-09 11:50:35 us=968000 TLS_ERROR: BIO read tls_read_plaintext error
2021-11-09 11:50:35 us=968000 TLS Error: TLS object -> incoming plaintext read error
2021-11-09 11:50:35 us=968000 TLS Error: TLS handshake failed
2021-11-09 11:50:35 us=968000 PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0000027923B19070, ptr=0000000000000000, ad=0000027923B190D8, idx=1, argl=0, argp=00007FFF7B8B0570
2021-11-09 11:50:35 us=968000 PKCS#11: __pkcs11h_openssl_ex_data_free entered - parent=0000027923B18FB0, ptr=0000000000000000, ad=0000027923B19018, idx=1, argl=0, argp=00007FFF7B8B0570
2021-11-09 11:50:35 us=968000 TCP/UDP: Closing socket

[Selva Nair]

Replying to kwinz:

Replying to Selva Nair:

If you are keen, you can restrict the signature algorithms in openssl.cnf.

Dear Selva,

I had high hopes that your solution would solve the problem but it doesn't. To test it I updated to latest OpenVPN GUI: OpenVPN 2.5.4 Windows-MSVC [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Oct 20 2021

Unfortunately, that solution will not work on OpenVPN 2.5.3 and later. Loading of OpenSSL config file was disabled on the Windows build since 2.5.3 (CVE-2121-3606).

Version 2.5.2 should work -- the risk mentioned in the CVE could be mitigated by making the built-in OPENSSLDIR location read-only for users. AFAIK this location would point to "/etc/ssl" in the build which probably gets interpreted as "C:/etc/ssl"

[ system_default_sect ] didn't exist yet in openssl.cnf so I created a new section with this name

That's unlikely to work -- section names in OpenSSL config are arbitrary strings --- they get their meaning though definitions that point to the section-name. In this case you want to set certain properties in SSL_CTX which is controlled by the system_default variable. So you will at least need ssl_conf and system_default defined. For example, here is a relevant snippet from an openssl.cnf file:

openssl_conf = default_conf

[default_conf]
ssl_conf = ssl_sect

[ssl_sect]
system_default = system_default_sect

[system_default_sect]
MinProtocol = TLSv1.1
SignatureAlgorithms = RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:RSA+SHA1:ECDSA+SHA1

Also see OpenSSL manual for config files --- especially the use of system_default variable.

[kwinz]

Replying to Selva Nair:

Unfortunately, that solution will not work on OpenVPN 2.5.3 and later. Loading of OpenSSL config file was disabled on the Windows build since 2.5.3 (CVE-2121-3606).

Version 2.5.2 should work -- the risk mentioned in the CVE could be mitigated by making the built-in OPENSSLDIR location read-only for users. AFAIK this location would point to "/etc/ssl" in the build which probably gets interpreted as "C:/etc/ssl"

Thank you very much for the explanation, the link to the CVE ( ​https://community.openvpn.net/openvpn/wiki/CVE-2021-3606 ) and the notes on the section name definitions in openssl.cnf.

Unfortunately using an old release is just not a practical solution. As you can probably understand I am extremly hesitant to roll out anything in our company that does not work on the latest OpenVPN release. I don't want to be trapped relying on an old unpatched version of OpenVPN that may or may not work with new Windows releases or may contain security vulneraibilities.

I would be happy if the solution that you mentioned making the openssl.cnf location non configurable for users can work. Or only configurable via a registry key set by an administrator system wide in HKLM. Or only accepted if it is placed in the working directory C:\Program Files\OpenVPN\bin\ next to openssl.exe and openvpn.exe, which is not writable by unprivileged users.

Or ideally it would be possible to add a new configuration option like tls-signaturealgorithms to client.ovpn config file in future OpenVPN releases so administrators don't have to deal with openssl directly.

[kwinz]

PS: I can confirm that it works with the old vulnerable OpenVPN release 2.5.2.
Using the openssl.cnf that you posted it successfully negotiates TLSv1.2, cipher TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384 and establishes the connection.

[Selva Nair]

Replying to kwinz:

Unfortunately using an old release is just not a practical solution. As you can probably understand I am extremly hesitant to roll out anything in our company that does not work on the latest OpenVPN release. I don't want to be trapped relying on an old unpatched version of OpenVPN that may or may not work with new Windows releases or may contain security vulneraibilities.

The real solution to your problem is to use hardware tokens that support PSS or ECDSA signatures.

As an interim measure, if your server is not on Windows, you could restrict the signature algorithm on the server side using OpenSSL config. I haven't tested this though.

I would be happy if the solution that you mentioned making the openssl.cnf location non configurable for users can work.

I was referring to securing 2.5.2 and earlier --- create C:/etc/ssl and make it read-only for users.

Or only configurable via a registry key set by an administrator system wide in HKLM. Or only accepted if it is placed in the working directory C:\Program Files\OpenVPN\bin\ next to openssl.exe and openvpn.exe, which is not writable by unprivileged users.

In 2.6 we should be able to re-instate config file loading on Windows by fixing the way OpenSSL is built. But your hardware may not work at all in 2.6 unless it is compatible with Windows CNG.

In 2.5 we could use putenv()/setenv() to ensure config files are loaded from a pre-defined safe location and re-enable it. Or fix the way OpenSSL is built. But you will have to make a persuasive argument to make that happen.

[kwinz]

Replying to Selva Nair:

The real solution to your problem is to use hardware tokens that support PSS or ECDSA signatures.

I would if it was as easy as buying new hardware. However this is a software limitation of Windows. ​https://docs.microsoft.com/en-us/windows/security/identity-protection/virtual-smart-cards/virtual-smart-card-use-virtual-smart-cards
It does not support PSS padding on Virtual Smart Cards, regardless of the TPM hardware.

In 2.6 we should be able to re-instate config file loading on Windows by fixing the way OpenSSL is built.

Great! If that remains stable that would be a workable solution.

But your hardware may not work at all in 2.6 unless it is compatible with Windows CNG.

Since the hardware of both the issue reporter and me is virtual hardware made by Microsoft, that is not a problem. Windows CAPI is the native API (see links in comments above) and I am already using cryptoapicert in the client config, not the pkcs11* options. Are you intending to deprecate PKCS11 support in 2.6?

[Selva Nair]

@kwinz I am a bit confused: are you using --cryptoapicert option or pkcs11-helper library? The original report was on cryptoapicert, but on looking through the logs you posted two days ago, it shows pkcs11-helper interaction. Currently the latter is incapable of handling PSS signatures irrespective of whether the hardware and driver supports it or not.

We should be able to support PSS signatures using pkcs11-helper when its next release is out -- of course hardware/driver support would be required as well.

Anyway, my advice would be to move away from hardware/software that can't do RSA_PKCS1_PSS and/or ECDSA signatures. I do not know anything about TPM-backed virtual smart cards, but if it only supports obsolete algorithms why insist on using it?

[kwinz]

Replying to Selva Nair:

@kwinz I am a bit confused: are you using --cryptoapicert option or pkcs11-helper library? The original report was on cryptoapicert, but on looking through the logs you posted two days ago, it shows pkcs11-helper interaction. Currently the latter is incapable of handling PSS signatures irrespective of whether the hardware and driver supports it or not.

Yes, you are correct. I have tried both pkcs11 and cryptoapicert. Without setting SignatureAlgorithms it doesn't work with either.

This is the error that I get with cryptoapicert "THUMB:971f180ba80234845a99b116ea02e5ca6dffad1e":

Thu Nov 11 06:52:29 2021 OpenSSL: error:C506D064:microsoft cryptoapi:NCryptSignHash:This smart card does not support the requested feature.
Thu Nov 11 06:52:29 2021 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
Thu Nov 11 06:52:29 2021 TLS_ERROR: BIO read tls_read_plaintext error
Thu Nov 11 06:52:29 2021 TLS Error: TLS object -> incoming plaintext read error
Thu Nov 11 06:52:29 2021 TLS Error: TLS handshake failed

This is the error that I get with

pkcs11-providers "C:/Program Files/OpenSC Project/OpenSC/pkcs11/opensc-pkcs11.dll"
pkcs11-id  'www.mysmartlogon.com/PKCS\x2315\x20emulated/8ef553487aadf787/GIDS\x20card\x20\x28UserPIN\x29/00'

2021-11-11 07:01:05 PKCS#11: Cannot perform signature 1:'CKR_CANCEL'
2021-11-11 07:01:05 OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
2021-11-11 07:01:05 TLS_ERROR: BIO read tls_read_plaintext error
2021-11-11 07:01:05 TLS Error: TLS object -> incoming plaintext read error
2021-11-11 07:01:05 TLS Error: TLS handshake failed

However if I use the old vulnerable version 2.5.2 with your openssl.cnf then *both* work.

I do not know anything about TPM-backed virtual smart cards, but if it only supports obsolete algorithms why insist on using it?

It makes the client key non extractable from the client machines, even with root permissions. And every machine has a TPM.

And TLS1.2 is secure enough for us. And while I wish that Microsoft would update their TPM driver just as ChromeOS did recently[1], as far as I know the padding weakness for RSA with legacy PKCS-v1_5 padding is not exploitable in practice. "PSS has a security proof and is more robust in theory than PKCSV1_5. Nevertheless PKCSV1_5 has no known security weaknesses at this time. [...] The older RSAES-PKCS-v1_5 scheme has some known vulnerabilities (easily avoided), and is still widely used."[2]

"There is a class of attacks against PKCS1v1.5 due to Bleichenbacher, but it's due to implementations of signature verification that don't verify everything they should. [...] major implementations of PKCS1v1.5 have been safe for ages. [...] The encryption scheme is extremely difficult to implement" [3]

So while it's not modern crypto, that was conservatively designed to stay safe even if the implementation is bad, if properly mitigated for oracle attacks such as in TLS1.2 with openssl then RSA-PKCSV1_5 padding is secure. At least that's how I understood it.

[1] ​https://bugs.chromium.org/p/chromium/issues/detail?id=924230
[2] ​https://www.cryptosys.net/pki/manpki/pki_rsaschemes.html
[3] ​https://crypto.stackexchange.com/a/74974/64655

[Gert Döring]

openssl.cnf loading has been brought back, by

commit 23e6aaef149bd31a7e80af28ee1e3658d2810d4f (master)
commit f911b3f69b0a8296918a06d02eb5144bb4cd8a06 (release/2.5)
Author: Lev Stipakov
Date: Fri Nov 19 03:55:48 2021 +0200

Load OpenSSL config on Windows from trusted location

so 2.5.5 will load openssl.cnf from c:\program files\OpenVPN\ssl\openssl.cnf (if that's the openvpn install path), as will 2.6.x ("unless something happens to change that code again").

Test binaries for 2.5.4 with that patch are here:

​https://github.com/OpenVPN/openvpn/actions/runs/1498804083#artifacts

[Selva Nair]

so 2.5.5 will load openssl.cnf from c:\program files\OpenVPN\ssl\openssl.cnf (if that's the openvpn install path), as will 2.6.x ("unless something happens to change that code again").

To add to the above: setting the location of openssl.cnf using the env variable OPENSSL_CONF suggested in an earlier comment will also work. The location C:\Program Files\OpenVPN\ssl\openssl.cnf is used only if the env variable is not set by the user.

[krudas74]

Is there any possibility to integrate this into the .ovpn File instead of using the openssl.cnf file to restrict the TLS Version to 1.2 cause this is what we need to have a working openvpn Version combined with the virtual smart card in the TPM.

[Selva Nair]

Replying to krudas74:

Is there any possibility to integrate this into the .ovpn File instead of using the openssl.cnf file to restrict the TLS Version to 1.2 cause this is what we need to have a working openvpn Version combined with the virtual smart card in the TPM.

Yes its possible through a new option like --sigalgs x:y:z but that wont qualify for 2.5. By the time 2.6 is released, try to move to an HSM that supports PSS.

I had earlier suggested restricting the signature algorithms on the server side. Have you tried that? May be much easier for you to administer.

[krudas74]

You know it doesnt look like the solution with Virtual Smartcards on the TPM Chip with Microsoft will support this right now. For sure on a long term we don't wanna keep the restriction to TLS 1.2.
Thank you for the hint with --sigalgs

BTW : Great job, I am very happy that this is working with the latest release again in that way.

[Selva Nair]

Replying to krudas74:

Thank you for the hint with --sigalgs

To be clear, that's an option I conjured up from thin air. It doesn't exist, and I know of no plans for adding it.

[q1q1]

OpenVPN 2.4.9 with Microsoft Virtual Smart Card works. I've read the topic. Then I reinstall 2.4.9 to 2.5.2, add to the .ovpn file

tls-version-min 1.2
tls-version-max 1.2

So, my ovpn.conf is

remote server.url1
remote server.url12

port portnumber
proto udp
client
resolv-retry infinite
nobind
 
tls-auth tls.key 1
ca CA.pem
cipher AES-128-CBC
mute 20
dev tun
tun-mtu 1500
mssfix 1300
persist-key
persist-tun
remote-cert-tls server
auth-user-pass
keepalive 5 20
reneg-sec 0

auth-nocache
register-dns
block-outside-dns

cryptoapicert "THUMB:ххх"

tls-version-min 1.2
tls-version-max 1.2

I get some errors in logfile (as a comment above ​https://community.openvpn.net/openvpn/ticket/1296#comment:23):

DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM). Future OpenVPN version will ignore --cipher for cipher negotiations. Add 'AES-128-CBC' to --data-ciphers or change --cipher 'AES-128-CBC' to --data-ciphers-fallback 'AES-128-CBC' to silence this warning.
OpenVPN 2.5.2 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [LZ4] [PKCS11] [AEAD] built on Apr 21 2021
Windows version 10.0 (Windows 10 or greater) 64bit
library versions: OpenSSL 1.1.1k  25 Mar 2021, LZO 2.10
Enter Management Password:
TCP/UDP: Preserving recently used remote address: [AF_INET]server:port
UDP link local: (not bound)
UDP link remote: [AF_INET]server:port
OpenSSL: error:C506D064:microsoft cryptoapi:NCryptSignHash:This smart card does not support the requested feature.
OpenSSL: error:141F0006:SSL routines:tls_construct_cert_verify:EVP lib
TLS_ERROR: BIO read tls_read_plaintext error
TLS Error: TLS object -> incoming plaintext read error
TLS Error: TLS handshake failed
SIGUSR1[soft,tls-error] received, process restarting

I have openssl.cnf from comment ​https://community.openvpn.net/openvpn/ticket/1296#comment:17
in three paths:
c:\Program Files\OpenVPN\ssl\openssl.cnf
c:\etc\ssl\openssl.cnf
c:\Program Files\OpenVPN\bin\openssl.cnf

and in system (not current user) env variable too:
OPENSSL_CONF = "C:\Program Files\OpenVPN\bin\openssl.cnf"

What should I do with my settings for this and newer version OpenVPN to work with my Microsoft Virtual Smart Card?

[krudas74]

unfortunately this is not working in the .ovpn file

tls-version-min 1.2
tls-version-max 1.2

You need to have it in the openssl.cnf file
so something like this :

openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = ssl_default_sect
[ssl_default_sect]
 
 SignatureAlgorithms = RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256"
 MaxProtocol = TLSv1.2
 MinProtocol = TLSv1.2

[q1q1]

Replying to krudas74:

unfortunately this is not working in the .ovpn file

tls-version-min 1.2
tls-version-max 1.2

You need to have it in the openssl.cnf file
so something like this :

openssl_conf = default_conf
[default_conf]
ssl_conf = ssl_sect
[ssl_sect]
system_default = ssl_default_sect
[ssl_default_sect]
 
 SignatureAlgorithms = RSA+SHA512:ECDSA+SHA512:RSA+SHA384:ECDSA+SHA384:RSA+SHA256:ECDSA+SHA256"
 MaxProtocol = TLSv1.2
 MinProtocol = TLSv1.2

Thank you! I used only this strings in the openssl.cnf file and it works good!