Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi Mike,

On Wed, Apr 21, 2021 at 4:55 PM mike tancsa  wrote:

> On 4/21/2021 12:05 PM, Selva Nair wrote:
> > I think that patch is still not applied upstream. I tested softhsm
> > using your instructions and it works for TlS 1.3 and PSS -- softhsm2
> > gets request to sign pre-padded PSS data as Raw RSA and it seems to
> > handle that.
> >
> > I can understand some hardware tokens may refuse to sign pre-padded
> > data, so we need to find a fix for this.
> >
> If it would help development efforts, I am happy to donate a couple of
> keys to the project.  I have an assortment of old (CardOS based)  and
> new (SafeNet5110 which supports ECC).  I would be mailing from Canada,
> so ideally anyone close by, but happy to send internationally too.
>

Thanks for the offer, this could help. Tokens I have are some fairly
ancient one's that do not support RSA-PSS nor ECC.  Would be good to have
some newer tokens.

Domestic mail would work for me.

Selva
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[mike tancsa]

On 4/21/2021 12:05 PM, Selva Nair wrote:
> I think that patch is still not applied upstream. I tested softhsm
> using your instructions and it works for TlS 1.3 and PSS -- softhsm2
> gets request to sign pre-padded PSS data as Raw RSA and it seems to
> handle that.
>
> I can understand some hardware tokens may refuse to sign pre-padded
> data, so we need to find a fix for this.
>
If it would help development efforts, I am happy to donate a couple of
keys to the project.  I have an assortment of old (CardOS based)  and
new (SafeNet5110 which supports ECC).  I would be mailing from Canada,
so ideally anyone close by, but happy to send internationally too.

    ---Mike





___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi,

On Wed, Apr 21, 2021 at 6:32 AM Jan Just Keijser  wrote:
>
> Hi,
>
> On 20/04/21 20:05, Selva Nair wrote:
> > On Tue, Apr 20, 2021 at 6:47 AM Jan Just Keijser  wrote:
> >> [...]
>
> >> This is surprising. SoftHSM would support raw RSA signatures and hence
> >> should work with OpenVPN + pkcs11-helper 1.26 and later even with TLS
> >> 1.3 and PSS signatures.  The problem should arise only for tokens that
> >> insist on doing the padding internally.
> >>
> >> By any chance, are you using an older pkcs11-helper library?
> >>
> >>
>
> I was using the "default" pkcs11-helper library from Fedora Core 32,
> which is still at version 1.22; note that Fedora 33 *also* uses
> pkcs11-helper 1.22 (the upcoming Fedora 34 will include v1.27).
>
> I grabbed pkcs11-helper from github and compiled it then recompiled
> OpenVPN 2.5.1 with it. Now, when using softhsm, I get
>
> 2021-04-21 10:12:01 us=639135 PKCS#11: Adding PKCS#11 provider
> '/usr/lib64/libsofthsm2.so'
> 2021-04-21 10:12:01 us=640607 PKCS#11: Cannot deserialize id
> 19-'CKR_ATTRIBUTE_VALUE_INVALID'
> 2021-04-21 10:12:01 us=640614 Cannot load certificate
> "pkcs11:model=SoftHSM%20v2;token=SoftToken1;..." using PKCS#11 interface

The deserialize error seems to indicate it's not able to parse the id.
What does openvpn --show-pkcs11-ids /usr/lib64/libsoftshsm2.so.

To use the id like "pkcs11:." you would need the RFC7512 patch
which we apply in our Windows builds. Or use the old style id like:

pkcs11-id 
'SoftHSM\x20project/SoftHSM\x20v2/serial-goes-here/SoftToken1/20210420'

I think that patch is still not applied upstream. I tested softhsm
using your instructions and it works for TlS 1.3 and PSS -- softhsm2
gets request to sign pre-padded PSS data as Raw RSA and it seems to
handle that.

