Re: Intermittent Issues with 8152 Error frm NSS on SSL public / private key with PHP/Curl

On Wednesday, 9 December 2020 17:24:45 CET, Craig Henry wrote:
> Hi,
>
> This is my first post to this list so please be kind! I'm a PHP developer
> by trade and not a server person.
>
> Environment - Linux Centos
> SSL - 1.0.2k19-el7
>
> Connection - CURL (via PHP) with public / private key auth + http basic auth
>
> We're having an issue where we are seeing intermittent behavior connecting
> to a 3rd party of the key being rejected with a 8152 error - "The key does
> not support the requested operation". Other times it works OK.
>
> We have another user who is using this 3rd party and same connection type
> but not reported this issue.
>
> Has anyone got any clue as to what might be causing this type of
> intermittent connection issue ?
>
> The CURL logs are below but altered for privacy reasons.

that doesn't look like anytihng I've seen in our testing (and we test with 
this
cipher suite quite extensively)

few things to consider:
* is the client connecting to exact same server every time?
  some servers can advertise support for rsa-pss signatures even in TLS 1.2
  while others do not—that may cause different behaviour even with the same
  client key and cipher
* is the client private key stored in a file, in the nssdb or in a hardware
  token (HSM, smartcard, or similar)?
* what's the bit size of the client modulus? is it 2048 bit exactly or is 
it
  slighly off, like 2047 bit?

difference on network level: comparison of packet traces for successful and
failed connection, may also be enlightening

>
>
> *Key blocked response*
>
> * About to connect() to XXXXXXXX > port 443 (#96)
> *   Trying XXXXXX
> * Connected to XXXXXX (XXXXXXXXX) port 443 (#96)
> *   CAfile: /XXXXX_tlstrust.pem
>
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=XXXXXXX
> ,O=XXXXXXXX,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXXXXXXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'XXXXXXXX'
>> POST /XXXXXX/services HTTP/1.1
> Authorization: Basic XXXXXXXXX
> Host: XXXXXXXX
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
>
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=XXXXXXXX,OU=Buntingford,O=XXXXXXXXXX,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name: xxxxxxxx
> * issuer: CN=XXXXXX,O=XXXXXXXX GmbH,L=Bad
> Vilbel,ST=Hessen,C=DE
> * SSL read: errno -8152 (SEC_ERROR_INVALID_KEY)
> * The key does not support the requested operation.
> * Closing connection 96
>
>
> *Successful response*
>
> * About to connect() to XXXXXXXXXX port 443 (#81)
> *   Trying xxxxxxx...
> * Connected to XXXXXXXXxxxxxxx(XXXXXX) port 443 (#81)
> *   CAfile: /XXXXXXXXX
> xxxxxx
>   CApath: none
> * SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
> * Server certificate:
> * subject: CN=www.xxxxxxxxxxxx xxxxx
> ,O=XXXXXXn,L=Atlanta,ST=Georgia,C=US
> * start date: Jun 17 00:00:00 2020 GMT
> * expire date: Jun 18 12:00:00 2022 GMT
> * common name: XXXXXXXXXXXXXXX
> * issuer: CN=DigiCert Global CA G2,O=DigiCert Inc,C=US
> * Server auth using Basic with user 'XXXXXXXXX'
>> POST /XXXXX/services HTTP/1.1
> Authorization: Basic xxxxxxxx
> Host: XXXXXXXXX xxxxxxxxxx
> Accept: */*
> Content-Type:text/xml
> Content-Length: 1019
>
> * upload completely sent off: 1019 out of 1019 bytes
> * NSS: client certificate from file
> * subject: CN=XXXXXXXX,OU=Buntingford,O=XXXXXXXXXX Ltd,C=DE
> * start date: Dec 03 10:01:35 2020 GMT
> * expire date: Dec 01 10:01:35 2030 GMT
> * common name:XXXXXXXXX
> * issuer: CN=XXXXXXXXXxxxxxxx>,O=XXXXXXXXXXXX,L=Bad
> Vilbel,ST=Hessen,C=DE
> < HTTP/1.1 500
> < Date: Tue, 08 Dec 2020 13:42:26 GMT
> < Server: Apache
> < Strict-Transport-Security: max-age=63072000; includeSubdomains
> < X-XSS-Protection: 1; mode=block
> < X-Content-Type-Options: nosniff
> < Cache-Control: no-cache, no-store, must-revalidate
> < Pragma: no-cache
> < X-Frame-Options: SAMEORIGIN
> < Content-Security-Policy: default-src 'self' *.googleapis.com *.klarna.com
> *.masterpass.com *.mastercard.com *.npci.org.in 'unsafe-eval'
> 'unsafe-inline'; frame-ancestors 'self'
> < X-Application-Context: application:spring-boot,node-global,node-api:8843
> < Accept: text/xml, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
> < SOAPAction: ""
> < Expires: 0
> < Content-Type: text/xml;charset=utf-8
> < Content-Length: 1481
> < Set-Cookie: JSESSIONID=8778DF260AA5C9E0AAB3E1E4C572453D.ipg_api_k8s;
> Path=/XXXXX; Secure; HttpOnly;HttpOnly;Secure;SameSite=Lax
> < Connection: close
> <
> * Closing connection 81
>
> *Development Team*
>
> *tassolutions <http://www.tas-solutions.co.uk/>*
> the attic | south suite | fullbridge mill | maldon | essex | cm9 4le | UK
>
> *tel:*   +44 (0)1621 857785 <+44%201621%20857785>  - 
> *www.tas-solutions.co.uk
> <http://www.tas-solutions.co.uk/>*
>
> *Our business | support hours are Monday - Friday 9.00am to 5.30pm*
>
> Offices are closed on all UK Bank Holidays.
>
> Support outside these hours can be arranged on request.
>
> <https://twitter.com/tassolutions>
> <https://www.linkedin.com/company/tas-solutions>
> <https://www.aito.com/aito-information/aito-business-partners>
>
> This E-mail and any attachments contain confidential and proprietary
> information of TAS Solutions Ltd and are intended only for the use of the
> person/s to whom it is addressed. If you have received this E-mail in error
> please immediately notify support by telephone on +44 (0)1621 857785
> <+44%201621%20857785>. Although this e-mail and any attachments are
> believed to be free of any virus, or other defect which might affect any
> computer or system into which they are received and opened, internet
> communications cannot be guaranteed to be secure or error-free and
> therefore it is the responsibility of the recipient to ensure that they are
> virus free. The sender therefore does not accept liability for any loss or
> damage from receipt or use thereof which arises as a result of internet
> transmission. Any views/opinions expressed within this e-mail and any
> attachments are that of the individual and not necessarily that of TAS
> Solutions Ltd.

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

-- 
dev-tech-crypto mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto