RSA BSAFE® SSL-J 6.2.
Copyright and Trademark Notice and Trademarks Copyright © 2019 Dell Inc. or its subsidiaries. All rights reserved. Dell, EMC, RSA, the RSA logo, and BSAFE are registered trademarks of Dell Inc. or its subsidiaries in the United States and/or other countries. All other products and services mentioned are trademarks of their respective companies. For the most up-to-date listing of Dell trademarks, go to www.dell.com/learn/us/en/19/shared-content/dell-trademark-list.
Security Best Practices Guide 13.11.19 RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide The RSA BSAFE SSL-J (SSL-J) is a software development toolkit for building cryptographic, certificate, and Transport Layer Security (TLS) security technologies into Java™ applications, devices, and systems. The installation and configuration of SSL-J as part of an application deployment must be considered by the customer to ensure the toolkit is securely available.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Best Practice for SSL-J FIPS 140-2 Compliance SSL-J allows TLS protocols to be used in a FIPS 140-2 compliant manner. It is designed to be integrated into client applications using the Java JSSE and JCE cryptographic provider frameworks, or using the proprietary SSLJ API.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide SSL/TLS Communications This section describes potential vulnerabilities with regards to SSL and TLS communications, and the SSL-J configuration options available to protect against these vulnerabilities, as well as some general SSL and TLS recommendations. The potential vulnerabilities include: • SSL/TLS Renegotiation Denial of Service Exploit • Sweet32: Birthday Attack.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Sweet32: Birthday Attack The Sweet32:Birthday attack is a vulnerability that affects cipher suites which use DES or Triple-DES as the symmetric encryption cipher. A block cipher’s security primarily depends on the key size where a larger key, k, provides a higher security strength. However, the block size, n, must also be considered when encrypting a large amount of data with the same key and using a mode of encryption such as CBC.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Logjam Vulnerability In TLS 1.2 and earlier, a Man-in-the-Middle attack can occur where an attacker might be able to force a client downgrade to Ephemeral Diffie-Hellman (DH) keys with export-grade cipher strength. For more information about the Logjam Vulnerability, see CVE-2015-4000.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Poodle Attack In October 2014, the POODLE (Padding Oracle On Downgraded Legacy Encryption) attack was announced. TLS clients are designed to communicate with TLS servers that support different versions of the TLS protocol, including SSLv3, TLS 1.0, TLS 1.1, and TLS 1.2.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide The SSLv3 protocol and RC4 cipher suites are disabled by default for SSL-J 6.2 and above, however care must be taken when changing the enabled protocols and cipher suites to ensure that the SSLv3 protocol and RC4 cipher suites do not become enabled unless their security attributes are fully understood and they are required for interoperability reasons.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide For example: SSLParams params = new SSLParams(); // Set the allowed TLS versions (not including SSLv3). int[] versions = { SSLParams.TLSV1_1, SSLParams.TLSV1_2 }; params.setVersions(versions); loadTrustAnchors(params); // Create an SSLSocket and connect it to the server. SSLSocket socket = new SSLSocket(HOSTNAME, PORT, params); // Use the Socket. InputStream in = socket.getInputStream(); OutputStream out = socket.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Triple Handshake Vulnerability The triple handshake attack is a vulnerability that might allow a Man-in-the-Middle to insert data into the first application message after renegotiation with a client certificate. The attack relies on the client not recognizing that the server certificate changes from the fake Man-in-the-Middle certificate to the real server certificate. The attack proceeds in three steps: 1.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Lucky Thirteen Attack In February 2013, the Lucky Thirteen (SSL/TLS Plaintext Recovery) attack was announced. Researchers discovered a weakness in the handling of CBC cipher suites in SSL, TLS, and DTLS. Vulnerable implementations do not properly consider timing side-channel attacks on a MAC check requirement during the processing of malformed CBC padding.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide BEAST Exploit There is a known vulnerability in SSLv3 and TLS v1.0 to do with how the Initialization Vector (IV) is generated. For symmetric key algorithms in CBC mode, the IV for the first record is generated using keys and secrets set during the SSL or TLS handshake. All subsequent records are encrypted using the ciphertext block from the previous record as the IV.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Note the following about first block splitting: • Splitting only occurs: – For negotiated cipher suites that use CBC mode. – For protocols SSLv3 or TLS v1.0. First block splitting is not required for negotiated protocols TLS v1.1 or higher. • Handshake packets are not split, only data packets. • The first application data block following any SSL or TLS handshake will be split.
RSA BSAFE SSL-J 6.2.6 Security Best Practices Guide Support and Service Access community and support information for your RSA BSAFE products on RSA Link. RSA Link offers a knowledge base containing answers to common questions and solutions to known problems, product documentation, community discussions, and case management. Customers can also open support cases by sending an email to support@rsa.com.
