回复: openssl-users Digest, Vol 86, Issue 1

Wed Jan 5 15:08:46 UTC 2022

You are welcome. Determining why TLS handshakes fail is a challenge
since it does require knowledge of what cipher suites and algorithms
are required by the server and are missing in the client.

On Tue, 2022-01-04 at 23:08 +0000, Ma Zhenhua wrote:
> Hi Mark,
> 
> 
> 
> 
> 
> 
> 
> Thanks so much for your advice.
>  You're right. This is truely caused by signature_algorithms_cert
> extension not containing rsa_pkcs1_sha256 (0x0401). Below solutions
> now works well regarding TLS handshake.
> 
> 
> 
> 
> 
> 1.The ClientHello doesn't include signature_algorithms_cert
> extension.
> 
> 2.The signature_algorithms_cert extension in ClientHello contains
> rsa_pkcs1_sha256 (0x0401).
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Thanks,
> 
> 
> Allen
> 
> 
> 发件人: openssl-users <openssl-users-bounces at openssl.org> 代表 
> openssl-users-request at openssl.org <openssl-users-request at openssl.org>
> 
> 发送时间: 2022年1月1日 15:48
> 
> 收件人: openssl-users at openssl.org <openssl-users at openssl.org>
> 
> 主题: openssl-users Digest, Vol 86, Issue 1
>  
> 
> 
> 
> Send openssl-users mailing list submissions to
> 
>         openssl-users at openssl.org
> 
> 
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 
>         https://mta.openssl.org/mailman/listinfo/openssl-users
> 
> or, via email, send a message with subject or body 'help' to
> 
>         openssl-users-request at openssl.org
> 
> 
> 
> You can reach the person managing the list at
> 
>         openssl-users-owner at openssl.org
> 
> 
> 
> When replying, please edit your Subject line so it is more specific
> 
> than "Re: Contents of openssl-users digest..."
> 
> 
> 
> 
> 
> Today's Topics:
> 
> 
> 
>    1. RE: undefined symbol: OSSL_provider_init when running "make
> 
>       test" for OpenSSL 3.0 (Lee Staniforth)
> 
>    2. RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert
> 
>       (Michael Wojcik)
> 
>    3. Re: [openssl-1.1.1l] TLS1.2 Server responses with Alert
> 
>       (Mark Hack)
> 
> 
> 
> 
> 
> -------------------------------------------------------------------
> ---
> 
> 
> 
> Message: 1
> 
> Date: Fri, 31 Dec 2021 13:46:49 +0000
> 
> From: Lee Staniforth <Lee.Staniforth at synchronoss.com>
> 
> To: Matt Caswell <matt at openssl.org>, "openssl-users at openssl.org"
> 
>         <openssl-users at openssl.org>
> 
> Subject: RE: undefined symbol: OSSL_provider_init when running "make
> 
>         test" for OpenSSL 3.0
> 
> Message-ID:
> 
>         <
> DM6PR07MB8028DD6128102487938131E882469 at DM6PR07MB8028.namprd07.prod.outlook.com
> >
> 
>         
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> Thanks very much, Matt and defulger.
> 
> Removing the "-fvisibility=hidden" has enabled the tests to pass.
> 
> 
> 
> I'll now have to see how my application (which is statically linked
> to OpenSSL) fairs.
> 
> 
> 
> Lee
> 
> 
> 
> From: Matt Caswell <matt at openssl.org>
> 
> Sent: 23 December 2021 10:13
> 
> To: Lee Staniforth <Lee.Staniforth at synchronoss.com>; 
> openssl-users at openssl.org
> 
> Subject: Re: undefined symbol: OSSL_provider_init when running "make
> test" for OpenSSL 3.0
> 
> 
> 
> On 21/12/2021 15:09, Lee Staniforth wrote: > ./Configure linux-x86_64 
> no-shared -m64 -fPIC -fvisibility=hidden Try dropping "-
> fvisibility=hidden". I can replicate this problem when using no-
> shared and
> 
> External (matt at openssl.org<mailto:matt at openssl.org>)
> 
>   Report This Email<
> https://protection.inkyphishfence.com/report?id=c3luY2hyb25vc3MvbGVlLnN0YW5pZm9ydGhAc3luY2hyb25vc3MuY29tL2NiZGFiM2RjZDIzNWI3NDllOWQzYzRlYzBlYTA3Y2I1LzE2NDAyNTQzODIuMzc=#key=1fa1e349d7396284bf7cc883faec871a
> > 
>  FAQ<https://www.inky.com/banner-faq/>  Protection by INKY<
> https://www.inky.com>
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On 21/12/2021 15:09, Lee Staniforth wrote:
> 
> 
> 
> > ./Configure linux-x86_64 no-shared -m64 -fPIC -fvisibility=hidden
> 
> 
> 
> 
> 
> 
> 
> Try dropping "-fvisibility=hidden". I can replicate this problem when
> 
> 
> 
> using no-shared and -fvisibility=hidden. If I drop the
> 
> 
> 
> "-fvisibility=hidden" the problem goes away.
> 
> 
> 
> 
> 
> 
> 
> Matt
> 
> -------------- next part --------------
> 
> An HTML attachment was scrubbed...
> 
> URL: <
> https://mta.openssl.org/pipermail/openssl-users/attachments/20211231/0f037481/attachment-0001.htm
> >
> 
> 
> 
> ------------------------------
> 
> 
> 
> Message: 2
> 
> Date: Fri, 31 Dec 2021 15:05:26 +0000
> 
> From: Michael Wojcik <Michael.Wojcik at microfocus.com>
> 
> To: "openssl-users at openssl.org" <openssl-users at openssl.org>
> 
> Subject: RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert
> 
> Message-ID:
> 
>         <
> DM6PR18MB27005C4E44DE291D1C26B9EEF9469 at DM6PR18MB2700.namprd18.prod.outlook.com
> >
> 
>         
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> 
> > From: openssl-users <openssl-users-bounces at openssl.org> On Behalf
> Of Ma Zhenhua
> 
> > Sent: Thursday, 30 December, 2021 23:59
> 
> 
> 
> > On the SSL/TLS server, there's one error as follows. 
> 
> > "SSL Error(118) - no suitable signature algorithm"
> 
> 
> 
> Debugging handshake failures isn't my area of expertise, but I note
> both ClientHellos include a signature_algorithms extension, and the
> contents are quite different. In particular, the successful
> ClientHello includes the Signature Hash Algorithm Hash and Signature
>  Hash Algorithm Signature parameters, while the failing one doesn't.
> 
> 
> 
> The failing one also includes a signature_algorithms_cert extension,
> while the successful one does not. I don't know offhand how the
> algorithms specified in that extension correspond to the signature-
> algorithm OIDs in signatures, but the server's certificate
>  has 1.2.840.113549.1.1.11 (sha256WithRSAEncryption) which seems like
> it ought to correspond to either rsa_pss_rsae_sha256 or
> rsa_pss_pss_sha256. (Apparently those are both RSA-PSS with SHA256,
> as the name implies, and the difference between the two of them
>  is whether the public key is encoded using the rsaEncryption format
> in the certificate, or the id-RSASSA-PSS format. The failing client
> is saying it understands both, AIUI.)
> 
> 
> 
> So my guess would be the server is unhappy that the failing client's
> ClientHello doesn't include the parameters for the various supported
> signature schemes in its signature_algorithms extension. But that's
> just a guess, and I don't know how you'd fix it.
> 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20220105/1cce73cb/attachment.htm>