Xuelei Fan's Blog

Use Braces Even For Single Line Statement

2014-02-24T22:04:00.001-08:00

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)
        goto fail;

    err = sslRawVerify(ctx,
                       ctx->peerPubKey,
                       dataToSign,    /* plaintext */
                       dataToSignLen,   /* plaintext length */
                       signature,
                       signatureLen);
    if(err) {
        sslErrorLog("SSLDecodeSignedServerKeyExchange: sslRawVerify "
                    "returned %d\n", (int)err);
        goto fail;
    }

fail:
    SSLFreeBuffer(&signedHashes);
    SSLFreeBuffer(&hashCtx);
    return err;

}

Did you note these lines?

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0)
        goto fail;
        goto fail;

There are two "goto fail;" lines. The second one will always be executed and jump to "fail" marked block. Therefore, there is no chance to execute the sslRawVerify() method, which is essential to establish a safe SSL connection. Here comes the security issue. Read here if you want to learn more detailed analysis of the issue.

The lesson I learned:
1. Be patient during code review. Even a minor typo can result in serious security issues.
2. Follow good code conversions. People make fewer mistakes in consistent environments.

Java suggests to always to use braces for "if" statements. C and C++ also have similar conversions, for example the brace policy in C and C++.

Note: if statements always use braces, {}. Avoid the following error-prone form:

if (condition) //AVOID! THIS OMITS THE BRACES {}!
    statement;

Rewrite the Apple code with the braces policy:

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
        goto fail;
    }
    goto fail;

With this reorg, it is easier to find the problem during code review. Or

    if ((err = SSLHashSHA1.update(&hashCtx, &signedParams)) != 0) {
        goto fail;
        goto fail;
    }

With this reorg, the problem disappears.

Good code conversions make a lot of fun!

JEP 115: AES-GCM CipherSuites in JDK 8

2014-01-19T06:22:00.000-08:00

Chengdu, China

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_DHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288)
    TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 (RFC 5288)
 
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289)
    TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 (RFC 5288)

The following SSL/TLS AEAD/GCM cipher suites are supported but not enabled by default in SunJSSE provider for TLS version 1.2:

    TLS_DH_anon_WITH_AES_256_GCM_SHA384 (RFC 5288)
    TLS_DH_anon_WITH_AES_128_GCM_SHA256 (RFC 5288)

The following SSL/TLS AEAD/GCM cipher suites are defined, but not implemented or supported by SunJSSE provider:

    TLS_DH_RSA_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DH_RSA_WITH_AES_256_GCM_SHA384 (RFC 5288)
 
    TLS_DH_DSS_WITH_AES_128_GCM_SHA256 (RFC 5288)
    TLS_DH_DSS_WITH_AES_256_GCM_SHA384 (RFC 5288)

For better compatibility and interoperability, in JDK 8, it is decided to decrease the preference priority of cipher suites in GCM mode for a while before GCM technologies mature in the industry. New developments in TLS security have occurred recently, the industry is moving towards TLS 1.1/1.2 and the use of GCM-based cipher suites. The preference priority of GCM-based cipher suites by default may be increased in JDK 9, or a JDK 8 update release in the future.

Enojoy this new feature!

JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

