Java™ SE 7 Security Enhancements

The following topics are covered:

Enhancements in Java SE 7 Update 2
Enhancements in Java SE 7

Enhancements in Java SE 7 Update 2

Area: Java Cryptography Extension
Synopsis: Public key certificates containing Elliptic Curve Cryptography (ECC) keys are parsed correctly by the SunPKCS11 JCE security provider on Solaris 11. See 7054637.

Enhancements in Java SE 7

The Java SE 7 release adds the following features:

Elliptic Curve Cryptography (ECC)

A new native provider has been added to the Java SE 7 release that provides several ECC-based algorithms (ECDSA/ECDH). For more information, see The SunEC Provider's Supported Algorithms section in the Java Cryptography Architecture Oracle Providers Documentation.
CertPath Algorithm Disabling

Weak cryptographic algorithms can now be disabled. For example, the MD2 digest algorithm is no longer considered secure. The Java SE 7 release provides a mechanism for denying the use of specific algorithms in certification path processing and TLS handshaking. See Appendix D: Disabling Cryptographic Algorithms in Java PKI Programmer's Guide and Disabled Cryptographic Algorithms in Java Secure Socket Extension (JSSE) Reference Guide for more information.
JSSE (SSL/TLS)
- TLS 1.1
  
  The SunJSSE provider now supports TLS 1.1 as described in RFC 4346. The most important update is protection against cipher block chaining (CBC) attacks.
- TLS 1.2
  
  The SunJSSE provider now supports TLS 1.2 as described in RFC 5246. Among other things, it specifies different internal hashing algorithms, adds new cipher suites, and contains improved flexibility, particularly for negotiation of cryptographic algorithms.
- Weak cipher suites deprecated
  
  Per RFC 4346, RFC 5246, and RFC 5469, some cipher suites have been made obsolete and should not be used. These obsolete suites are all disabled by default in SunJSSE. For details, consult the cipher suite lists in the documentation about the SunJSSE provider.
- Connection-sensitive trust management
  
  Both trust managers and key managers now have the ability to examine parameters of the TLS connection, specifically the SSLSession under construction, during the handshake. For example, a trust manager might restrict the types of certificates used based on the list of valid signature algorithms.
- Endpoint verification
  
  An endpoint identification algorithm can be specified to verify that a remote computer's host address matches its supplied certificate. Although this type of verification was previously performed for the HTTPS protocol (see HttpsURLConnection and HostnameVerifier), such verification can now be optionally performed at the TLS level.
- TLS renegotiation
  
  Java SE supports RFC 5746, which fixes a renegotiation issue in the TLS protocol.
- SSLv2Hello disabled by default on the client
  
  In Java SE 7, SSLv2Hello is removed from the default enabled protocol list on the client.
- Algorithm disabling
  
  Weak cryptographic algorithms can now be disabled, as previously described.
- Server Name Indication (SNI) for JSSE client
  
  The Java SE 7 release supports the Server Name Indication (SNI) extension in the JSSE client. SNI is described in RFC 4366. This enables TLS clients to connect to virtual servers.
- Tighter checking of EncryptedPreMasterSecret version numbers
  
  Java SE 7 tightens version number checking during TLS 1.1 and TLS 1.2 handshaking. See Tighter Checking of EncryptedPreMasterSecret Version Numbers in Java Cryptography Architecture Oracle Providers Documentation for more information.

In addition, the following enhancements are added:

Area: Security
Standard/Platform: Java SE 7
Synopsis: Security algorithm requirement have been defined for Java SE 7 that provide a list of algorithms that all implementations of Java SE 7 must support. The class summary of applicable classes (ex: java.security.Signature) has been updated to include the implementation requirements. Also, all of the requirements are listed in the Implementation Requirements section of the Standard Algorithms document.
RFE: 5001004

