Fails to ask for POP3 password, connection attempt does not succeed with version 78. Works with version 68.
Categories
(MailNews Core :: Networking: POP, defect)
Tracking
(Not tracked)
People
(Reporter: pyxis24, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [tls1.2 required])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.2 Safari/605.1.15
Steps to reproduce:
Upgrade 68.9 -> 78.0
Actual results:
I have several POP3 and IMAP accounts, some have passwords saved in TB, some should prompt for password once opened.
The accounts with the saved passwords work.
The IMAP accounts with the saved passwords work.
The POP3 accounts without saved passwords claim to be "Connected to ..." the server in the status line, but fail to prompt for the password. Thus they do not succeed loading new mail.
Expected results:
prompt for the password
I donwgraded to 68.10 with --allow-downgrade, restored the address book (history.mab) from backup, and things work as they used to, all accounts w/o saved passwords prompt for them.
|
||
Updated•4 years ago
|
|
||
Comment 2•4 years ago
|
||
Please attach a pop3 protocol log: https://wiki.mozilla.org/MailNews:Logging
|
||
Comment 3•4 years ago
|
||
Even if it doesn't look like it at first, it could be a TLS version issue.
|
|
||
Comment 4•4 years ago
|
||
Looks like too old SSL version. We now require TLS 1.2. OVerride by setting security.tls.version.min to 1 (for TLS 1.0)
nmap --script ssl-enum-ciphers -p 995 mail.multicon.de
Starting Nmap 7.80 ( https://nmap.org ) at 2020-08-27 14:37 EEST
Nmap scan report for mail.multicon.de (85.237.64.235)
Host is up (0.037s latency).
rDNS record for 85.237.64.235: light24.powerweb.de
PORT STATE SERVICE
995/tcp open pop3s
| ssl-enum-ciphers:
| SSLv3:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 4096) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 4096) - C
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
| compressors:
| DEFLATE
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| 64-bit block cipher IDEA vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| CBC-mode cipher in SSLv3 (CVE-2014-3566)
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
| TLSv1.0:
| ciphers:
| TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (dh 1024) - D
| TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (dh 1024) - A
| TLS_DHE_RSA_WITH_SEED_CBC_SHA (dh 1024) - A
| TLS_RSA_WITH_3DES_EDE_CBC_SHA (rsa 4096) - C
| TLS_RSA_WITH_AES_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_AES_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_IDEA_CBC_SHA (rsa 4096) - A
| TLS_RSA_WITH_RC4_128_MD5 (rsa 4096) - C
| TLS_RSA_WITH_RC4_128_SHA (rsa 4096) - C
| TLS_RSA_WITH_SEED_CBC_SHA (rsa 4096) - A
| compressors:
| DEFLATE
| NULL
| cipher preference: client
| warnings:
| 64-bit block cipher 3DES vulnerable to SWEET32 attack
| 64-bit block cipher IDEA vulnerable to SWEET32 attack
| Broken cipher RC4 is deprecated by RFC 7465
| Ciphersuite uses MD5 for message integrity
| Key exchange (dh 1024) of lower strength than certificate key
|_ least strength: D
Fair enough if that's the reason - but shouldn't the user get an error message stating that the TLS version is unsuitable, instead of the communication attempt silently and endlessly failing?
An end user typically has little influence what server version her provider runs. The provider however needs a qualified report from the end user to change things.
|
|
||
Comment 6•4 years ago
|
||
I agree. We're hoping to do that in bug 1590473, bug 1590474 or a follow-up once those are covered.
Description
•