2014-01-02T22:20:00.004-08:00

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 accepted in an SSL/TLS
 * handshake, the record version, the hello
 * version, and server name indication, etc.,
 * of an SSL/TLS connection.
 * 
 * {@code SSLCapabilities} can be retrieved by exploring the network
 * data of an SSL/TLS connection via {@link SSLExplorer#explore(ByteBuffer)}
 * or {@link SSLExplorer#explore(byte[], int, int)}.
 *
 * @see SSLExplorer
 */
public abstract class SSLCapabilities {

    /**
     * Returns the record version of an SSL/TLS connection
     *
     * @return a non-null record version
     */
    public abstract String getRecordVersion();

    /**
     * Returns the hello version of an SSL/TLS connection
     *
     * @return a non-null hello version
     */
    public abstract String getHelloVersion();

    /**
     * Returns a {@code List} containing all
     * {@link SNIServerName}s of the server name indication.
     *
     * @return a non-null immutable list of {@link SNIServerName}s
     *         of the server name indication parameter, may be empty
     *         if no server name indication.
     *
     * @see SNIServerName
     */
    public abstract List<SNIServerName> getServerNames();
}

SSLExplorer is defined to explore the initial ClientHello message from TLS Client. But it does not kick off handshaking, or consume network data. The SSLExplorer.explore() method parses the ClientHello message, and retrieve the security parameters from ClientHello message into SSLCapabilities.

This method must be called before handshaking occurs on any TLS connections.

/**
 * Instances of this class acts as an explorer of the network data of an
 * SSL/TLS connection.
 */
public final class SSLExplorer {

    /**
     * The header size of TLS/SSL records.
     * <P>
     * The value of this constant is {@value}.
     */
    public final static int RECORD_HEADER_SIZE = 0x05;

    /**
     * Returns the required size in byte from byte buffer to explore an
     * SSL/TLS connection.
     * <P>
     * This method tries to parse as few bytes as possible from
     * {@code source} byte buffer to get the length of an
     * SSL/TLS record.
     *
     * @param  source
     *         a {@code ByteBuffer} containing
     *         inbound or outbound network data for an SSL/TLS connection.
     *
     * @throws BufferUnderflowException if less than {@code RECORD_HEADER_SIZE}
     *         bytes remaining in {@code source}
     */
    public final static int getRequiredSize(ByteBuffer source);

    /**
     * Returns the required size in byte from byte array to explore an
     * SSL/TLS connection.
     * <P>
     * This method tries to parse as few bytes as possible from
     * {@code source} byte array to get the length of an
     * SSL/TLS record.
     *
     * @param  source
     *         a byte array containing inbound or outbound network data for
     *         an SSL/TLS connection.
     * @param  offset
     *         the start offset in array {@code source} at which the
     *         network data is read from.
     * @param  length
     *         the maximum number of bytes to read.
     *
     * @throws BufferUnderflowException if less than {@code RECORD_HEADER_SIZE}
     *         bytes remaining in {@code source}
     */
    public final static int getRequiredSize(byte[] source,
            int offset, int lenght) throws IOException;

    /**
     * Launch and explore the security capabilities from byte buffer.
     * <P>
     * This method tries to parse as few records as possible from
     * {@code source} byte buffer to get the {@code SSLCapabilities}
     * of an SSL/TLS connection.
     * <P>
     * Please NOTE that this method must be called before any handshaking
     * occurs.  The behavior of this method is not defined in this release
     * if the handshake has begun, or has completed.
     * <P>
     * This method accesses the {@code source} parameter in read-only
     * mode, and does not update the buffer's properties such as capacity,
     * limit, position, and mark values.
     *
     * @param  source
     *         a {@code ByteBuffer} containing
     *         inbound or outbound network data for an SSL/TLS connection.
     *
     * @throws IOException on network data error
     * @throws BufferUnderflowException if no enough source bytes available
     *         to make a complete exploration.
     *
     * @return the explored {@code SSLCapabilities} of the SSL/TLS
     *         connection
     */
    public final static SSLCapabilities explore(ByteBuffer source)
            throws IOException;

    /**
     * Launch and explore the security capabilities from byte array.
     * <P>
     * Please NOTE that this method must be called before any handshaking
     * occurs.  The behavior of this method is not defined in this release
     * if the handshake has begun, or has completed.
     * <P>
     * Please NOTE that this method must be called before any handshaking
     * occurs.  Once handshake has begun, or has completed, the security
     * capabilities can not and should not be launched with this method.
     *
     * @param  source
     *         a byte array containing inbound or outbound network data for
     *         an SSL/TLS connection.
     * @param  offset
     *         the start offset in array {@code source} at which the
     *         network data is read from.
     * @param  length
     *         the maximum number of bytes to read.
     *
     * @throws IOException on network data error
     * @throws BufferUnderflowException if no enough source bytes available
     *         to make a complete exploration.
     * @return the explored {@code SSLCapabilities} of the SSL/TLS
     *         connection
     *
     * @see #explore(ByteBuffer)
     */
    public final static SSLCapabilities explore(byte[] source,
            int offset, int length) throws IOException;
}

Please note that the above two classes is not part of JDK. It is used to illustrate how to use JSSE specification of server name indication.

Socket Based Scenarios of a virtual servers dispatcher

Step 1: register server name handler in the dispatcher server
At the step, the application may create different SSLContext for different server name indication, or link a certain server name indication to a specified virtual machine or distributed system.

For example, for server name of "www.example.com", the registered server name handler may be for a local virtual hosting web service. The local virtual hosting web service will use a specified SSL context. For server name of "www.invalid.com", the registered server name handler may be for a virtual machine hosting on "10.0.0.36". The handler may map proxy this connection to the virtual machine.

Step 2: create a server socket, and accept a new connection

    ServerSocket serverSocket = new ServerSocket(serverPort);
    Socket socket = serverSocket.accept();

Step 3: read and buffer bytes from the socket input stream, and explore the buffered bytes

    InputStream ins = socket.getInputStream();

    byte[] buffer = new byte[0xFF];
    int position = 0;
    SSLCapabilities capabilities = null;

    // Read the header of TLS record
    while (position < SSLExplorer.RECORD_HEADER_SIZE) {
        int count = SSLExplorer.RECORD_HEADER_SIZE - position;
        int n = ins.read(buffer, position, count);
        if (n < 0) {
            throw new Exception("unexpected end of stream!");
        }
        position += n;
    }

    // Get the required size to exlpore the SSL capabilities
    int recordLength = SSLExplorer.getRequiredSize(buffer, 0, position);
    if (buffer.length < recordLength) {
        buffer = Arrays.copyOf(buffer, recordLength);
    }

    while (position < recordLength) {
        int count = recordLength - position;
        int n = ins.read(buffer, position, count);
        if (n < 0) {
            throw new Exception("unexpected end of stream!");
        }
        position += n;
    }

    // Explore
    capabilities = SSLExplorer.explore(buffer, 0, recordLength);;
    if (capabilities != null) {
        System.out.println("Record version: " +
                capabilities.getRecordVersion());
        System.out.println("Hello version: " +
                capabilities.getHelloVersion());
    }

Step 4: get the requested server name from the SSLCapabilities

    List<SNIServerName> serverNames = capabilities.getServerNames();

Step 5: looking for the registered server name handler for this server name indication
Typically, there are two types of handler. The first one is that the service of the hostname is resident in a virtual machine or another distributed separated box. In this case, the application need to forward the connection to the destination. The application requires to read and write the raw internet data, rather than the SSL application from the socket stream.

    Socket destinationSocket = new Socket(serverName, 443);

    // forward buffered bytes and network data from the current socket to
    // destinationSocket, proxy-like coding

The 2nd one is that the service of the server name is resident in the same process. And the service is able to use the socket directly. In this case, the application will simply set the SSLSocket instance to the server.

    SSLContext serviceContext = ...
                    // get service context from registered handler
                    // or create the context on the fly
    SSLSocketFactory serviceSocketFac =
                    serviceContext.getSSLSocketFactory();

    ByteArrayInputStream bais =
        new ByteArrayInputStream(buffer, 0, position);
                           // wrap the buffered bytes
    SSLSocket serviceSocket =
        (SSLSocket)serviceSocketFac.createSocket(socket, bais, true);

    // Now the service can use the serviceSocket as normal.

SSLEngine Based Scenarios of a virtual servers dispatcher

Similar to the socket based scenatios. There is a little different in the 2nd case in step 5.
The 2nd case is that the service of the hostname is resident in the same process. And hostname service is able to use the engine directly. In this case, the application will simply feed the net data to the new engine.

    SSLContext serviceContext =
                    // get service context from registered handler
                    // or create the context on the fly
    SSLEngine serviceEngine = serviceContext.createSSLEngine();

    // Now the service can use the buffered bytes and other byte
    // buffer as normal.

The scenarios for the cases that bridge SSLSocket source to SSLEngine destination, or SSLEngine source to SSLSocket destination are pretty similar to the above two scenarios.

No server name indication extension

It's often that there is no server name indication extension in a ClientHello message. There is no way to select a proper service according to server name indication.

For such cases, the application may want to specify a default service. When there is no server name indication extension, the connection will be delegated to the default service.

Failover

Please NOTE that the explore of the security capabilities should neither consume nor produce network or application data. So what about if the explore fails?

SSLExploree.explore() should not checking the validity of SSL/TLS contents. However, it requires that the record format complies to SSL/TLS specification, and handshaking has not started. SSLExploree.explore() may throw IOException for such bad cases.

SSLExploree.explore() cannot produce network data. And SSL/TLS protocols requires to reply with proper alert messages. It is not recommended to close the raw socket out of band of SSL/TLS protocols. Failover is recommended to handle exception thrown by SSLExplorer.explore().

The application need to define a failover SSLContext, it is not used to negotiate any real SSL/TLS connection. Instead, it is used to close the SSL/TLS connection with proper alert message. So the initialization of the context can be very basic.

    byte[] buffer = ...       // buffered network data
    boolean failed = true;    // SSLExploree.explore() throws an exception

    // off course, the above explore failed. Faile to failure handler
    SSLContext context = SSLContext.getInstance("TLS");
                                        // the failover SSLContext
    context.init(null, null, null);
    SSLSocketFactory sslsf = context.getSocketFactory();
    ByteArrayInputStream bais =
            new ByteArrayInputStream(buffer, 0, position);
    SSLSocket sslSocket = (SSLSocket)sslsf.createSocket(socket, bais, true);

    SNIMatcher matcher = new DenialSNIMatcher(); // see case 2.2.1
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    SSLParameters params = sslSocket.getSSLParameters();
    params.setSNIMatchers(matchers);    // no recognizable server name
    sslSocket.setSSLParameters(params);

    try {
        InputStream sslIS = sslSocket.getInputStream();
        sslIS.read();
    } catch (Exception e) {
        System.out.println("server exception " + e);
    } finally {
        sslSocket.close();
    }

To put it together, as SSLExplore.explore() may fail with exception, the application MUST handle the exception with a failover solution, such as failover SSLContext. An application may also need to handle ClientHello message without server name indication extension, the application MUST specify a default service for non-server-name-indication handshaking. And an application may be expected to handle server name indication properly, the application MUST specify the target service for a particular server name indication.

Hope it helps!

More blog entries about TLS Server Name Indication (SNI) Extension:
TLS Server Name Indication Extension and Unrecognized_name
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)
JEP 114: TLS SNI Extension - Typical User Cases

JEP 114: TLS SNI Extension - Typical User Cases

2014-01-02T21:12:00.001-08:00

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 cases

Case 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 server name list:

    List<SNIServerName> serverNames = new ArrayList<>(1);
    sslParameters.setServerNames(serverNames);

Case C-3: I want to access URL, "https://www.example.com"

Doing nothing in SunJSSE, the provider default behaviors will set the hostname for me. I don't have to care about what's the real server name indication.

But third parties' providers may not support default server name indication. It is recommended to use Case C-1 to be provider independent.

Case C-4: I want to switch a socket from server mode to client mode

The socket was in server mode, but I need it work in client mode. Firstly, need to switch the mode:Set the host name explicit.

    sslSocket.setUseClientMode(true);

Secondly, need to reset the server name indication parameters in server mode, see case S-1~S-5 for different purposes.

Server side user cases

Case S-1: I want to accept all kind of server name indication

Doing nothing, the server will ignore the server name indication.

Case S-2: I want to deny all server name indication of type host_name

Set an invalid server name pattern for host_name:

    SNIMatcher matcher = SNIHostName.createSNIMatcher("");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Or define a new SNIMatcher extension, which the matches() method always returns false.

    class DenialSNIMatcher extends SNIMatcher {
        DenialSNIMatcher() {
            super(StandardConstants.SNI_HOST_NAME);
        }

        @Override
        public boolean matches(SNIServerName serverName) {
            return false;
        }
    }

    SNIMatcher matcher = new DenialSNIMatcher();
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);

    sslParameters.setSNIMatchers(matchers);

