Hi Selva,
On 19/04/21 19:01, Selva Nair wrote:
Hi JJK,
On Mon, Apr 19, 2021 at 7:19 AM Jan Just Keijser <janj...@nikhef.nl
<mailto:janj...@nikhef.nl>> wrote:
Hi Selva,
On 15/04/21 20:20, Selva Nair wrote:
> [...]
>>
>>
>> Another thing I am not clear on, is where the cert signature
type is set
>> / required. I am guessing the entire chain needs to be at
least SHA256
>> right ? PKI's CA CRT, CSR, signed CRT ?
> We are referring to the signature algorithm set in the
ClientHello during TLS
> handshake. OpenSSL 1.1.1 will include rsa_pss_pss_sha256 and similar
> as a supported algorithms in the signature_algorithms extension
> of clientHello. This is true even if you choose TLS 1.2. The
idea of editing
> OpenSSL.cnf is to remove PSS schemes from that list.
>
I can reproduce this issue with a Safenet token on Linux:
- openvpn 2.4 or 2.5 built with openssl 1.1 fails to connect to a
server
built with openssl 1.1 ; it has no problems connecting to a server
built
with openssl 1.0.2
- modifying the openssl.cnf file like this:
##########
openssl_conf = default_modules
[ default_modules ]
ssl_conf = ssl_module
[ ssl_module ]
system_default = crypto_policy
[ crypto_policy ]
SignatureAlgorithms = RSA+SHA256
##########
and adding
--tls-max-version 1.2
does allow me to connect, so changing the SignatureAlgorithms works.
I am having problems with openvpn and the Safenet driver on my
Fedora 32
box, but that has more to do with the (out of date) Safenet driver
than
with OpenVPN.
However, I think this *IS* an OpenVPN (or more likely, pkcs11-helper)
issue, as I can set up a TLS 1.3 connection using openssl s_server +
s_client with rsa-pss using the openssl-pkcs11 engine and the
same token:
## server:
openssl s_server -CAfile ca.crt -cert server.crt -key server.key -www
## client:
openssl s_client -engine pkcs11 -cert client.crt -keyform engine -key
20210419 -connect localhost:4433
(the key id is the ID of the private key on the token and was set to
today's date).
Shared Signature Algorithms:
ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:Ed25519:Ed448:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA-PSS+SHA256:RSA-PSS+SHA384:RSA-PSS+SHA512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:ECDSA+SHA1:RSA+SHA224:RSA+SHA1
I'll continue to investigate,
In the successful case using the pkcs11 engine, any idea what sigalg
is being used -- especially the padding that is being requested from
the token?
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2725 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
so it looks like PSS is used.
pkcs11-helper only supports RSA_PKCS1_PADDING (=CKM_RSA_PKCS for the
token) and RSA_NO_PADDING (=CKM_RSA_X_509). We added the latter to
1.26 to handle PSS with OpenSSL. The openssl callback the "helper"
hooks into only provides padded data when PSS is in use.
The pkcs11 engine uses libp11, isn't it? It hooks into
EVP_PKEY_METHOD(s) as we do in cryptoapi and can thus let the token
handle PSS padding.
yes, that's exactly what it does...
The question would be whether the token supports signing of prepadded
data (raw RSA). If it does, we need to troubleshoot OpenVPN +
pkcs11-helper further, otherwise we can't fix this without changing
pkcs11-helper.
A better fix would be to stop using pkcs11-helper unless mbedtls is in
use for which we probably have no other option.
I agree that it is better to stop using pkcs11-helper (if possible). I
can reproduce the problem using "softhsm" (from
http://www.opendnssec.org/) as well, thus you don't even need a hardware
token for this.
This is what I tested:
softhsm2-util --init-token --slot 0 --label "SoftToken1"
pkcs11-tool --module libsofthsm2.so --login -w client-key.der --type
privkey --id 20210420
pkcs11-tool --module libsofthsm2.so --login -w client-cert.der --type
cert --id 20210420
and then run openvpn using
~/src/openvpn-2.5.1/src/openvpn/openvpn --config pkcs11-udp-client.conf
--verb 5
with
[...]
pkcs11-providers /usr/lib64/libsofthsm2.so
pkcs11-id
'pkcs11:model=SoftHSM%20v2;token=SoftToken1;manufacturer=SoftHSM%20project;serial=ea81c0d7adb47653;id=%20%21%04%20'
and I get the exact same error:
2021-04-20 12:05:09 us=913235 OpenSSL: error:141F0006:SSL
routines:tls_construct_cert_verify:EVP lib
2021-04-20 12:05:09 us=913246 TLS_ERROR: BIO read tls_read_plaintext error
2021-04-20 12:05:09 us=913250 TLS Error: TLS object -> incoming
plaintext read error
2021-04-20 12:05:09 us=913254 TLS Error: TLS handshake failed
2021-04-20 12:05:09 us=913351 TCP/UDP: Closing socket
Hopefully this will enable others to reproduce the problem.
As for fixing pkcs11-helper: I doubt whether that is worth the effort,
I'd rather switch to lib11/openssl-pkcs11 engine or perhaps even
p11-kit-proxy (although both have their own issues)
HTH,
JJK
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
