Opened 4 years ago
Last modified 3 years ago
#1296 new Bug / Defect
Openssl Error OpenVPN 2.4.9 Windows 10
Reported by: | krudas74 | Owned by: | Steffan Karger |
---|---|---|---|
Priority: | major | Milestone: | release 2.5.5 |
Component: | Crypto | Version: | OpenVPN 2.4.9 (Community Ed) |
Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | |
Cc: | tct, stipa |
Description
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
Attachments (3)
Change History (36)
comment:1 Changed 4 years ago by
comment:2 Changed 4 years ago by
Component: | Generic / unclassified → Crypto |
---|---|
Owner: | set to Steffan Karger |
@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.
comment:3 Changed 4 years ago by
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.
comment:4 Changed 4 years ago by
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.
comment:5 Changed 4 years ago by
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.
comment:6 follow-up: 7 Changed 4 years ago by
So there is no solution from OpenVPN site to see at the end of the tunnel?
comment:7 follow-up: 8 Changed 4 years ago by
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.
comment:8 Changed 4 years ago by
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"?
comment:9 follow-up: 10 Changed 4 years ago by
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.
comment:10 Changed 4 years ago by
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.
comment:11 Changed 4 years ago by
https://datatracker.ietf.org/doc/rfc8996/
Let me change the advertised sigalgs used for negotiation. So that the client is advertising something it actually supports. Sounds like the right solution.
comment:12 follow-up: 16 Changed 4 years ago by
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.
comment:13 Changed 4 years ago by
Cc: | tct added |
---|
comment:14 Changed 4 years ago by
Milestone: | release 2.4.9 |
---|---|
Version: | → OpenVPN 2.4.9 (Community Ed) |
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)
comment:15 Changed 3 years ago by
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)
comment:16 follow-up: 17 Changed 3 years ago by
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
comment:17 follow-up: 18 Changed 3 years ago by
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.
comment:18 follow-up: 20 Changed 3 years ago by
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.
comment:19 Changed 3 years ago by
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.
comment:20 follow-up: 21 Changed 3 years ago by
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.
comment:21 Changed 3 years ago by
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?
comment:22 follow-up: 23 Changed 3 years ago by
@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?
comment:23 Changed 3 years ago by
Replying to Selva Nair:
@kwinz I am a bit confused: are you using
--cryptoapicert
option orpkcs11-helper
library? The original report was oncryptoapicert
, but on looking through the logs you posted two days ago, it showspkcs11-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
comment:24 Changed 3 years ago by
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
comment:25 Changed 3 years ago by
Cc: | stipa added |
---|---|
Milestone: | → release 2.5.5 |
comment:26 Changed 3 years ago by
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.
comment:27 follow-up: 28 Changed 3 years ago by
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.
comment:28 Changed 3 years ago by
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.
comment:29 follow-up: 30 Changed 3 years ago by
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.
comment:30 Changed 3 years ago by
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.
Changed 3 years ago by
Attachment: | 2fa — Microsoft Virtual Smart Card.ovpn added |
---|
comment:31 Changed 3 years ago by
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?
Changed 3 years ago by
Attachment: | 2fa — Microsoft Virtual Smart Card.log added |
---|
comment:32 follow-up: 33 Changed 3 years ago by
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
Changed 3 years ago by
Attachment: | openssl.cnf added |
---|
comment:33 Changed 3 years ago by
Replying to krudas74:
unfortunately this is not working in the .ovpn file
tls-version-min 1.2 tls-version-max 1.2You 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!
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.