Case S-3: I want to be accessed as "www.example.com"

Set the recognizable server name for "host_name" as "www.example.com":

    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("www\\.example\\.com");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Case S-4: I want to be accessed as "www.example.com" or "www.example.net"

Set the recognizable server name for "host_name" as "www.example.com" or "www.example.net":

    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("www\\.example\\.(com|net)");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Case S-5: I want to be accessed as any hostname in the example.com domain

Set the recognizable server name for "host_name" as "*.example.com":

    SNIMatcher matcher =
        SNIHostName.createSNIMatcher("(.*\\.)*example\\.com");
    Collection<SNIMatcher> matchers = new ArrayList<>(1);
    matchers.add(matcher);
    sslParameters.setSNIMatchers(matchers);

Case S-6: I want to switch a socket from client mode to server mode

The socket was in client mode, but I need it work in server mode. Firstly, need to switch the mode:

    sslSocket.setUseClientMode(true);

Secondly, need to reset the server name indication in client mode, see case C-1-C-3 for different purpose.

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

2014-01-02T02:01:00.003-08:00

Students Apartment, Harbin Institute of Technology (HIT), China

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", "cn=www.invalid.com" and "cn=www.example.net". When the client requested server name indication is "www.example.net", the server should be able to select the cert with subject "cn=www.example.net", rather than the other two certs.

Server name indication sensitive TrustManager

Endpoint identification can be based on IP address or literal hostname.

In JDK 7, if a SSL/TSL connection specified the literal hostname of the server, the hostname will be used to make the endpoint identification against the peer's identity presented in the end-entity X.509 certificate.

For example:

 
        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("www.example.com", 443);

the hostname, "www.example.com" will be used to make the endpoint identification.

While for

        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);

as the hostname is an IP address, the endpoint identification cannot be used for literal hostname.

In JDK 8, developers have a chance to explicitly set the server name indication with SSLParameters.setServerNames(List<SNIServerName> serverNames). The server name indication in client mode also has impact on endpoint identification.

In SunJSSE provider, in client mode, the endpoint identification in the implementation of X509ExtendedTrustManager will make use of the server name indication, retrieved by ExtendedSSLSession.getRequestedServerNames().

For example:

        SSLSocketFactory factory = ...
        SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);
        // SSLEngine sslEngine = sslContext.createSSLEngine("172.16.10.6", 443);
 
        SNIHostName serverName = new SNIHostName("www.example.com");
        List<SNIServerName> serverNames = new ArrayList<>(1);
        serverNames.add(serverName);
 
        SSLParameters params = sslSocket.getSSLParameters();
        params.setServerNames(serverNames);
        sslSocket.setSSLParameters(params);
        // sslEngine.setSSLParameters(params);

the hostname in server name indication, "www.example.com", will be used to make endpoint identification against the peer's identity presented in the end-entity X.509 certificate.

More blog entries about TLS Server Name Indication (SNI) Extension:
TLS Server Name Indication Extension and Unrecognized_name
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes
JEP 114: TLS SNI Extension - Typical User Cases
JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

JEP 114: TLS SNI Extension - SunJSSE Behavior Changes

2014-01-02T01:46:00.000-08:00

Silver Cave, Guilin, China

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 indication extension will appear in ClientHello message.

And for

    SSLSocketFactory factory = ...
    SSLSocket sslSocket = factory.createSocket("docs", 443);

although the real hostname may be docs.example.com, but as "docs" is not a fully qualified domain name, No server name indication extension will appear in ClientHello message.

For

    SSLSocketFactory factory = ...
    SSLSocket sslSocket = factory.createSocket("docs.example", 443);

the real hostname may be docs.example.com, although "docs.example" is not a fully qualified domain name, but the computer cannot tell this point. "docs.example" will be regarded as a fully qualified domain name, and server name indication extension will appear in ClientHello message. It is ambiguous!

In JDK 8, developers have a chance to explicitly set the server name indication. It is SSLParameters.setServerNames(List serverNames).

    SSLSocketFactory factory = ...
    SSLSocket sslSocket = factory.createSocket("172.16.10.6", 443);
    // SSLEngine sslEngine = sslContext.createSSLEngine("172.16.10.6", 443);

    SNIHostName serverName = new SNIHostName("www.example.com");
    List serverNames = new ArrayList<>(1);
    serverNames.add(serverName);

    SSLParameters params = sslSocket.getSSLParameters();
    params.setServerNames(serverNames);

    sslSocket.setSSLParameters(params);
    // sslEngine.setSSLParameters(params);

The SNI extension in server mode

In JDK 7, server will ignore all server name indication extension.

In JDK 8, by default, server reserves the behaviors of JDK 7. For better interoperability, providers generally will not define default matchers so that by default servers will ignore the SNI extension and continue the handshake. However, in JDK 8, server can use SNIMatcher to decide how to recognize server name indication.

        SSLSocket sslSocket = sslServerSocket.accept();
 
        SNIMatcher matcher = SNIHostName.createSNIMatcher(
                                        "www\\.example\\.(com|org)");
        Collection matchers = new ArrayList<>(1);
        matchers.add(matcher);
 
        SSLParameters params = sslSocket.getSSLParameters();
        params.setSNIMatchers(matchers);
        sslSocket.setSSLParameters(params);

        SSLServerSocket sslServerSocket = ...;
 
        SNIMatcher matcher = SNIHostName.createSNIMatcher(
                                        "www\\.example\\.(com|org)");
        Collection matchers = new ArrayList<>(1);
        matchers.add(matcher);
 
        SSLParameters params = sslServerSocket.getSSLParameters();
        params.setSNIMatchers(matchers);
        sslServerSocket.setSSLParameters(params);
 
        SSLSocket sslSocket = sslServerSocket.accept();

If server does not configure the server name matchers, the behavior is the same as JDK 7.
The following table shows the interaction behaviors between server SNI configuration and client request SNI in ClientHello message.

  Server configured matcher           client requested SNI
                             www.example.com    www.invalid.com    empty
 
        www\\.example\\.com       +                    x             v
        www\\.invalid\\.com       x                    +             v
        no matcher                v                    v             v
 
v: accepted server name indication, but no server name confirmation in
   server hello message.
+: accepted server name indication, response with recognized server name
   confirmation in server hello message
x: rejected with unrecognized_name fatal error

For example, if the server name in SNI extension of ClientHello message is "www.example.com", and the server is configured to support "www.example.com", the server will accept the SNI extension, and reply a confirmation in server hello message. However, if the server is configurated to support "www.invalid.com", but not "www.example.com", the server will deny the SNI extension, and response with a unrecognized_name fatal error.

