Issue with smartcard authentication for openvpn

[Selva Nair]

Hi,

On Wed, Apr 10, 2019 at 10:11 AM Francois Gelis <francois.gelis at gmail.com>
wrote:

> Hi all,
>
> I have a working openvpn setup with client certificate and private key
> stored on my laptop. Then, I have loaded them into a smartcard (Yubico 5
> NFC), and modified accordingly the openvpn client config. But running the
> openvpn client now fails with an error that seems to originate inside
> openssl. Here is a verbose openvpn log (only the portion that seems
> relevant for this error, but I have the full log if useful):
>
> Sat Apr  6 15:57:20 2019 us=467260 Incoming Ciphertext -> TLS
> Sat Apr  6 15:57:20 2019 us=467271 SSL state (connect): SSLv3/TLS read
> server hello
> Sat Apr  6 15:57:20 2019 us=467468 VERIFY OK: depth=1, CN=FG-CA
> Sat Apr  6 15:57:20 2019 us=467598 VERIFY KU OK
> Sat Apr  6 15:57:20 2019 us=467609 Validating certificate extended key
> usage
> Sat Apr  6 15:57:20 2019 us=467615 ++ Certificate has EKU (str) TLS Web
> Server Authentication, expects TLS Web Server Authentication
> Sat Apr  6 15:57:20 2019 us=467620 VERIFY EKU OK
> Sat Apr  6 15:57:20 2019 us=467625 VERIFY OK: depth=0, CN=tx2
> Sat Apr  6 15:57:20 2019 us=467650 SSL state (connect): SSLv3/TLS read
> server certificate
> Sat Apr  6 15:57:20 2019 us=467735 SSL state (connect): SSLv3/TLS read
> server key exchange
> Sat Apr  6 15:57:20 2019 us=467763 SSL state (connect): SSLv3/TLS read
> server certificate request
> Sat Apr  6 15:57:20 2019 us=467771 SSL state (connect): SSLv3/TLS read
> server done
> Sat Apr  6 15:57:20 2019 us=467845 SSL state (connect): SSLv3/TLS write
> client certificate
> Sat Apr  6 15:57:20 2019 us=468012 SSL state (connect): SSLv3/TLS write
> client key exchange
> Sat Apr  6 15:57:20 2019 us=468053 PKCS#11: __pkcs11h_openssl_rsa_enc
> entered - flen=256, from=0x559d078d6e70, to=0x559d078d6bc0,
> rsa=0x559d078b3630, padding=3
>

padding = 3 means "no padding" indicating that the data for signature is
already padded. That's why the data size (flen) is 256 (hashed data padded
to the rsa key size of 2048 bits, I guess). If you are using OpenSSL 1.1.1,
this could be due to PSS padding in which case current implementation
passes pre-padded data for raw signature to the callback. AFAIK,
pkcs11-helper only handles PKCS1 padding (CKM_RSA_PKCS) though pkcs11
standard does support raw signatures.

A work around may be to restrict TLS version to 1.1 which is not ideal. Not
sure whether openssl has any config options to restrict signature
algorithms.

Sat Apr  6 15:57:20 2019 us=468060 PKCS#11: __pkcs11h_openssl_rsa_enc -
> return rv=112-'CKR_MECHANISM_INVALID'
>
>
Sat Apr  6 15:57:20 2019 us=468070 SSL alert (write): fatal: internal error
> Sat Apr  6 15:57:20 2019 us=468085 OpenSSL: error:141F0006:SSL
> routines:tls_construct_cert_verify:EVP lib
> Sat Apr  6 15:57:20 2019 us=468092 TLS_ERROR: BIO read tls_read_plaintext
> error
> Sat Apr  6 15:57:20 2019 us=468097 TLS Error: TLS object -> incoming
> plaintext read error
> Sat Apr  6 15:57:20 2019 us=468101 TLS Error: TLS handshake failed
>
> Somehow, it seems that __pkcs11h_openssl_rsa_enc was called with an
> unexpected padding. Any ideas on what might be the cause of this?
>

pkcs11-helper needs to be patched to support raw signatures.

Selva
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20190410/221938de/attachment.html>