12:50 a.m.
Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
The problem is that Thunderbird does not show any error message but it's
not able to communicate with the IMAP server. I'm not able to receive
any message from the server. I'm able to send a message but a copy is
then not saved to sent folder for the same reason. My first thought was
that the problem is caused by a downgrade from 68.11 to 68.10 because
Thunderbird currently FTBFS in Fedora 33 but it does not seem to be so.
I've also tried to remove the account and add it back but it did not
help because I was no longer able to log in to my account without any
particular error message. I've also tried to delete the server's
certificates.
The problem seems to be caused by strict crypto policies in Fedora 33
and too small DH key provided by the server.
$ update-crypto-policies --show
DEFAULT
$ openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
too small:ssl/statem/statem_clnt.c:2149:
---
$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
---
... <certificates chain> ...
---
* OK IMAP4 ready
As you can see above, the DH key provided by the server is too small so
the SSL verification fails. Setting the crypto policies to LEGACY solves
the issue for me and I am again able to recreate my Red Hat account in
Thunderbird.
Hope this helps. I'm going to report this problem to service desk.
Lumír
1:18 a.m.
Probably better than switching the system-wide policy to LEGACY is to
create a policy modifier which alters only the minimum size of DH keys.
$ sudo echo "min_dh_size = 1023" >
/etc/crypto-policies/policies/modules/DH-SIZE.pmod
$ sudo update-crypto-policies --set DEFAULT:DH-SIZE
The issue is already reported to the service desk.
Lumír
On 10/1/20 7:50 AM, Lumír Balhar wrote:
Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
The problem is that Thunderbird does not show any error message but
it's not able to communicate with the IMAP server. I'm not able to
receive any message from the server. I'm able to send a message but a
copy is then not saved to sent folder for the same reason. My first
thought was that the problem is caused by a downgrade from 68.11 to
68.10 because Thunderbird currently FTBFS in Fedora 33 but it does not
seem to be so. I've also tried to remove the account and add it back
but it did not help because I was no longer able to log in to my
account without any particular error message. I've also tried to
delete the server's certificates.
The problem seems to be caused by strict crypto policies in Fedora 33
and too small DH key provided by the server.
$ update-crypto-policies --show
DEFAULT
$ openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress =
infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
too small:ssl/statem/statem_clnt.c:2149:
---
$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress =
infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
---
... <certificates chain> ...
---
* OK IMAP4 ready
As you can see above, the DH key provided by the server is too small
so the SSL verification fails. Setting the crypto policies to LEGACY
solves the issue for me and I am again able to recreate my Red Hat
account in Thunderbird.
Hope this helps. I'm going to report this problem to service desk.
Lumír
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
12:20 p.m.
Note that at this point in time (2020), this is a server bug not a
Fedora policy problem.
I also heartily approve of using a custom policy change rather than
switching to legacy, and hopefully people will quickly be able to
remove that custom change too because that DH size is simply too weak
for today standard, and the policy affects all software on the system,
not just thunderbird ...
Simo.
On Thu, 2020-10-01 at 08:18 +0200, Lumír Balhar wrote:
Probably better than switching the system-wide policy to LEGACY is to
create a policy modifier which alters only the minimum size of DH keys.
$ sudo echo "min_dh_size = 1023" >
/etc/crypto-policies/policies/modules/DH-SIZE.pmod
$ sudo update-crypto-policies --set DEFAULT:DH-SIZE
The issue is already reported to the service desk.
Lumír
On 10/1/20 7:50 AM, Lumír Balhar wrote:
> Hello.
>
> I've upgraded to Fedora 33 beta and I've discovered a problem with
> Thunderbird. All email accounts work well except the Red Hat one with
> mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
>
> The problem is that Thunderbird does not show any error message but
> it's not able to communicate with the IMAP server. I'm not able to
> receive any message from the server. I'm able to send a message but a
> copy is then not saved to sent folder for the same reason. My first
> thought was that the problem is caused by a downgrade from 68.11 to
> 68.10 because Thunderbird currently FTBFS in Fedora 33 but it does not
> seem to be so. I've also tried to remove the account and add it back
> but it did not help because I was no longer able to log in to my
> account without any particular error message. I've also tried to
> delete the server's certificates.
>
> The problem seems to be caused by strict crypto policies in Fedora 33
> and too small DH key provided by the server.
>
> $ update-crypto-policies --show
> DEFAULT
>
> $ openssl s_client -showcerts -connect mail.corp.redhat.com:993
> -servername mail.corp.redhat.com
> CONNECTED(00000003)
> depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
> OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress =
> infosec(a)redhat.com
> verify return:1
> depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
> verify return:1
> depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
> verify return:1
> depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
> Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
> mail.corp.redhat.com
> verify return:1
> 139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
> too small:ssl/statem/statem_clnt.c:2149:
> ---
>
> $ sudo update-crypto-policies --set LEGACY
> Setting system policy to LEGACY
> Note: System-wide crypto policies are applied on application start-up.
> It is recommended to restart the system for the change of policies
> to fully take place.
>
> openssl s_client -showcerts -connect mail.corp.redhat.com:993
> -servername mail.corp.redhat.com
> CONNECTED(00000003)
> depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
> OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress =
> infosec(a)redhat.com
> verify return:1
> depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
> verify return:1
> depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
> verify return:1
> depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
> Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
> mail.corp.redhat.com
> verify return:1
> ---
> ... <certificates chain> ...
> ---
> * OK IMAP4 ready
>
> As you can see above, the DH key provided by the server is too small
> so the SSL verification fails. Setting the crypto policies to LEGACY
> solves the issue for me and I am again able to recreate my Red Hat
> account in Thunderbird.
>
> Hope this helps. I'm going to report this problem to service desk.
>
> Lumír
> _______________________________________________
> devel mailing list -- devel(a)lists.fedoraproject.org
> To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
1:01 p.m.
On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote:
On 01. 10. 20 19:20, Simo Sorce wrote:
> and the policy affects all software on the system, not just thunderbird ...
Is it possible to workaround the problem in Thunderbird only?
Only if thunderbrind provides a configuration option to set it and then
instructs NSS, afaik.
CCing Bob, in case he knows of other ways.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
1:05 p.m.
On Thu, 2020-10-01 at 14:01 -0400, Simo Sorce wrote:
On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote:
> On 01. 10. 20 19:20, Simo Sorce wrote:
> > and the policy affects all software on the system, not just thunderbird ...
>
> Is it possible to workaround the problem in Thunderbird only?
Only if thunderbrind provides a configuration option to set it and then
instructs NSS, afaik.
CCing Bob, in case he knows of other ways.
Adding back context for Bob,
this is about enabling 1024 DH, because some IMAP servers are still
badly configured ...
The q. is if this can be done exclusively for thunderbird instead of
changing the system crypto policy for all TLS applications.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
6:30 p.m.
On 10/1/20 11:05 AM, Simo Sorce wrote:
On Thu, 2020-10-01 at 14:01 -0400, Simo Sorce wrote:
> On Thu, 2020-10-01 at 19:47 +0200, Miro Hrončok wrote:
>> On 01. 10. 20 19:20, Simo Sorce wrote:
>>> and the policy affects all software on the system, not just thunderbird ...
>> Is it possible to workaround the problem in Thunderbird only?
> Only if thunderbrind provides a configuration option to set it and then
> instructs NSS, afaik.
>
> CCing Bob, in case he knows of other ways.
Adding back context for Bob,
this is about enabling 1024 DH, because some IMAP servers are still
badly configured ...
I initially handled this by turning off DHE ciphers.
goto thunderbird advanced tab, click on the config editior, type dhe in
the search change
security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha
to false.
Now you can connect thunderbird you a faulty configured server, without
loosing the other protections you get with the DEFAULT policy.
Your browser will still fail on those websites (though you can fix that
with the same trick for firefox).
While application can, in theory, override policy, almost no application
do (and thunderbird is no exception).
bob
The q. is if this can be done exclusively for thunderbird instead of
changing the system crypto policy for all TLS applications.
Simo.
1:08 p.m.
On Thu, Oct 1, 2020 at 5:21 PM Simo Sorce <simo(a)redhat.com> wrote:
Note that at this point in time (2020), this is a server bug not a
Fedora policy problem.
Regardless, as (especially) corporate services tend
to have lives that are excessively longer than updates
in security policies, it might deserve a special mention
in the release notes that some (especially) corporate
systems may fail to connect due to the change in
Fedora security policies, because it may impact the
user experience in a very negative way.
2:02 p.m.
On Thu, 2020-10-01 at 18:08 +0000, Gary Buhrmaster wrote:
On Thu, Oct 1, 2020 at 5:21 PM Simo Sorce <simo(a)redhat.com>
wrote:
> Note that at this point in time (2020), this is a server bug not a
> Fedora policy problem.
Regardless, as (especially) corporate services tend
to have lives that are excessively longer than updates
in security policies, it might deserve a special mention
in the release notes that some (especially) corporate
systems may fail to connect due to the change in
Fedora security policies, because it may impact the
user experience in a very negative way.
You mean Fedora 33 release notes ?
We already blocked things like TLS1.0/1.1 in previous Fedras, and that
had a larger impact on legacy enterprise laggards, I do not know if
this specific case is worth that much.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:10 p.m.
On 01/10/2020 20:02, Simo Sorce wrote:
You mean Fedora 33 release notes ?
We already blocked things like TLS1.0/1.1 in previous Fedras, and that
had a larger impact on legacy enterprise laggards, I do not know if
this specific case is worth that much.
Actually TLS1.0 and 1.1 are still allowed - that's something
else that changes in F33 ;-)
Tom
--
Tom Hughes (tom(a)compton.nu)
http://compton.nu/
7:31 a.m.
On Thu, 2020-10-01 at 20:10 +0100, Tom Hughes wrote:
On 01/10/2020 20:02, Simo Sorce wrote:
> You mean Fedora 33 release notes ?
> We already blocked things like TLS1.0/1.1 in previous Fedras, and that
> had a larger impact on legacy enterprise laggards, I do not know if
> this specific case is worth that much.
Actually TLS1.0 and 1.1 are still allowed - that's something
else that changes in F33 ;-)
Eh right! Maybe a release notes item for all of this makes sense
indeed.
Simo.
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
2:28 a.m.
| I've upgraded to Fedora 33 beta and I've discovered a problem with
| Thunderbird. All email accounts work well except the Red Hat one with
| mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
|
| The problem is that Thunderbird does not show any error message but it's not
| able to communicate with the IMAP server. I'm not able to receive any
| message from the server. I'm able to send a message but a copy is then not
| saved to sent folder for the same reason. My first thought was that the
| problem is caused by a downgrade from 68.11 to 68.10 because Thunderbird
| currently FTBFS in Fedora 33 but it does not seem to be so. I've also tried
| to remove the account and add it back but it did not help because I was no
| longer able to log in to my account without any particular error message.
| I've also tried to delete the server's certificates.
|
| The problem seems to be caused by strict crypto policies in Fedora 33 and
| too small DH key provided by the server.
|
| $ update-crypto-policies --show
| DEFAULT
|
| $ openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername
| mail.corp.redhat.com
| CONNECTED(00000003)
| depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU =
| Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
| verify return:1
| depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
| verify return:1
| depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
| verify return:1
| depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
| Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
| mail.corp.redhat.com
| verify return:1
| 139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too
| small:ssl/statem/statem_clnt.c:2149:
| ---
|
| $ sudo update-crypto-policies --set LEGACY
| Setting system policy to LEGACY
| Note: System-wide crypto policies are applied on application start-up.
| It is recommended to restart the system for the change of policies
| to fully take place.
|
| openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername
| mail.corp.redhat.com
| CONNECTED(00000003)
| depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU =
| Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
| verify return:1
| depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
| verify return:1
| depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
| verify return:1
| depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
| Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
| mail.corp.redhat.com
| verify return:1
| ---
| ... <certificates chain> ...
| ---
| * OK IMAP4 ready
|
| As you can see above, the DH key provided by the server is too small so the
| SSL verification fails. Setting the crypto policies to LEGACY solves the
| issue for me and I am again able to recreate my Red Hat account in
| Thunderbird.
|
| Hope this helps. I'm going to report this problem to service desk.
Same thing applies to mutt. I've filed this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1883976
Harish
2:48 a.m.
New subject: Thunderbird with mail.corp.redhat.com does not work on Fedora
33
On Thu, 2020-10-01 at 15:28 +0800, Harish Pillay wrote:
Same thing applies to mutt. I've filed this bz:
https://bugzilla.redhat.com/show_bug.cgi?id=1883976
Hi,
every application which uses library which complies to system crypto
policies is "affected". For more information:
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
Also see the "Upgrade/compatibility impact" section there.
Bye,
Milan
2:42 a.m.
On Thursday, October 1, 2020 7:50:49 AM CEST Lumír Balhar wrote:
I've upgraded to Fedora 33 beta and I've discovered a problem
with
Thunderbird. All email accounts work well except the Red Hat one with
mail.corp.redhat.com as an IMAP server (I use Zimbra servers not Gmail).
I asked a few days back if the crypto on the mail server could be updated to
comply with F33 (internal ticket INC1447620).
Pavel
The problem is that Thunderbird does not show any error message but
it's
not able to communicate with the IMAP server. I'm not able to receive
any message from the server. I'm able to send a message but a copy is
then not saved to sent folder for the same reason. My first thought was
that the problem is caused by a downgrade from 68.11 to 68.10 because
Thunderbird currently FTBFS in Fedora 33 but it does not seem to be so.
I've also tried to remove the account and add it back but it did not
help because I was no longer able to log in to my account without any
particular error message. I've also tried to delete the server's
certificates.
The problem seems to be caused by strict crypto policies in Fedora 33
and too small DH key provided by the server.
$ update-crypto-policies --show
DEFAULT
$ openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key
too small:ssl/statem/statem_clnt.c:2149:
---
$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
openssl s_client -showcerts -connect mail.corp.redhat.com:993
-servername mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.",
OU = Red Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU =
Information Technology, emailAddress = servicedesk(a)redhat.com, CN =
mail.corp.redhat.com
verify return:1
---
... <certificates chain> ...
---
* OK IMAP4 ready
As you can see above, the DH key provided by the server is too small so
the SSL verification fails. Setting the crypto policies to LEGACY solves
the issue for me and I am again able to recreate my Red Hat account in
Thunderbird.
Hope this helps. I'm going to report this problem to service desk.
Lumír
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
4:32 p.m.
On 01. 10. 20 7:50, Lumír Balhar wrote:
Hello.
I've upgraded to Fedora 33 beta and I've discovered a problem with Thunderbird.
All email accounts work well except the Red Hat one with mail.corp.redhat.com as
an IMAP server (I use Zimbra servers not Gmail).
The problem is that Thunderbird does not show any error message but it's not
able to communicate with the IMAP server. I'm not able to receive any message
from the server. I'm able to send a message but a copy is then not saved to sent
folder for the same reason. My first thought was that the problem is caused by a
downgrade from 68.11 to 68.10 because Thunderbird currently FTBFS in Fedora 33
but it does not seem to be so. I've also tried to remove the account and add it
back but it did not help because I was no longer able to log in to my account
without any particular error message. I've also tried to delete the server's
certificates.
The problem seems to be caused by strict crypto policies in Fedora 33 and too
small DH key provided by the server.
$ update-crypto-policies --show
DEFAULT
$ openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername
mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red
Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information
Technology, emailAddress = servicedesk(a)redhat.com, CN = mail.corp.redhat.com
verify return:1
139893557032768:error:141A318A:SSL routines:tls_process_ske_dhe:dh key too
small:ssl/statem/statem_clnt.c:2149:
---
$ sudo update-crypto-policies --set LEGACY
Setting system policy to LEGACY
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
openssl s_client -showcerts -connect mail.corp.redhat.com:993 -servername
mail.corp.redhat.com
CONNECTED(00000003)
depth=3 C = US, ST = North Carolina, L = Raleigh, O = "Red Hat, Inc.", OU = Red
Hat IT, CN = Red Hat IT Root CA, emailAddress = infosec(a)redhat.com
verify return:1
depth=2 O = Red Hat, OU = prod, CN = Intermediate Certificate Authority
verify return:1
depth=1 O = Red Hat, OU = prod, CN = Certificate Authority
verify return:1
depth=0 C = US, ST = North Carolina, L = Raleigh, O = Red Hat, OU = Information
Technology, emailAddress = servicedesk(a)redhat.com, CN = mail.corp.redhat.com
verify return:1
---
... <certificates chain> ...
---
* OK IMAP4 ready
As you can see above, the DH key provided by the server is too small so the SSL
verification fails. Setting the crypto policies to LEGACY solves the issue for
me and I am again able to recreate my Red Hat account in Thunderbird.
Hope this helps. I'm going to report this problem to service desk.
For the record: Not sure if this was fixed on server side or some polices have
changed, however I have not needed to apply the workaround, my email works out
of the box after the upgrade.
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
11:38 p.m.
On Sun, Oct 18, 2020 at 9:32 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
For the record: Not sure if this was fixed on server side or some
polices have
changed, however I have not needed to apply the workaround, my email works out
of the box after the upgrade.
You could probably use openssl connect to determine if the
certificate has been updated (seems likely), but I will offer
that this is why I tend to run with a policy of "NEXT" (almost)
all the time so that I can see what issues are going to hit
me and those I support (allowing an easy change to DEFAULT
until I can get the offending server(s)/service(s) adjusted).
And while I certainly understand why sometimes a policy of
NEXT is going to have to be reverted to DEFAULT to get the
$dayjob$ accomplished, it is the only way to stay ahead of
the changes.
1279
days inactive
1297
days old
15 comments
9 participants
participants (9)
-
Gary Buhrmaster -
Harish Pillay -
Lumír Balhar -
Milan Crha -
Miro Hrončok -
Pavel Raiskup -
Robert Relyea -
Simo Sorce -
Tom Hughes