crypto-policies not very useful, FUTURE too strict?

[Tomasz Torcz]

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: zdzichubg(a)chrome.pl                                          72->|   80->|

[Nicolas Chauvet]

2016-12-17 16:19 GMT+01:00 Tomasz Torcz <tomek(a)pipebreaker.pl&gt;:
>  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)

[Tom Hughes]

On 17/12/16 17:05, Nicolas Chauvet wrote:

>  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. 
As far as I can see both the intermediate and leaf certificates have 
SHA-256 signatures. It is only the root certificate that has an SHA-1 
signature and that will still be allowed by chrome - to quote that blog 
post:

"At this point, sites that have a SHA-1-based signature as part of the 
certificate chain (not including the self-signature on the root 
certificate) will trigger a fatal network error.

So the self signature on the root certificate can still be SHA-1 because 
that certificate is in the root set and hence is valid simply by 
existing and it's signature algorithm doesn't really matter.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Scott Schmit]

On Sat, Dec 17, 2016 at 06:05:49PM +0100, Nicolas Chauvet wrote:
>  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. 
Storing the root keys as certificates makes sense from an implementation
standpoint -- it conveniently associates the keys with the subject DNs
and other properties like key usage, but the self signature (or
otherwise) is already nonsense -- either I already trust the key (thus I
don't need to validate it) or I don't (in which case the signature can't
be trusted either).

Thus, if the signature on the certs in the trust store matter, that's a
bug.  The presence of the keys in the trust store should be all that's
required for them to be trusted -- the details of the signature
algorithm can't be irrelevant.

[Scott Schmit]

On Sat, Dec 17, 2016 at 01:07:52PM -0500, Scott Schmit wrote:
>  On Sat, Dec 17, 2016 at 06:05:49PM +0100, Nicolas Chauvet wrote:
>  > 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.
>  
>  Storing the root keys as certificates makes sense from an implementation
>  standpoint -- it conveniently associates the keys with the subject DNs
>  and other properties like key usage, but the self signature (or
>  otherwise) is already nonsense -- either I already trust the key (thus I
>  don't need to validate it) or I don't (in which case the signature can't
>  be trusted either).
>  
>  Thus, if the signature on the certs in the trust store matter, that's a
>  bug.  The presence of the keys in the trust store should be all that's
>  required for them to be trusted -- the details of the signature
>  algorithm can't be irrelevant. 
"can't be relevant", I meant.

[Nikos Mavrogiannopoulos]

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

[Tomasz Torcz]

On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos wrote:
>  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*.
>  
>  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. 

  So, what exactly is the use case behind this preference?

 
>  > $ 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. 
  Done:
https://bugzilla.redhat.com/show_bug.cgi?id=1405959

 
-- 
Tomasz Torcz               "Never underestimate the bandwidth of a station
xmpp: zdzichubg(a)chrome.pl    wagon filled with backup tapes." -- Jim Gray

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-19 at 11:07 +0100, Tomasz Torcz wrote:
>  On Mon, Dec 19, 2016 at 09:35:09AM +0100, Nikos Mavrogiannopoulos
>  wrote:
>  > 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*.
>  > 
>  > 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.
>    So, what exactly is the use case behind this preference? 
Administrators which need to set their system on a specific security
level. Future is defined to be on the 112-bit level.

regards,
Nikos

[Nikos Mavrogiannopoulos]

On Mon, 2016-12-19 at 09:35 +0100, Nikos Mavrogiannopoulos wrote:

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

Actually it relates to a particular behavior of wget [0]. In fact it
was disabling the system-wide policy as soon as it was enabling it.

[0]. https://bugzilla.redhat.com/show_bug.cgi?id=1405956

regards,
Nikos