ianG <i...@iang.org> writes: >Not sure if it has been mentioned here. The Better Crypto group at >bettercrypto.org have written a (draft) paper for many of those likely >configurations for net tools. The PDF is here: > >https://bettercrypto.org/static/applied-crypto-hardening.pdf > >If you're a busy sysadm with dozens of tools to fix, this might be the guide >for you.
There are some pretty weird choices in there though, a number of which seem to have been dictated mostly by fashion-statement requirements rather than any security need. For example they recommend disabling (if I'm reading the OpenSSL config line-noise correctly) PSK and SRP, which are the only mutual- auth mechanisms provided in TLS, they enable Camellia but disable 3DES (why?), they optionally allow ECC but only with P384 (which requires the oddball SHA-384, why not the universal P256 with SHA-256?), for OpenSSH they only allow a bunch of fashion-statement ciphers (aes256-...@openssh.com and some others) which is pretty much guaranteed to lock out the zillion third-party SSH implementations that do 3DES-CBC and AES-CBC (the same can apply for SSL in older systems that don't support the newer fashion-statement ciphers while still supporting the perfectly secure 3DES), I'm not seeing much (if anything) about actually verifying the certs and/or checking that the information in them matches what you think you're connecting to, the IPsec predefined suites seem to be restricted only to Suite B (that's the crypto designed and promoted by the nation-state adversary that we're supposed to be defending against), and so on. As a general observation, it also promotes the thinking that all we need to do is choose magic algorithm A instead of magic algorithm B and everything is fixed. The crypto is pretty much the last thing you need to worry about, since the attackers will ignore it and go for all the other weak points instead. So while disabling obviously dangerous settings (many of which are disabled by default anyway) is a good thing, obsessing over which colour of algorithm you're using is at best a distraction from securing other aspects of a system, and at worst a problem when restricting yourself to oddball algorithms breaks the ability of clients to connect. Peter. _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
