Your message dated Sun, 04 Nov 2018 11:28:58 +0700 with message-id <[email protected]> and subject line Re: Bug#912818: getmail: socket error ([SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:726)) has caused the Debian Bug report #912818, regarding getmail: socket error ([SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:726)) to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 912818: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=912818 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: getmail Version: 5.6-1 Severity: normal getmail no longer works after dist-upgrade to Buster: ~~~~ SimplePOP3SSLRetriever:{USER}@[email protected]:995: {USER}@iinet.net.au: socket error ([SSL: WRONG_SIGNATURE_TYPE] wrong signature type (_ssl.c:726)) ~~~~ I tried version 5.7-3 from "unstable" but it fails in the same way... -- Regards, Dmitry Smirnov
signature.asc
Description: This is a digitally signed message part.
--- End Message ---
--- Begin Message ---On Sun 2018-11-04 11:26:26 +1100, Dmitry Smirnov wrote: > Package: getmail > Version: 5.6-1 > Severity: normal > > getmail no longer works after dist-upgrade to Buster: > > ~~~~ > SimplePOP3SSLRetriever:{USER}@[email protected]:995: > {USER}@iinet.net.au: socket error ([SSL: WRONG_SIGNATURE_TYPE] wrong > signature type (_ssl.c:726)) > ~~~~ > > I tried version 5.7-3 from "unstable" but it fails in the same way... The problem here is with the behavior of the remote server, so i'm closing this bug report. If you think my analysis below is wrong, feel free to reopen the bug report and explain why! You can replicate the failure on buster with: openssl s_client -connect mail.iinet.net.au:993 In particular, the client is offering in its TLS 1.2 ClientHello a "signature_algorithms" extension that does *not* list rsa_pkcs1_sha1 (0x0201) -- but the server goes ahead and uses that particular signature algorithm in its ServerKeyExchange method. The reason this is excluded is that OpenSSL 1.1.1 is more aggressive about deprecating known-weak cryptographic algorithsm, and in 2018 that includes SHA1. I actually can't even get openssl to offer to accept SHA1 any longer, and that's good :) openssl s_client -sigalgs RSA+SHA1:RSA+SHA256 -connect mail.iinet.net.au:993 only offers Signature Algorithm: rsa_pkcs1_sha256 (0x0401), despite having listed RSA+SHA1! However, you can see the same misbehavior by the server with gnutls-cli, depending on whether you ask it to accept SHA1 signatures or not. compare this failing command: gnutls-cli --priority=NORMAL:-SIGN-RSA-SHA1 mail.iinet.net.au:995 with this succeeding command: gnutls-cli --priority=NORMAL:+SIGN-RSA-SHA1 mail.iinet.net.au:995 So the server operator is offering TLS 1.2 without respecting the client's signature_algorithms extension. Feel free to forward this report to the server operator. And they are welcome to follow up here (whether or not we reopen the bug report) if they want to ask questions or suggest clarifications. Regards, --dkg
Description: PGP signature
--- End Message ---
