2016-12-17 16:19 GMT+01:00 Tomasz Torcz <tomek(a)pipebreaker.pl>:
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?
Maybe we need to rename FUTURE by QUITE_SOON instead, because the
error you have pointed is about sha-1 been deprecated:
According to this blog, chrome will remove support for sha-1
certificates on 1 January 2017 (it's an old post, so I don't know if
it's still current).
https://security.googleblog.com/2015/12/an-update-on-sha-1-certificates-i...
the getfedora certificates is signed with sha-256, but the root CA has
signed the intermediate certificate with sha-1. That the issue.
Thx for rising the point, I will check which certificates are still
sha-1 in my own cert usage.
--
-
Nicolas (kwizart)