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
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:
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:
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.