I can understand some hardware tokens may refuse to sign pre-padded
data, so we need to find a fix for this.

Selva


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Jan Just Keijser]

Hi,

On 20/04/21 20:05, Selva Nair wrote:

On Tue, Apr 20, 2021 at 6:47 AM Jan Just Keijser  wrote:

[...]



This is surprising. SoftHSM would support raw RSA signatures and hence
should work with OpenVPN + pkcs11-helper 1.26 and later even with TLS
1.3 and PSS signatures.  The problem should arise only for tokens that
insist on doing the padding internally.

By any chance, are you using an older pkcs11-helper library?




I was using the "default" pkcs11-helper library from Fedora Core 32, 
which is still at version 1.22; note that Fedora 33 *also* uses 
pkcs11-helper 1.22 (the upcoming Fedora 34 will include v1.27).


I grabbed pkcs11-helper from github and compiled it then recompiled 
OpenVPN 2.5.1 with it. Now, when using softhsm, I get


2021-04-21 10:12:01 us=639135 PKCS#11: Adding PKCS#11 provider 
'/usr/lib64/libsofthsm2.so'
2021-04-21 10:12:01 us=640607 PKCS#11: Cannot deserialize id 
19-'CKR_ATTRIBUTE_VALUE_INVALID'
2021-04-21 10:12:01 us=640614 Cannot load certificate 
"pkcs11:model=SoftHSM%20v2;token=SoftToken1;..." using PKCS#11 interface


so no luck there; with my trusty old Aladdin/Safenet eToken I get the 
same error, so I'm guessing there's something wrong with v1.27 as well...


JJK



___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi,

On Tue, Apr 20, 2021 at 6:47 AM Jan Just Keijser  wrote:
>
> Hi Selva,
>

..some good info snipped..

>
> 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

This is surprising. SoftHSM would support raw RSA signatures and hence
should work with OpenVPN + pkcs11-helper 1.26 and later even with TLS
1.3 and PSS signatures.  The problem should arise only for tokens that
insist on doing the padding internally.

By any chance, are you using an older pkcs11-helper library?


Selva

>
>
> 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

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Jan Just Keijser]

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 > 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 

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi JJK,

On Mon, Apr 19, 2021 at 7:19 AM Jan Just Keijser  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

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Jan Just Keijser]

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,

JJK





___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi,

On Thu, Apr 15, 2021 at 1:46 PM mike tancsa  wrote:
>
> On 4/14/2021 8:23 PM, Selva Nair wrote:
> >
> > You can restrict TLS version using th eoption --tls-version-min in
> > OpenVPN config file, but restricting to TLS 1.2 is not enough with
> > OpenSSL 1.1.1. It defaults to PSS for both TLS 1.2 and 1.3.
> >
> > Rather than building your own OpenSSL, a much simpler option would be
> > to make an openssl.cnf file and restrict signature algorithms. See my
> > comment on the trac
> > ticket link I posted in my previous reply.
> >
> Thanks, still no luck just yet getting things to work using the .cnf
> file.  Not sure why its not picking up the pointer properly.  I will
> keep trying.

You can privately email me the OpenSSL config file you are using, and
I can take a look.

>
>
>
> 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.

>
> Also, I was playing around creating a default CA from scratch using
> easy-rsa.  It by default generates a CA cert as so

Recreating certificates will not make any difference.

Selva


___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[mike tancsa]

On 4/14/2021 8:23 PM, Selva Nair wrote:
>  
> You can restrict TLS version using th eoption --tls-version-min in
> OpenVPN config file, but restricting to TLS 1.2 is not enough with
> OpenSSL 1.1.1. It defaults to PSS for both TLS 1.2 and 1.3. 
>
> Rather than building your own OpenSSL, a much simpler option would be
> to make an openssl.cnf file and restrict signature algorithms. See my
> comment on the trac 
> ticket link I posted in my previous reply. 
>
Thanks, still no luck just yet getting things to work using the .cnf
file.  Not sure why its not picking up the pointer properly.  I will
keep trying.



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 ?

