Description of problem: Run Evolution and configure POP3 point it to old server with TLS protocoll < 1.2 cause this error: "Error performing TLS handshake: A packet with illegal or unsupported version was received." Version-Release number of selected component (if applicable): Fedora 32 beta with crypto-policies-20191128-5.gitcd267a5.fc32.noarch How reproducible: Steps to Reproduce: 1.Install and run evolution 2.Configure it on a pop3/imap/smtp with TLS < 1.2 3.Try download mails Actual results: You get TLS handshake error Expected results: work as expect also with old TLS protocol. The change of default TLS protocol and drop TLS 1.[01] will done into Fedora 33 Additional info: See also this thread https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/BUNGWYSPMVR2ZKMDUKBGFVEJSTNUC5F7/
Daiki, apparently GnuTLS does not enable TLS 1.0 and 1.1 with NORMAL priority by default. Is that true? If so, we will need the gnutls back-end generator updated to enable TLS 1.0 and TLS 1.1 if in policy.
(In reply to Tomas Mraz from comment #1) > Daiki, apparently GnuTLS does not enable TLS 1.0 and 1.1 with NORMAL > priority by default. Is that true? Beginning with GnuTLS 3.7, yes. But in Fedora 32 we have GnuTLS 3.6 still. Problem is, glib-networking tries to match web browsers in addition to system policy, so it uses -VERS-TLS1.1:-VERS-TLS1.0 because web browsers planned TLS 1.0/1.1 disablement for March 2020 and glib-networking 2.64 release was scheduled for March. That made sense at the time, but browsers have delayed TLS 1.0/1.1 disablement indefinitely because some government COVID-19 website only supported TLS 1.0. So we need to push an update to reenable these protocols for F32. (glib-networking can't directly use system policy because, although Fedora system policy might not be too far behind what web browsers are doing, upstream policies move much too slow. E.g. GnuTLS 3.6 branch will never disable TLS 1.0/1.1, but it might be a long time before GnuTLS 3.7 is stable.)
FEDORA-2020-60b926a6f5 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-60b926a6f5
FEDORA-2020-60b926a6f5 has been pushed to the Fedora 32 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-60b926a6f5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-60b926a6f5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
(In reply to Fedora Update System from comment #4) > FEDORA-2020-60b926a6f5 has been pushed to the Fedora 32 testing repository. > In short time you'll be able to install the update with the following > command: > `sudo dnf upgrade --enablerepo=updates-testing > --advisory=FEDORA-2020-60b926a6f5` > You can provide feedback for this update here: > https://bodhi.fedoraproject.org/updates/FEDORA-2020-60b926a6f5 > > See also https://fedoraproject.org/wiki/QA:Updates_Testing for more > information on how to test updates. I have install this update testing and the access to old email server (TLS<1.2) via evolution work again. Thank to all Dario
FEDORA-2020-60b926a6f5 has been pushed to the Fedora 32 stable repository. If problem still persists, please make note of it in this bug report.