Cipher Security: How to harden TLS and SSH

Version 0.58 of PuTTY also does not implement the strong AES-CTR ciphers (these appear to have been introduced in the 0.60 release) and likewise will not connect to an SSH server where they are used exclusively. It is strongly recommended that you implement the Cipher directive, as it removes RC4 (arcfour), which is totally inappropriate for modern SSH. It is not unreasonable to expect corporate clients to run the latest versions of PuTTY, as new releases are trivially easy to install.

Oracle Linux 5 has a role of special importance as it is the underlying OS for the Linux version of the Oracle Exadata architecture (the alternate OS being Solaris). If you are an Exadata customer, confirm with Oracle that you will retain vendor support if you change cipher and protocol settings on a supported Exadata appliance.

V5's default SSH ciphers will be pruned especially hard:


$ man sshd_config | col -b | awk "/Ciphers/,/ClientAlive/"

Ciphers

Specifies the ciphers allowed for protocol version 2.  
Multiple ciphers must be comma-separated. The 
supported ciphers are 3des-cbc, aes128-cbc, aes192-cbc, 
aes256-cbc, aes128-ctr, aes192-ctr, aes256-ctr, arcfour128,
arcfour256, arcfour, blowfish-cbc, and cast128-cbc. The
default is

    aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
    aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
    aes256-cbc,arcfour

It is possible to install a newer version of OpenSSH on V5, but it is not easy. Attempting to compile the latest release results in the following error:


error: OpenSSL >= 0.9.8f required (have "0090802f 
 ↪(OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008)")

It is possible to compile OpenSSH without OpenSSL dependencies with the following:


--without-openssl Disable use of OpenSSL; use only 
 ↪limited internal crypto **EXPERIMENTAL**

Enterprise deployments are likely unwilling to use experimental code, so I won't go into further details. If you obtain binary RPMs for upgrade, ensure that you know how they were produced.

Oracle Linux 7 lacks a few ciphers from the latest releases of SSH and differs only slightly from the recommended settings:


HostKey /etc/ssh/ssh_host_rsa_key
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,
↪aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms diffie-hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-
↪etm@openssh.com,hmac-ripemd160-etm@openssh.com,
↪umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,
↪hmac-ripemd160,umac-128@openssh.com

Oracle Linux 7.1 can be configured exactly as recommended, including the new ed25519 hostkey:


HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
Ciphers chacha20-poly1305@openssh.com,aes256-
↪gcm@openssh.com,aes128-gcm@openssh.com,
↪aes256-ctr,aes192-ctr,aes128-ctr
KexAlgorithms curve25519-sha256@libssh.org,diffie-
↪hellman-group-exchange-sha256
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-
↪etm@openssh.com,hmac-ripemd160-etm@openssh.com,
↪umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-
↪256,hmac-ripemd160,umac-128@openssh.com

The Stribika Guide immediately dismisses the 3DES cipher, which is likely reasonable as it is slow and relatively weak, but also goes to some length to criticize the influence of NIST and the NSA. In the long view, this is not entirely fair, as the US government's influence over the field of cryptography has been largely productive. To quote cryptographer Bruce Schneier, "It took the academic community two decades to figure out that the NSA 'tweaks' actually improved the security of DES....DES did more to galvanize the field of cryptanalysis than anything else." Despite unfortunate recent events, modern secure communication has much to owe to the Data Encryption Standard and those who were involved in its introduction.

Stribika levels specific criticism:

...advising against the use of NIST elliptic curves because they are notoriously hard to implement correctly. So much so, that I wonder if it's intentional. Any simple implementation will seem to work but leak secrets through side channels. Disabling them doesn't seem to cause a problem; clients either have Curve25519 too, or they have good enough DH support. And ECDSA (or regular DSA for that matter) is just not a good algorithm, no matter what curve you use.

In any case, there is technical justification for leaving 3DES in TLS, but removing it from SSH—there is a greater financial cost when browsers and customers cannot reach you than when your administrators are inconvenienced by a software standards upgrade.

If you are using ssh-agent with a private key, you can strengthen the encryption of the password on the key using this method documented by Martin Kleppmann with PKCS#8. Here is the procedure summarized from the author:


cd ~/.ssh

mv ~/.ssh/id_rsa ~/.ssh/id_rsa.old

openssl pkcs8 -topk8 -v2 des3 -in ~/.ssh/id_rsa.old 
 ↪-out ~/.ssh/id_rsa

chmod 600 ~/.ssh/id_rsa

The author estimates that this procedure provides the equivalent benefit of adding two extra characters to the password. It is important to note, however, that the PuTTY agent is not able to read the new format produced here. If you use pagent with PuTTY (or expect to), convert your OpenSSH key to pagent first, then run this procedure, assuming that retention of your key in both formats is allowed. It is likely wise to retain a copy of the original private key on offline media. It is also important to note that this procedure does not add any extra protection from a keylogger.

User SSH keypairs are likely superior to passwords for many aspects of security. SSH servers cannot enforce password standards on remote keys (minimum password length, change frequency, reuse prevention and so on), and there are definite risks in forwarding the ssh-agent that would compromise server security. If you allow your users to authenticate with SSH keypairs that they generate, you should understand how they can be (ab)used.

Finally, be aware that keystroke delay duration can be used as a side channel exploit in SSH via the application of the Viterbi Algorithm. Interactive SSH sessions are more revealing of content than most expect and should be avoided for those with high security requirements. Send batches of ssh commands, or implement a bandwidth "fuzzer" in a secondary session on the same channel if an interactive session is required but security is critical. Of particular note:

  • The "superuser" command (that is, su -) creates a distinct traffic signature in the encrypted data stream that reveals the exact length of the target password, plus keystroke timing. It should not be used over an SSH session.

  • If a user logs in to a remote SSH host, then uses the remote to log in to yet another host in a three-host configuration, this creates an even more distinct traffic signature in the encrypted data stream that essentially advertises the exact length of any passwords used. Avoid this practice.

  • Depending upon the cipher used, a short password (less than seven characters) can be detected at login. Enforce a minimum password length larger than seven characters, especially for SSH sessions.

I would like to thank Stribika for his contribution to and thoughtful commentary on SSH security.

Unbreakable Encryption

While the best practices above are helpful, these protocols have been entirely inadequate in assuring private communication channels, and they have been broken many times.

If your needs for secure communication are so dire that any risk of interception is too great, you likely should consider encryption tools that do not appear to have been broken as of yet.

A careful parse of recent evidence indicates that the Gnu Privacy Guard implementation of Pretty Good Privacy (PGP) continues to present insurmountable difficulty to eavesdropping and unauthorized decryption.

This utility is installed in all recent versions of Oracle Linux by default. It should be your first thought for secure communications, and you should realize that all the techniques described above are compromises for the sake of expedience.

Resources

The Heartbleed Bug: http://heartbleed.com

"Meaner POODLE bug that bypasses TLS crypto bites 10 percent of websites" by Dan Goodin: http://arstechnica.com/security/2014/12/meaner-poodle-bug-that-bypasses-tls-crypto-bites-10-percent-of-websites

CRIME ("Compression Ratio Info-leak Made Easy"): https://en.wikipedia.org/wiki/CRIME

"Beat the BEAST with TLS 1.1/1.2 and More" by Omar Santos: http://blogs.cisco.com/security/beat-the-beast-with-tls

Cypto Law Survey: http://www.cryptolaw.org

"Homeland Security Begs Silicon Valley to Stop the Encyption" by Annalee Newitz: http://gizmodo.com/dhs-secretary-begs-silicon-valley-to-stop-the-encryptio-1699273657

NIST Decprecates TLS 1.0 for Government Use by Bill Shelton: http://forums.juniper.net/t5/Security-Now/NIST-Deprecates-TLS-1-0-for-Government-Use/ba-p/242052

RFC 7525—Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS): https://www.rfc-editor.org/rfc/rfc7525.txt