More blog entries about TLS Server Name Indication (SNI) Extension:
TLS Server Name Indication Extension and Unrecognized_name
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)
JEP 114: TLS SNI Extension - Typical User Cases
JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

TLS Server Name Indication Extension and Unrecognized_name

2013-12-03T20:45:00.001-08:00

Heavy Pond, Jianfengling National Forest Park, Ledong, Hainan, China

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" extension. What is the "server name"? In section 3.1 of RFC4366:

3.1. Server Name Indication 

TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting.  It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address.

In order to provide the server name, clients MAY include an extension of type "server_name" in the (extended) client hello.

Let's Look Into a Case

There is a lot of discussion about the timestamp service from timestamp.EXAMPLE.com. The service is hosted as "https://timestamp.EXAMPLE.com/tsa". Let's look at the scenarios of the access:

Client want to negotiate a TLS connection with timestamp.EXAMPLE.com. By default, the server name indication extension will be included in the client hello. The server name is "timestamp.EXAMPLE.com". It is expected that:

The server does not understand the server name indication extension. No problem, the server will ignore the extension, will continue the negotiation. No impact on the TLS negotiation/handshaking.
The server understands the server name indication extension, but does not recognize the server name. In this case, that's to say, the server does not think that the server name in the request, "timestamp.EXAMPLE.com", is its supported/recognized server name.
The server is able to recognize the server name in the request. The handshaking will go on.

The server response with a "unexpected_message" fatal alert. As means that the server understand the server name indication extension, but it does not recognize the server name. It looks a little weird in this case in that the server is "timestamp.EXAMPLE.com", but it does not admit that it is "timestamp.EXAMPLE.com".
The client have to terminate the negotiation because the server has denied to continue.

It is strange, is it? The server, "timestamp.EXAMPLE.com", said it is not ""timestamp.EXAMPLE.com".

Know nothing about the details in TSA server, timestamp.EXAMPLE.com, it looks more like a configuration problem in the server side.

Workaround

It would be nice if the timestamp.EXAMPLE.com server would like to correct the behaviors in server side. But before the correction, many applications may need to work day to day. As a workaround, the client can disable the server name indication in client hello.

Java platform starts to support server name indication extension from JDK 7. However, considering the compatibility issues, a system property, "jsse.enableSNIExtension", is defined to disable the extension in TLS handshaking:

jsse.enableSNIExtension system property.

Server Name Indication (SNI) is a TLS extension, defined in RFC4366.It enables TLS connections to virtual servers, in which multiple servers for different network names are hosted at a single underlying network address.

Some very old SSL/TLS vendors may not be able handle SSL/TLS extensions. In this case, set this property to false to disable the SNI extension.

OK, let looks at an example in jarsigner in JDK 7. The 2nd one uses the system property, jsse.enableSNIExtension, to disable the server name indication extension in client.

$ jarsigner -keystore myKeyStore -tsa https://timestamp.EXAMPLE.com/tsa \
      -signedjar signedjar.jar toBeSigned.jar myKeyAliasInKeyStore

jarsigner: unable to sign jar: javax.net.ssl.SSLProtocolException: \
      handshake alert:  unrecognized_name

$ jarsigner -J-Djsse.enableSNIExtension=false \
      -keystore myKeyStore -tsa https://timestamp.EXAMPLE.com/tsa \
      -signedjar signedjar.jar toBeSigned.jar myKeyAliasInKeyStore

Hope it helps!

More blog entries about TLS Server Name Indication (SNI) Extension:
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes
JEP 114: TLS SNI Extension - SunJSSE Behavior Changes (Continue)
JEP 114: TLS SNI Extension - Typical User Cases
JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

Understanding of OCSP Stapling

2013-11-12T23:33:00.000-08:00


Sun and Moon Pagodas, Shanhu Lake, Guilin, China

What's OCSP Stapling?

OCSP stapling, also known as the TLS Certificate Status Request extension, is an alternative approach to the Online Certificate Status Protocol (OCSP) for checking the revocation status of X.509 digital certificates. It allows the presenter of a certificate to bear the resource cost involved in providing OCSP responses, instead of the issuing Certificate Authority (CA). [WIKI]

With OCSP stapling, it is the responsibility of the web site to get the OCSP response and send OCSP response to clients/browsers in SSL/TLS handshaking.

OCSP stapling is defined as TLS Certificate Status Request extension in section 8 of RFC 6066.

The Benefits of OCSP Stapling

The performance bottleneck of OCSP server
If client checks the certificate status directly from OCSP server, for each client with a given certificate, the OCSP server has to response with a particular certificate status. For high traffic web site, OCSP server is likely to be the performance bottleneck. The client side also need more cycles (DNS, networking, CPU etc.) to communicate with OCSP server.

OCSP stapling can save OCSP query cost of both OCSP server and clients. The certificate holder (the server), rather than the client, queries the certificate status from OCSP server in a regular interval. And the OCSP response can be used directly by client side in a "stapled" approach. Note that the server performance impact is pretty limited as the OCSP response (valid from hours to days) can be cached and used repeatedly in the valid period.

The performance impact has very bad side effect that browsers/clients may choose to disable certificate status checking or continue the TLS handshaking if the OCSP server is not accessible (for example, Firefox will continue the connection if it cannot connect to the CA, and the same for IE).

According to a report from CloudFlare, OCSP stapling can make SSL 30% faster.
The potential privacy impairment of OCSP request
In normal OCSP scenarios, when client requests a OCSP service, it exposes both the server (via server certificate entry) and itself (via IP address at least) to OCSP server, and hence disclose the browser behaviors. A way to verify validity without disclosing browsing behavior would be desirable for some groups of users.

OCSP stapling solved this issue because client won't need to query OCSP server any more, while server queries of OCSP status won't disclose any client information at all.
The limitation of the Captive Portal technique
The captive portal technique forces an HTTP client on a network to see a special web page (usually for authentication purposes) before using the Internet normally. In such environments, clients are not able to check OCSP status of the SSL/TLS certificate since all Internet access is blocked until authentication is successful.

There is no such limitation with OCSP stapling as OCSP status is stapled within the target SSL handing processes.

The deployment of OCSP Stapling

In Server side,

Apache HTTP Server supports OCSP stapling since version 2.3.3, with SSLUseStapling Directive
Nginx web server supports OCSP stapling since version 1.3.7/1.4.0, with ssl_stapling directive.
Microsoft IIS web server supports OCSP stapling since version 7. The feature is enabled by default. It is also enabled in Kerberos PKINIT.

In client side,

Beginning with Windows Server 2008, Kerberos clients will request OCSP stapling when using PKINIT by default.
Firefox, since version 25 (and this link).
IE (it is said OCSP stapling is supported since Vista, but I did not get the declare yet. IE 10 does support OSCP stapling according to my test.)
Google Chrome browser (no data so far when it get supported. Chrom version 30 does support it according to my test)
Opera browser (no date so far when it get supported. Opera 12.11 does support it according to my test)

TLS Vendors,

The OpenSSL project included support in their 0.9.8h since 2008, please also take care of the OCSP stapling vulnerability in OpenSSL.
Microsoft IIS/Schennel support OCSP stapling since version 7.
NSS supports OCSP stapling since version 3.15.

Why a SSL/TLS vendor need this feature

Because of performance, we cannot enable OCSP checking on TLS client side by default. Chrome had decide to disable OCSP checking because of performance. However, if check certificate status cannot be checked, there is a security issue if certificate has been revoked.
Support OCSP stapling in server side boost the performance and improve security of client sides who supports OCSP stapling.
OCSP based certificate status checking of TLS cannot work in a certain environment, for example in Captive Porta environment.
It's required to check certificate status for EV certificate.
Generally, Java based SSL web server, for example Tomcat/Glassfish, may also want to support OCSP stapling to better service its customers and compete with other platform, for example Apachs HTTP server, Nginx and Microsoft IIS.
OCSP stapling has been widely supported in the industry in both client and server.