Also, I was playing around creating a default CA from scratch using
easy-rsa.  It by default generates a CA cert as so


 % openssl x509 -in ca.crt -text
Certificate:
    Data:
    Version: 3 (0x2)
    Serial Number:
    5c:d4:ed:f7:b7:0a:82:c7:52:dd:6b:bc:18:22:0a:53:8d:4e:2f:08
    Signature Algorithm: sha256WithRSAEncryption
    Issuer: CN = Mike CA
.
.
    Exponent: 65537 (0x10001)
    X509v3 extensions:
    X509v3 Subject Key Identifier:
    45:DA:14:8D:C1:6B:C1:A2:F5:AE:61:76:89:E2:F4:46:83:90:6C:C1
    X509v3 Authority Key Identifier:
   
keyid:45:DA:14:8D:C1:6B:C1:A2:F5:AE:61:76:89:E2:F4:46:83:90:6C:C1
    DirName:/CN=Mike CA
   
serial:5C:D4:ED:F7:B7:0A:82:C7:52:DD:6B:BC:18:22:0A:53:8D:4E:2F:08

    X509v3 Basic Constraints:
    CA:TRUE
    X509v3 Key Usage:
    Certificate Sign, CRL Sign
    Signature Algorithm: sha256WithRSAEncryption


Should those Signature Algorithm lines show something different ?

When I build a client, the same values.  I dont have RSA-/PS referenced
anywhere ?/

/
/

/    ---Mike
/


> That said, it's my guess that the token is refusing to sign pre-padded
> data. You may want to ask the token supplier (SafeNet Inc) about it.
>
> Selva

___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi,


On Wed, Apr 14, 2021 at 8:09 PM mike tancsa  wrote:

> Thank you very much for the analysis and pointer.  The application is a
> kiosk type environment and for a number of reasons, the windows dialog
> PIN popping up is not workable. Its been a while since I built OpenVPN
> from source, but I imagine I could roll a version of the OpenSSL.DLL
> that would max out at TLS 1.2 or at least default to that ?
>
>
You can restrict TLS version using th eoption --tls-version-min in OpenVPN
config file, but restricting to TLS 1.2 is not enough with OpenSSL 1.1.1.
It defaults to PSS for both TLS 1.2 and 1.3.

Rather than building your own OpenSSL, a much simpler option would be to
make an openssl.cnf file and restrict signature algorithms. See my comment
on the trac
ticket link I posted in my previous reply.

That said, it's my guess that the token is refusing to sign pre-padded
data. You may want to ask the token supplier (SafeNet Inc) about it.

Selva
___
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[mike tancsa]

Thank you very much for the analysis and pointer.  The application is a
kiosk type environment and for a number of reasons, the windows dialog
PIN popping up is not workable. Its been a while since I built OpenVPN
from source, but I imagine I could roll a version of the OpenSSL.DLL
that would max out at TLS 1.2 or at least default to that ?

    ---Mike

