Security enhancements and changes JavaTM 2 SDK, Standard Edition, v 1.3

Documentation Contents

trustProxy Property Now true by Default

In version 1.3 of the Java Plug-in, the trustProxy property is set to true by default. In previous releases of the Java platform, trustProxy was false by default.

Reason for the change:
To prevent DNS spoofing, a security check in Java Plug-in requires the server-side host name to be resolved into an IP address before any connection is made from the applet. As part of this security check, the client-side intranet DNS server must be able to resolve external host names from the Internet. However, the DNS servers within many enterprise networks are not able to perform this resolution due to firewall or other security restrictions on the enterprise site. The trustProxy property has been set to true by default so that in such cases the Java Plug-in will defer the DNS name resolution to the client site's proxy server.

Security implication of the change:
Because the DNS lookup can be delegated to the proxy server when the trustProxy property is true, care should be taken that the proxy server will not expose the local site to DNS spoofing attacks. The proxy server should consistently map a given host name to the same IP address and should never map an Internet server host name to the IP address of a machine on the local, client-side intranet. If the proxy server cannot be trusted to always provide unique host-name/IP-address mappings or cannot distinguish between internal and external IP addresses, network administrators may want to set the trustProxy property equal to false. This can be done by entering -DtrustProxy=false in the Java Run Time Parameters field of the Java Plug-in Control Panel. When trustProxy is false, DNS lookup will be up to the client-side intranet DNS server and will not be delegated to the proxy server. This will mean, however, that applets will not be able to be downloaded over the Internet whenever the intranet DNS server cannot resolve the applet server's host name.

New Classes/Interfaces

• java.security.spec.RSAKeyGenParameterSpec

  New class java.security.spec.RSAKeyGenParameterSpec makes it possible to specify both the size of the (to-be-generated) public modulus and the value of the public exponent when generating an RSA keypair.

• java.security.DomainCombiner

  New interface java.security.DomainCombiner provides a means to dynamically update the ProtectionDomains associated with the current AccessControlContext.

• java.security.interfaces.RSAKey

  New interface java.security.interfaces.RSAKey allows generic examination of keys before examining them in detail. java.security.interfaces.RSAPublicKey.getModulus() and java.security.interfaces.RSAPrivateKey.getModulus() have been moved to this interface. The existing RSAPublicKey and RSAPrivateKey interfaces now extend off of this new interface.

Modified Classes/Interfaces

• java.security.BasicPermission and java.lang.System

  Constructors for class java.security.BasicPermission have been modified to:

  • raise a NullPointerException if the permission name is null
  • raise an IllegalArgumentException if the permission name is empty

  Before, these conditions were ignored.

  The change also affects the behavior of java.lang.System.getProperty(String key) and java.lang.System.getProperty(String key, String def) whose implementations construct an instance of java.util.PropertyPermission, a subclass of java.security.BasicPermission. Under the change, a call to java.lang.System.getProperty() or java.lang.System.setProperty() with an empty property name will result in an IllegalArgumentException.

• java.security.interfaces.RSAPrivateKey and java.security.interfaces.RSAPublicKey

  The method getModulus() of java.security.interfaces.RSAPublicKey and java.security.interfaces.RSAPrivateKey has been moved to java.security.interfaces.RSAKey. See above.

• java.security.KeyPairGenerator

  The method java.security.KeyPairGenerator.generateKeyPair() has been restored to ensure backwards compatibility with JDK 1.1.x.

• java.security.Security

  Two new methods have been added to java.security.Security, making it possible to select service providers based on the capabilities that they offer:

  • public static Provider[] getProviders(java.util.Map filter)
  • public static Provider[] getProviders(String filter)

• java.security.Signature

  A new signature verification method has been added to java.security.Signature, and this new method is FIPS 140-1 compliant. FIPS 140-1 requires a public key to be passed as a certificate, which is accomplished through the addition of:

  • Signature.initVerify(Certificate certificate)

Miscellaneous Information

• Support for RSA signatures and related services is supplied by a Cryptographic Service Provider to the Java Cryptography Architecture (JCA), which is packaged as a JAR file and provided on the bootstrap classpath of the JRE.

• A new command line option ("-provider") has been added to keytool and jarsigner which allows the user to specify a particular service provider not listed in the security properties file of the Java Runtime Environment (JRE).

• Enhancements have been made to support all X.520 attributes that are either mandated or recommended by PKIX RFC 2459.

• Jarsigner can now verify Netscape-signed jar files.

• The handling of X509 certificates has been updated to include support for multiple Attribute/Value Assertions (AVA's) within a Relative Distinguished Name (RDN).

• Java 2 SDK v 1.3 now fully interoperates with Verisign's code signing certificates. keytool is now able to import Verisign certificates.

• The 1.2.2 FCS plug-in release required an exact match (including validity period) of the JAR signer's root CA certificate (fingerprint) with one in Microsoft's Internet Explorer (IE) CA store on the executing platform.

  This algorithm was too restrictive, due to the proliferation of valid, but different root CA certificates (expiring in 2004, 2018, 2028, etc.) in various incarnations of IE's CA store. This date match algorithm was removed. IE's CA store is used for verification in the executing environment, whether using Netscape or IE as the browser. For more information, please see:

  http://java.sun.com/products/plugin/1.2/docs/nsobjsigning.html

• Jar files containing support classes for applets can be placed in the Plug-in lib/applet/ directory. This reduces startup time for large applets by allowing applet classes to be preloaded from the local file system by the applet classloader, providing the same protections as if they had been downloaded over the network.

Copyright © 1999 Sun Microsystems, Inc. All Rights Reserved. Please send comments to: java-security@sun.com. This is not a subscription list.

Java Software