Harness SSL and JSSE: Key Size Control

2013-11-08T04:51:00.000-08:00

Aged Bridge, Yulong River, Yangshuo, China

Why Key Size Concerns

The key size is an important security parameter to determine the strength of cryptography algorithms. For example, RSA keys with fewer than 1024 bits are considered forgeable. If RSA keys less than 1024 bits are used in X.509 certificates, the private keys used in these certificates can be derived and could allow an attacker to duplicate the certificates and use them fraudulently to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.

On August 14, 2012, Microsoft offered an update to Windows that restricts the use of certificates with RSA keys less than 1024 bits in length. As of October 9, 2012, the update is delivered via automatic update through the Microsoft update service. Microsoft recommends that customers apply the update at the earliest opportunity.

Since JDK 7u12, RSA keys less than 1024 bits in X.509 certificates are disabled. This is in line with the NIST recommendations to move to a minimum of 2048-bit keys by January 1, 2014. With this key size restriction, those who use X.509 certificates based on RSA keys less than 1024 bits will encounter compatibility issues with certification path building and validation. This key size restriction also impacts components that based on X.509 certificates, for example signed JAR verification, SSL/TLS transportation, HTTPS connections, etc.

According to the SSL surveys on November 03, 2013, none out of around 200,000 SSL-enabled web sites based on Alexa's list of most popular sites are using keys below 1024 bits. And according to another research targeted more wild scope, 0.96% (123,038) of 12,828,613 public live SSL hosts and 0.08% (8,459)of 10,216,363 live SSH hosts in the world are using a key size of 512 bits. In order to avoid any compatibility issue, applications are strongly recommended to renew their certificates with stronger keys. Or on your own risks, adjust the key size restriction property (jdk.certpath.disabledAlgorithms) to permit the smaller key sizes in case of any compatibility issue.

The impact on JSSE

Since JDK 7u12, RSA keys less than 1024 bits in X.509 certificates are disabled. This improvement directly impacts the behaviors of SunJSSE (Oracle JSSE provider) if certificate based authentication is used and the certification path contains RSA keys less than 1024 bits.

This restriction is limited via security property, "jdk.certpath.disabledAlgorithms" (See more "Java™ SE 7 Release Security Enhancements - Weak Cryptography Control" about this property).

jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024

This security property was introduced since JDK 7. There is no such handy approach in JDK 6 and 5.0 as the author wrote this blog.

Workarounds

If RSA keys less than 1024 bits in X.509 certificates have to be used in a certain circumstance, it is likely to run into compatibility because of this key size restriction. Please adjust the key size restriction property (jdk.certpath.disabledAlgorithms) to permit small key sizes. For example:

-    jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024
+    jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 512

Note that it is really risky. One must understand and control the potential risks in the application runtime environment before enforcing this workaround.

Best Practices

Put more weak key size restrictions. Of course, please consider the potential compatibility issues. For example, EC keys less than 160 bits and DSA keys less than 1024 bits may be also considered too weak to be acceptable.
```
   jdk.certpath.disabledAlgorithms=MD2, RSA keySize < 1024, \
                EC keySize < 160, DSA keySize < 1024
```
Upgrade your X.509 certificate to use strong keys. At present, the preferable security strength is 128-bits (128 bits AES/3072 bits RSA/256 bits ECC/3072 bits DSA keys). 2048 bits RSA/DSA keys is also acceptable according to NIST recommendations (See also a summary of the time frame, NIST Security Strength Time Frames).
Moving forward to use EC keys, which is more performance friendly.
Encourage to enforce more flexible algorithm (and key size) constraints in JSSE with javax.net.ssl.SSLParameters.setAlgorithmConstraints(AlgorithmConstraints).

Looking forward …

Enforce and improve algorithm and key constraints in more components other than PKI and JSSE.

In a long run, enforce more strict, wide and fine key size restriction by default, for example RSA and DSA keys must be great than 1024 bits when apply to data, and EC keys cannot be less than 224 bits.

NIST Security Strength Time Frames

2012-04-24T06:36:00.000-07:00

Security Strength Time Frames of NIST SP 800-57 Part 1
Security Strength	80		112		128	192	256
Security Strength	applying	processing	applying	processing	128	192	256

through 2010	acceptable	acceptable	acceptable	acceptable	acceptable	acceptable	acceptable
2011 through2013	deprecated	legacy use	acceptable	acceptable	acceptable	acceptable	acceptable
2014 through 2030	disallowed	legacy use	acceptable	acceptable	acceptable	acceptable	acceptable
2031 and Beyond	disallowed	legacy use	disallowed	legacy use	acceptable	acceptable	acceptable

Symmetric Algorithms	2TDEA		3TDEA		AES-128	AES-192	AES-256
FFC (e.g., DSA, D-H)	L = 1024 N = 160		L = 2048 N = 224		L = 3072 N = 256	L = 7680 N = 384	L = 15360 N = 512
IFC (e.g., RSA)	k = 1024		k = 2048		k = 3072	k = 7680	k = 15360
ECC (e.g.,ECDSA)	f = 160-223		f = 224-255		f = 256-383	f = 384-511	f = 512+
Digital Signatures and hash-only applications	SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-224, SHA-256, SHA-384, SHA-512		SHA-256, SHA-384, SHA-512	SHA-384, SHA-512	SHA-512
HMAC	SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512	SHA-224, SHA-256, SHA-384, SHA-512	SHA-256, SHA-384, SHA-512
Key Derivation Functions	SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512	SHA-224, SHA-256, SHA-384, SHA-512	SHA-256, SHA-384, SHA-512
Random Number Generation	SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512		SHA-1, SHA-224, SHA-256, SHA-384, SHA-512	SHA-224, SHA-256, SHA-384, SHA-512	SHA-256, SHA-384, SHA-512

Note (Reference from NIST SP 800-57 part 1, reversion 3):

"applying" and "processing" indicates whether cryptographic protection is being applied to data (e.g., encrypted), or whether cryptographically protected data is being processed (e.g., decrypted).
"Acceptable" indicates that the algorithm or key length is not known to be insecure.
"Deprecated" means that the use of an algorithm or key length that provides the indicated security strength may be used if risk is accepted; note that the use deprecated algorithms or key lengths may have restrictions.
"Disallowed" means that an algorithm or key length shall not be used for applying cryptographic protection.
"Legacy use" means that an algorithm or key length may be used because of its use in legacy applications (i.e., the algorithm or key length can be used to process cryptographically-protected data).

SSL Server Test Online Service

2012-01-26T18:20:00.000-08:00

The SSL Server Test Online Service performs a deep analysis of the configuration of any SSL web server on the public Internet. It's a great web service to test the quality of a SSL web server.

Another Challenge of Hash Functions

2011-12-30T06:00:00.000-08:00

No comments, please refer to the following docs: "Hash Table Collision Attacks Could Trigger DDoS on a Massive Scale | SecurityWeek.Com" and the research from n.runs AG

Search and Replace Strings in Files Under a Certain Directory

2011-12-29T18:52:00.000-08:00

As simple as:

$ find thePath -type f -name theFileNamePattern |xargs \
  perl -e "s/toBeReplacedString/newString/g" -pi

A proposal to countermeasure BEAST attack

2011-11-06T19:35:00.000-08:00

