Wet Socks and Insecure Socket Layers

Wet Socks and Insecure Socket Layers: Two of the Worst Things for You and Your Company

Wet socks. No one likes them. Network intrusion? Nobody gets excited about that, either. When it comes to securing your socket layer, there are a few areas that you should be considering.

Java Versions

The recommended version of Java is the latest release of Java 8. Java 7 reached its end of life in April of 2015 with regard to publicly available security fixes and upgrades and Oracle has since urged users to migrate to Java 8^[1]. Java 9 is no longer a supported version and reached its End of Life in March of 2018. Currently Java 8 and Java 10 (18.3) are the most recent supported releases. Given that many applications do not yet support Java 10 (18.3) because of how new it is as well as its small features and vulnerabilities list, Java 8 is a strong counterpart to use while Java 10 matures and infrastructure is upgraded to support it. Java 8 is also up to date with the most secure cipher suites and algorithms.

SSL/TLS Restrictions

Disable SSLv2 due to the number of analytical design flaws which cannot be worked around without breaking protocol and could lead to exposure of modification of confidential data. Google’s POODLE attack will leverage browser scripting capabilities and the broken padding implementations in SSLv3 in order to launch man in the middle attacks. There are workarounds to combat this; however, it still remains recommended that SSLv3 be disabled as Java 8 natively does not allow SSLv3. As essentially a revision to SSLv3, TLSv1 is not susceptible to the POODLE attack, but is susceptible to the BEAST attack, which also leverages browser scripting capabilities. Supporting this version of TLS is not recommended, as it would take significantly more overhead to maintain and keep secure than implementing TLSv1.1 or TLSv1.2.

Algorithm Restrictions

The RC4 scheduling algorithm is weak in that the early bytes of output can be correlated with the key. This algorithm led to the attacks against the WEP encryption attacks. Security researchers at Microsoft recommend this cipher suite be disabled – as well as Zirous – but c’mon, I feel like if Microsoft’s security team says don’t enable… It’s probably a solid tactic.

CBC is vulnerable to Chaining attacks and Padding Oracle attacks and when used in conjunction with TLSv1.0 will leave the system vulnerable to attacks. It should be disabled, or if using TLSv1.1+, it is recommended to use GCM in place of CBC.

There is absolutely no encryption with Null Cipher suites (Null, eNull, aNull) and they should be always disabled unless debugging or testing certain networking issues.

Export Grade Ciphers (DES, 3DES) are now considered obsolete and should be disabled.

When using an anonymous cipher (any cipher with anon in the name), SSL/TLS does not use a certificate to prove a server’s identity and should be disabled due to the blatant risks.

The MD5 algorithm has shown to be weak and susceptible to collisions, and it also makes use of ciphers that have known weakness (RC2), and they should be disabled. Disabling MD5 will result in RC2 being disabled as well.

Enabled Algorithms and SSL/TLS Versions

TLSv1.2 was released as a revision to TLSv1.1 and introduces very useful features such as higher performance GCM cipher suites and SHA-256 based pseudorandom functions. GCM suites also provide authenticated encryption which replaces the traditional Encrypt-then-Authenticate scheme. TLSv1.1 can be enabled to support legacy systems, but has been shown to be susceptible to compression (CRIME) attacks and renegotiation attacks.

ECDH/DH Cipher Suites are newer cipher suites for key exchange which provide the function of having passively captured traffic not be decryptable even if the server’s private key is compromised at a later time.

AES Cipher Suites are often used by clients that will not support ECDH/DH cipher suites and should be enabled to allow for a more robust security.

Cipher Choice

The most recent cipher suites make use of RSA, ECDH, or ECDSA for authentication, ECDHE for key exchange, AES for encryption, and GCM for integrity. Zirous’ recommended cipher suite to be used for SSL negotiation would be ECDHE_RSA_WITH_AES_256_GCM_SHA384. This allows for:

• ECDHE (Elliptic Curve Diffie-Hellman, ephemeral) which employs forwarding Secrecy. That is, if an attacker ever gets access to your server’s private key, the attacker cannot use the private key to decrypt any of the archived sessions;
• RSA (Rivest-Shamir-Adleman) which is the most widely accepted by internal Certificate Authorities;
• AES_256 (Advanced Encryption Standard, 256 bit Block Size) for strong encryption;
• GCM (Galois/ Counter Mode) that give certificate integrity verification; and
• SHA384 (Secure Hashing Algorithm, 384 bit Hash) for a strong hashing algorithm.

—–

In order to properly proactively fight against network intrusion and stinky offices, keep the wet socks to a minimum and be sure to secure your socket layer to the maximum.

Sources

[1] https://java.com/en/download/faq/java_7.xml
https://www.owasp.org/index.php/Transport_Layer_Protection_Cheat_Sheet
https://www.securityevaluators.com/ssl-tls-protocol-versions-cipher-suites-use/
https://technology.amis.nl/2017/07/04/ssltls-choose-cipher-suite/