http://www.linuxjournal.com/content/cipher-security-how-harden-tls-and-ssh
Encryption and secure communications are critical to our life on the Internet. Without the ability to authenticate and preserve secrecy, we cannot engage in commerce, nor can we trust the words of our friends and colleagues.
It comes as some surprise then that insufficient attention has been paid in recent years to strong encryption, and many of our "secure" protocols have been easily broken. The recent Heartbleed, POODLE, CRIME and BEAST exploits put at risk our trust in our networks and in one another.
Gathered here are best-practice approaches to close known exploits and strengthen communication security. These recommendations are by no means the final word on the subject—the goal here is to draw focus upon continuing best practice.
Please note that many governments and jurisdictions have declared encryption illegal, and even where allowed, law enforcement has become increasingly desperate with growing opaque content (see the Resources section for articles on these topics). Ensure that both these techniques and the content that they protect are not overtly illegal.
This article focuses on Oracle Linux versions 5, 6 and 7 and close brethren (Red Hat, CentOS and Scientific Linux). From here forward, I refer to these platforms simply as V5, V6 and V7. Oracle's V7 runs only on the x86_64 platform, so that's this article's primary focus.
These products rightly can be considered defective, in spite of constant vendor patches. The library designers would likely argue that their place is to implement mechanism, not policy, but the resulting products are nonetheless critically flawed. Here is how to fix them.
It should come as no surprise that SSL must not be used in any context for secure communications. The last version, SSLv3, was rendered completely insecure by the recent POODLE exploit. No version of SSL is safe for secure communications of any kind—the design of the protocol is fatally flawed, and no implementation of it can be secure.
TLS version 1.0 is also no longer safe. The immediate preference for secure communication is the modern TLS version 1.2 protocol, which, unfortunately, is not (yet) widely used. Despite the lack of popularity, prefer 1.2 if you value security.
Yet, even with TLS version 1.2, there still are a number of important weaknesses that must be addressed to meet current best practice as specified in RFC 7525:
For TLS cipher hardening under OpenSSL, I turn to Hynek Schlawack's Web site on the subject. He lists the following options for the SSL configuration of the Apache Web server:
On an older V5 system (which does not implement TLS 1.1 or 1.2 in OpenSSL), the list of acceptable ciphers is relatively short:
On V7, the list of allowed ciphers is considerably longer:
If you have connectivity problems with Web clients, try disabling the Cipher Order directive first. Custom HTTP clients may not fully implement the TLS negotiation, which might be solved by allowing the client to pick the cipher.
The cipher selector above also prevents any exploit of the "Logjam" (weak Diffie-Hellman primes) security flaw that recently has surfaced. If your version of Apache supports an alternate dh-prime configuration, it is recommended that you follow this procedure:
When you have applied these configuration changes to your Apache Web server, use the SSLlabs.com scan tool to rate your server (see Resources). If you are on an older V5 platform that uses the OpenSSL 0.9.8e release, the grade assigned to your server should be a "B"—your final security grade will be higher if you are on a later release.
It is also important to restart your TLS Web server for key regeneration every day, as is mentioned in the Apache changelog:
Note that Hynek Schlawack's site provides configuration instructions for nginx and HAProxy in addition to Apache. Several other applications allow a custom cipher specification—two that I mention here are stunnel and sendmail.
The stunnel "TLS shim" allows clear-text socket applications to be wrapped in TLS encryption transparently. In your stunnel configuration, specify the
The sendmail transport agent has received recent patches to specify ciphers fully. You can add the following options to your sendmail.cf to force best practice ciphers:
For a public mailserver, it is important to be more permissive with the allowed ciphers to prevent SMTP sessions from going clear text. Behind a corporate firewall, however, it is likely better to force strong TLS ciphers more rigorously.
It is also important to apply vendor patches promptly for TLS. It recently was discovered that later TLS versions were using SSLv3 padding functions directly in violation of the standards, rendering the latest versions vulnerable (this was more a concern for NSS than OpenSSL). Prompt patching is a requirement for a secure TLS configuration.
I would like to thank Hynek Schlawack for his contribution to and thoughtful commentary on TLS security.
The first concern for an SSH administrator is to disable protocol 1 as it is thoroughly broken. Despite a stream of vendor updates, older Linux releases maintain this flawed configuration, requiring the system manager to remove it by hand. Do so by ensuring "Protocol 2" appears in your sshd_config, and all reference to "Protocol 2,1" is deleted. Encouragement also is offered to remove it from client SSH applications as well, in case a server is inaccessible or otherwise overlooked.
For further hardening of Protocol 2 ciphers, I turn to the Stribika SSH Guide. These specifications are for the very latest versions of SSH and directly apply only to Oracle Linux 7.1.
For older versions of SSH, I turn to the Stribika Legacy SSH Guide, which contains relevant configuration details for Oracle Linux 5, 6 and 7.
There are only two recommended sshd_config changes for Oracle Linux 5:
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:
Oracle Linux 7 lacks a few ciphers from the latest releases of SSH and differs only slightly from the recommended settings:
Stribika levels specific criticism:
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:
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
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.
"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
Encryption and secure communications are critical to our life on the Internet. Without the ability to authenticate and preserve secrecy, we cannot engage in commerce, nor can we trust the words of our friends and colleagues.
It comes as some surprise then that insufficient attention has been paid in recent years to strong encryption, and many of our "secure" protocols have been easily broken. The recent Heartbleed, POODLE, CRIME and BEAST exploits put at risk our trust in our networks and in one another.
Gathered here are best-practice approaches to close known exploits and strengthen communication security. These recommendations are by no means the final word on the subject—the goal here is to draw focus upon continuing best practice.
Please note that many governments and jurisdictions have declared encryption illegal, and even where allowed, law enforcement has become increasingly desperate with growing opaque content (see the Resources section for articles on these topics). Ensure that both these techniques and the content that they protect are not overtly illegal.
This article focuses on Oracle Linux versions 5, 6 and 7 and close brethren (Red Hat, CentOS and Scientific Linux). From here forward, I refer to these platforms simply as V5, V6 and V7. Oracle's V7 runs only on the x86_64 platform, so that's this article's primary focus.
These products rightly can be considered defective, in spite of constant vendor patches. The library designers would likely argue that their place is to implement mechanism, not policy, but the resulting products are nonetheless critically flawed. Here is how to fix them.
Strong Ciphers in TLS
The Transport Layer Security (TLS) protocols emerged from the older Secure Sockets Layer (SSL) that originated in the Netscape browser and server software.It should come as no surprise that SSL must not be used in any context for secure communications. The last version, SSLv3, was rendered completely insecure by the recent POODLE exploit. No version of SSL is safe for secure communications of any kind—the design of the protocol is fatally flawed, and no implementation of it can be secure.
TLS version 1.0 is also no longer safe. The immediate preference for secure communication is the modern TLS version 1.2 protocol, which, unfortunately, is not (yet) widely used. Despite the lack of popularity, prefer 1.2 if you value security.
Yet, even with TLS version 1.2, there still are a number of important weaknesses that must be addressed to meet current best practice as specified in RFC 7525:
- "Implementations MUST NOT negotiate RC4 cipher suites." The RC4 cipher is enabled by default in many versions of TLS, and it must be disabled explicitly. This specific issue was previously addressed in RFC 7465.
- "Implementations MUST NOT negotiate cipher suites offering less than 112 bits of security, including so-called 'export-level' encryption (which provide 40 or 56 bits of security)." In the days of SSL, the US government forced weak ciphers to be used in encryption products sold or given to foreign nationals. These weak "export" ciphers were created to be easily broken (with sufficient resources). They should have been removed long ago, and they recently have been used in new exploits against TLS.
- "Implementations MUST NOT negotiate SSL version 3." This formalizes our distaste for the entire SSL suite.
- "Implementations SHOULD NOT negotiate TLS version 1.0 (or) 1.1." Prefer TLS 1.2 whenever possible.
For TLS cipher hardening under OpenSSL, I turn to Hynek Schlawack's Web site on the subject. He lists the following options for the SSL configuration of the Apache Web server:
SSLProtocol ALL -SSLv2 -SSLv3
SSLHonorCipherOrder On
SSLCipherSuite
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
On an older V5 system (which does not implement TLS 1.1 or 1.2 in OpenSSL), the list of acceptable ciphers is relatively short:
$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 5.11
Red Hat Enterprise Linux Server release 5.11 (Tikanga)
$ openssl ciphers -v
'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1
AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1
On V7, the list of allowed ciphers is considerably longer:
$ cat /etc/oracle-release /etc/redhat-release
Oracle Linux Server release 7.1
Red Hat Enterprise Linux Server release 7.1 (Maipo)
$ openssl ciphers -v
'ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+
↪AES128:DH+AES:ECDH+3DES:DH+3DES:RSA+AESGCM:
↪RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS'
ECDHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AESGCM(256) Mac=AEAD
ECDH-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AESGCM(256) Mac=AEAD
ECDH-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AESGCM(256) Mac=AEAD
ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AESGCM(128) Mac=AEAD
ECDH-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AESGCM(128) Mac=AEAD
ECDH-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AESGCM(128) Mac=AEAD
DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
ECDHE-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AES(256) Mac=SHA384
ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA
↪Enc=AES(256) Mac=SHA384
ECDHE-RSA-AES256-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=AES(256) Mac=SHA1
ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=AES(256) Mac=SHA1
ECDH-RSA-AES256-SHA384 TLSv1.2 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(256) Mac=SHA384
ECDH-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(256) Mac=SHA384
ECDH-RSA-AES256-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(256) Mac=SHA1
ECDH-ECDSA-AES256-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH
↪Enc=AES(256) Mac=SHA1
DHE-RSA-AES256-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AES(256) Mac=SHA256
DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA
↪Enc=AES(256) Mac=SHA1
ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA
↪Enc=AES(128) Mac=SHA256
ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH
↪Au=ECDSA Enc=AES(128) Mac=SHA256
ECDHE-RSA-AES128-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=AES(128) Mac=SHA1
ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=AES(128) Mac=SHA1
ECDH-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH/RSA
↪Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(128) Mac=SHA256
ECDH-RSA-AES128-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=AES(128) Mac=SHA1
ECDH-ECDSA-AES128-SHA SSLv3 Kx=ECDH/ECDSA
↪Au=ECDH Enc=AES(128) Mac=SHA1
DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA
↪Enc=AES(128) Mac=SHA256
DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA
↪Enc=AES(128) Mac=SHA1
ECDHE-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=RSA
↪Enc=3DES(168) Mac=SHA1
ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA
↪Enc=3DES(168) Mac=SHA1
ECDH-RSA-DES-CBC3-SHA SSLv3 Kx=ECDH/RSA Au=ECDH
↪Enc=3DES(168) Mac=SHA1
ECDH-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH/ECDSA
↪Au=ECDH Enc=3DES(168) Mac=SHA1
EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA
↪Enc=3DES(168) Mac=SHA1
AES256-GCM-SHA384 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AESGCM(256) Mac=AEAD
AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AESGCM(128) Mac=AEAD
AES256-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AES(256) Mac=SHA256
AES256-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=AES(256) Mac=SHA1
AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA
↪Enc=AES(128) Mac=SHA256
AES128-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=AES(128) Mac=SHA1
DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA
↪Enc=3DES(168) Mac=SHA1
SSLCompression
Off directive. Compression should not be used with TLS because of the
CRIME attack.
If you have connectivity problems with Web clients, try disabling the Cipher Order directive first. Custom HTTP clients may not fully implement the TLS negotiation, which might be solved by allowing the client to pick the cipher.
The cipher selector above also prevents any exploit of the "Logjam" (weak Diffie-Hellman primes) security flaw that recently has surfaced. If your version of Apache supports an alternate dh-prime configuration, it is recommended that you follow this procedure:
openssl dhparam -out /home/httpd/conf/dhparams.pem 2048
SSLOpenSSLConfCmd DHParameters "/home/httpd/conf/dhparams.pem"
When you have applied these configuration changes to your Apache Web server, use the SSLlabs.com scan tool to rate your server (see Resources). If you are on an older V5 platform that uses the OpenSSL 0.9.8e release, the grade assigned to your server should be a "B"—your final security grade will be higher if you are on a later release.
It is also important to restart your TLS Web server for key regeneration every day, as is mentioned in the Apache changelog:
Session ticket creation uses a random key created during web server startup and recreated during restarts. No other key recreation mechanism is available currently. Therefore using session tickets without restarting the web server with an appropriate frequency (e.g. daily) compromises perfect forward secrecy.This information is not well known, and has been met with some surprise and dismay in the security community: "You see, it turns out that generating fresh RSA keys is a bit costly. So modern web servers don't do it for every single connection. In fact, Apache mod_ssl by default will generate a single export-grade RSA key when the server starts up, and will simply re-use that key for the lifetime of that server" (from http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html).
Note that Hynek Schlawack's site provides configuration instructions for nginx and HAProxy in addition to Apache. Several other applications allow a custom cipher specification—two that I mention here are stunnel and sendmail.
The stunnel "TLS shim" allows clear-text socket applications to be wrapped in TLS encryption transparently. In your stunnel configuration, specify the
cipher= directive with the above string to force stunnel to
best practice. Also, on the V7 platform, supply the
fips=no directive;
otherwise, you will be locked to the TLS version 1 protocol with the message
'sslVersion = TLSv1' is required in FIPS mode.
The sendmail transport agent has received recent patches to specify ciphers fully. You can add the following options to your sendmail.cf to force best practice ciphers:
O CipherList=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+
↪AES256:ECDH+AES128:DH+AES:ECDH+3DES:DH+3DES:
↪RSA+AESGCM:RSA+AES:RSA+3DES:!aNULL:!MD5:!DSS
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
↪+SSL_OP_CIPHER_SERVER_PREFERENCE
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
↪+SSL_OP_CIPHER_SERVER_PREFERENCE
May 12 10:17:58 myhost sendmail[1234]: STARTTLS=client,
↪relay=mymail.linuxjournal.com., version=TLSv1/SSLv3,
↪verify=FAIL, cipher=AES128-SHA, bits=128/128
May 12 10:38:28 myhost sendmail[5678]: STARTTLS=client,
↪relay=mymail.linuxjournal.com., version=TLSv1/SSLv3,
↪verify=FAIL, cipher=AES128-SHA, bits=128/128
verify=FAIL indicates that your keys are not signed by a certificate
authority (which is not as important for an SMTP server). The encryption is
listed as AES128-SHA.
For a public mailserver, it is important to be more permissive with the allowed ciphers to prevent SMTP sessions from going clear text. Behind a corporate firewall, however, it is likely better to force strong TLS ciphers more rigorously.
It is also important to apply vendor patches promptly for TLS. It recently was discovered that later TLS versions were using SSLv3 padding functions directly in violation of the standards, rendering the latest versions vulnerable (this was more a concern for NSS than OpenSSL). Prompt patching is a requirement for a secure TLS configuration.
I would like to thank Hynek Schlawack for his contribution to and thoughtful commentary on TLS security.
Strong Ciphers in SSH
It is now well-known that (some) SSH sessions can be decrypted (potentially in real time) by an adversary with sufficient resources. SSH best practice has changed in the years since the protocols were developed, and what was reasonably secure in the past is now entirely unsafe.The first concern for an SSH administrator is to disable protocol 1 as it is thoroughly broken. Despite a stream of vendor updates, older Linux releases maintain this flawed configuration, requiring the system manager to remove it by hand. Do so by ensuring "Protocol 2" appears in your sshd_config, and all reference to "Protocol 2,1" is deleted. Encouragement also is offered to remove it from client SSH applications as well, in case a server is inaccessible or otherwise overlooked.
For further hardening of Protocol 2 ciphers, I turn to the Stribika SSH Guide. These specifications are for the very latest versions of SSH and directly apply only to Oracle Linux 7.1.
For older versions of SSH, I turn to the Stribika Legacy SSH Guide, which contains relevant configuration details for Oracle Linux 5, 6 and 7.
There are only two recommended sshd_config changes for Oracle Linux 5:
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-ripemd160
MACs hmac-ripemd160 setting and will not connect
to a V5 server when this configuration is implemented. As PuTTY quietly
has become a corporate standard, this likely is an insurmountable
incompatibility, so most enterprise deployments will implement only the
Cipher directive.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
error: OpenSSL >= 0.9.8f required (have "0090802f
↪(OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008)")
--without-openssl Disable use of OpenSSL; use only
↪limited internal crypto **EXPERIMENTAL**
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
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
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
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.
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
No comments:
Post a Comment