I posted the proposal to countermeasure the BEAST attack in Bug 665814 at Bugzilla@Mozilla. For quick reference, I copy it in the blog:

Xuelei Fan 2011-07-20 20:35:42 PDT Comment 59:

One significant drawback of the current proposed countermeasure
(sending empty application data packets) is that the empty packet
might be rejected by the TLS peer (see comments #30/#50/others:  MSIE
does not accept empty fragments, Oracle application server (non-JSSE)
cannot accept empty fragments, etc.)

We've been looking at a slightly different countermeasure that should
comply with the TLSv1.0/SSLv3.0 specifications, and likely won't break
implementations. Would you please review the following proposal?
If this is sound, this might avoid the empty packet issue, and the
switches necessary to configure it.

Looking at the spec of TLS, the block-ciphered structure is defined as:

       block-ciphered struct {
           opaque content[TLSCompressed.length];
           opaque MAC[CipherSpec.hash_size];
           uint8 padding[GenericBlockCipher.padding_length];
           uint8 padding_length;
       } GenericBlockCipher;

This implies that if the TLSCompressed.length is less than the cipher
block size, the MAC and padding data [1] will be used to construct the
first block.

The countermeasure:  instead of sending a completely empty fragment
before the supplied application data, send the first byte of
application data in a packet, followed by the remaining data from the
write call.  I think this should work because the TLS specification
requires content followed by the MAC.  Like the proposed solution,
you're still removing the adaptive guessing mechanism from the IV
calculation, but in a different way.

Assume here a cipher block size of 8.  Since the MAC effectively
randomizes the IV for successive SSL/TLS packets, if this first byte is
one of the bytes being guessed, that still leaves a search space of 28
(1 byte of data) * 256 (MAC) = 264, which is the same as the cipher
itself.  If the 1 byte is known plaintext, then the MAC will change the
IV for successive packets, and the attacker is not given the chance to
adapt the input Pj.

Implementations should readily accept 1 byte of application data, so
this will likely address the empty fragment issue, while complying with
the SSL 3.0 and TLS 1.0 specifications.

Looking forward to your comments.

Thanks,
Xuelei

[1] From a quick review of the standard hashes and ciphers of TLS
cipher suites, the CipherSpec.hash_size should be always bigger or
equal to block size. So the first block of an cipher operation should
not contain the padding data.

Java SE 7 New Features Ed 1 course

2011-08-26T18:17:00.000-07:00

The first of the Java SE 7 courses - D72697GC10 - Java SE 7 New Features Ed 1 is now on the public schedule on education.oracle.com.

JSSE Oracle Provider Default Disabled TLS Cipher Suites

2011-08-07T18:04:00.000-07:00

The following TLS cipher suites are supported by Oracle provider, SunJSSE. These cipher suites are disabled by default because of one of the following reasons:

obsoleted weak cipher suites
anonymous cipher suites
no encryption cipher suites (null cipher)
Kerberos cipher suites

Cipher suites for Kerberos (KRB5) need additional KRB5 service configuration, and these cipher suites are not common in practice.

You are NOT supposed to use these cipher suites unless you really know what you're doing from a standpoint.

Perference	Value	Description
1	0x00,0x6D	TLS_DH_anon_WITH_AES_256_CBC_SHA256
2	0xC0,0x19	TLS_ECDH_anon_WITH_AES_256_CBC_SHA
3	0x00,0x3A	TLS_DH_anon_WITH_AES_256_CBC_SHA
4	0x00,0x6C	TLS_DH_anon_WITH_AES_128_CBC_SHA256
5	0xC0,0x18	TLS_ECDH_anon_WITH_AES_128_CBC_SHA
6	0x00,0x34	TLS_DH_anon_WITH_AES_128_CBC_SHA
7	0xC0,0x16	TLS_ECDH_anon_WITH_RC4_128_SHA
8	0x00,0x18	SSL_DH_anon_WITH_RC4_128_MD5
9	0xC0,0x17	TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
10	0x00,0x1B	SSL_DH_anon_WITH_3DES_EDE_CBC_SHA
11	0xC0,0x3B	TLS_RSA_WITH_NULL_SHA256
12	0xC0,0x06	TLS_ECDHE_ECDSA_WITH_NULL_SHA
13	0xC0,0x10	TLS_ECDHE_RSA_WITH_NULL_SHA
14	0x00,0x02	SSL_RSA_WITH_NULL_SHA
15	0xC0,0x01	TLS_ECDH_ECDSA_WITH_NULL_SHA
16	0xC0,0x05	TLS_ECDH_RSA_WITH_NULL_SHA
17	0x00,0x15	TLS_ECDH_anon_WITH_NULL_SHA
18	0x00,0x01	SSL_RSA_WITH_NULL_MD5
19	0x00,0x09	SSL_RSA_WITH_DES_CBC_SHA
20	0x00,0x15	SSL_DHE_RSA_WITH_DES_CBC_SHA
21	0x00,0x12	SSL_DHE_DSS_WITH_DES_CBC_SHA
22	0x00,0x03	SSL_RSA_EXPORT_WITH_RC4_40_MD5
23	0x00,0x17	SSL_DH_anon_EXPORT_WITH_RC4_40_MD5
24	0x00,0x08	SSL_RSA_EXPORT_WITH_DES40_CBC_SHA
25	0x00,0x14	SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
26	0x00,0x11	SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
27	0x00,0x19	SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA
28	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
29	0x00,0x20	TLS_KRB5_WITH_RC4_128_SHA
30	0x00,0x24	TLS_KRB5_WITH_RC4_128_MD5
31	0x00,0x1F	TLS_KRB5_WITH_3DES_EDE_CBC_SHA
32	0x00,0x23	TLS_KRB5_WITH_3DES_EDE_CBC_MD5
33	0x00,0x1E	TLS_KRB5_WITH_DES_CBC_SHA
34	0x00,0x22	TLS_KRB5_WITH_DES_CBC_MD5
35	0x00,0x28	TLS_KRB5_EXPORT_WITH_RC4_40_SHA
36	0x00,0x2B	TLS_KRB5_EXPORT_WITH_RC4_40_MD5
37	0x00,0x26	TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
38	0x00,0x29	TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5

Note that the data was from the Java SE doc of SunJSSE provider.

Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

2011-07-31T04:09:00.000-07:00

Weak cryptographic algorithms can now be disabled in Java SE 7 release. The MD2 Message-Digest Algorithm was disabled by default in Sun PKIX provider and SunJSSE provider.

The MD2 algorithm is a cryptographic hash function developed by Ronald Rivest in 1989, and was published in 1992 as an Informational RFC (RFC 1319).; RFC 6149 moves RFC 1319/MD2 to historic status, "Since its publication, MD2 has been shown to not be collision-free, albeit successful collision attacks for properly implemented MD2 are not that damaging. Successful pre-image and second pre-image attacks against MD2 have been shown."

Although MD2 is no longer considered secure, it remains in use in public key infrastructures as part of certificates generated with MD2 and RSA. An a countermeasure of the vulnerability, Java SE has disabled MD2 algorithm in certification path building and validation.

You may wonder, Java SE has disabled MD2 algorithm in certification path building and validation in the latest releases and updates, what is the enhancement in Java SE 7?; Good question, NOT ONLY MD2, BUT ALSO MD4, MD5, or what else weak cryptographic algorithms, you can disable them in Java SE 7; and you also can disable cryptographic keys without enough strength key size. To control the usage of weak cryptographic algorithms, Java SE 7 introduces two new security properties, "jdk.certpath.disabledAlgorithms" and "jdk.tls.disabledAlgorithms".

The security property (and the syntax) of "jdk.certpath.disabledAlgorithms" is defined as:

