Posts

Use Braces Even For Single Line Statement

Image
On Feb. 21, 2014, Apple released security update for iOS that affected SSL/TLS connections. The impact is described as "An attacker with a privileged network position may capture or modify data in sessions protected by SSL/TLS." And the CVSS v2 Base Score is 6.8(AV:N/AC:M/Au:N/C:P/I:P/A:P). What's the problem with it?

Here is the Apple code:
static OSStatus SSLVerifySignedServerKeyExchange(SSLContext *ctx, bool isRsa, SSLBuffer signedParams, uint8_t *signature, UInt16 signatureLen) { ... if ((err = ReadyHash(&SSLHashSHA1, &hashCtx)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &clientRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &serverRandom)) != 0) goto fail; if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) goto fail; goto fail; if ((err = SSLHashSHA1.final(&hashCtx, &hashOut)) != 0) …

JEP 115: AES-GCM CipherSuites in JDK 8

Image
RFC 5288 describes the use of AES in Galois Counter Mode (GCM) (AES-GCM) with various key exchange mechanisms as a cipher suite for TLS. AES-GCM is an authenticated encryption with associated data (AEAD) cipher (as defined in TLS 1.2) providing both confidentiality and data origin authentication.

Java SE had already defined the AES-GCM interfaces in Java SE 7.  In the coming Java SE 8, as an implementation of JEP 115, AES-GCM algorithms is implemented in SunJCE provider, and AES-GCM cipher suites are implemented in SunJSSE provider.

The following SSL/TLS AEAD/GCM cipher suites, in preference order, are enabled by default in SunJSSE provider for TLS version 1.2:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289) TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288) TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) TLS_…

JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

Image
The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. In the previous blog entries, we talked about the behavior changes in JSSE, and a few typical user cases. Let's look at a special user case, how to design a virtual server dispatcher in Java. Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.


Prepare the ClientHello Parser
Applications need to implementation their own APIs to parser the client hello message from a plaintext socket. Suppose that an application design the following API to do the work, SSLCapabilities and SSLExplorer.
SSLCapabilities is defined to show the SSL/TLS security capabilities during handshaking, SSLCapabilities can be retrieved by exploring the network data of an SSL/TLS connection via SSLExplorer.explore(ByteBuffer).

/** * Encapsulates the security capabilities * of an SSL/TLS connection. * * The security capabilities are the list * ciphersuites to be…

JEP 114: TLS SNI Extension - Typical User Cases

Image
The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. In the previous two blog entries, we talked about the behavior changes in JSSE. Let's look at a few typical user cases. Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.

Client side user casesCase C-1: I want to access "www.example.com" Set the host name explicit.
SNIHostName serverName = new SNIHostName("www.example.com"); List<SNIServerName> serverNames = new ArrayList<>(1); serverNames.add(serverName); sslParameters.setServerNames(serverNames); It is recommend that the client always specify the host name.

Case C-2: I don't want to use server name indication The server side terminates the transaction if server name indication is presented. I cannot use server name indication because of the compatibility issues in server side.

Disable the server name indication with empty serv…

JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)

Image
The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. In the previous blog entry, we talked about the behavior changes in client and server mode. This blog entry will continue to talk about behavior changes in key manager and trust manager of JSSE. Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.

Server Name Indication (SNI) sensitive KeyManager
In JDK 7 and previous releases, the KeyManager of server is not server name indication sensitive. The KeyManager of SunJSSE provider does not check the server name indication in order to get the proper key and certificate.

In JDK 8, the KeyManager of server of SunJSSE provider will try check the server name indication in extension and select the appropriate keys according to requested server name indication.

For example, supposed that there are three key/cert entries in server key store. The subject of the certs are "cn=www.example.com&q…

JEP 114: TLS SNI Extension - SunJSSE Behavior Changes

Image
The implementation of JEP 114 (TLS Server Name Indication (SNI) Extension) had integrated into JDK 8 at October, 2012. This blog entry will talk about some useful behavior changes and user cases that make use of SNI extenstion.  Please refer to javax.net.ssl package of JDK 8 APIs for the detailed specification.

The SNI extension in client mode
In JDK 7, if a SSL/TSL connection specified hostname of the server, and when the hostname is fully qualified domain name (FQDN), the hostname will be used as the default server name indication in ClientHello message, implicitly.

For example:
    SSLSocketFactory factory = ...     SSLSocket sslSocket = factory.createSocket("www.example.com", 443);
the hostname, "www.example.com" will appear in the server name indication extension in ClientHello message.

While for
    SSLSocketFactory factory = ...     SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);
as the hostname is an IP address, No server name indi…

TLS Server Name Indication Extension and Unrecognized_name

Image
It's getting hot that some TLS/HTTPS server failed with "unrecognized_name". For example, the Adobe AIR 3 Code Signing Certificate Problem, the ADT handshake alert, and the jarsigner issue with timestamp.geotrust.com, etc. This entry will discussion some background of the "unrecognized_name" alert, and the TLS Server Name Indication (SNI) extension.

Background
"Unrecognized_name" is an error alert, define by RFC4366.  In section 4 of RFC4366:
- "unrecognized_name": this alert is sent by servers that receive a server_name extension request, but do not recognize the server name. This message MAY be fatal. And in section 3.1 of of RFC4366:
If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal).
From above sections, we see that "unrecognized_name" is related to "the server name" or "server_name" extensi…