Opened 8 months ago

Last modified 2 months 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.4.9
Component: Crypto Version:
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc:

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

Change History (5)

comment:1 Changed 8 months ago by 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.

comment:2 Changed 6 months ago by Gert Döring

Component: Generic / unclassifiedCrypto
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 6 months ago by 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.

comment:4 Changed 2 months ago by 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.

comment:5 Changed 2 months ago by 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.

Note: See TracTickets for help on using tickets.