I've been reading through bettercrypto.org's Applied Crypto Hardening and really enjoying it. They take a refreshingly practical approach to cryptography books. I've done a couple of cryptography courses, and read Understanding Cryptography cover to cover, which had great video lectures and problem sets to solve. Actually I started watching the videos first and they were so good I bought the book.
All the course and books I've come accross go out of their way to be vendor neutral, which I think is a great thing. Not using specific software or versions in the books an courses means that they age well. However it also means they lack practical content and at the end of the course I feel I have a solid understanding of how the cryptography works, but haven't learnt how to configure OpenSSL for Apache, nginx and postfix or setup SSH with keys rather than passwords.
Applied Crypto Hardening on the other hand doesn't cover the theory but goes straight to the practical. It squarely targets sysadmins. It provides simple configs that can easily be copied and pasted. Eben Upton has a great anecdote of when he got his first computer and bought a mouse but didn't know how to get it working. So his dad phoned tech support for him and they said "If your son can't write his own mouse driver, then he does not deserve a mouse." Now days it's almost inconceivable that someone would write a mouse driver, or even know what a driver is before they start using a mouse. The point is that people don't need to know all the internals of how something works to use it. It's not a perfect example I know, but I don't fully understand how all the internals of my microwave oven work, but I can still cook with it. Most sysadmins don't need to fully understand how all the internals of cryptography work but can still enable TLS to secure their users.
When I got to Applied Crypto Hardening's settings for postfix I saw they supported some weak ciphers but it was prefaced by a bit that says:
...However, we leave this at its default value for server to server connections, as many mail servers only support outdated protocols and ciphers. We consider bad encryption still better than plain text transmission.
While I agree with their decision it's an interesting view and worthy of debate.
The examples of where bad crypto is better than no crypto I would think should be fairly clear. Take for example if email was transmitted using a single round of DES, it's clearly broken. I haven't kept up to date with factoring speeds and hardware needed to crack DES. The last time I looked at cracking DES was around 2012 when Moxie Marlinspike did some truly amazing research into breaking MS-CHAPv2 and part of that involved breaking a single round of DES which took a worst case of ~23 hours so I think it's fair to assume that in 2015 someone with a few hundred bucks and 24 hours on Amazon Web Services could brake it. If I was given a choice where someone could either read all my emails whenever they like, or read all my emails but it would cost them $100 per email and take 24 hours before they could read it I'd choose the second option every time.
The counter example that is that weak crypto has the potential to lull people into a false sense of security. Take the MS-CHAPv2 example from before, many people were using and are still using PPTP VPNs with MS-CHAPv2 to connect to their work because it's the default in many Microsoft Products. It's easy to use and integrates nicely with Active Directory. They believe they have a secure connection to their work but they are putting themselves at risk every time they use it. If they were to use it at a coffee shop or on McDonald's free WiFi for example someone malicious could not only break their encryption but recover their username and password1 and connect in with their credentials to start rifling through confidential documents.
I'm aware that the text says "better than plain text transmission." but another option that I think is worth discussing is failing loudly. A good example of this is after the POODLE attack came out many websites disabled SSL 3.0 and if you try to visit those sites using something like Internet Explorer 6 you just get a message that the site could not be loaded. Rather that just silently downgrade to weaker encryption, because bad encryption still better than plain text, some sites simply don't work at all with weak crypto. If people want to use that service they need to use a modern browser. It's possible to set postfix to only accept TLS connections and no plain text email. Imagine if users got a bounce back saying that the email can't be delivered because their server doesn't support secure email. I'd like to think that that would get some questions asked and some systems upgraded2.
Over all I think they made the right choice, I think that we are unlikely to be able to change all mail server to modern encryption. In most cases it's better to downgrade to weak ciphers than to downgrade to none, and punishing the users of an outdated system by not accepting their mail at all is not really the right way to go about things. I'm a follower of the Robustness Principle
Be conservative in what you do, be liberal in what you accept from others
It should also be noted that the Applied Crypto Hardening settings for postfix do enforce high grade crypto for when you own both ends (i.e. internal mail servers, and clients connecting to the server)
-
The attack doesn't directly recover the password, it recovers an MD4 hash of the password, which is all that's needed to connect to a PPTP VPN or that could be used in an off line dictionary attack. ↩
-
Although the cynic in me who has seen that most users don't even read enough to see the difference between can't be delivered because it's too large and address doesn't exist is not so sure. ↩
