Discussion:
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
(too old to reply)
Johannes 'josch' Schauer
2019-08-11 07:50:01 UTC
Permalink
Package: curl
Version: 7.65.3-1
Severity: normal

Hi,

steps to reproduce:

$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (OUT), TLS alert, handshake failure (552):
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type

This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.

Thanks!

cheers, josch
Johannes Schauer
2019-08-12 08:10:02 UTC
Permalink
Control: reassign -1 openssl 1.1.1~~pre9-1
Control: tag -1 + buster
Post by Johannes 'josch' Schauer
$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: none
CApath: /etc/ssl/certs
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.
I now figured out that this problem is actually due to openssl and not due to
curl. I bisected Debian unstable from snapshot.d.o to figure out that the last
working snapshot is 20180822T014239Z and the first that shows this problem is
20180822T060826Z. When I diff the output of `dpkg -l` on both chroots then I
get:

82c82
< ii libssl1.1:amd64 1.1.0h-4 amd64 Secure Sockets Layer toolkit - shared libraries
---
Post by Johannes 'josch' Schauer
ii libssl1.1:amd64 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - shared libraries
95c95
< ii openssl 1.1.0h-4 amd64 Secure Sockets Layer toolkit - cryptographic utility
---
Post by Johannes 'josch' Schauer
ii openssl 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - cryptographic utility
Thanks!

cheers, josch
Johannes Schauer
2019-08-12 08:50:02 UTC
Permalink
Hi,
Post by Johannes Schauer
Post by Johannes 'josch' Schauer
$ sudo debootstrap --include=curl,ca-certificates unstable debian-unstable
[...]
$ sudo chroot debian-unstable curl -vvv https://www.daserste.de
* Trying 8.248.97.252:443...
* TCP_NODELAY set
* Connected to www.daserste.de (8.248.97.252) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* CAfile: none
CApath: /etc/ssl/certs
* error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
* Closing connection 0
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
This also happens with other domains. I hope this is actually a curl
issue and not my own stupidity but this problem only occurs with curl
and not wget or firefox and the domain from above has an A+ rating on
ssllabs.com, so I guess it is properly configured.
I now figured out that this problem is actually due to openssl and not due to
curl. I bisected Debian unstable from snapshot.d.o to figure out that the last
working snapshot is 20180822T014239Z and the first that shows this problem is
20180822T060826Z. When I diff the output of `dpkg -l` on both chroots then I
82c82
< ii libssl1.1:amd64 1.1.0h-4 amd64 Secure Sockets Layer toolkit - shared libraries
---
Post by Johannes 'josch' Schauer
ii libssl1.1:amd64 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - shared libraries
95c95
< ii openssl 1.1.0h-4 amd64 Secure Sockets Layer toolkit - cryptographic utility
---
Post by Johannes 'josch' Schauer
ii openssl 1.1.1~~pre9-1 amd64 Secure Sockets Layer toolkit - cryptographic utility
thanks to juliank on #debian-devel I found out that this issue seems to be a
duplicate of #912759?

If so, what should I write to the server admins of daserste.de? I'm not quite
knowledgable about the topic and with the Qualys SSL Labs Server test reporting
an A+ for the server, I don't know what argument to make that they are wrong.

Thanks!

cheers, josch
Kurt Roeckx
2019-08-12 16:40:01 UTC
Permalink
Post by Johannes Schauer
Post by Johannes 'josch' Schauer
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
thanks to juliank on #debian-devel I found out that this issue seems to be a
duplicate of #912759?
If so, what should I write to the server admins of daserste.de? I'm not quite
knowledgable about the topic and with the Qualys SSL Labs Server test reporting
an A+ for the server, I don't know what argument to make that they are wrong.
Yes, this is a duplicate of #912759. Their software is buggy, most
likely not supported. They should probably talk to their vendor to
get an update.


Kurt
Sebastian Andrzej Siewior
2019-08-12 20:40:01 UTC
Permalink
Post by Kurt Roeckx
Post by Johannes Schauer
Post by Johannes 'josch' Schauer
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
thanks to juliank on #debian-devel I found out that this issue seems to be a
duplicate of #912759?
If so, what should I write to the server admins of daserste.de? I'm not quite
knowledgable about the topic and with the Qualys SSL Labs Server test reporting
an A+ for the server, I don't know what argument to make that they are wrong.
Yes, this is a duplicate of #912759. Their software is buggy, most
likely not supported. They should probably talk to their vendor to
get an update.
| $ host www.daserste.de
| www.daserste.de is an alias for sni.daserste.c.footprint.net.
| sni.daserste.c.footprint.net has address 8.248.125.252
| sni.daserste.c.footprint.net has address 67.26.137.252
| sni.daserste.c.footprint.net has address 8.248.129.252

