Hi JJK, On Mon, Apr 19, 2021 at 7:19 AM Jan Just Keijser <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? 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. 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. Selva
_______________________________________________ Openvpn-users mailing list Openvpn-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-users
