A flaw was discovered in the DTLS in JSSE component of OpenJDK, allowing malicious clients to make a DTLS server consume excessive resources by repeatedly transmitting a series of handshake initiation requests. The malicious client could also use this flaw to send pre-generated messages with a spoofed source, causing the server to send replies to a victim machine, thus potentially flooding it.
A flaw was found in the way the TLS implementation in the JSSE component of OpenJDK re-used single null TLS sessions for new TLS connections. A remote attacker could possibly use this flaw to impact availability of a Java application providing TLS server.
A flaw was found in the way the TLS implementation in the JSSE component of OpenJDK handled unexpected Certificate messages during the TLS handshake. This could possibly allow an attacker to tamper with certificate verification performed during the handshake.
A flaw was found in the way the JSSE component of OpenJDK handled certificate status / OCSP stapling message during TLS handshake. A remote attacker could possibly use this flaw to gain access to certain sensitive information by manipulating TLS handshake messages.
A flaw was found in the way the JSSE component in OpenJDK performed X.509 certificate identify verification when establishing TLS/SSL connection to a host identified using IP address. In certain cases, it would incorrectly use a host name obtained after performing reverse DNS lookup of the specified IP address rather than the original IP address for the identity check, possibly leading to having a certificate issued for different identity to be accepted as valid.
This issue is know to affect cases when SSLSocketFactory.createSocket() is called with certain InetAddress instances. It is not known to affect cases when target host IP is passed to createSocket() as string, or when IP is used in URL used for HttpsURLConnection.
With this patch, reverse DNS lookup is no longer performed. The fix also adds new system property jdk.tls.trustNameService that can be used to allow the DNS lookup to be performed and hence have its result used during identity check.
Multiple packages on Sun Solaris, including (1) NSS; (2) Java JDK and JRE 5.0 Update 8 and earlier, SDK and JRE 1.4.x up to 1.4.212, and SDK and JRE 1.3.x up to 1.3.119; (3) JSSE 1.0.303 and earlier; (4) IPSec/IKE; (5) Secure Global Desktop; and (6) StarOffice, when using an RSA key with exponent 3, removes PKCS-1 padding before generating a hash, which allows remote attackers to forge a PKCS #1 v1.5 signature that is signed by that RSA key and prevents these products from correctly verifying X.509 and other certificates that use PKCS #1.
Java Secure Socket Extension (JSSE) 1.0.3 through 1.0.32 does not properly validate the certificate chain of a client or server, which allows remote attackers to falsely authenticate peers for SSL/TLS.
X509TrustManager in (1) Java Secure Socket Extension (JSSE) in SDK and JRE 1.4.0 through 1.4.001, (2) JSSE before 1.0.3, (3) Java Plug-in SDK and JRE 1.3.0 through 1.4.1, and (4) Java Web Start 1.0 through 1.2 incorrectly calls the isClientTrusted method when determining server trust, which results in improper validation of digital certificate and allows remote attackers to (1) falsely authenticate peers for SSL or (2) incorrectly validate signed JAR files.