On 4/14/2021 7:16 PM, Selva Nair wrote:
> Hi,
>
> As per the logs its requesting unpadded signature of size 256 (padding
> = 3) which is expected with OpenSSL 1.1.1 and TLS 1.2 or 1.3 as the it
> requires PSS padded signature and OpenSSL provides the padded data to
> sign with padding = NONE. My guess would be that your hardware token
> doesn't support signing pre-padded data.
>
> In case cryptoapi, we pass in the unpadded data and the padding type,
> so that both padding and signing is handled by the cryptography
> provider (token's dll through Windows).
>
> 2.4.7 is built with older OpenSSL that does not support TLS 1.3 and
> doe snot use PSS padding by default. For newer releases, there is a
> work around like use TLS1.2 and configure OpenSSL to not negotiate PSS
> padding with the server[1], but why not use cryptoapi as it works? 
>
> Selva
>
> [1] https://community.openvpn.net/openvpn/ticket/1296#comment:12
> 
>
> On Wed, Apr 14, 2021 at 6:03 PM mike tancsa  > wrote:
>
>
> Trying out a newer version of OpenVPN community edition (latest
> from the
> website) on windows 10 and running into problems with a config that
> works from 2.4.7.  If I use the token with OpenVPN 2.4.7 it works as
> expected. On 2.5.1, I get a series of errors when using the pkcs11
> method. The token works fine with cryptoapicert as the interface
> to the
> eToken.
>
> cryptoapicert "SUBJ:officeVPN"
>
> However, if I use
>
> pkcs11-providers eTpkcs11.dll
> pkcs11-id 'pkcs11:model=eToken;token=.
>
> (i.e the output of --show-pkcs11-ids)
>
>
> I enter the PIN, and its the right PIN as the fail count on the token
> doesn't go down. It just fails and asks for the PIN again.  The pkcs11
> fail bits from the log are below. Like I said, this same token works
> with the same config under 2.4.7 and works with 2.5.1 if I use it via
> cryptoapcicert. Any idea where / why I am getting those 2 errors using
> the pkcs11 method under 2.5.1 ?
>
>
>
> 2021-04-14 17:24:36 us=284747 SSL state (connect): TLSv1.3 read server
> certificate verify
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS read
> finished
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS write
> change cipher spec
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS write
> client certificate
> 2021-04-14 17:24:36 us=284747 PKCS#11: __pkcs11h_openssl_rsa_enc
> entered
> - flen=256, from=007968E0, to=00795B10,
> rsa=0075EEE0, padding=3
> 2021-04-14 17:24:36 us=284747 PKCS#11: Performing signature
> 2021-04-14 17:24:36 us=284747 PKCS#11: pkcs11h_certificate_signAny
> entry
> certificate=007586B0, mech_type=3, source=007968E0,
> source_size=0100, target=00795B10,
> *p_target_size=0100
> 2021-04-14 17:24:36 us=284747 PKCS#11: Getting key attributes
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> __pkcs11h_certificate_getKeyAttributes entry
> certificate=007586B0
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes entry
> attrs=0072E140, count=4
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes return
> 2021-04-14 17:24:36 us=284747 PKCS#11: Get private key attributes
> failed: 130:'CKR_OBJECT_HANDLE_INVALID'
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_certificate_resetSession
> entry certificate=007586B0, public_only=0,
> session_mutex_locked=1
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_getObjectById
> entry session=00759C40, class=3, id=0075F4A0,
> id_size=0008, p_handle=007586C8
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate entry
> session=00759C40
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate
> session->pin_expire_time=0, time=1618435476
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate
> return
> rv=0-'CKR_OK'
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_findObjects
> entry session=00759C40, filter=0072E0C0,
> filter_attrs=2,
> p_objects=0072E0B8, p_objects_found=0072E0B4
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_findObjects
> return rv=0-'CKR_OK', *p_objects_found=1
> 2021-04-14 17:24:36 us=284747 

Re: [Openvpn-users] PKCS11 problems with 2.5.1 under windows 10

[Selva Nair]

Hi,

As per the logs its requesting unpadded signature of size 256 (padding = 3)
which is expected with OpenSSL 1.1.1 and TLS 1.2 or 1.3 as the it requires
PSS padded signature and OpenSSL provides the padded data to sign with
padding = NONE. My guess would be that your hardware token doesn't support
signing pre-padded data.

In case cryptoapi, we pass in the unpadded data and the padding type, so
that both padding and signing is handled by the cryptography provider
(token's dll through Windows).

2.4.7 is built with older OpenSSL that does not support TLS 1.3 and doe
snot use PSS padding by default. For newer releases, there is a work around
like use TLS1.2 and configure OpenSSL to not negotiate PSS padding with the
server[1], but why not use cryptoapi as it works?

Selva

[1] https://community.openvpn.net/openvpn/ticket/1296#comment:12

On Wed, Apr 14, 2021 at 6:03 PM mike tancsa  wrote:

>
> Trying out a newer version of OpenVPN community edition (latest from the
> website) on windows 10 and running into problems with a config that
> works from 2.4.7.  If I use the token with OpenVPN 2.4.7 it works as
> expected. On 2.5.1, I get a series of errors when using the pkcs11
> method. The token works fine with cryptoapicert as the interface to the
> eToken.
>
> cryptoapicert "SUBJ:officeVPN"
>
> However, if I use
>
> pkcs11-providers eTpkcs11.dll
> pkcs11-id 'pkcs11:model=eToken;token=.
>
> (i.e the output of --show-pkcs11-ids)
>
>
> I enter the PIN, and its the right PIN as the fail count on the token
> doesn't go down. It just fails and asks for the PIN again.  The pkcs11
> fail bits from the log are below. Like I said, this same token works
> with the same config under 2.4.7 and works with 2.5.1 if I use it via
> cryptoapcicert. Any idea where / why I am getting those 2 errors using
> the pkcs11 method under 2.5.1 ?
>
>
>
> 2021-04-14 17:24:36 us=284747 SSL state (connect): TLSv1.3 read server
> certificate verify
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS read finished
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS write
> change cipher spec
> 2021-04-14 17:24:36 us=284747 SSL state (connect): SSLv3/TLS write
> client certificate
> 2021-04-14 17:24:36 us=284747 PKCS#11: __pkcs11h_openssl_rsa_enc entered
> - flen=256, from=007968E0, to=00795B10,
> rsa=0075EEE0, padding=3
> 2021-04-14 17:24:36 us=284747 PKCS#11: Performing signature
> 2021-04-14 17:24:36 us=284747 PKCS#11: pkcs11h_certificate_signAny entry
> certificate=007586B0, mech_type=3, source=007968E0,
> source_size=0100, target=00795B10,
> *p_target_size=0100
> 2021-04-14 17:24:36 us=284747 PKCS#11: Getting key attributes
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> __pkcs11h_certificate_getKeyAttributes entry certificate=007586B0
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes entry attrs=0072E140, count=4
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes return
> 2021-04-14 17:24:36 us=284747 PKCS#11: Get private key attributes
> failed: 130:'CKR_OBJECT_HANDLE_INVALID'
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_certificate_resetSession
> entry certificate=007586B0, public_only=0, session_mutex_locked=1
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_getObjectById
> entry session=00759C40, class=3, id=0075F4A0,
> id_size=0008, p_handle=007586C8
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate entry
> session=00759C40
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate
> session->pin_expire_time=0, time=1618435476
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_validate return
> rv=0-'CKR_OK'
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_findObjects
> entry session=00759C40, filter=0072E0C0, filter_attrs=2,
> p_objects=0072E0B8, p_objects_found=0072E0B4
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_findObjects
> return rv=0-'CKR_OK', *p_objects_found=1
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_session_getObjectById
> return rv=0-'CKR_OK', *p_handle=02970005
> 2021-04-14 17:24:36 us=284747 PKCS#11: _pkcs11h_certificate_resetSession
> return rv=0-'CKR_OK'
> 2021-04-14 17:24:36 us=284747 PKCS#11: Key attributes enforced by
> provider (0002)
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes entry attrs=0072E140, count=4
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> _pkcs11h_session_freeObjectAttributes return
> 2021-04-14 17:24:36 us=284747 PKCS#11:
> __pkcs11h_certificate_getKeyAttributes return rv=0-'CKR_OK'
> 2021-04-14 17:24:36 us=284747 PKCS#11: pkcs11h_certificate_signRecover
> entry certificate=007586B0, mech_type=3,
> source=007968E0, source_size=0100,
> target=00795B10, *p_target_size=0100
>