# Algorithm restrictions for certification path (CertPath) processing
#
# In some environments, certain algorithms or key lengths may be undesirable
# for certification path building and validation.  For example, "MD2" is
# generally no longer considered to be a secure hash algorithm.  This section
# describes the mechanism for disabling algorithms based on algorithm name
# and/or key length.  This includes algorithms used in certificates, as well
# as revocation information such as CRLs and signed OCSP Responses.
#
# The syntax of the disabled algorithm string is described as this Java
# BNF-style:
#   DisabledAlgorithms:
#       " DisabledAlgorithm { , DisabledAlgorithm } "
#
#   DisabledAlgorithm:
#       AlgorithmName [Constraint]
#
#   AlgorithmName:
#       (see below)
#
#   Constraint:
#       KeySizeConstraint
#
#   KeySizeConstraint:
#       keySize Operator DecimalInteger
#
#   Operator:
#       <= | < | == | != | >= | >
#
#   DecimalInteger:
#       DecimalDigits
#
#   DecimalDigits:
#       DecimalDigit {DecimalDigit}
#
#   DecimalDigit: one of
#       1 2 3 4 5 6 7 8 9 0
#
# The "AlgorithmName" is the standard algorithm name of the disabled
# algorithm. See "Java Cryptography Architecture Standard Algorithm Name
# Documentation" for information about Standard Algorithm Names.  Matching
# is performed using a case-insensitive sub-element matching rule.  (For
# example, in "SHA1withECDSA" the sub-elements are "SHA1" for hashing and
# "ECDSA" for signatures.)  If the assertion "AlgorithmName" is a
# sub-element of the certificate algorithm name, the algorithm will be
# rejected during certification path building and validation.  For example,
# the assertion algorithm name "DSA" will disable all certificate algorithms
# that rely on DSA, such as NONEwithDSA, SHA1withDSA.  However, the assertion
# will not disable algorithms related to "ECDSA".
#
# A "Constraint" provides further guidance for the algorithm being specified.
# The "KeySizeConstraint" requires a key of a valid size range if the
# "AlgorithmName" is of a key algorithm.  The "DecimalInteger" indicates the
# key size specified in number of bits.  For example, "RSA keySize <= 1024"
# indicates that any RSA key with key size less than or equal to 1024 bits
# should be disabled, and "RSA keySize < 1024, RSA keySize > 2048" indicates
# that any RSA key with key size less than 1024 or greater than 2048 should
# be disabled. Note that the "KeySizeConstraint" only makes sense to key
# algorithms.
#
# Note: This property is currently used by Oracle's PKIX implementation. It
# is not guaranteed to be examined and used by other implementations.
#
# Example:
#   jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
jdk.certpath.disabledAlgorithms=MD2

And the security property of "jdk.tls.disabledAlgorithms" is defined as:

# Algorithm restrictions for Secure Socket Layer/Transport Layer Security
# (SSL/TLS) processing
#
# In some environments, certain algorithms or key lengths may be undesirable
# when using SSL/TLS.  This section describes the mechanism for disabling
# algorithms during SSL/TLS security parameters negotiation, including cipher
# suites selection, peer authentication and key exchange mechanisms.
#
# For PKI-based peer authentication and key exchange mechanisms, this list
# of disabled algorithms will also be checked during certification path
# building and validation, including algorithms used in certificates, as
# well as revocation information such as CRLs and signed OCSP Responses.
# This is in addition to the jdk.certpath.disabledAlgorithms property above.
#
# See the specification of "jdk.certpath.disabledAlgorithms" for the
# syntax of the disabled algorithm string.
#
# Note: This property is currently used by Oracle's JSSE implementation.
# It is not guaranteed to be examined and used by other implementations.
#
# Example:
#   jdk.tls.disabledAlgorithms=MD5, SHA1, DSA, RSA keySize < 2048

You are able to find the definition from java_home/jre/lib/security/java.security.
OK, let's look at more examples about how to control weak cryptographic algorithms and key strength.
MD5 is no longer acceptable where collision resistance is required such as digital signatures [RFC 6151]. However, there are still a lot of well-known certificates generated with MD5 based signature.
For RSA crypto-system, 512-bit keys no longer provide sufficient security for anything more than very short-term security needs [How large a key should be used in the RSA cryptosystem?]. RSA is widely used in the industry, for better interoperability, you may not be able to completely disable RSA crypto-system in your application. You may only accept strength enough RSA keys.
You may want to disable MD5 algorithms and RSA keys size less than 1024 bits in Sun PKIX provider. The security property may look like:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

For what ever reason, you may not like a particular TLS cipher suites, for example, "SSL_RSA_WITH_RC4_128_MD5/TLS_RSA_WITH_RC4_128_MD5". Of course, you can disable it in SunJSSE provider with:

jdk.tls.disabledAlgorithms=SSL_RSA_WITH_RC4_128_MD5

Yes, with these two security properties, you can control weak cryptographic algorithms and key sizes in Java VM globally. It is as you will!

Time of ECC Algorithms in Web Services?

2011-07-29T01:56:00.000-07:00

It's a question, the answer depends on your application deployment. The browser market share in the following pie may be a fact of your consideration. From previous posts, I learned that out of the major market players, only Opera does not support ECC TLS cipher suites yet.

Oracle Launches Java 7

2011-07-28T17:37:00.000-07:00

Source: www.oracle.com. Oracle Announces Availability of Java SE 7, you are able to download and try Java SE 7 right now.

You may also want to know Java™ SE 7 Release Security Enhancements. I may publish new post to introduce the new security features in the blog. Stay Tuned!

JSSE Oracle Provider Preference of TLS Cipher Suites

2011-07-23T20:32:00.000-07:00

Perference Order	Value	Description
1	0xC0,0x24	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
2	0xC0,0x28	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
3	0x00,0x3D	TLS_RSA_WITH_AES_256_CBC_SHA256
4	0xC0,0x26	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
5	0xC0,0x2A	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
6	0x00,0x6B	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
7	0x00,0x6A	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
8	0xC0,0x0A	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
9	0xC0,0x14	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
10	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
11	0xC0,0x05	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
12	0xC0,0x0F	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
13	0x00,0x39	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
14	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
15	0xC0,0x23	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
16	0xC0,0x27	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
17	0x00,0x3C	TLS_RSA_WITH_AES_128_CBC_SHA256
18	0xC0,0x25	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
19	0xC0,0x29	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
20	0x00,0x67	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
21	0x00,0x40	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
22	0xC0,0x09	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
23	0xC0,0x13	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
24	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
25	0xC0,0x04	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
26	0xC0,0x0E	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
27	0x00,0x33	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
28	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
29	0xC0,0x07	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
30	0xC0,0x11	TLS_ECDHE_RSA_WITH_RC4_128_SHA
31	0x00,0x05	SSL_RSA_WITH_RC4_128_SHA
32	0xC0,0x02	TLS_ECDH_ECDSA_WITH_RC4_128_SHA
33	0xC0,0x0C	TLS_ECDH_RSA_WITH_RC4_128_SHA
34	0xC0,0x08	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
35	0xC0,0x12	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
36	0x00,0x0A	SSL_RSA_WITH_3DES_EDE_CBC_SHA
37	0xC0,0x03	TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
38	0xC0,0x0D	TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
39	0x00,0x16	SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA
40	0x00,0x13	SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
41	0x00,0x04	SSL_RSA_WITH_RC4_128_MD5
42	0x00,0xFF	TLS_EMPTY_RENEGOTIATION_INFO_SCSV [1]

Note that the data was from the Java SE doc of SunJSSE provider.

