Opened 13 months ago

Last modified 4 months ago

#1296 new Bug / Defect

Openssl Error OpenVPN 2.4.9 Windows 10

Reported by: krudas74 Owned by: Steffan Karger
Priority: major Milestone:
Component: Crypto Version: OpenVPN 2.4.9 (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: tct

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 (14)

comment:1 Changed 13 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 11 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 11 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 7 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 7 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.

comment:6 Changed 4 months ago by krudas74

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

comment:7 in reply to:  6 ; Changed 4 months ago by 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.

comment:8 in reply to:  7 Changed 4 months ago by 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"?

Last edited 4 months ago by kwinz (previous) (diff)

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

comment:10 in reply to:  9 Changed 4 months ago by 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.

Last edited 4 months ago by kwinz (previous) (diff)

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

Last edited 4 months ago by kwinz (previous) (diff)

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

Last edited 4 months ago by Selva Nair (previous) (diff)

comment:13 Changed 4 months ago by tct

Cc: tct added

comment:14 Changed 4 months ago by Gert Döring

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)

Note: See TracTickets for help on using tickets.