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
- 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:

$ 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             
                                                                                
                   Connecting to 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.

  Not only github:

Connecting to getfedora.org (getfedora.org)|2001:4178:2:1269::fed2|:443... 
connected.
ERROR: The certificate of 'getfedora.org' is not trusted.
ERROR: The certificate of 'getfedora.org' was signed using an insecure 
algorithm.

  Switching back to DEFAULT make those working again.  But it buys us nothing,
we have one setting which is default and the other is unusable. Why have this
setting at all, then?

  Should we introduce another level, like FUTURE-BUT-WORKING?  With secure 
settings,
post-quantum cryptographic algorithms but working with today websites?
 
-- 
Tomasz Torcz                                                       72->|   80->|
xmpp: zdzich...@chrome.pl                                          72->|   80->|
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to