[prev in list] [next in list] [prev in thread] [next in thread]
List: openssl-users
Subject: Re: =?UTF-8?Q?=E5=9B=9E=E5=A4=8D=3A?= openssl-users Digest, Vol 86, Issue 1
From: Mark Hack <markhack () markhack ! com>
Date: 2022-01-05 15:08:46
Message-ID: 920a3c54a6a05ac6d27bf6d4aa4f45fbad843266.camel () markhack ! com
[Download RAW message or body]
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@openssl.org> 代表
> openssl-users-request@openssl.org <openssl-users-request@openssl.org>
>
> 发送时间: 2022年1月1日 15:48
>
> 收件人: openssl-users@openssl.org <openssl-users@openssl.org>
>
> 主题: openssl-users Digest, Vol 86, Issue 1
>
>
>
>
> Send openssl-users mailing list submissions to
>
> openssl-users@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@openssl.org
>
>
>
> You can reach the person managing the list at
>
> openssl-users-owner@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@synchronoss.com>
>
> To: Matt Caswell <matt@openssl.org>, "openssl-users@openssl.org"
>
> <openssl-users@openssl.org>
>
> Subject: RE: undefined symbol: OSSL_provider_init when running "make
>
> test" for OpenSSL 3.0
>
> Message-ID:
>
> <
> DM6PR07MB8028DD6128102487938131E882469@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@openssl.org>
>
> Sent: 23 December 2021 10:13
>
> To: Lee Staniforth <Lee.Staniforth@synchronoss.com>;
> openssl-users@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@openssl.org<mailto:matt@openssl.org>)
>
> Report This Email<
> https://protection.inkyphishfence.com/report?id=c3luY2hyb25vc3MvbGVlLnN0YW5pZm9ydGhA \
> c3luY2hyb25vc3MuY29tL2NiZGFiM2RjZDIzNWI3NDllOWQzYzRlYzBlYTA3Y2I1LzE2NDAyNTQzODIuMzc=#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@microfocus.com>
>
> To: "openssl-users@openssl.org" <openssl-users@openssl.org>
>
> Subject: RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert
>
> Message-ID:
>
> <
> DM6PR18MB27005C4E44DE291D1C26B9EEF9469@DM6PR18MB2700.namprd18.prod.outlook.com
> >
>
>
>
> Content-Type: text/plain; charset="us-ascii"
>
>
>
> > From: openssl-users <openssl-users-bounces@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.
>
>
>
[Attachment #3 (text/html)]
<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=gb2312">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} \
</style> </head>
<body dir="ltr" style="text-align:left; direction:ltr;"><div>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.</div><div><br></div><div><br></div><div><br></div><div>On Tue, 2022-01-04 at \
23:08 +0000, Ma Zhenhua wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; \
border-left:2px #729fcf solid;padding-left:1ex"> <div style="font-family: Calibri, \
Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> Hi <span \
style="font-family:"Microsoft Yahei UI", Verdana, Simsun, "Segoe \
UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", \
sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline \
!important">Mark,</span></div> <div style="font-family: Calibri, Helvetica, \
sans-serif; font-size: 12pt; color: rgb(0, 0, 0);"> <span \
style="font-family:"Microsoft Yahei UI", Verdana, Simsun, "Segoe \
UI", -apple-system, BlinkMacSystemFont, Roboto, "Helvetica Neue", \
sans-serif;font-size:14.6667px;background-color:rgb(255, 255, 255);display:inline \
!important"><br> </span></div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: \
rgb(0, 0, 0);"> <span style="font-family:"Microsoft Yahei UI", Verdana, \
Simsun, "Segoe UI", -apple-system, BlinkMacSystemFont, Roboto, \
"Helvetica Neue", sans-serif;font-size:14.6667px;background-color:rgb(255, \
255, 255);display:inline !important">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.</span></div> <div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> 1.The ClientHello doesn't include signature_algorithms_cert \
extension.<br> 2.The signature_algorithms_cert extension in ClientHello contains \
rsa_pkcs1_sha256 (0x0401).<br> </div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> <br>
</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> Thanks,</div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; \
color:rgb(0,0,0)"> Allen</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" \
style="font-size:11pt"><b>发件人:</b> openssl-users \
<openssl-users-bounces@openssl.org> 代表 openssl-users-request@openssl.org \
<openssl-users-request@openssl.org><br> <b>发送时间:</b> 2022年1月1日 \
15:48<br> <b>收件人:</b> openssl-users@openssl.org \
<openssl-users@openssl.org><br> <b>主题:</b> openssl-users Digest, Vol 86, \
Issue 1</font> <div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="PlainText">Send openssl-users mailing list submissions to<br>
openssl-users@openssl.org<br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a \
href="https://mta.openssl.org/mailman/listinfo/openssl-users">https://mta.openssl.org/mailman/listinfo/openssl-users</a><br>
or, via email, send a message with subject or body 'help' to<br>
openssl-users-request@openssl.org<br>
<br>
You can reach the person managing the list at<br>
openssl-users-owner@openssl.org<br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of openssl-users digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. RE: undefined symbol: OSSL_provider_init when running "make<br>
test" for OpenSSL 3.0 (Lee Staniforth)<br>
2. RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert<br>
(Michael Wojcik)<br>
3. Re: [openssl-1.1.1l] TLS1.2 Server responses with Alert<br>
(Mark Hack)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Fri, 31 Dec 2021 13:46:49 +0000<br>
From: Lee Staniforth <Lee.Staniforth@synchronoss.com><br>
To: Matt Caswell <matt@openssl.org>, "openssl-users@openssl.org"<br>
<openssl-users@openssl.org><br>
Subject: RE: undefined symbol: OSSL_provider_init when running "make<br>
test" for OpenSSL 3.0<br>
Message-ID:<br>
\
<DM6PR07MB8028DD6128102487938131E882469@DM6PR07MB8028.namprd07.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
Thanks very much, Matt and defulger.<br>
Removing the "-fvisibility=hidden" has enabled the tests to pass.<br>
<br>
I'll now have to see how my application (which is statically linked to OpenSSL) \
fairs.<br> <br>
Lee<br>
<br>
From: Matt Caswell <matt@openssl.org><br>
Sent: 23 December 2021 10:13<br>
To: Lee Staniforth <Lee.Staniforth@synchronoss.com>; \
openssl-users@openssl.org<br>
Subject: Re: undefined symbol: OSSL_provider_init when running "make test" for \
OpenSSL 3.0<br> <br>
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<br> External \
(matt@openssl.org<mailto:matt@openssl.org>)<br> Report This Email<<a \
href="https://protection.inkyphishfence.com/report?id=c3luY2hyb25vc3MvbGVlLnN0YW5pZm9y \
dGhAc3luY2hyb25vc3MuY29tL2NiZGFiM2RjZDIzNWI3NDllOWQzYzRlYzBlYTA3Y2I1LzE2NDAyNTQzODIuMz \
c=#key=1fa1e349d7396284bf7cc883faec871a">https://protection.inkyphishfence.com/report? \
id=c3luY2hyb25vc3MvbGVlLnN0YW5pZm9ydGhAc3luY2hyb25vc3MuY29tL2NiZGFiM2RjZDIzNWI3NDllOWQ \
zYzRlYzBlYTA3Y2I1LzE2NDAyNTQzODIuMzc=#key=1fa1e349d7396284bf7cc883faec871a</a>>
FAQ<<a href="https://www.inky.com/banner-faq/">https://www.inky.com/banner-faq/</a>> \
Protection by INKY<<a href="https://www.inky.com">https://www.inky.com</a>><br> \
<br> <br>
<br>
<br>
<br>
<br>
On 21/12/2021 15:09, Lee Staniforth wrote:<br>
<br>
> ./Configure linux-x86_64 no-shared -m64 -fPIC -fvisibility=hidden<br>
<br>
<br>
<br>
Try dropping "-fvisibility=hidden". I can replicate this problem when<br>
<br>
using no-shared and -fvisibility=hidden. If I drop the<br>
<br>
"-fvisibility=hidden" the problem goes away.<br>
<br>
<br>
<br>
Matt<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="https://mta.openssl.org/pipermail/openssl-users/attachments/20211231 \
/0f037481/attachment-0001.htm">https://mta.openssl.org/pipermail/openssl-users/attachments/20211231/0f037481/attachment-0001.htm</a>><br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Fri, 31 Dec 2021 15:05:26 +0000<br>
From: Michael Wojcik <Michael.Wojcik@microfocus.com><br>
To: "openssl-users@openssl.org" <openssl-users@openssl.org><br>
Subject: RE: [openssl-1.1.1l] TLS1.2 Server responses with Alert<br>
Message-ID:<br>
\
<DM6PR18MB27005C4E44DE291D1C26B9EEF9469@DM6PR18MB2700.namprd18.prod.outlook.com><br>
<br>
Content-Type: text/plain; charset="us-ascii"<br>
<br>
> From: openssl-users <openssl-users-bounces@openssl.org> On Behalf Of Ma \
Zhenhua<br> > Sent: Thursday, 30 December, 2021 23:59<br>
<br>
> On the SSL/TLS server, there's one error as follows. <br>
> "SSL Error(118) - no suitable signature algorithm"<br>
<br>
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.<br>
<br>
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.)<br> <br>
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.<br> <br>
</div></span></font></div></div></blockquote></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic