Differences in defaults between 1.0.2 and 1.1.1

[Matt Caswell]

On 19/03/2019 15:15, Perrow, Graeme wrote:
> Thanks Matt, the command you listed did succeed. I was hoping to be able to
> change our code so that we could connect to any server we were able to
> connect to before, but if this is truly a server-side bug, there's only so
> much we can do on the client side.
> 
> If our customers see this change in behaviour after we upgrade OpenSSL, my
> understanding is that they will simply have to fix their server.

Fixing the server really is the right solution here. It is broken and clients
shouldn't be forced to work around such broken set ups.

If you absolutely *had* to do it, you can do the same workaround in C code that
s_client does with that "-sigalgs" parameter using the function
SSL_CTX_set1_sigalgs (or SSL_set1_sigalgs):

https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set1_sigalgs.html

But I'd strongly advise against it since using such a sigalgs list will impact
your ability to interoperate with TLSv1.3 servers.

Matt


> 
> Graeme
> 
> -----Original Message----- From: openssl-users
> <openssl-users-bounces at openssl.org> On Behalf Of Matt Caswell Sent: March 19,
> 2019 10:23 AM To: openssl-users at openssl.org Subject: Re: Differences in
> defaults between 1.0.2 and 1.1.1
> 
> 
> 
> On 19/03/2019 13:40, Perrow, Graeme wrote:
>> TLS: error: accept - force handshake failure: errno 11 - moznss error
>> -12162
>> 
>> TLS: can't accept: TLS error -12162:Unsupported hash algorithm used by TLS
>> peer..
> 
> 
> Just to confirm - you've not configured client authentication?
> 
> Assuming not, the above error message from the server suggests that it
> doesn't like one of the signature algorithms sent through from the client in
> the ClientHello. At least I'm assuming that's the point at which it fails.
> You omitted most of the -debug output so its a little unclear exactly how
> far through the handshake it got before the failure occurred. If my
> assumption is right then it looks like the server may be behaving
> incorrectly. It isn't supposed to fail if it encounters a parameter it
> doesn't recognise - its just supposed to ignore it.
> 
> To test the theory I suggest sending through the same list of signature 
> algorithms in the same order that 1.0.2 sends them. You can do that using
> the "-sigalgs" parameter to s_client:
> 
> openssl s_client -showcerts -host <host>:<port> -debug -sigalgs 
> "RSA+SHA512:DSA+SHA512:ECDSA+SHA512:RSA+SHA384:DSA+SHA384:ECDSA+SHA384:RSA+SHA256:DSA+SHA256:ECDSA+SHA256:RSA+SHA224:DSA+SHA224:ECDSA+SHA224:RSA+SHA1:DSA+SHA1:ECDSA+SHA1"
>
>  Matt
>