Please convert this application to use the system's crypto policy for SSL and TLS: https://fedoraproject.org/wiki/Packaging:CryptoPolicies If this program is compiled against gnutls, change the default priority string to be "@SYSTEM" or to use gnutls_set_default_priority(). If this program is compiled against openssl, and there is no default cipher list specified, you don't need to modify it. Otherwise replace the default cipher list with "PROFILE=SYSTEM". In both cases please verify that the application uses the system's crypto policies. If the package is already using the system-wide crypto policies, or it does not use SSL or TLS, no action is required, the bug can simply be closed.
While converting filezilla to use the system cipher policy, the developer has raised a concern that the cipher are not sorted by security margin in the DEFAULT policy (Whereas they are in filezilla). Is there any reason for that ? filezilla currently uses a dedicated cipher list. Upstream currently suggests to use @SYSTEM but to specify weak ciphers to be denied explicitly from that list. To me that defeat the point to have a central location to maintain allowed ciphers list over per application cipher list. I plan to submit a configure option to allow to select the default policy in some case (fedora >= 22) where a crypto-policy currently exists and leave with per-application default if not specifically requested. Does that sound good ?
(In reply to Nicolas Chauvet (kwizart) from comment #1) > While converting filezilla to use the system cipher policy, the developer > has raised a concern that the cipher are not sorted by security margin in > the DEFAULT policy (Whereas they are in filezilla). > Is there any reason for that ? The ciphers that are slow in 256 bits mode are prioritized after their 128-bit equivalent (i.e., AES-256 is after AES-128). There is no point to spend additional resources to strive for 256-bits of a cipher when the overall security level of TLS (with all the involved ciphers) is around 80-90 bits. (also there are more attacks known for AES-256 than for AES-128 - although that's not currently the reason for that order) > filezilla currently uses a dedicated cipher list. > Upstream currently suggests to use @SYSTEM but to specify weak ciphers to be > denied explicitly from that list. To me that defeat the point to have a > central location to maintain allowed ciphers list over per application > cipher list. I agree. We have removed all the weak ciphers from the policy and continue to do so as new attacks get found. Having an additional "static" removal of some ciphers in the code will not buy anything new. > I plan to submit a configure option to allow to select the default policy in > some case (fedora >= 22) where a crypto-policy currently exists and leave > with per-application default if not specifically requested. > Does that sound good ? Yes, it sounds reasonable. Thanks.
(In reply to Nikos Mavrogiannopoulos from comment #2) > > filezilla currently uses a dedicated cipher list. > > Upstream currently suggests to use @SYSTEM but to specify weak ciphers to be > > denied explicitly from that list. To me that defeat the point to have a > > central location to maintain allowed ciphers list over per application > > cipher list. > I agree. We have removed all the weak ciphers from the policy and continue > to do so as new attacks get found. Having an additional "static" removal of > some ciphers in the code will not buy anything new. In fact doing so will break the case where some admin relaxes the policy (e.g., to allow connections to a server which only uses RC4).
Fixed in f23+ filezilla and upstreamed in next filezilla (post 3.14) To sum-up the conversation with upstream about that, the downside to potentially allow bad ciphers in case of using a weak "LEGACY" policies was circumvented to advertise that fact to filezilla users when encountering a server using weak ciphers.