Bug#934453: curl: SSL
On Tue, Aug 13, 2019 at 09:09:35PM +0200, Sebastian Andrzej Siewior wrote: > 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
Bug#934453: curl: SSL
Hi Sebastian & Kurt, Quoting Sebastian Andrzej Siewior (2019-08-13 21:09:35) > On 2019-08-12 23:59:10 [+0200], Kurt Roeckx wrote: > > > 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. > > > 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 signature.asc Description: signature
Bug#934453: curl: SSL
On 2019-08-12 23:59:10 [+0200], Kurt Roeckx wrote: > > 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. > 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 :) > > Kurt > Sebastian
Bug#934453: [Pkg-openssl-devel] Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
On Mon, Aug 12, 2019 at 10:04:11PM +0200, Sebastian Andrzej Siewior wrote: > On 2019-08-12 18:22:38 [+0200], Kurt Roeckx wrote: > > On Mon, Aug 12, 2019 at 10:42:06AM +0200, Johannes Schauer wrote: > > > > > 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
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
On 2019-08-12 18:22:38 [+0200], Kurt Roeckx wrote: > On Mon, Aug 12, 2019 at 10:42:06AM +0200, Johannes Schauer wrote: > > > > 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… > Kurt Sebastian
Bug#934453: [Pkg-openssl-devel] Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
On Mon, Aug 12, 2019 at 10:42:06AM +0200, Johannes Schauer wrote: > > > 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
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
Hi, On Mon, 12 Aug 2019 10:01:03 +0200 Johannes Schauer wrote: > On Sun, 11 Aug 2019 09:42:21 +0200 Johannes 'josch' Schauer > wrote: > > 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. > > 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 > --- > > ii libssl1.1:amd64 1.1.1~~pre9-1amd64 > > Secure Sockets Layer toolkit - shared libraries > 95c95 > < ii openssl 1.1.0h-4 amd64 > Secure Sockets Layer toolkit - cryptographic utility > --- > > ii openssl 1.1.1~~pre9-1amd64 > > 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 signature.asc Description: signature
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
Control: reassign -1 openssl 1.1.1~~pre9-1 Control: tag -1 + buster On Sun, 11 Aug 2019 09:42:21 +0200 Johannes 'josch' Schauer wrote: > 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. 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 --- > ii libssl1.1:amd64 1.1.1~~pre9-1amd64 > Secure Sockets Layer toolkit - shared libraries 95c95 < ii openssl 1.1.0h-4 amd64 Secure Sockets Layer toolkit - cryptographic utility --- > ii openssl 1.1.1~~pre9-1amd64 > Secure Sockets Layer toolkit - cryptographic utility Thanks! cheers, josch signature.asc Description: signature
Bug#934453: curl: SSL routines:tls12_check_peer_sigalg:wrong signature type
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