[1] TLS_EMPTY_RENEGOTIATION_INFO_SCSV means that secure TLS renegotiation [RFC 5746] is supported.

Browser Safari Preference of TLS Cipher Suites

2011-07-23T20:01:00.000-07:00

Perference Order	Value	Description
1	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
2	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
3	0x00,0x05	TLS_RSA_WITH_RC4_128_SHA
4	0x00,0x0A	TLS_RSA_WITH_3DES_EDE_CBC_SHA
5	0xC0,0x13	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
6	0xC0,0x14	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
7	0xC0,0x09	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
8	0xC0,0x0A	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
9	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
10	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
11	0x00,0x13	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
12	0x00,0x04	TLS_RSA_WITH_RC4_128_MD5

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Safari 5.1.

Browser Opera Preference of TLS Cipher Suites

2011-07-23T19:51:00.000-07:00

Perference Order	Value	Description
1	0x00,0xFF	TLS_EMPTY_RENEGOTIATION_INFO_SCSV [1]
2	0x00,0x6B	TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
3	0x00,0x6A	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
4	0x00,0x69	TLS_DH_RSA_WITH_AES_256_CBC_SHA256
5	0x00,0x68	TLS_DH_DSS_WITH_AES_256_CBC_SHA256
6	0x00,0x3D	TLS_RSA_WITH_AES_256_CBC_SHA256
7	0x00,0x39	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
8	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
9	0x00,0x37	TLS_DH_RSA_WITH_AES_256_CBC_SHA
10	0x00,0x36	TLS_DH_DSS_WITH_AES_256_CBC_SHA
11	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
12	0x00,0x67	TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
13	0x00,0x40	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
14	0x00,0x3F	TLS_DH_RSA_WITH_AES_128_CBC_SHA256
15	0x00,0x3E	TLS_DH_DSS_WITH_AES_128_CBC_SHA256
16	0x00,0x3C	TLS_RSA_WITH_AES_128_CBC_SHA256
17	0x00,0x33	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
18	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
19	0x00,0x31	TLS_DH_RSA_WITH_AES_128_CBC_SHA
20	0x00,0x30	TLS_DH_DSS_WITH_AES_128_CBC_SHA
21	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
22	0x00,0x05	TLS_RSA_WITH_RC4_128_SHA
23	0x00,0x04	TLS_RSA_WITH_RC4_128_MD5
24	0x00,0x13	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
25	0x00,0x0D	TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
26	0x00,0x16	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
27	0x00,0x10	TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
28	0x00,0x0A	TLS_RSA_WITH_3DES_EDE_CBC_SHA

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Opera 11.50.

[1] TLS_EMPTY_RENEGOTIATION_INFO_SCSV means the browser supports secure TLS renegotiation [RFC 5746].

Google Chrome Preference of TLS Cipher Suites

2011-07-23T19:37:00.000-07:00

Perference Order	Value	Description
1	0xC0,0x0A	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
2	0xC0,0x14	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
3	0x00,0x88	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
4	0x00,0x87	TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
5	0x00,0x39	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
6	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
7	0xC0,0x0F	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
8	0xC0,0x05	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
9	0x00,0x84	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
10	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
11	0xC0,0x07	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
12	0xC0,0x09	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
13	0xC0,0x11	TLS_ECDHE_RSA_WITH_RC4_128_SHA
14	0xC0,0x13	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
15	0x00,0x45	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
16	0x00,0x44	TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
17	0x00,0x66	TLS_DHE_DSS_WITH_RC4_128_SHA
18	0x00,0x33	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
19	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
20	0xC0,0x0C	TLS_ECDH_RSA_WITH_RC4_128_SHA
21	0xC0,0x0e	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
22	0xC0,0x02	TLS_ECDH_ECDSA_WITH_RC4_128_SHA
23	0xC0,0x04	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
24	0x00,0x96	TLS_RSA_WITH_SEED_CBC_SHA
25	0x00,0x41	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
26	0x00,0x04	TLS_RSA_WITH_RC4_128_MD5
27	0x00,0x05	TLS_RSA_WITH_RC4_128_SHA
28	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
29	0xC0,0x08	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
30	0xC0,0x12	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
31	0x00,0x16	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
32	0x00,0x13	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
33	0xC0,0x0d	TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
34	0xC0,0x03	TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
35	0xFE,0xFF	SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
36	0x00,0x0a	TLS_RSA_WITH_3DES_EDE_CBC_SHA

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Google Chrome 14.0.

Internet Explorer Preference of TLS Cipher Suites

2011-07-23T19:22:00.000-07:00

Perference Order	Value	Description
1	0x00,0x3C	TLS_RSA_WITH_AES_128_CBC_SHA256
2	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
3	0x00,0x3D	TLS_RSA_WITH_AES_256_CBC_SHA256
4	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
5	0x00,0x05	TLS_RSA_WITH_RC4_128_SHA
6	0x00,0x0A	TLS_RSA_WITH_3DES_EDE_CBC_SHA
7	0xC0,0x27	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
8	0xC0,0x13	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
9	0xC0,0x14	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
10	0xC0,0x2B	TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
11	0xC0,0x23	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
12	0xC0,0x2C	TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
13	0xC0,0x24	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
14	0xC0,0x09	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
15	0xC0,0x0A	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
16	0x00,0x40	TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
17	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
18	0x00,0x6A	TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
19	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
20	0x00,0x13	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
21	0x00,0x04	TLS_RSA_WITH_RC4_128_MD5

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Internet Explorer (IE) 9.0.

Firefox Preference of TLS Cipher Suites

2011-07-23T19:06:00.000-07:00

Order	Value	Description
1	0xC0,0x0A	TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
2	0xC0,0x14	TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
3	0x00,0x88	TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
4	0x00,0x87	TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
5	0x00,0x39	TLS_DHE_RSA_WITH_AES_256_CBC_SHA
6	0x00,0x38	TLS_DHE_DSS_WITH_AES_256_CBC_SHA
7	0xC0,0x0F	TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
8	0xC0,0x05	TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
9	0x00,0x84	TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
10	0x00,0x35	TLS_RSA_WITH_AES_256_CBC_SHA
11	0xC0,0x07	TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
12	0xC0,0x09	TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
13	0xC0,0x11	TLS_ECDHE_RSA_WITH_RC4_128_SHA
14	0xC0,0x13	TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
15	0x00,0x45	TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
16	0x00,0x44	TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
17	0x00,0x33	TLS_DHE_RSA_WITH_AES_128_CBC_SHA
18	0x00,0x32	TLS_DHE_DSS_WITH_AES_128_CBC_SHA
19	0xC0,0x0C	TLS_ECDH_RSA_WITH_RC4_128_SHA
20	0xC0,0x0E	TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
21	0xC0,0x02	TLS_ECDH_ECDSA_WITH_RC4_128_SHA
22	0xC0,0x04	TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
23	0x00,0x96	TLS_RSA_WITH_SEED_CBC_SHA
24	0x00,0x41	TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
25	0x00,0x04	TLS_RSA_WITH_RC4_128_MD5
26	0x00,0x05	TLS_RSA_WITH_RC4_128_SHA
27	0x00,0x2F	TLS_RSA_WITH_AES_128_CBC_SHA
28	0xC0,0x08	TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
29	0xC0,0x12	TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
30	0x00,0x16	TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
31	0x00,0x13	TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
32	0xC0,0x0D	TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
33	0xC0,0x03	TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
34	0xFE,0xFF	SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
35	0x00,0x0A	TLS_RSA_WITH_3DES_EDE_CBC_SHA

Note that the data was from the observation of the TLS ClientHello message when visiting a HTTPS web site from Firefox 5.0.