Area: API: JSSE
Standard/Platform: Java SE 7
Synopsis: In previous releases, except for the default algorithm, there was no standard algorithm name for KeyManagerFactory. In the Java SE 7 release, "PKIX" is exported as the standard algorithem name for KeymanagerFactory. The "PKIX" KeyManagerFactory algorithm is defined as:
A factory for X509ExtendedKeyManagers that manages X.509 certificate-based key pairs for the local side authentication according to the rules defined by th eIETF PKIX working group in RFC 3280 or its successor. The KeyManagerFactory must support initialization using the class javax.net.ssl.KeyStoreBuilderParameters.
RFE: 7022855

Area: API: JSSE
Standard/Platform: Java SE 7
Synopsis: Support for TLS 1.2 has been added to the SunJSSE provider.
RFE: 6916074

Area: JSSE
Standard/Platform: JDK 7
Synopsis: The TLS renegotiation fix has been implemented. Please see TLS/SSLv3 Renegotiation Vulnerability Explained, Understanding the TLS Renegotiation Attack and Authentication Gap in TLS Renegotiation for more information.

Area: JSSE
Standard/Platform: JDK 7
Synopsis: Support for the Server Name Indication (SNI) extension has been added to the JSSE client in the SunJSSE provider.
RFE: 6985179

Area: SASL
Standard/Platform: JDK 7
Synopsis: NTLM is now supported as a SASL mechanism on both the client and server side. Only the authentication layer is implemented, and there is no privacy or integrations protection in communication.
RFE: 6911951

Area: Security
Standard/Platform: JDK 7
Synopsis: The implementaton of PKIX has been enhanced to include an option to reject certificates if the corresponding key is not strong enough, for example MD2 hash functions or any RA key with key size less than 1024.
RFE: 6792180

Area: API: JSSE
Standard/Platform: JDK 7
Synopsis: Support for TLS 1.1 has been added to the SunJSSE provider, and the SSLv2Hello "pseudo protocol" is no longer active by default in the SunJSSE provider.
RFE: 4873177

Area: JGSS
Standard/Platform: JDK 7
Synopsis: Java now reads a keytab file whenever that keytab file changes. The file can be empty or nonexistent when the application that uses the file is started.

Area: JGSS
Standard/Platform: JDK 7
Synopsis: A default configuration file is now provided for JGSS with default krb5.conf settings for Windows and *nix systems. This makes deploying a JGSS/krb5 program very easy, especially for deploying Java applets.
RFE: 6483218, 6785456, 6552334

Area: JCE
Standard/Platform: JDK 7
Synopsis: SunPKCS11 provider now supports Raw RSA encryption, for example, Cipher.getInstance("RSA/ECB/NoPadding") calls, when the underlying PKCS11 library supports CKM-RSA_X_509 mechanism. In addition, SunPKCS11 provider recognizes "RSA" as an alias for the "RSA/ECB/PKCS1Padding" transformation when requesting a Cipher object.
RFE: 6994008

Area: JCE
Standard/Platform: JDK 7
Synopsis: The SunPKCS11 provider now supports ECB, CBC modes with PKCS5Padding for certain block ciphers. To be more specific, it supports the following transformations for Cipher.getInstance(...) calls when the corresponding PKCS11 mechanism is supported by the underlying PKCS11 library:

DES, DESede, AES, and Blowfish with CBC mode and PKCS5Padding
DES, DESede, AES with ECB mode and PKCS5Padding
DES, DESede, AES with ECB mode and NoPadding

RFE: 4898461

Area: JCE
Standard/Platform: JDK 7
Synopsis: The SunPKCS11 provider now supports AES encryption with Counter mode (CTR), (for example, Cipher.getInstance("AES/CTR/NoPadding") calls) when the underyling PKCS11 library supports CKM_AES_CTR mechanism.
RFE: 6604496

Area: JCE
Standard/Platform: JDK 7
Synopsis: Given that the relevant Solaris bug (i.e. 6306708 "CKM_SSL3_KEY_AND_MAC_DERIVE returns incorrect cipher keys for exportable ciphersuites") has been addressed in the Solaris 10 update 5 release, the SunPKCS11 provider no longer disables the following two mechanisms by default:

CKM_SSL3_KEY_AND_MAC_DERIVE
CKM_TLS_KEY_AND_MAC_DERIVE

RFE: 7036252