Description of problem: For Evolution to function using TLS the policy needs to be set to DEFAULT on the server end. Client no issue. Server is Fedora 33 with emails located on it. Client is using Evolution and attempting to connect to server to retrieve email using TLS login method etc. Version-Release number of selected component (if applicable): Fedora 33 How reproducible: Always if Set to Default on Server. Client can be Legacy or Default and problem arises. Steps to Reproduce: 1. Set client end to DEFAULT 2. Set server end to LEGACY 3. Start Evolution and do a SEND/RECEIVE 4. Connection successful and email retrieved 5. Set Server to DEFAULT 6. Evolution show error "Error performing TLS handshake: An unexpected TLS packet was received." 7. Reboots etc and no change to results. Actual results: Error displayed Expected results: Should function and TLS login process should proceed without error Additional info: Both Systems worked fine with Fedora 32. Client changed to Fedora 33 and still worked fine. Server upgraded to Fedora 33 and problem appeared. I then experimented with crypto-policies and found the reason and the work around. Hopefully I just need to either update a module or some setting somewhere is incorrect.
Thanks for your report. Several more details would be needed to narrow the cause of the issue. Could you please provide the evolution logs? There's a guide at https://wiki.gnome.org/Apps/Evolution/Debugging Please scrub the personal information, if there will be any, before posting them. Most importantly, what server software are you using (for retrieving mail)? Could you provide logs of the server side as well?
This is most likely an issue with the server using too small of a Diffie hellman key. Try turning off DHE in the application and see if you can connect.
I check/tried some of the logs suggested above and found this error which appears when the server is set to DEFAULT (WebKitWebProcess:2): GStreamer-WARNING **: 10:14:34.249: External plugin loader failed. This most likely means that the plugin loader helper binary was not found or could not be run. You might need to set the GST_PLUGIN_SCANNER environment variable if your setup is unusual. This should normally not be required though. The POP3 log was the same for the two cases DEFAULT and LEGACY and from what I could understand had no error and included. POP3_STREAM_LINE (30): '+OK Begin TLS negotiation now.' Got + response which implied that TLS was OK even though the message on the screen showed what I think is failure. To the best of my knowledge my setup is "normal" I am NOT compiling any code in the OS and standard modules. This is happening on at least several of my clients (Once I spotted the error I did the patch to prevent issues). The systems clients and what I call the server are all fairly vanilla Fedora 33 Workstation. My server is really just a gateway between my clients and the outside and holds some central data. I obviously wish to fix this so that I can stay vanilla in future and just update with new releases etc. I am located in Australia and so am likely to be 12 hours displaced from any help/advice I am given and so am likely to be "slow" for any tests or responses. I can remotely connect to my "server" from home so being on holiday for the next two weeks will not prevent me to doing tests or gathering information. I am happy to try tests/reconfigure or display loges etc to get this sorted as that is good for everyone. I hope I have done what was requested, I have no idea what to do about the "Diffie hellman" key or what might need changing.
Sorry, that didn't uncover much, aside from the fact you're using pop3. Gstreamer error is unrelated. I'm still interested in the output of CAMEL_DEBUG=pop3 evolution or maybe even CAMEL_DEBUG=all evolution after a failed connection, and I still would like to know what server you use and what's in the server logs.
The Server is just F33 Workstation version. Its basically the same as the clients but with dhcp, dovecot and a few other things going. How do I attach the "large" all files. I made pop3 and all both working and failing versions. Even the diff of the all ok and fail is over 2000 lines long. Removing the identifiable folders would take a while but that I don't think really reveals much so I am OK with that.
Created attachment 1741652 [details] Logs OK and failed cases I have seen now attachments are at the top of the log so here are some log files
Oh yeah, so dovecot is the server. According to https://wiki.dovecot.org/SSL/DovecotConfiguration When Dovecot starts up for the first time, it generates new 512bit and 1024bit Diffie Hellman parameters and saves them into <prefix>/var/lib/dovecot/ssl-parameters.dat. Such weak Diffie-Hellman parameters are now disallowed in Fedora 33 DEFAULT (https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2). Please use 2048 bit size or higher, regenerate them (see https://wiki.dovecot.org/SSL/DovecotConfiguration) and confirm that it solves the issue for you.
Seems to be /etc/dovecot/dh.pem and `openssl dhparam -out /etc/dovecot/dh.pem 4096` according to /etc/dovecot/conf.d/10-ssl.conf.
Thanks for your help so far. This us what I have done. 1) I did openssl dhparam -out /etc/dovecot/dh.pem 4096 to generate a new key. Yep took about 30 minutes but appears to have made it fine. Did a reboot of server 2) I then saw that ssl = yes # Preferred permissions: root:root 0444 ssl_cert = </etc/ssl/certs/dovecot.pem # Preferred permissions: root:root 0400 ssl_key = </etc/ssl/private/dovecot.pem permissions was not correct to I adjusted those did a systemctl restart dovecot I am using in 10-ssl.conf these locations ssl = required ssl_cert = </etc/pki/dovecot/certs/dovecot.pem ssl_key = </etc/pki/dovecot/private/dovecot.pem I believe this is new locations. I was just about to check all my evolution settings etc when I ran out of time and so will continue checking etc tomorrow. Any further help at this point is welcome but I don't expect any.
I have read the instructions and clearly my problem is with dovecot and ssl etc. I have done all that has been suggested and check my configurations in evolution etc. I have rebooted both client and server ends etc. I tried using evolution directly on the server end to see if I could reduce down the problem. The instructions indicated that if the client and server are on the same machine then security is not done as its assued to be safe. Well it works fine locally so nothing learned there. Looking at the server logs for dovecot I get these results Policy set to LEGACY dovecot[1455]: pop3-login: Debug: SSL: where=0x10, ret=1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: before SSL initialization dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read client hello dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write server hello dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write change cipher spec dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write encrypted extensions dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write certificate dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 write server certificate verify dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write finished dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=-1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: TLSv1.3 early data dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS read finished dovecot[1455]: pop3-login: Debug: SSL: where=0x20, ret=1: SSLv3/TLS write session ticket dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket dovecot[1455]: pop3-login: Debug: SSL: where=0x2001, ret=1: SSLv3/TLS write session ticket dovecot[1455]: pop3-login: Debug: SSL: where=0x2002, ret=1: SSL negotiation finished successfully audit[4992]: AVC avc: denied { getattr } for pid=4992 comm="auth" name="/" dev="proc" ino=1 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 audit[4993]: AVC avc: denied { getattr } for pid=4993 comm="auth" name="/" dev="proc" ino=1 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 audit[4991]: USER_AUTH pid=4991 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:dovecot_auth_t:s0 msg='op=PAM:authentication grantors=pam_unix acct="ME-XX" exe="/usr/libexec/dovecot/auth" hostname=203.xx.xx.xx addr=203.xx.xx.xx terminal=dovecot res=success' audit[4994]: AVC avc: denied { getattr } for pid=4994 comm="auth" name="/" dev="proc" ino=1 scontext=system_u:system_r:dovecot_auth_t:s0 tcontext=system_u:object_r:proc_t:s0 tclass=filesystem permissive=0 audit[4991]: USER_ACCT pid=4991 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:dovecot_auth_t:s0 msg='op=PAM:accounting grantors=pam_unix,pam_localuser acct="ME-XX`" exe="/usr/libexec/dovecot/auth" hostname=203.xx.xx.xx addr=203.xx.xx.xx terminal=dovecot res=success' dovecot[1455]: pop3-login: Login: user=<ME-XX>, method=PLAIN, rip=203.xx.xx.xx, lip=192.xx.xx.xx, mpid=4995, TLS, session=<PaxorFO3HOPLP0zm> dovecot[1455]: pop3(ME-XX)<4995><PaxorFO3HOPLP0zm>: Disconnected: Logged out top=0/0, retr=0/0, del=0/0, size=0 dovecot[1455]: pop3-login: Debug: SSL alert: close notify Policy set to DEFAULT dovecot[1455]: pop3-login: Error: Failed to initialize SSL server context: Can't load SSL certificate (ssl_cert setting): error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small: user=<>, rip=203.xx.xx.xx, lip=192.xx.xx.xx, secured, session=<6Na7pVO3EOPLP0zm> dovecot[1455]: pop3-login: Disconnected: TLS initialization failed. (no auth attempts in 0 secs): user=<>, rip=203.xx.xx.xx, lip=192.xx.xx.xx, secured, session=<6Na7pVO3EOPLP0zm> 192...... is the server end and 203..... is me remotely trying to connect. Looks to me like I still have some sort of issue with the SSL certificate. I will try the testing instructions in the WIKI page and also investigate SSL_CTX_use_certificate:ee key too small: I will report what I find. At least the error is narrowed down I think. Any advice or help welcome.
Started testing as per WIKI page and the server report the certificates have expired. Verify return code: 10 (certificate has expired) I assume I require some new certificates of some sort.
Hi All, I have tried going further but now I am completely confused about which certificate and what files where are supposed to have/be/configured. The above tells me the key is too small (but I just remade things with 4096 key size). Then when I run the test procedures as per the WIKI it tells me its expired but I just made it a few hours ago. Like I said I am confused and suspect I am looking at the wrong files etc. Any help appreciated. For now reset back to LEGACY so it continues to work.
All in all, that doesn't sound like a crypto-policies issue to me, so I'm going to close this bug. I believe that 1) setting `ssl_dh=</etc/dovecot/dh.pem`, and 2) generating new key/certificate with an allowed key size (`ssl_key/ssl_cert`) will solve the issue for you. In an unlikely case it won't, please try to reproduce the issue with a clean installation of dovecot. If dovecot defaults still lead to your issue, please file a bug against dovecot.
The message SSL_CTX_use_certificate:ee key too small: indicates that the dovecot.pem key/cert is <2048 bits long. Just regenerate it.
Thanks again to everyone for your help. I believe I have done a clean install of dovecot (did a dnf re-install) but maybe that was not enough so I will try again this time try remove and delete all the files I know about and the dnf install again. I will also try again and generate a new 4k key. I agree my problem does appear to be with dovecot and so this should be logged under dovecot. Unfortunately I am still away for another week and I do not wish to risk "breaking" my email server with remote clients so I will do all of this after the 11th when I return. I will report here what I did (if it is fixed). If not then I will create a new bug under dovecot but I am sure its just the key.
What I have now tried to do to correct this. First I copied my existing dovecot configuration (in /etc/dovecot). I then uninstalled dovecot by "dnf remove dovecot". To be sure I then "rm -rf /etc/dovecot". I then "dnf install dovecot". the installation reported some soft errors in my tmpfiles.d usage for nss-pam-ldapd, opendkim, opendmarc. I corrected the /run locations for the pid files and repeated the above which lead to a clean (no errors) install. I then checked 10-mail.conf and 10-ssl.conf to see what differences I had in my configuration compared to the standard configurations. the differences were minor. For mail it was just the mailbox location and the socket locations. For ssl it is the fact that I am using a new dh.pem file In addition I also have the below set to assist in debugging etc ssl_prefer_server_ciphers = yes verbose_ssl = yes For dovecot.conf file I also have listen = *, :: base_dir = /run/dovecot/ login_trusted_networks = my-local-network and my-external-network Again this I think will have no problems. I then tested the new configuration. With it set to LEGACY all is OK. With it set to DEFAULT my-external-network gets in fine and works but my-local-network is still failing. After further investigating turns out that the issue is caused by the fact that /etc/pki/dovecot/dovecot-openssl.cnf and the associated .pem files where old and the bits was too small. This information was found in 1882939. So what to do to fix it was /etc/pki/dovecot/dovecot-openssl.cnf was changed to have 4096 bit pattern rm /etc/pki/dovecot/*/*pem # remove keys first /usr/libexec/dovecot/mkcert.sh # create self signed cert Evolution then complained that the key was now not secure but you just accept it permanently and it then appears to be all sorted.