Re: crypto-policies not very useful, FUTURE too strict?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sat, 2016-12-17 at 16:19 +0100, Tomasz Torcz wrote:
> Hi,
> 
>   Since few release we have nifty, consolidated way to select system-
> wide crypto
> policy. It's great, but granularity of selection is little lacking. 
> We have
> basically two sensible choices:
> - DEFAULT, which is, well, default

That is one of the main goals of crypto policies. To set a sensible
default across the system applications, irrespective of which back-end
library it uses. It should not be underestimated, as even now we are
not there yet, especially with the applications depending on the less
known tls libraries, or applications using libssh*.

> - FUTURE, which is said to be more secure; if the admin wants to
> change the policy,
>   (s)he will have to switch to FUTURE
>  So let's imagine Joe Sysadmins who in the face of LogJam and other
> vulnerabilites,
> wants to tighten security a bit. He switches to FUTURE and now GitHub
> doesn't work:

As a general goal, the intention of the FUTURE policy is not to be
compatible with the rest of the internet. That's the goal of the
DEFAULT policy. The FUTURE is intended to be compatible with servers
using parameters which are considered secure.

> $ update-crypto-policies --set FUTURE
> Setting system policy to FUTURE
> 
> $ wget https://github.com
> Resolving github.com (github.com)... 192.30.253.112, 
> 192.30.253.113  
>                                                      github.com
> (github.com)|192.30.253.112|:443... connected
> ERROR: The certificate of 'github.com' is not trusted.
> ERROR: The certificate of 'github.com' was signed using an insecure
> algorithm.

The example you have above is a glitch on the combination of the shared
system store use and crypto policies at gnutls. Please file a bug on
it. That host should have been within the crypto policies FUTURE
requirements.

>  Should we introduce another level, like FUTURE-BUT-WORKING?  With
> secure settings,

No. The purpose of the policies is to provide levels of assurance. A
connection is within that set or not. FUTURE-BUT-WORKING doesn't mean
anything; the DEFAULT policy serves that purpose.

regards,
Nikos
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux