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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141015180933.18771.64526.report...@heisenberg.scientia.net