ach level3 CDN, lovely. So the problem is to find someone who
understands the problem. This goes for the people behind daserste.de
and those behind the CDN.

Kurt, could we get something into OpenSSL (aka openssl s_client
-connect) which describes the error more accurate / verbose?
I will try to collect some information and point the ssllabs people to
it hoping that it will pop up in the server rating…
Post by Kurt Roeckx
Kurt
Sebastian
Kurt Roeckx
2019-08-12 22:10:02 UTC
Permalink
Post by Sebastian Andrzej Siewior
Post by Kurt Roeckx
Post by Johannes Schauer
Post by Johannes 'josch' Schauer
curl: (35) error:1414D172:SSL routines:tls12_check_peer_sigalg:wrong signature type
thanks to juliank on #debian-devel I found out that this issue seems to be a
duplicate of #912759?
If so, what should I write to the server admins of daserste.de? I'm not quite
knowledgable about the topic and with the Qualys SSL Labs Server test reporting
an A+ for the server, I don't know what argument to make that they are wrong.
Yes, this is a duplicate of #912759. Their software is buggy, most
likely not supported. They should probably talk to their vendor to
get an update.
| $ host www.daserste.de
| www.daserste.de is an alias for sni.daserste.c.footprint.net.
| sni.daserste.c.footprint.net has address 8.248.125.252
| sni.daserste.c.footprint.net has address 67.26.137.252
| sni.daserste.c.footprint.net has address 8.248.129.252
ach level3 CDN, lovely. So the problem is to find someone who
understands the problem. This goes for the people behind daserste.de
and those behind the CDN.
Kurt, could we get something into OpenSSL (aka openssl s_client
-connect) which describes the error more accurate / verbose?
I will try to collect some information and point the ssllabs people to
it hoping that it will pop up in the server rating…
The error is very clear to me. The server picked a signature
algorithm that the client didn't offer. Should I try to contact
level 3?


Kurt
Sebastian Andrzej Siewior
2019-08-13 19:20:02 UTC
Permalink
Post by Kurt Roeckx
Post by Sebastian Andrzej Siewior
Kurt, could we get something into OpenSSL (aka openssl s_client
-connect) which describes the error more accurate / verbose?
I will try to collect some information and point the ssllabs people to
it hoping that it will pop up in the server rating…
The error is very clear to me. The server picked a signature
algorithm that the client didn't offer.
signature algorithm used for the key-exchange (forward-security) if I'm
not mistaken. My point is that with more information here, we maybe
could avoid being involved :)
I don't know if the problem is a bug in an older openssl version or a
bad configarion used on the server side.
Post by Kurt Roeckx
Should I try to contact
level 3?
Yes, please. As an openssl dev you might have more luck. With a template
I would ping the ssllabs folks :)
Post by Kurt Roeckx
Kurt
Sebastian
Johannes Schauer
2019-08-14 13:20:01 UTC
Permalink
Hi Sebastian & Kurt,

Quoting Sebastian Andrzej Siewior (2019-08-13 21:09:35)
Post by Sebastian Andrzej Siewior
Post by Kurt Roeckx
Post by Sebastian Andrzej Siewior
Kurt, could we get something into OpenSSL (aka openssl s_client
-connect) which describes the error more accurate / verbose?
I will try to collect some information and point the ssllabs people to
it hoping that it will pop up in the server rating

The error is very clear to me. The server picked a signature
algorithm that the client didn't offer.
signature algorithm used for the key-exchange (forward-security) if I'm
not mistaken. My point is that with more information here, we maybe
could avoid being involved :)
I don't know if the problem is a bug in an older openssl version or a
bad configarion used on the server side.
Post by Kurt Roeckx
Should I try to contact
level 3?
Yes, please. As an openssl dev you might have more luck. With a template
I would ping the ssllabs folks :)
thanks a lot for looking into this issue.

I would volunteer to help somehow as well but so far I don't know enough to be
of any help, I'm afraid. I wouldn't even know how to show that the server
picked a signature algorithm that the client didn't offer.

Thanks a lot to you both and tell me if there is anything I can do.

cheers, josch
Kurt Roeckx
2019-08-14 21:10:02 UTC
Permalink
Post by Sebastian Andrzej Siewior
Yes, please. As an openssl dev you might have more luck. With a template
I would ping the ssllabs folks :)
I've opened https://github.com/ssllabs/ssllabs-scan/issues/740

I think they're actually know enough about TLS to know what the
issue is.


Kurt

Loading...