RFC 7465—Prohibiting RC4 Cipher Suites: http://tools.ietf.org/html/rfc7465

OpenSSL: http://www.openssl.org

NSS: http://nss-crypto.org

The GnuTLS Transport Layer Security Library: http://gnutls.org

GnuTLS considered harmful: http://www.openldap.org/lists/openldap-devel/200802/msg00072.html

Hardening Your Web Server's SSL Ciphers—Hynek Schlawack: https://hynek.me/articles/hardening-your-web-servers-ssl-ciphers

The Logjam Attack: https://weakdh.org

SSL Labs Scan Tool: https://www.ssllabs.com

Apache changelog: http://www.apache.org/dist/httpd/CHANGES_2.4

"Attack of the week: FREAK (or 'factoring the NSA for fun and profit')" by Matthew Green: http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html

"The POODLE bites again": https://www.imperialviolet.org/2014/12/08/poodleagain.html

Stribika SSH Guide: https://stribika.github.io/2015/01/04/secure-secure-shell.html

Stribika Legacy SSH Guide: https://github.com/stribika/stribika.github.io/wiki/Secure-Secure-Shell

"Saluting the data encryption legacy" by Bruce Schneier: http://www.cnet.com/news/saluting-the-data-encryption-legacy

"Improving the security of your SSH private key files" by Martin Kelppmann: http://martin.kleppmann.com/2013/05/24/improving-security-of-ssh-private-keys.html

"Timing Analysis of Keystrokes and Timing Attacks on SSH" by Dawn Xiaodong Song, David Wagner and Xuqing Tian: http://www.cs.berkeley.edu/~dawnsong/papers/ssh-timing.pdf

"The Encryption Tools the NSA Still Can't Crack Revealed in New Leaks" by Kelsey Campbell: http://gizmodo.com/the-encryption-tools-the-nsa-still-cant-crack-revealed-1675978237

"Prying Eyes: Inside the NSA's War on Internet Security" by SPIEGEL Staff: http://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html

The GNU Privacy Guard: https://gnupg.org

______________________

Charles Fisher has an electrical engineering degree from the University of Iowa and works as a systems and database administrator for a Fortune 500 mining and manufacturing corporation.