[Secure-testing-team] Bug#765512: general: distrust old crypto algos and protocols perdefault

[Christoph Anton Mitterer]

Package: general
Severity: important
Tags: security


Hi.

Not sure if there is already some concentrated effort, but I think
there should be one, i.e.:


---
To disable crypto algorithms and protocols per default, which are
known to be no longer secure, across Debian.

And ideally, to default to securer versions where possible, e.g.
not using SHA1, or SHA256, if it makes no difference to use SHA512
or maybe in some time Keccak.
---


I see that some people may actually be forced to still use such old
algorithms for whatever reason, but at least per default programs
should no longer accept them and manual admin/user intervention
should be required to re-enable them.

Of course there are some clear exceptions as well, i.e. for a program
like jacksum (in the package of the same name) it makes not sense
to forbid md5 from being calculated.

Further, some programs use some crypto algorithms (especially hash
algos) in a not-so-much security related way.
But care should be taken, since often it's not obvious, whether
something is actually security relevant or not.
For git it's e.g. quite clear that it's use of SHA1 *is* security
relevant.
For mldonkey one might think "well they use it just as an ID".

For some packages there may be simply no alternative, at least
none that Debian (or anything else but upstream) could provide.
An example again would be git,... even if it would be decided one
day, that SHA1 is no longer enough for the way being used in git,
we of course cannot change this alone.
Another example, anything OpenPGP related is inherently bound to
SHA1 (at least in parts), and without a new standard, nothing can
be done about.


In many cases, the respective upstreams already have discussions
about phasing out old algorithms, like in gnupg there is right no
a discussion abot old v3 keys.
But often these upstreams react very slowly and/or only when they
really have no further choice.
Take Mozilla now with the Poodle attack... that SSLv3 is close to
be broken could be seen for years now,... but they left users
vulnerable for no really good reasons.
IIRC, per default they still have rc4 enabled, which is broken
and the argument "that some servers support nothing else" may be
true but it's still a bad one. What people want from https is
"secure" communications (as far as this is possible within the
current X.509/SSL/TLS model) and better no connection at all
than one that anybody can read.



I'm probly not the biggest crypto expert out there, but I guess
most people will agree that following algorithms should be
avoided:
- MD5 (or anything before)
- RC4
- DSA1 with 1024 bit only
- SSLv3 (of course v2 as well)
- depending on where it's used: CBC
- MtE and EaM MACs should be avoided

and ideally:
- SHA1 should be avoided as well, it's not yet broken, sure, but
  cracks can be seen
- probably RIPEMD160 should be avoided as well,... I'm not sure
  about it's latest status in cryptoanalysis, but being one of
  the niche algortihms is another danger
- where possible, new algorithms (e.g. AE ciphers) should be
  used per default, GCM and recently ED25519 ChaCha and Poly1305
  look promising
- I personally would probably try to avoid the NIST curves in ECC
- where possible prefer (or only allow) algos with PFS



Affected packages/programs (of course this is only a small excerpt):
- major browsers (FF, Chromium, konqueror[0])
  - disable SLLv3, anything with MD5 (this includes certificates)
    and RC4
    IMHO users are better of with failed connections than using any
    of them
  - set safer preferred algorithm lists
  - do this before Mozilla/Google/etc. decide so only because they
    already now about an upcoming hole which completely breaks an
    algo which is already known to have issues
- smaller browsers (links, lynx, etc.)
  basically the same
- curl,... not sure what it actually does, but options only allow
  to force a given SSL/TLS versions, not to disallow some
- wget seems to even use SSLv2 per default? (see manpage
  --secure-protocol option)
- anything related to secure APT (apt, aptitude, etc.) should no
  longer trust MD5, and ideally SHA1 should be phased out as well
  actually I'd probably vote for a combination of
  SHA2-512 and SHA3-512 in which *both* are validated and if any
  of them fails it's considered to be failed.
- http servers should default to not offer SSLv3 at least, and
  ideally at least suggest people to restrict even more
- SSH
- anything IPsec
- the countles of Perl, Python, Ruby, etc. packages which can
  to https or TLS/SSL
- ...



As one can see, this is probably nothing on person or maintainer
can do alone...
Yet I feel far to often these years that I wake up from time to
time, reading in the news that one was using algos with known
issue till now for no good reasons.



Cheers,
Chris.


[0] Last time I checked Epiphany was still vulnerable to insecure
redirections and thus SSL/TLS is completely disfunctional there.