Java Security and Networking

by Smullan-Oracle - Slides for my JavaOne 2014 session on "Understanding the New JDK 8 Security Features"

Smullan-Oracle — Thu, 02 Oct 2014 16:24:09 +0000

Here are the slides for my JavaOne 2014 session on Understanding the New JDK 8 Security Features.

Thanks to all who attended the session. I hope it was very useful.

by Smullan-Oracle - Version 5.0 of the Java Secure Coding Guidelines now available!

Smullan-Oracle — Mon, 14 Apr 2014 19:21:58 +0000

A new version of the Java Secure Coding Guidelines is now available at http://www.oracle.com/technetwork/java/seccodeguide-139067.html

This version has many updates, including:

Additional information for some of the new Java SE 8 features
Several new guidelines and examples
A new appendix covering the Java Native Interface
A new symbolic naming for sections
Several formatting changes

These guidelines contain coding patterns and best practices that are extremely useful for building robust and secure Java applications.

by Smullan-Oracle - How to use the XML Signature secure validation mode

Smullan-Oracle — Thu, 13 Mar 2014 13:52:16 +0000

In JDK 7u25, we introduced a new secure validation mode for XML Signatures. This mode is designed to protect you from XML Signatures that contain potentially hostile constructs that could cause denial-of-service or other types of security issues.

The good news is that if you run your application with a SecurityManager, the secure validation mode is enabled by default, and there is no further action required.

Otherwise, a new property with the name org.jcp.xml.dsig.secureValidation has been defined to allow applications to enable the mode.

The property can be set by an application by calling the setProperty method of the javax.xml.crypto.dsig.dom.DOMValidateContext class with the name of the property above and a Boolean value. For example:

    DOMValidateContext context = new DOMValidateContext(key, element);
    context.setProperty("org.jcp.xml.dsig.secureValidation", Boolean.TRUE);

The property should be set before you validate an XML Signature. When set to true, this property instructs the implementation to process XML signatures more securely. This will set limits on various XML signature constructs to avoid conditions such as denial-of-service attacks. Specifically, it enforces the following restrictions:

Forbids use of the XSLT Transform
Restricts the number of SignedInfo or Manifest References to 30 or less
Restricts the number of Reference Transforms to 5 or less
Forbids the use of MD5 related signature or mac algorithms
Ensures that Reference Ids are unique to help prevent signature wrapping attacks
Forbids Reference URIs of type http or file
Does not allow a RetrievalMethod to reference another RetrievalMethod

The feature is based on a similar validation mode that was included in version 1.5.0 of Apache Santuario XML Security. The JDK implementation is based on Apache Santuario.

This mode is also in the soon to be released JDK 8.

by Weijun - A Bug in Kerberos used by Java's HTTP

Weijun — Fri, 28 Feb 2014 03:42:02 +0000

Sorry, I didn't notice a thread on Oracle's forum until recently JDK-8028351 was reported to us directly. After some investigation, the bug is resolved in 7u60/8. Hopefully it's not too late for our customers.

A web page that is behind "Windows Authentication" is in fact protected by Kerberos and NTLM, and is accessible whichever auth scheme a client supports. In JDK 7, Kerberos works out-of-the-box on a Windows machine that already joins a domain (well, not exactly, see below), so it's always tried first. However, without the allowtgtsessionkey registry key being set, Java still needs a password to login. There is no way to get this password (unless you program JAAS directly) so Java tries the empty password. Obviously, the KDC (Windows domain controller) does not like it and blocks the user if it's tried multiple times.

The thread mentions the .java.login.config trick. When Java wants to use that file but cannot find it, it just fails without trying to login at all. The bug report mentions that disabling kerberos pre-authentication is also a workaround. In this case, no encrypted timestamp is sent so the KDC has no chance to know the client does not have the correct password.

In all these cases, Kerberos always fails and Java falls back to NTLM and the web page is still reached. However, the terrible thing about the empty password case is that you can read the page when you first access it, but if you access it again and again, your account is finally blocked and even NTLM does not work anymore.

by Xuelei Fan - Use Braces Even For Single Line Statement

Xuelei Fan — Mon, 24 Feb 2014 22:04:00 +0000

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!

by Xuelei Fan - JEP 115: AES-GCM CipherSuites in JDK 8

Xuelei Fan — Sun, 19 Jan 2014 06:22:00 +0000

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!

by Xuelei Fan - JEP 114: TLS SNI Extension - Virtual Servers Dispatcher

Xuelei Fan — Thu, 02 Jan 2014 22:20:00 +0000

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

by Xuelei Fan - JEP 114: TLS SNI Extension - Typical User Cases

Xuelei Fan — Thu, 02 Jan 2014 21:12:00 +0000

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.

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

Xuelei Fan — Thu, 02 Jan 2014 02:01:00 +0000

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

by Xuelei Fan - JEP 114: TLS SNI Extension - SunJSSE Behavior Changes

Xuelei Fan — Thu, 02 Jan 2014 01:46:00 +0000

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

by Xuelei Fan - TLS Server Name Indication Extension and Unrecognized_name

Xuelei Fan — Tue, 03 Dec 2013 20:45:00 +0000

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

by Smullan-Oracle - How to determine if a signed JAR is timestamped

Smullan-Oracle — Tue, 03 Dec 2013 13:39:18 +0000

Applying a timestamp when you sign a JAR is strongly recommended, as it allows you to prove that you signed the JAR during the time interval that your code signing certificate was still valid. This allows your JAR to be validated after the certificate expires thereby prolonging the lifetime of your application. There's really no good reason you should not apply a timestamp, and we are encouraging all developers to do that as we introduce stricter applet/RIA restrictions in JDK 7u51.

To sign a JAR with a timestamp, use the -tsa option of the jarsigner utility, as follows:

    jarsigner -tsa http://example.tsa.url jar alias

where "http://example.tsa.url" is an example of a URL of the Time Stamp Authority (TSA). Do an internet search for "timestamp server URL" to find TSA servers that you can use.

You can use the jarsigner utility to determine if a signed JAR has been timestamped as follows:

    jarsigner -verify -verbose -certs signed.jar

where signed.jar is the name of your signed JAR. If it is timestamped, the output will include lines of the following indicating the time it was signed:

    [entry was signed on 8/2/13 3:48 PM]

If the JAR is not timestamped, the output will not include those lines. Currently, the -certs option only prints the contents of the code signer's certificate chain, and not the Time Stamp Authority's (TSA) chain. However, there is an open RFE to add that functionality.

by Xuelei Fan - Understanding of OCSP Stapling

Xuelei Fan — Tue, 12 Nov 2013 23:33:00 +0000


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.

by Xuelei Fan - Harness SSL and JSSE: Key Size Control

Xuelei Fan — Fri, 08 Nov 2013 04:51:00 +0000

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.

by Smullan-Oracle - JEP 124: Enhance the Certificate Revocation-Checking API

Smullan-Oracle — Fri, 01 Nov 2013 14:09:41 +0000

Revocation checking is the mechanism to determine the revocation status of a certificate. If it is revoked, it is considered invalid and should not be used. Currently as of JDK 7, the PKIX implementation of java.security.cert.CertPathValidator includes a revocation checking implementation that supports both OCSP and CRLs, the two main methods of checking revocation. However, there are very few options that allow you to configure the behavior. You can always implement your own revocation checker, but that's a lot of work.

JEP 124 (Enhance the Certificate Revocation-Checking API) is one of the 11 new security features in JDK 8. This feature enhances the java.security.cert API to support various revocation settings such as best-effort checking, end-entity certificate checking, and mechanism-specific options and parameters. Let's describe each of these in more detail and show some examples.

The features are provided through a new class named PKIXRevocationChecker. A PKIXRevocationChecker instance is returned by a PKIX CertPathValidator as follows:

CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
PKIXRevocationChecker prc = (PKIXRevocationChecker)cpv.getRevocationChecker();

You can now set various revocation options by calling different methods of the returned PKIXRevocationChecker object. For example, the best-effort option (called soft-fail) allows the revocation check to succeed if the status cannot be obtained due to a network connection failure or an overloaded server. It is enabled as follows:

prc.setOptions(Enum.setOf(Option.SOFT_FAIL));

When the SOFT_FAIL option is specified, you can still obtain any exceptions that may have been thrown due to network issues. This can be useful if you want to log this information or treat it as a warning. You can obtain these exceptions by calling the getSoftFailExceptions method:

List<CertPathValidatorException> exceptions = prc.getSoftFailExceptions();

Another new option called ONLY_END_ENTITY allows you to only check the revocation status of the end-entity certificate. This can improve performance, but you should be careful using this option, as the revocation status of CA certificates will not be checked. To set more than one option, simply specify them together, for example:

prc.setOptions(Enum.setOf(Option.SOFT_FAIL, Option.ONLY_END_ENTITY));

By default, PKIXRevocationChecker will try to check the revocation status of a certificate using OCSP first, and then CRLs as a fallback. However, you can switch the order using the PREFER_CRLS option, or disable the fallback altogether using the NO_FALLBACK option. For example, here is how you would only use CRLs to check the revocation status:

prc.setOptions(Enum.setOf(Option.PREFER_CRLS, Option.NO_FALLBACK));

There are also a number of other useful methods which allow you to specify various options such as the OCSP responder URI, the trusted OCSP responder certificate, and OCSP request extensions. However, one of the most useful features is the ability to specify a cached OCSP response with the setOCSPResponse method. This can be quite useful if the OCSPResponse has already been obtained, for example in a protocol that uses OCSP stapling.

After you have set all of your preferred options, you must add the PKIXRevocationChecker to your PKIXParameters object as one of your custom CertPathCheckers before you validate the certificate chain, as follows:

PKIXParameters params = new PKIXParameters(keystore);
params.addCertPathChecker(prc);
CertPathValidatorResult result = cpv.validate(path, params);

Early access binaries of JDK 8 can be downloaded from http://jdk8.java.net/download.html

by Smullan-Oracle - Slides for my JavaOne session: "Using the New JDK 8 Security Features"

Smullan-Oracle — Wed, 25 Sep 2013 17:19:58 +0000

Thanks to everyone who attended my talk yesterday on "Using the New JDK 8 Security Features". Here are the slides for my session for those that could not attend or would like a copy for further reference: CON_7932_Mullan.pdf.

by Smullan-Oracle - JEP 131: PKCS#11 Crypto Provider for 64-bit Windows

Smullan-Oracle — Mon, 26 Aug 2013 18:17:19 +0000

JEP 131 (PKCS#11 Crypto Provider for 64-bit Windows) is another of the 11 new security features funded and targeted to JDK 8.

PKCS #11 is a standard that defines a platform-independent API to cryptographic tokens like smart cards and hardware security modules. Oracle's JDK currently supports PKCS #11 on Solaris (SPARC and x86), Linux (32-bit and 64-bit), and Windows (32-bit). PKCS #11 support is provided via a JCA provider which is simply a bridge to the native PKCS #11 library. This allows developers to use the standard Java Cryptography APIs and take advantage of the PKCS #11 functionality without having to change their applications. Support for Solaris is configured out-of-the-box, but some additional configuration is required on the other platforms.

JEP 131 adds PKCS #11 support for 64-bit Windows. To use the provider, additional configuration is required that specifies the location of the native PKCS #11 library along with additional directives as documented in the Java PKCS#11 Reference Guide.

A PKCS #11 provider can be configured statically in the java.security file, ex:

     security.provider.1=sun.security.pkcs11.SunPKCS11 pkcs11.cfg

or dynamically in code, ex:

    Provider p = new sun.security.pkcs11.SunPKCS11(“pkcs11.cfg”);
    Security.addProvider(p);

Early access binaries of JDK 8 can be downloaded at http://jdk8.java.net/download.html

by Smullan-Oracle - JEP 130: SHA-224 Message Digests

Smullan-Oracle — Mon, 19 Aug 2013 19:50:07 +0000

JEP 130 (SHA-224 Message Digests) is one of the 11 new security features funded and targeted to JDK 8.

The SHA-2 cryptographic hash family includes the SHA-224, SHA-256, SHA-384, and SHA-512 algorithms. The JDK already includes support for SHA-256, SHA-384, and SHA-512. JEP 130 completes the JDK support for the SHA-2 family.

SHA-224 is basically a truncated version of SHA-256. The calculated hash is 224 bits (instead of 256) and is computed with a different initial value than SHA-256. It provides 112 bits of security (which is the same as two-key Triple DES). Use SHA-224 when your cryptographic application provides no more than 112 bits of security or you need the extra savings of the smaller hash size.

Here are some code examples using SHA-224:

// Create a SHA-224 java.security.MessageDigest
MessageDigest md = MessageDigest.getInstance(“SHA-224”);

// Create a SHA224withRSA java.security.Signature
Signature sig = Signature.getInstance(“SHA224withRSA”);
// Create a SHA224withECDSA java.security.Signature
Signature esig = Signature.getInstance(“SHA224withECDSA”);

// Create an HmacSHA224 javax.crypto.KeyGenerator
KeyGenerator kg = KeyGenerator.getInstance(“HmacSHA224”);

// Create an HmacSHA224 javax.crypto.Mac
Mac mac = Mac.getInstance(“HmacSHA224”);

// Create an RSA/ECB/OAEPWithSHA-224ANDMGF1PADDING javax.crypto.Cipher
Cipher c = Cipher.getInstance(“RSA/ECB/OAEPWithSHA-224ANDMGF1PADDING”);

Early access binaries of JDK 8 can be downloaded at http://jdk8.java.net/download.html

by Smullan-Oracle - I will be speaking at JavaOne 2013 on "Using the New JDK 8 Security Features"

Smullan-Oracle — Thu, 15 Aug 2013 14:29:28 +0000

Hi all,

I will be presenting a session at this year's JavaOne 2013 (San Francisco) on "Using the New JDK 8 Security Features". This will be an informative session describing the 11 new security features (aka "JEPs") and will include plenty of code samples.

Over the next few weeks, I will be posting new blog entries with more details of each of these features. So stay tuned for more information or attend my session if you are coming to JavaOne!

by Weijun - Re-read [capaths]

Weijun — Wed, 24 Apr 2013 10:06:37 +0000

Discovery

[capaths] does not have the same meaning in JDK and the rest of the world (See references at the bottom).

In JDK, each line describes a relation and one needs to consult multiple relations to create a path. In the rest of the world, each line itself is a path.

So, suppose shared keys are between A and B, B and C, and, C and D. For a client in A, in order to visit a service in D, it needs A -> B -> C -> D.

In JDK, the capaths is written as

A = {
   B = .     # I can go B directly
   C = B     # To go C, I need to go B first
   D = C     # To go D, I need to go C first
}

In the rest of the world, it's

A = {
   B = .    # I can go B directly
   C = B    # To go C, I need to go B. Done
   D = B C  # To go D, I need to go B and then C. Done
}

and the last line is often written into multiple lines

D = B
D = C

although this becomes not so clear.

Problem

When a sub-tag has multiple values (either on a single line or multiple lines), it is interpreted differently.

A = {
   B = C D
}

For the rest of the world, it's a series of realms that the client needs to walk thru to the server. The client in A needs to go to C and then D to reach B
For Java, it's a list of alternatives that can lead to the server. In order for a client A to go to B, it must reach C or D first.

and the Java way is wrong.

Fix

There will be a behavior change anyway, but we must preserve as much as we can. That is to say, if there are no sub-tags with multiple values, we do the same as before. If there are, we should treat it correctly like the rest of the world.

Here is a way to unify the two different designs. For

cRealm = {
   sRealm = A ... B
}

"A ... B" should be regarded as a (possibly partial) path from cRealm to sRealm.

The key point here is the "possibly partial" modifier. By partial, it means the path could be only the tail, i.e. you need to find zero or more realms "C ... D" to build the full path "C ... D A ... B", where C directly shares keys with cRealm.

Now, the rest of the world always gives the full path, and JDK gives the shortest-available partial path. Unified.

How to build the full path then? Given the previous example

A = {
   B = .     # I can go B directly
   C = B     # To go C, I need to go B first
   D = C     # To go D, I need to go C first
}

From D = C, we get partial path for A to D as C -> D. Here A cannot directly go to C, so we start building. We have C = B, we have a partial path for A to C as B -> C. Merging the partial paths give a longer path from A to D being B -> C -> D. B = . shows B is a direct link, and we have the full path.

There are still some rules:

. can only appear in a single-valued sub-tag
No loops
No dups in multiple values of the same subtag
Neither cRealm nor sRealm can appear in path

If any rule is broken, the output is undefined. The current implementation is that the value is ignored.

Workaround

From the discussion above, we can say that previous JDK releases still work if there is no multiple-value sub-tags. This means you can always rewrite "A = B C" to two lines "A = C" and "C = B". Both the old JDK and future JDK will recognize it. Unfortunately, the rest of the world does not like this format, say, MIT's krb5.

And, the Hierarchy Case

The hierarchy algorithm is also wrong: When two realms have completely no common components, Java now regards it as a direct link. However, the correct path should go down to the last component of cRealm, and then go up from the last component of sRealm to the full sRealm.

For example, a path from A.COM to B.ORG will be A.COM -> COM -> ORG -> B.ORG.

References

by Weijun - A Test for 2013

Weijun — Sat, 05 Jan 2013 03:01:57 +0000

I want to see if this blog and its commenting system still works.

Update: Aha, I have to manually approve each comment.

by Xuelei Fan - NIST Security Strength Time Frames

Xuelei Fan — Tue, 24 Apr 2012 06:36:00 +0000

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

by Xuelei Fan - SSL Server Test Online Service

Xuelei Fan — Thu, 26 Jan 2012 18:20:00 +0000

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.

by Xuelei Fan - Another Challenge of Hash Functions

Xuelei Fan — Fri, 30 Dec 2011 06:00:00 +0000

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

by Xuelei Fan - Search and Replace Strings in Files Under a Certain Directory

Xuelei Fan — Thu, 29 Dec 2011 18:52:00 +0000

As simple as:

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

by Weijun - Old Versions of Cisco AnyConnect and Java 6u29

Weijun — Mon, 07 Nov 2011 18:33:54 +0000

In Oracle Java 6u14, we introduced blacklist support. The blacklist "is a list of signed jars that contain serious security vulnerabilities that can be exploited by untrusted applets or applications". Once a signed jar is listed here, it will never be loaded. Recently, in 6u29, we added more entries into the list. Some of them are for the Cisco AnyConnect Mobility Client, and you can see why this is a very serious problem on Cisco's own support page.

Unfortunately, it seems quite a lot of AnyConnect servers out there are not updated to the latest version. Some are not that ancient, which do no harm to a Windows client, but can still be exploited if the client is on a non-Windows system like Linux or Apple MacOS X. Read the Cisco page above for details.

Therefore, 6u29 users will see an error when trying to install AnyConnect clients from such a server, for example, this report to Cisco. AnyConnect admins, please update your server as soon as possible.

Please note that this is not a vulnerability in Oracle's JRE. On the contrary, 6u29 protects you from any possible exploit of this issue to damage your system.

by Xuelei Fan - A proposal to countermeasure BEAST attack

Xuelei Fan — Sun, 06 Nov 2011 19:35:00 +0000

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.

by Xuelei Fan - Java SE 7 New Features Ed 1 course

Xuelei Fan — Fri, 26 Aug 2011 18:17:00 +0000

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.

by Xuelei Fan - JSSE Oracle Provider Default Disabled TLS Cipher Suites

Xuelei Fan — Sun, 07 Aug 2011 18:04:00 +0000

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.

by Xuelei Fan - Java™ SE 7 Release Security Enhancements - Weak Cryptography Control

Xuelei Fan — Sun, 31 Jul 2011 04:09:00 +0000

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!

by Xuelei Fan - Time of ECC Algorithms in Web Services?

Xuelei Fan — Fri, 29 Jul 2011 01:56:00 +0000

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.

by Xuelei Fan - Oracle Launches Java 7

Xuelei Fan — Thu, 28 Jul 2011 17:37:00 +0000

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!

by Xuelei Fan - JSSE Oracle Provider Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 20:32:00 +0000

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.

by Xuelei Fan - Browser Safari Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 20:01:00 +0000

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.

by Xuelei Fan - Browser Opera Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 19:51:00 +0000

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

by Xuelei Fan - Google Chrome Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 19:37:00 +0000

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.

by Xuelei Fan - Internet Explorer Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 19:22:00 +0000

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.

by Xuelei Fan - Firefox Preference of TLS Cipher Suites

Xuelei Fan — Sat, 23 Jul 2011 19:06:00 +0000

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.

by Weijun - Kerberos Programming on Windows

Weijun — Mon, 23 May 2011 21:09:23 +0000

This article was published as http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html some time in 2009, but the original link does not exist anymore. It's copied here mainly for archive purpose and a lot of thing have changed since. I might or might not update it.

This article talks about Kerberos programming on Windows, especially in a Kerberos environment of Windows Active Directory (AD), with all clients and services running on Windows platforms in AD domains. The typical client/server environment described here is Windows XP and Windows Server 2003. We may talk about other scenarios if necessary.

Note: Kerberos programming in Java is done through the JGSS-API. Please make sure you're familiar with basic JGSS concepts and programming styles. Read the Java SE documentation of JGSS section first.

Basic Setup

There are three roles in Kerberos: the KDC, the client, and the server. We're talking about writing Java programs on the client or the server, or both.

First, you must have a Windows Active Directory server running, and all clients and servers joining this AD domain. In order for Java to recognize this environment, extra configurations are needed on both the client and the server side.

Realm and KDC Info

There are two ways to inform a Java program what the Kerberos realm and KDC are:

krb5.ini configuration file
- krb5.ini should contain the realm info and hostname of the KDC for this realm. For example:
```
[libdefaults]
default_realm = MY.REALM
realms]
MY.REALM = {
    kdc = kdc.my.realm
}
```
- The file location can be specified by system property java.security.krb5.conf. Otherwise, Java will try to locate this file in these locations (ordered by):
  1. %JAVA_HOME%/lib/security/krb5.conf
  2. %WINDOWS_ROOT%/krb5.ini
System properties java.security.krb5.realm and java.security.krb5.kdc.

Please note that these two configurations cannot be provided at the same time.

In JDK 7, when neither of the two ways above is used. Java will try to read the realm and KDC settings from Windows environment variables.

JAAS login config file

Since JGSS uses JAAS to acquire the initial Kerberos credentials, a JAAS login config file is always needed. The location of this file should be specified inside the java.security file or using the system property java.security.auth.login.config. Read here for details.

The login module required here is com.sun.security.auth.module.Krb5LoginModule, we'll talk about the details in later sections for the client side and the server side respectively.

In JDK 7, when no JAAS login config file is specified, pre-defined entries are created for the client side and server side respectively:

For the client side:

com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule
    required
    useTicketCache=true
    doNotPrompt=false
};

For the server side:

com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule
    required
    useKeyTab=true
    storeKey=true
    doNotPrompt=true
    isInitiator=false;
};

TGT accessibility

By default, Windows does not allow the session key of a TGT to be accessed. Please add the following registry key on the client side, so that the session key for TGT is accessible and Java can use it to acquire additional service tickets.

For Windows XP and Windows 2000, the registry key and value should be:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

For Windows 2003 and Windows Vista, the registry key and value should be:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Value Name: allowtgtsessionkey
Value Type: REG_DWORD
Value: 0x01

Programming the client side

The Initial Credentials

JGSS uses JAAS to get the initial credentials (in the case of Kerberos, the initial TGT). Java tries to get it in this order:

File credentials cache (%HOME%\krb5cc_userid for Windows)
Native credentials cache (LSA, or Local Security Authority, for Windows)
Read key from a keytab file and use AS_REQ to acquire credentials from KDC
Prompt for username and password and use AS_REQ to acquire credentials from KDC

Not all of them will be tried. The actual behavior depends on what's specified in Krb5LoginModule of your JAAS long config file:

If useTicketCache=true, 1, 2 will be tried
If useKeyTab=true, 3 will be tried
If doNotPrompt=true, 4 will not be tried

Note that all of these parameters' default values are false. They can be specified in any combination.

The most common case on a Windows client is that the user has already logged on to the system as an AD account, which means there's a native credential cached in LSA. This goes the 2nd way above. However, if the client platform is not Windows, or, although it's Windows but the user is not logged on as an AD account, there's no LSA cache available. Please check the availability of an LSA cache using the MS klist.exe tool (Attention: not the klist.exe comes with Java) or kerbtray.exe (for GUI lovers) provided by Microsoft.

Therefore, the typical JAAS login config file for client should look like this:

com.sun.security.jgss.krb5.initiate {
    com.sun.security.auth.module.Krb5LoginModule
    required
    useTicketCache=true
    doNotPrompt=false
};

This means the ticket cache (LSA) should be used automatically, doNotPrompt=false means when the cache is not available, username and password will be prompted using a CallbackHandler.

Attention: Unfortunately, there's no way to inform Java that LSA should be looked up ahead of the file cache. So, you should always make sure that the %HOME%\krb5cc_userid file does not exist when you want to use the LSA. This file is generated by the kinit.exe command, so don't run it if you wish to use the credentials from the LSA cache.

On the other hand, if you want your program working even if the LSA cache is not available, normally you choose one of the following:

Run kinit.exe (comes with Java) before running the Java app, this will create a credentials cache file %HOME%\krb5cc_userid, which goes the 1st way. The JAAS login config file is the same as the typical style. If you create the credentials cache file into a different pathname, specify the location using ticketCache="c:/path/to/file" inside the JAAS login config file.
Feed username and password to the Java program directly using a CallbackHandler, which goes the 4th way. Please specify doNotPrompt=false in the JAAS login config file. You can provide an instance of CallbackHandler at the creation time of LoginContext if the JAAS call style is used (see the next section), or Java will create a new instance of the type specified by the security property auth.login.defaultCallbackHandler. For direct JGSS without JAAS, if this security property is not given, the internal text-based callback handler will be used.

JGSS calls

There are 2 ways to start JGSS:

Use JAAS to generate a Subject that contains the initial credentials, and call JGSS from this subject:
```
LoginContext lc = new LoginContext(name, callback);
lc.login(); lc.commit();
Subject.doAs(lc.getSubject(), /* JGSS-API calls... */)
```
In this case, you can choose whatever login entry name in the JAAS login config file. Read more for details.
Direct JGSS:
```
/* JGSS-API calls... */
```
In this case, the JAAS config file's entry name MUST be the standard entry name (com.sun.security.jgss.krb5.initiate), and you must set -Djavax.security.auth.useSubjectCredsOnly=false on the Java command line. Read here for details.

Other APIs that use JGSS

In Java, there are 2 other APIs that call JGSS-API internally.

SASL using JGSS as the mechanism. Read here and here for details.
HTTP/SPNEGO. Read here for details. Please note that the system property javax.security.auth.useSubjectCredsOnly is now default false for HTTP/SPNEGO now.

Please note that when initial credentials are not available from the cache (neither from a file nor the LSA), HTTP/SPNEGO behaves different in username and password providing. Instead of the JAAS callback model, java.net.Authenticator is used. Read the doc mentioned above.

Programming the server side

Service name

The biggest difference here from the client side is that there's no such concept as a native keytab, which means a JGSS server program cannot simply "RunAs" a Windows service account and uses the encryption key for that account. To make server side JGSS programming on Windows available, a special step is needed to create a mapping service name and a keytab file, by using the Microsoft provided tool ktpass.exe.

For example, if the AD domain name is AD.LOCAL, and you'd like to run a service called myservice on the host machine.ad.local, you can perform these steps on your AD server:

Create a normal user account (say myservicemachine) inside AD.LOCAL, any password is OK.
Call "ktpass -princ myservice/machine.ad.local@AD.LOCAL -mapuser myservicemachine@AD.LOCAL -out x.keytab +rndPass" to create a SPN mapping to the user account, and generate a keytab file x.keytab. The password is regenerated with a random value so the password you give in step 1 is useless.

Now, put the x.keytab file into a secret place that only your service application can read. The server side JAAS login config file would look like:

com.sun.security.jgss.krb5.accept {
    com.sun.security.auth.module.Krb5LoginModule
    required
    storeKey=true
    useKeyTab=true
    keyTab="c:/secret/path/to/x.keytab"
    principal="service/machine.ad.local"
    isInitiator=false;
};

Here you need to provide the location of the keytab file. Otherwise, Java will try to locate this file in these locations (ordered by):

default_keytab_name in the [libdefaults] section of krb5.ini, or
%HOME%/krb5.keytab

Note: isInitiator=false is specified here so that the application acts as a pure server side program that will never try to authenticate itself to the KDC. This is useful when it cannot communicate directly with the KDC.

JGSS calls

Just like the client side, you can use JAAS to create a Subject and call JGSS-APIs through this subject, or calls JGSS methods directly. In the latter case, please specify

   -Djavax.security.auth.useSubjectCredsOnly=false.

Delegations

To enable delegations, both configurations and programming on needed.

Configuration at client side (the delegated)

In order for the credentials of the client to be delegatable to a service, if the initial TGT is acquired the Java way, please add forwardable=true into the [libdefaults] section of krb5.ini. If from LSA, make sure the "Account is sensitive and cannot be delegated" is NOT set in AD account settings.

Configuration at server side (the delegator)

In order to use the delegated credentials from the client, we suggest the service needs to be configured to be allowed receiving delegations. For a computer account, find the delegation tab, or for a user account, find the account tab, check "Trusted for delegation". The turns on the OK-AS-DELEGATE for the service ticket. A Windows native client program needs this flag to enable delegation. A Java client MAY respect this flag later (currenrly NO except for HTTP/SPNEGO).

Programming

Please call GSSContext.requestCredDeleg(true) on the client side. Read here for details.

Trusts between Domains

If you have already setup cross realms trusts in multiple AD domains, please add the [domain_realm] section into the client side's krb5.conf file so that Java can correctly locate the realm for a requested service. Like this:

[domain_realm]
.this.com = THIS.COM
.that.com = THAT.COM

With this configuration, when a client on THIS.COM tries to connect to a service service/host.that.com, Java can correctly figured out that the service belongs to another realm THAT.COM and perform proper inter-realm authentications.

Other Windows Platforms

This article talks about Kerberos programming on the Windows platform. The typical KDC is Windows Server 2003. The typical client is Windows XP, and the typical server is Windows Server 2003 or Windows XP. There're some minor issues for other flavors of Windows versions.

Windows 2000 Server

Note that before SP4 of Windows 2000, there's no need to specify the allowtgtsessionkey registry key.

Windows Server 2008

In Windows 2008, the AES etype is supported. In order to use AES256 as the encryption etype, please download and enable Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files. Read the "Other downloads" section for details.

In Windows 2008, you cannot request a service ticket for a normal user, since Windows only allows user2user communications with a normal user using a special Microsoft defined Kerberos extension. In fact, Windows KDC simply does not issue a service ticket targeting a normal user.

There's a workaround to allow normal service ticket for a normal user on Windows 2008. Call setspn -a service/host username, a SPN will be created for this user. After this step, the client can acquire a normal service ticket targeting either the username or the SPN. This will also lure out the delegation tab for a user so that you can allows delegation on the user.

Debugging

These options are most useful in debugging a JGSS program:

Add -Dsun.security.krb5.debug=true on Java command line
Add debug=true into JAAS login config file
Inspect networking packets using a sniffer

Also, remember to always use the latest version of JRE/JDK. Some bugs may have already been fixed. The new versions may also show better debug information.

Frequently Asked Questions (FAQ)

Note: Please remember to always read the JGSS troubleshooting guide first. Some of the following case are included in that guide, and some are Windows-specific.

JGSS complains that my JAAS config file has errors: Make sure it has correct format, the semi-colons are always there. Sometimes you need to put "" around a file name or principal name
I have a keytab, but JGSS still asks me for password: Make sure the keytab path is correct. Maybe you need to provide a full path, maybe you need to add "" around it. Also, use "/" or "\\" as path separator.
The client seems not login as an AD account: Sometimes you forgot to login as an AD account, or, if there are any network problems and your Windows client automatically goes to offline login mode. Use the Microsoft klist.exe or kerbtray.exe to see if a TGT is available in the LSA.
The debug output shows native TGT is loaded, but does not use it: This happens when the session key inside TGT is not readable. For clients before Vista, use kerbtray.exe to see if encryption type for session key is null. For Vista, look at the debug output to see if the key are all zero. If so, please setup the allowtgtsessionkey registry key.
Kerberos is never called (no Kerberos debug info after I add -Dsun.security.krb5.debug=true): Make sure various configurations are in place, which includes JAAS login conf file, krb5.ini file (or kdc/realm system properties). Also, if you don't use JAAS explicitly, make sure javax.security.auth.useSubjectCredsOnly is set to false.
Delegation in HTTP/SPNEGO fails: Make sure in Windows AD computer settings, the allow delegation box is checked.
Credentials not available: You don't have a native cache. Try to re-login as an AD account, or, consider the LSA-less way, say, -kinit.exe= or callback.
Checksum failed (or other encryption/decryption errors): If you are using username/password callbacks, possibly the password is wrong. If you are using a keytab (on the server side), possibly the keytab contains a bad key.
The Kerberos principal is not mine: Make sure there's no krb5cc_userid file inside your home directory. Java always uses this credential cache even if the user is logged in an AD user. Remove it.
EType not supported: Latest Java (update releases of all versions) already supports RC4-HMAC, which is the default etype used on Windows. You needn't specify default etypes for either the session key or ticket in krb5.ini.
Cannot find server name in Kerberos database: Have you mapped the service principal name(SPN) correctly? Please note that an SPN cannot be mapped to multiple accounts. Also, you must use the full qualified domain name in the ktpass command.
Server name (as seen in the debug output) is not FQDN (full qualified domain name), or becomes simply numeric IP address: Make sure DNS is correctly configured. JGSS uses InetAddress.getCanonicalHostName() to get the FQDN of the server's hostname. Write a tiny program to check it.
Cannot access Windows services like IIS: Make sure "Do not require pre-authentication" is not checked in AD user setting. Windows native services needs pre-authentication to provide PAC info in tickets.
Cross realm failed: Read into debug outputs, especially the TGS-REQ info. Make sure the service principal name is correct. If the Windows DNS server is not configured correctly, it may not return the correct full qualified host name.
Invalid option setting in ticket request: There are some options inside the [libdefaults] section of krb5.ini (say, forwardable=true, proxiable=true etc) which are used to provide KDCOptions when requesting a TGT using the AS-REQ message. In this case, when a TGT is returned, its TicketFlags are compared to the options here. Since in this paper we're mainly talking about TGT from the Windows LSA cache, these options are useless. Proving too many of them will only bring conflicts with your native TGT.

Known Issues

If an AD account is also added into local administrator group on the client PC, Microsoft restricts such client from getting the session key for tickets (even if you set the allowtgtsessionkey registry key to 1). The workaround is: Just forget you're a logged in user, call kinit.exe. Do not depends on LSA credential cache.

In a recent hotfix (should be included in Vista SP1), this restriction is lifted for normal service tickets. However, it still applies to TGT. Since Java uses TGT to acquire tickets for other services (the standard Kerberos process), this update provides no benefit to JGSS programming on Windows. Furthermore, even if the implementation of Java is changed to read service tickets from the LSA cache, it still cannot perform delegation, since a TGT is always needed in that case.

Useful Tools

KERBTRAY.EXE, KLIST.EXE. SETSPN.EXE, KTPASS.EXE from Microsoft.
Any network packet sniffer. For example, Windows Netmon, Wireshark.
Web browsers, with HTTP header viewer (for example, LiveHTTPHeaders for Firefox, and iehttpheaders for IE) are useful in debugging HTTP/SPNEGO programs.

References

RFC 4120, 4121, 3961, 3962
MSDN doc on Kerberos and Active Directory

by Weijun - Some Kerberos Compiler Warnings on Windows

Weijun — Mon, 21 Mar 2011 03:25:22 +0000

There is a rather old bug on native code compiler warnings on Windows. I have been the responsible engineer for some time but never really started working on it. Unfortunately, some warnings result in a real runtime error now. Sorry.

Here is the changeset for it.

As you can see, we used the swprintf function in a not-so-standard way. The correct signature of the function is swprintf(buffer, size, format, args...) but we didn't provide the size argument. In the age of VC++ 2003, there were already warnings, but the runtime accepted this "overloaded" form and it ran fine. Starting from jdk7b108, we start using VC++ 2010 to build jdk7, the same warnings still show, but this time the runtime does not accept the form anymore, and a JVM crash is observed.

The lesson is never ignore compiler warnings.

The fix would be integrated in jdk7 builds in several weeks, and I've uploaded a copy here (32 bit build) in case anyone wants to try it out. I build it in a VirtualBox guest and hope it contains no virus.

by Weijun - Jarsigner with Timestamping Behind a Firewall

Weijun — Thu, 17 Mar 2011 20:13:37 +0000

We've supported timestamping in jarsigner for a long time. By providing a -tsa option to the command when signing a jar file, a timestamping block will be added to the signed jar. This makes an application to be accepted by Java Plugin in a future time when the signer's certificate already expires.

In a lot of enterprise environments, you need to go through a firewall to access the Internet, here, the TSA (Time Stamping Authority). We've noticed this some time ago. Therefore, when a connection to the TSA is not available, jarsigner would print out a message like this:

jarsigner: unable to sign jar: no response from the Timestamping Authority. When connecting from behind a firewall then an HTTP proxy may need to be specified. Supply the following options to jarsigner:
-J-Dhttp.proxyHost=<hostname>
-J-Dhttp.proxyPort=<portnumber>

We thought this is very helpful, but there are still some customer feedbacks saying it does not work. It turns out that when a TSA server provides its service through an HTTPS website, in order to specify the proxy setting, you should use another pair of system property names:

-J-Dhttps.proxyHost=<hostname>
-J-Dhttps.proxyPort=<portnumber>

Detailed of proxy support in Java can be found here.

In order for people using other languages to reach this page, here are the same messages in Simplified Chinese and Japanese:

jarsigner: 无法对 jar 进行签名: 时间戳颁发机构没有响应。如果要从防火墙后面连接, 则可能需要指定 HTTP 代理。请为 jarsigner 提供以下选项:

and

jarsigner: jarに署名できません: タイムスタンプ局からのレスポンスがありません。ファイアウォールを介して接続するときは、必要に応じてHTTPプロキシを指定してください。 jarsignerに次のオプションを指定してください:

(Best wishes for people in Japan. Hope this earthquake/tsunami/nuclear crisis can be over soon.)

by Weijun - Fixed-width Font Widened on Bold

Weijun — Tue, 15 Mar 2011 19:01:57 +0000

So here is a screenshot of a JDK source file I am working on now, in NetBeans:

It seems there is an extra space before the "// ok" comment on line 52 which makes the comments non-aligned. So I removed it. But then when I read the diff, it shows:

@@ -49,7 +49,7 @@
      \* Constructs an AS-REQ message.
      \*/
                                                 // Can be null? has default?
-    public KrbAsReq(EncryptionKey pakey,        // ok
+    public KrbAsReq(EncryptionKey pakey,       // ok
                       KDCOptions options,       // ok, new KDCOptions()
                       PrincipalName cname,      // NO and must have realm
                       PrincipalName sname,      // ok, krgtgt@CREALM

Bad, so they were aligned, but after my change, they are not.

I am really confused by this. Is there anything wrong with the hg repository? or the diff command? or my console? Or, is there a hidden TAB character? I checked and checked but nothing seems wrong.

Finally I have to count the spaces one by one. Good heavens! It turns out that the font used in NetBeans — Lucida Sans Typewriter — has different widths between normal and bold typefaces.

Isn't this ridiculous? A fixed-width font's width should be fixed whenever it's shown in normal, or bold, or italic. I believe all modern IDEs use these styles to show different types of source tokens.

Anyway, I changed the font to the simple "monospaced" and everything looks normal now. Maybe the Lucida Sans Typewriter font is not fixed-width at all, it just looks like one.

by Weijun - Cool Mercurial Bundles

Weijun — Mon, 14 Mar 2011 02:23:22 +0000

Although OpenJDK is mostly in open source state but there are still some code repositories closed. When I work from home and need to update these repositories, I'll have to connect to the Oracle VPN to access them. I always hesitate to use VPN at home because I won't be able to see other machines on the LAN (especially, VirtualBox guests using this machine as the host) and I don't like accessing the Internet using the Oracle proxy servers. My solution is to create a VirtualBox guest for VPN exclusively.

But then I see a problem, there is a VirtualBox bug saying that symlinks in a shared folder shows incorrectly inside the guest. Now I share the OpenJDK forest in read-write mode to the guest, when trying to run hg pull -R jdk/src/closed inside the guest, it would complain

abort: Is a directory: /mnt/root/openjdk7/jdk/src/closed/.hg/wlock

This is bad.

So I go take a look at the Mercurial commands and notice this cool feature: bundles. A bundle looks like a code repository as a single file, which can contain the whole history or only part of it. Now in the guest I would call

hg inc -R jdk/src/closed --bundle jsc

to create a bundle file to contain all incoming changesets of the jdk/src/closed repo. Note that there is no problem creating a normal file from within the guest in a shared folder. Then I can go back to the host machine, and call this

hg fetch -R jdk/src/closed bundle://jsc

Cool, a bundle-schemed URI. In fact, I can now make the shared folder as read-only, and create another another smaller read-write shared folder only for file transmission from guest to host. Mecurial has dedicated commands like bundle and unbundle to deal with bundles, but I'm not eager to look into their details now.

Something else to say, I wrap the calls into a script, and it's a single script that can be called on both guest and host. In fact, this script does not perform any real mercurial/file actions, all it does is to iterate thru repository names and call echo to output command lines on the screen (plus #comments). I often write scripts in this way so that I can take a second look at the output commands for safety. After making sure they are OK I can simply copy and paste (drag thru and middle-click) lines I want to run to execute them. In this case, I run the "hg inc" lines on the guest and "hg fetch" lines on the host.

by Weijun - PolicyTool Tiny Behavior Change

Weijun — Wed, 05 Jan 2011 18:42:59 +0000

PolicyTool is the only GUI tool included in the JRE, which is used to generate a policy file for Java security permission management. You can use the tool to create a policy file or edit an existing one.

The "Save As" command of the tool opens a file save dialog, let you choose a file, and save the current policy into that file. When the file you choose already exists, the tool will issue a warning asking you if you want to overwrite it.

Here comes the problem, back in the old days, the file save dialog is drawn by Java itself, and it does not care about file overwriting at all. Therefore, it's the PolicyTool itself showing the prompt of overwrite warning. Nowadays, the file save dialog is loaded using the standard dialog of the native platforms, say, Windows style, GTK style, Mac style, etc, etc. This is nice, because people are familiar with those dialogs on their platforms and each of them provides some nice features on locating and navigating through the file system. But, there is one issue, as far as I know, all of these Save As dialogs already provide the overwrite warning feature internally, that is to say, when you click OK there, before the dialog closes, it warns you about possible file overwriting. Now in PolicyTool, you see the warning and click YES, the save file dialog is closed, but then, PolicyTool warns you again and you have to click another YES button. This is quite confusing as well as frustrating.

Therefore we remove PolicyTool's warning dialog in JDK 7. The client/awt guys are also looking through all Save As dialogs on different platforms, to make sure the behavior is the same.

The lesson is: there is much more to care about in an API design. A spec can be never too complicated. I mean the java.awt.FileDialog class.

by Weijun - I'm Still Here

Weijun — Mon, 03 Jan 2011 18:00:58 +0000

Haven't written anything on this blog for a long time. I'm still in the Java SE core libraries team and we even have some new people. Oracle LEC in China was finished last September, JSRs for Java SE 7 and 8 were approved late last year and we are now busy adding the final bits for JDK 7 and testing it heavily. It's also time to think of what features I can add in JDK 8.

by Weijun - allow_weak_crypto for Kerberos

Weijun — Wed, 03 Mar 2010 18:53:27 +0000

I just added allow_weak_crypto support in OpenJDK. With this property set to false, des-cbc-md5 and des-cbc-crc etypes are not supported, even if you include them i permitted_enctypes or default_{tkt|tgs}_enctypes settings.

Please note that in MIT krb5-1.8, the default value for this property is false, which means the DES-related enctypes are disabled out-of-box. In Java, we choose to keep it true for compatibility reasons, which we've always cared most.

by Sean Mullan - Announcing XML Signature 1.1 and Signature Properties Last Call

Sean Mullan — Fri, 12 Feb 2010 14:11:02 +0000

The W3C XML Security Working Group has released a Last Call Working Draft for XML Signature 1.1:

http://www.w3.org/TR/xmldsig-core1/

An explanation of the changes against the XML Signature 1.0 specification is available:

http://www.w3.org/TR/xmldsig-core1/explain.html

Changes are focused on the set of mandatory to implement algorithms and markup for relevant key material.

The Working Group has also released a Last Call Working Draft for XML Signature Properties:

http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/

The Last Call period lasts until 18 March 2010; comments can be sent to public-xmlsec-comments @ w3.org. The next step in the W3C Recommendation Track process is either a Candidate Recommendation phase to collect implementation experience, or another Working Draft.

The WG continues its work on XML Encryption 1.1 and is also working on a 2.0 version of Canonical XML and XML Signature.

Details on all the publications of the Working Group are available on the Working Group Publication Status page at http://www.w3.org/2008/xmlsec/wiki/PublicationStatus .

by Weijun - Oracle

Weijun — Wed, 27 Jan 2010 15:24:26 +0000

The future begins today. Let's embrace it.

by Weijun - Sun

Weijun — Thu, 21 Jan 2010 06:44:44 +0000

Linked from James Gosling's blog.

by Sean Mullan - Secure Coding Guidelines for the Java Programming Language, Version 3.0

Sean Mullan — Wed, 06 Jan 2010 05:38:36 +0000

A new version (3.0) of the Secure Coding Guidelines for the Java Programming Language has just been published at http://java.sun.com/security/seccodeguide.html

The secure coding guidelines documents best practices and patterns that you should adhere to when writing Java code in order to avoid vulnerabilities. These guidelines are important for every Java developer, whether you are writing a trusted library or an end-user application.

Version 3.0 is a significant enhancement and includes a new section on fundamentals as well as many new guidelines and enhancements.

Please send me any feedback you may have.

by Weijun - ExtendedGSSContext

Weijun — Mon, 14 Dec 2009 21:45:27 +0000

We're doing some experiments in JDK 7 to add more JGSS APIs. Currently they're defined into the vendor-specific package com.sun.security.jgss, but we'd like to enhance them and finally get them into the standard org.ietf.jgss package.

Basically, we defined a new ExtendedGSSContext interface. Now it has 3 methods:

requestDelegPolicy(boolean state): Requests that the delegation policy be respected. When a true value is requested, the underlying context would use the delegation policy defined by the environment as a hint to determine whether credentials delegation should be performed. This method is mainly used to deal with the Kerberos OK-AS-DELEGATE flag.
getDelegPolicyState(): Returns the delegation policy response.
inquireSecContext(InquireType type): Returns the mechanism-specific attribute associated with type. Currently we're supporting four types for the Kerberos 5 mechanism: KRB5_GET_TKT_FLAGS for flags in a service ticket, KRB5_GET_SESSION_KEY for the session key of an established session, KRB5_GET_AUTHZ_DATA for authorization data in a service ticket (mainly used on AD for the PAC info), and KRB5_GET_AUTHTIME for the authtime in a service ticket.

We haven't created method names like getTicketFlags or getSessionKey because we believe these information are mechanism-specific and not general enough on the GSS level. Even the getSessionKey method only returns Kerberos 5-specific keys, where the etype values are only defined in Kerberos 5. A disadvantage side of this design is that the method must return Object and the result needs to be casted to other type depending on the input type value.

Full spec is at OpenJDK code repository, and implementation in other parts of the code repo.

by Sean Mullan - Using more recent Apache XML Security Libraries with JDK 6 or JDK 7

Sean Mullan — Thu, 01 Oct 2009 08:57:48 +0000

This question has come up in user forums quite a bit: "how can I use a more recent Apache XML Security library with the XML Signature APIs (JSR 105) in JDK 6 and JDK 7?"

Most of the time, you will not need to do this. Our JDK 6/7 XML Signature implementation is based on Apache XML Security and we try to keep up with the latest release. However, there may be a bug fix or new algorithm that you really need and are willing to depend on a more recent version of the Apache XML Security library that has that fix. Here is what you need to do if so:

Place the Apache xmlsec.jar in the endorsed standards directory.
You will also need to put the Apache commons logging jar there as well, since the Apache code uses a different logging mechanism than the JDK.

And that's it. You can also use the java.endorsed.dirs system property to point to different directory containing the jars above.

by Sean Mullan - Using stronger XML Signature Algorithms in JDK 7

Sean Mullan — Fri, 24 Jul 2009 09:07:10 +0000

One of the new features of the XML Signature 1.1 specification, which is currently in draft review, is the addition of stronger cryptographic algorithms to the REQUIRED algorithms, such as the RSAwithSHA256 SignatureMethod algorithm. Additional RECOMMENDED and OPTIONAL algorithms have also been added. See section 6.1 for a complete list of algorithm requirements.

In JDK 7, you can already use many of these stronger XML Signature algorithms in your Java applications. The following algorithms are newly supported: the RSAwithSHA256, RSAwithSHA384, RSAwithSHA512 signature algorithms and the HMAC-SHA256, HMAC-SHA384, and HMAC-SHA512 mac algorithms.

To take advantage of these stronger algorithms when generating XML Signatures, you may have to specify the URI of the algorithm (if there isn't a String constant already defined in the API). For example:

XMLSignatureFactory factory = XMLSignatureFactory.getInstance();

SignatureMethod sm = 
    factory.newSignatureMethod
        ("http://www.w3.org/2001/04/xmldsig-more#rsa-sha256", 
         (SignatureMethodParameterSpec) null);

No special code is required when validating XML Signatures with these algorithms as the implementation will automatically identify the algorithm URIs.

We plan to add String constants for these URIs in a future revision of the JSR 105 API, but for now you must specify the URIs when generating signatures.

Last, but not least, we are planning to backport support for these stronger signature and mac algorithms to JDK 6.

by Sean Mullan - Hope to see you at our Java Security BOF next week at JavaOne

Sean Mullan — Fri, 29 May 2009 08:45:15 +0000

Just a reminder that we'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7". It is on Wednesday at 6:45 PM in Gateway 102/103 in the Moscone Center. We plan to have a short presentation on the latest security features in JDK 6, JDK 7 and JavaFX. Then, we are going to show a demo of the new blacklist mechanism in the just-released JRE 6u14. The remaining time will be for Q&A so please bring your questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them.

by Weijun - Subscribe to a mail list and start replying immediately

Weijun — Sat, 25 Apr 2009 06:31:53 +0000

Sometimes I browse through archives of a mail list and find some topics very interesting. I subscribe it, but only new messages come to my mail client, and those topics I found interesting initially won't appear anymore. How I wish I can reply to those topics.

If it's also hosted on Google Groups, that's great. Just reply to it there. If you don't want to keep using your Google Account in the discussion. Reply with some nonsense in Google Groups, and then reply with your real identity after that nonsense reaches your mail box.

If the list is available on gmane.org, you may be able to reply from there.

If the above two methods do not apply, you can still force that mail appear in your mailbox. Just create a mbox file and import it into your mail client. If the mail list is not that busy, I would simply download the archive including the topic, gunzip it, and import the archive. Note that some archive changes the mail address to me at here.com. Just run a perl -p -i -e 's/ at /@/g' file is OK.

by Sean Mullan - Come to our Java Security BOF at JavaOne 2009

Sean Mullan — Fri, 24 Apr 2009 08:19:08 +0000

We'll be holding a BOF at this year's JavaOne conference on "New Security Features in JDK™ Releases 6 and 7". This is sure to be an interesting BOF, as we'll go over all of the latest security features that we have added to JDK 6 and new ones that are targeted for JDK 7. We also plan to show a demo of some of the features. There should be plenty of time for Q&A so please bring your questions on Java Security as many members of Sun's Java Security team will be on hand to help answer them.

I'll add more details as we get closer to JavaOne.

by Weijun - Fedora 10

Weijun — Wed, 22 Apr 2009 01:03:08 +0000

Trying to install it again. Last time (probably F8) it does not support GUI login as a NIS user. GDM hangs.

Hope it's fine now. Will see if it's a better system building OpenJDK.

Update: NIS account can login, no +::: lines needed. However, system goes unstable when trying to change network setting to manual IP. Re grub-install and now back in Ubuntu.

Anyway, OS is there now, might try again someday.

by Weijun - Several Enhancements for JarSigner

Weijun — Sun, 19 Apr 2009 18:55:31 +0000

There're several enhancements to the jarsigner tool in OpenJDK lately.

First, jarsigner accepts a new option -certchain file to use a certificate chain in an external file. People can using PKCS #11 tokens to store their private keys. Some of these tokens are so small that there's no place to store the certificate chain inside it. Although you can access it with a KeyStore.getInstance("pkcs11"), the getCertificateChain() method returns nothing. Now you can use jarsigner with this kind of tokens, using the token as the keystore, but point your certchain to another file that contains the full chain.

Second, people see jarsigner showing warnings now and then, like certificate expired, or keyusage not correct. if they want to know this information if jarsigner is called in a script, they can only grep the words. Now, if you add a new option -strict , not only the warnings will be printed, a System.exit(n) is called when there is/are warning(s). Here, n is a binary sum of these pre-defined warning codes:

2: hasExpiringCert
4: chainNotValidated (including hasExpiredCert, notYetValidCert)
8: Usages problems (including badKeyUsage, badExtendedKeyUsage, badNetscapeCertType)
16: hasUnsignedEntry
32: notSignedByAlias or aliasNotInStore

Noticed the new warning type notSignedByAlias? Now you can call jarsigner -verify jarfile alias0 alias1... with zero+ of aliases to check if certificates of the signed entries inside the file match any of these aliases.

Third, people complain jarfiles show too little or too much output at verifying. If you simply verify a jarfile, it might tell you some warnings, call with -verbose -certs to read details. You verify again with those two options on, and huala... thousands of lines fly through and you cannot catch a word. Now -verbose has sub options so you can precisely tell it how verbose the output should be:

-verbose:all, this is the default -verbose, which shows as much information as it did
-verbose:grouped, this shows less information. The entries with the same signer info are grouped together. This means the names of the entries are listed together, with the signer info only printed once. Something like this:
```
      smk   A.class
      smk   B.class
      ...
 
      Certificate A (CN=A, OU=B)
```
-verbose:summary. This is the simplest one. Besides grouping the entries with same signer info together, not all the entry names are printed, but only one line of summary. Something like this:
```
smk   A.class (and N-1 more)
 
      Certificate A (CN=A, OU=B)
```
Using this option, unless your jar file is signed by dozens of different signers, no matter how many entries inside, the output should not exceeds two screens.

by Brad Wetmore - Would 6 units of band class qualify me for a free JavaOne 2009 pass?

Brad Wetmore — Fri, 17 Apr 2009 20:23:45 +0000

The worst thing about graduating and getting a job in the real world is that all the cool benefits dried up. Student rates on travel, movie passes, food...etc.

I just noticed an offer on the J1 web site that appears to allow students (6 units or more) to get a free, FULL JavaOne 2009 conference pass. Even as a Sun employee, I only get a limited pass. Which got me thinking: I'm currently taking a 1 unit music performance class at a local community college. If I sign up for 5 more of these classes, would that qualify?

Hm...I should check with my manager...

by Sean Mullan - New API to indicate the reason a certificate chain was invalid

Sean Mullan — Fri, 03 Apr 2009 11:39:42 +0000

In JDK 7, we have added a new method (getReason) to the java.security.cert.CertPathValidatorException class which returns an object indicating the reason a certificate chain, or CertPath, is invalid. Previously, there was no standard mechanism to determine the reason of failure, and applications had to depend on the exception message or the cause which could vary based on the underlying service provider implementation.

The getReason method returns an instance of CertPathValidatorException.Reason, which is an interface. There are 2 subclasses of this interface. One is BasicReason which is an enumeration of reasons which can apply to certificate chains of any type (X.509, PGP, etc). It contains reasons such as EXPIRED (certificate has expired) or INVALID_SIGNATURE. The other subclass is PKIXReason, and that enumerates the potential PKIX-specific reasons that an X.509 certification path may be invalid according to the PKIX (RFC 3280) standard, for example UNRECOGNIZED_CRIT_EXT . Here's an example of how you might use these new APIs in your application that validates certificate chains:

CertPathValidator cpv = CertPathValidator.getInstance("PKIX");
try {
    CertPathValidatorResult cpvr = cpv.validate(path, params);
} catch (CertPathValidatorException cpve) {
    CertPathValidator.Reason reason = cpve.getReason();
    int index = cpve.getIndex();
    System.err.println("Invalid certificate chain, certificate[" + index + "], reason: " + reason);⁞  
}

by Sean Mullan - New CertificateRevokedException class in JDK 7

Sean Mullan — Fri, 27 Mar 2009 08:44:19 +0000

There is a new CertificateRevocationException class in JDK 7 in the java.security.cert package that indicates that an X.509 certificate is revoked and also allows you to determine additional information such as the reason the certificate has been revoked and when it was revoked. The getRevocationReason method returns a CRLReason, which is a new enum class that enumerates the different reasons an X.509 certificate can be revoked, such as compromise of the private key. In JDK 7, The Sun PKIX CertPathValidator service provider implementation has been enhanced to throw this exception. Here's an example of how your application may use this new exception class:

CertPathValidator cpv = CertPathValidator.getInstance("PKIX", "Sun");
try {
    CertPathValidatorResult cpvr = cpv.validate(path, params);
} catch (CertPathValidatorException cpve) {
    if (cpve.getCause() instanceof CertificateRevokedException) {
        CertificateRevokedExcepion cre = (CertificateRevokedException) cpve.getCause();
        System.err.println("Certificate  revoked on " + cre.getRevocationDate());
        System.err.println("reason  for revocation: " + cre.getCRLReason());
    }
}

by Sean Mullan - Greetings

Sean Mullan — Fri, 20 Mar 2009 12:49:12 +0000

Hello everyone. Although I have been with Sun for over 10 years, this is my first blog entry at blogs.sun.com. I already have a blog over at java.net (http://weblogs.java.net/blog/mullan/), but for now I will be posting new entries right here at blogs.sun.com. I may still update my blog at java.net from time to time, or figure out a way to cross-post my entries.

A little about myself. I work on the Java Security Team and have spent almost 10 years working on the Java SE security technology. I was specification lead of JSR 55 and co-specification lead of JSR 105, both successful APIs that were integrated into Java SE. I'm also Sun's representative on the W3C XML Security Working Group and a committer on the Apache XML Security project. Lately, I have been investigating and working on security features related to JavaFX and web-deployed technologies.

Stay tuned for my next entry about the new CertificateRevokedException class in JDK 7.

by Weijun - Another new keytool enhancement: -printcert -sslserver

Weijun — Sun, 22 Feb 2009 23:40:51 +0000

Andreas has written a blog entry on retrieving certificates from an SSL server. Whenever I see someone asking this question on the Java forum I point the user to this entry. Now it's time for this function to be included in keytool.

Call keytool -printcert -sslserver sun.com to see what's shown.

During the implementation of this feature, there are some discussions on how the function should be called. Two topics are most interesting:

What's the function name? At first, the plan is to add a new function to import the certificate into a keystore. The command will look like "-importcert -sslserver". However, there came several problems:

For a normal certificate file, you can first call -printcert on it, read carefully, and then decide if it can be imported. For a certificate from an SSL server, you can still call something like "-printcert -sslserver" on it, but do you dare call "-importcert -sslserver" after examining it carefully? No, because the SSL server is not controlled by you, and it might send out a different certificate in the second call. That's scary, isn't it?
An SSL server sends you a certificate chain. If you want to import one that's not always the end-entity cert, you need to specify a position number. This means another option, more interactions, and, more error messages or IndexOutOfBoundException. That's not good.

So the command ends up with a simple "-printcert -sslserver". It's left to the user to read/check/cut/paste the info wanted.

What protocols to support? This is a simple question, and the answer is ALL. Every application protocol that's based on SSL is included. However, the implementation chooses only HTTPS, for several reasons:

HTTPS is the most popular SSL-based protocol out there, and programming it is the easiest, I simply call
```
new URL("https://" + sslserver).openConnection().connect();
```
HTTPS supports proxy, so you can add -Dhttps.proxyHost and -Dhttps.proxyPort if the SSL server is behind a proxy.
Last and the best. It also works for any SSL-based application protocol, because the handshake part of any such protocol is identical. Please notice that I only call the connect() method, where handshake is done but no application specific data communication is performed yet.

BTW, the feature was added into keytool long time ago.

by Weijun - keytool enhancements

Weijun — Sun, 22 Feb 2009 20:59:12 +0000

Update: CRLDistributionPoints extension support added.

There're two enhancements made to keytool today (the doc has not been updated, it's still for JDK 6):

new commands and options

We have 2 new commands: -gencert, -printcertreq and 1 new option -ext. Read the RFE descriptions.

-printcertreq is simply for printing the content of a certificate request. It behaves like the -printcert command, reading a PKCS #10 format cert req from a file or stdin, and does not need a keystore to run with.

-gencert is a big enhancement, which means you can setup a tiny CA now with keytool. The command reads a certificate request from a file (specified by -infile) or stdin, creates a certificate, signs it with the private key in the PrivateKeyEntry specified by -alias, and print the output to another file (specified by -outfile) or stdout. That's it. Just like -genkeypair for self-signed certificate, you can specify -sigalg, -startdate, and -validity options to the command.

-ext is used to add X.509v3 certificate extensions to a certificate (for both -genkeypair and -gencert) or a certificate request (for -certreq). The option can be specified multiple times to add multiple extensions. The value of this option takes the form of name[:critical][=value]. Here name is the extension name, and value the value (omit if empty). The :critical modifier, if provided, means the extension's isCritical attribute is true; otherwise, false.

Currently we support these named extensions (case-insensitive):

name	value
BC or BasicConstraints	The full form: "ca:{true\|false}[,pathlen:len]"; or, "len", a shorthand for "ca:true,pathlen:len"; or omitted, means "ca:true"
KU or KeyUsage	usage(,usage)\*, usage can be one of digitalSignature, nonRepudiation (contentCommitment), keyEncipherment, dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly, decipherOnly. Usage can be abbreviated with the first few letters (say, dig for digitalSignature) or in camel-case style (say, dS for digitalSignature, cRLS for cRLSign), as long as no ambiguity is found. Usage is case-insensitive.
EKU or ExtendedkeyUsage	usage(,usage)\*, usage can be one of anyExtendedKeyUsage, serverAuth, clientAuth, codeSigning, emailProtection, timeStamping, OCSPSigning, or any OID string. Named usage can be abbreviated with the first few letters or in camel-case style, as long as no ambiguity is found. Usage is case-insensitive.
SAN or SubjectAlternativeName	type:value(,type:value)\*, type can be EMAIL, URI, DNS, IP, or OID, value is the string format value for the type.
IAN or IssuerAlternativeName	same as SubjectAlternativeName
SIA or SubjectInfoAccess	method:location-type:location-value (,method:location-type:location-value)\*, method can be "timeStamping", "caRepository" or any OID. location-type and location-value can be any type:value supported by the SubjectAlternativeName extension.
AIA or AuthorityInfoAccess	same as SubjectInfoAccess. method can be "ocsp", "caIssuers" or any OID.
CRL or CRLDistributionPoints	same as SAN. This means you can only add one point with only names

When name is an arbitrary OID, value is the HEX dumped DER encoding of the extnValue for the extension excluding the OCTET STRING type and length bytes. Any extra character other than standard HEX numbers (0-9, a-f, A-F) are ignored in the HEX string. Therefore, both "01:02:03:04" and "01020304" are accepted as identical values. If there's no value, the extension has an empty value field then.

A special name "honored", used in -gencert only, denotes how the extensions included in the certificate request should be honored. The value for this name is a comma-seperated list of "all" (all requested extensions are honored), "name[:{critical|non-critical}]" (the named extension is honored, but using a different isCritical attribute) and "-name" (used with all, denotes an exception). Requested extensions are not honored by default.

If, besides the -ext honored option, another named or OID -ext option is provided, this extension will be added to those already honored. However, if this name (or OID) also appears in the honored value, its value and criticality overrides the one in the request.

The subjectKeyIdentifier extension is always created. For non self-signed certificates, the authorityKeyIdentifier is always created.

Try this command on your system if you already have 2 self-signed certs me and ca created in your default keystore:

    keytool -storepass changeit -certreq -alias me -ext bc -ext eku=sa,ca | \\
    keytool -storepass changeit -gencert -alias ca -ext honored=all,-bc \\
        -ext aia=ocsp:uri:http://ocsp.ca.com,cai:uri:http://ca.com/ca.crt  |
    keytool -printcert

Here, the user me requests for an SSL server certificate from the CA. It asks for an EKU extension named ServerAuth and ClientAuth, which is useful for an SSL server. However, it also secretly asks for a BC extension, so that it can start its own CA. The CA, with sharp eyes, notices this problem. It grants all extensions requested except BC. It also adds another extension AIA which includes issuer info into the cert generated.

openssl-style certificate support

When you run openssl x509 -text with an X.509 certificate, the output includes a bunch of human-readable texts before the BASE64-encoded certificate itself. Java did not accept these texts and threw an exception something like "unknown tag or bad length", since it tried to interpret the file as DER encoded. Now we enhance the X.509 CertificateFactory class to accept this kind of certificate.

By the way, have I mentioned -startdate before? This option allows you to change the issuing time of a certificate from current system time to something else. Some people may like this option to create certs for special test cases, and some other people would like the certificate to have an earlier time because they want to use it right now but their clients and servers are not precisely time-synchronized. The grammar for this option takes one of the 2 following formats:

([+-]nnn[ymdHMS])+
[yyyy/mm/dd] [HH:MM:SS]

So -startdate -5M means 5 minutes ago, -startdate "2001/01/01 11:11:11" means that exact time, -startdate 11:11:11 means that time today. Read more in the RFE decriptions.

by Brad Wetmore - Extra! Extra! Read all about it! OpenJDK Bugzilla Goes Live!

Brad Wetmore — Fri, 06 Feb 2009 20:50:04 +0000

News at 11...or whenever the moderator on "announce at openjdk dot java dot net" approves my message...or just go to:

http://openjdk.java.net/groups/web/bugzilla.html

(Apologies to my younger or international readers if the title of this entry didn't make any sense.)

by Brad Wetmore - Update on the OpenJDK Bugzilla instance.

Brad Wetmore — Sun, 01 Feb 2009 21:42:26 +0000

I've recently been leading the effort to get our OpenJDK Bugzilla instance in place, and just wanted to let folks know that we're pretty close.

I took some time over the last couple days to take a snapshot of what we have and what's planned for the near and somewhat longer future. The short story is that we'll begin by tracking contributions from OpenJDK developers who do not have push rights to the JDK 6 and 7 forests. The next phase will expand the system to track most if not all of the OpenJDK projects under development.

The longer story is now available on the OpenJDK website.

One last point. Until the general system is up, you should continue to submit new bug reports through the normal channel.

There's still a lot of work to be done and questions to be answered, but thought you might like to see the current status and what's being planned.

by Weijun - Small Enhancements to HGrev

Weijun — Wed, 21 Jan 2009 01:10:45 +0000

I've enhanced http://hgrev.appspot.com a little. Now the patch view has links to previous and new codes in raw form, so that you can download it directly to try on your own computer.

by Weijun - Who Moved My krb5.ini?

Weijun — Mon, 19 Jan 2009 02:59:47 +0000

Java Kerberos 5, on Windows, looks for a config file named krb5.ini in the Windows directory, and a Windows directory is defined as the return value of the Win32 API GetWindowsDirectory(), which should normally return something like C:\\Windows.

But, since Windows Server 2003, something has changed. The Terminal Services Programming Guidelines has these words: In a Terminal Services environment, the Windows directory is guaranteed to be private for each user.

So this means if your (post Windows 2003) system has Terminal Services turned on, Java would look for krb5.ini inside %YOUR_HOME%\\Windows. This is bad, since we believe that the Kerberos 5 setting is a system-wide configuration, which should be setup once for all. To fix this problem, we make some changes in the OpenJDK codes. From now on, Java will look for krb5.ini in both GetWindowsDirectory() and GetSystemWindowsDirectory(),

FAQ:

Why is GetWindowsDirectory() still called? why is it even preferred to GetSystemWindowsDirectory()?

There are two reasons. First, compatibility matters. It is very possible that users out there have already noticed this issue and have put krb5.ini inside the user-private Windows directory instead of the system-wide one. For these users, JDK 7 should still work for them. Second, it's a common sense that user settings should override system settings. Therefore, user-private Windows is preferred to system-wide Windows.
I'm still using JDK 6 and I don't like this user-private Windows directory, what shall I do?
There are three solutions. First, you can provide the -Djava.security.krb5.conf =/path/to/my/krb5.ini option to your Java command line, or setup the environment variable _JAVA_OPTIONS to contain this value. Second, the most preferred Kerberos 5 config file is krb5.conf inside [JRE]/lib/security. Use this file is always safe (Note: it's krb5.conf, not krb5.ini). Third, you can trick the Windows to still return C:\\Windows for GetWindowsDirectory(). To do this, add a registry key HKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Terminal Server\\Compatibility\\Application\\JAVA, with a 32-bit DWORD value Flags=0x408. If you want to use Java's Kerberos command kinit, klist etc, provide keys with the name KINIT, KLIST etc.

P.S.: A minor Windows 2008 bug (or maybe not a bug, see below) makes this problem a little tougher. On Windows Server 2008, GetWindowsDirectory(NULL,0) returns the length of the system-wide directory, but not the user-private one. Thus our original trick of get-length-then-allocate-then-get-value fails, and JDK 6 cannot locate the correct user-private Windows directory. If you met this problem, you would have to choose one of the three workarounds above. MSDN never says the first parameter of this API can be NULL, although quite a lot of people are using the same trick.

The positive side is, we always print out the pathname of the krb5.ini file we're using in the debug output. Just add the -Dsun.security.krb5.debug =true option to your java command line to make sure it's using the krb5.ini of your intention.

by Weijun - NetBeans C++ is Cool

Weijun — Fri, 16 Jan 2009 01:04:08 +0000

Although I use NetBeans a lot writing Java, I've never really tried its C/C++ Pack before. Today I need to read some MIT Kerberos codes. There's a long time I haven't worked heavily on C so I find it quite difficult to find out which function does what and where it's defined. And then, I think of NetBeans, it's very good at parsing Java codes and give you multiple ways to navigate through the method calls and field definitions. How about trying it for C?

So I fire up NetBeans and go download the C/C++ pack. It's a huge 5MB module that takes care of projects, editing, debugging all in one place. Install and restart.

I create a C/C++ project, there's a choice called "Use existing codes" so I choose the Kerberos src directory and click go. The magic happens: it loads all the files inside the directory, and then starts to call the configure script, and I see yes/no lines flying in the output window. Then, it starts to build the source! With no human intervention, it does everything from the beginning to the end, and I'm now seeing MAKE SUCCESSFUL.

Brilliant, isn't it? I open a terminal window and run the newly-built kinit command with DYLD_LIBRARY_PATH pointing to the lib directory, and it runs smoothly and correctly, showing the kinit help page.

Now I'm browsing the Kerberos codes, using the familiar Command+click to go through function calls and variable definitions. A real charm!

by Weijun - Picasa for Mac

Weijun — Thu, 08 Jan 2009 00:23:18 +0000

I'm happy to become a Picasa user again. For the last two years, I use Finder and Preview to take care of all my photos. It's a very difficult job － I leave quite some duplicates here and there, and I dare not edit photos except rotating them. I hate iPhoto, I don't want the files be moved to somewhere else, and I feel bad when I don't know what it's doing and how it stores things.

Now I can do the so-called non-destructive edit again. Picasa for Mac still recognizes all previous edit made in Windows, the Picasa.ini file I mean. It would update the file if you make more edit. When there's no Picasa.ini, it happily creates a .picasa.ini file, which is the standard Unix style to name a hidden file.

I believe Picasa for Windows will recognize .picasa.ini also.

by Weijun - OpenSolaris on Bare Metal

Weijun — Tue, 06 Jan 2009 21:50:45 +0000

Finally I decide to install OpenSolaris on the bare metal, and probably use it as a nightly build machine.

Create a USB installer using usbcopy
Boot from this USB disk and install
Reboot, disable network/physical:nwam, enable multicast and network/physical:default, call sys-unconfig
Reconfigure the machine
Reboot again

I hadn't enabled/disabled the services first time when I run sys-unconfig, and the machine cannot reboot complaining avahi-bridge-dsd cannot start. Fortunately I can login to single user mode and do that again.

I'm learning how to give more privileges to my NIS user account now.

by Brad Wetmore - You can teach a somewhat older dog new tricks-OpenSolaris 2008.11: Wow!

Brad Wetmore — Thu, 18 Dec 2008 21:30:16 +0000

Way back in grad school (early 90's), I was called in to assist in the investigation of an internet porn exchange ring. The ring was using some unsecured FTP servers belonging to our state's government. Our team finished our initial assessment and called in the State Police to report our findings. I will never forget that day as long as I live. I said, "Yes, you've got a problem" and brought up one of the tamer images. This career cop was two years away from retirement, and he just rolled his eyes and said "I'm too old for this, I don't get this new technology."

I'm nowhere near retirement age, tho if that .com bubble hadn't burst...hmmm... But when I see something cool, it just invigorates me. Although I've been on the bleeding edge of Java technology for almost 10 years now, I'm ashamed to admit I've lost my edge in Solaris. I recently got called into a high-priority escalation involving some native code. All my familiar tools still worked, but were limited in how quickly I could drill down into the problem. To analyze this issue, I finally had the excuse to play with all the cool new tools now in Solaris. prstat, libumem, mdb, dtrace, etc. Wow, what a difference those years made. And that's only scratching the surface.

Even netbeans has come a long way since I last "attempted" to use it (4.X). The debugger and editor are light years better, the profiler now works, and I am now actually using it to debug my OpenJDK7 builds. How much productivity have I gained via "Ctrl-space"? Look for another post on using Netbeans 6.5 to work in OpenJDK7 when I get some more time.

Today, Tim Bell and I set up a sandbox area for the codereview and bug tracker databases for OpenJDK. We needed the usual parts: some hardware, an OS instance, a web server, a database. As we subscribe to the "Eat our own dogfood" school of thought, the new OpenSolaris 2008.11 immediately came to mind. Wow.

My day went something like this:

Lunch. Check.
Find x86 hardware. Check
Download OpenSolaris 2008.11, and burn to CD. Boot. Check.
Wait, what's this GUI installer thingy? Ok...a few simple questions later...wait for install to finish. Check.
Wait, it booted and the networking is already up and configured? DHCP by default? Cool! Check.
Wait, I just realized I didn't have to spend an hour trying to remember some arcane display commands. And then spending another two actually tweaking the settings. My display just came up. And the default workspace looks good.
And now you're telling me I can just use the new IPS GUI to point and click to install a webserver, SQL instance, netbeans, and a bunch of other tools? No downloading the source, building, cursing? Cool!
Elapsed time: 3 hours.

I'm sure I'll spend the next couple days/weeks tweaking things, but for simply getting something up quickly, Solaris has made huge inroads in the last few years, both in tools for techies and for providing a general work environment for the non-techie. What a pleasure. And all on x86. I can distinctly recall several periods in Sun's history where mentioning x86 and Solaris in the same breath were grounds for dismissal.

It's to the point where I can finally recommend Solaris to my parents.

Except that my brother works at Microsoft, and gets a great discount.

And they always did like him better.

by Weijun - mechListMIC in SPNEGO

Weijun — Tue, 16 Dec 2008 19:37:36 +0000

I try hard to understand when should mechListMIC be generated in SPNEGO, but still find the specification (RFC 4178) confusing. I'd like to interpret it this way:

If the chosen mech is the first one in the list, don't bother to create it
Generate the MIC whenever you think you can do it, i.e. mech's isEstablished() is true
Response to a MIC whenever you receive one

In case you believe the incoming token should have the MIC but it hasn't, if it's already marked COMPLETE, you go COMPLETE also. Otherwise, it may be expecting a MIC from you, either create the MIC and send back, or send back an empty COMPLETE.

OK, I admit I don't understand it.

by Brad Wetmore - Consolidation of the JSN and TL gates.

Brad Wetmore — Wed, 12 Nov 2008 15:54:40 +0000

For the last 4 years, I've been the "Gatekeeper" for the Java Security and Network (JSN) team. Gatekeepers are those under-appreciated but highly necessary folks who make sure that new changes work, and play nicely with what's already there. We're only as good as our test cases, but not all developers are as diligent about running everything that's available.

A month ago, I was asked to take on a project to support the OpenJDK project. In order to free up time, we decided to decommission the JSN gate, and transition the JSN developers to the Tools and Libraries (TL) gate run by Tim Bell. My last push from/to the JSN gate was October 20th, and the first push of the merged TL gate was done last week November 7th. The JSN gate still exists in its normal place, but is fast becoming out-of-date. We will eventually remove it completely from the project.

Giving up this role has been bittersweet. I had spent a lot of time automating the process, and those scripts now sit mostly unused. But I've been gatekeeper for JDK 1.3.1 and in my previous life working on Trusted Solaris 2.5 with Sun's Federal Systems Division. I wouldn't be surprised if I find myself in this role again, but for now, I'm definitely looking forward to doing something different for a while.

For anyone thinking of breaking the TL gate, Tim now has the noose, and isn't afraid to assign it.

P.S. For the "GhostBusters" fans out there, even though I'm no longer "Gatekeeper," I still have my other job as backup "Keymaster". Requests for JCE Code Signing Certificates still come to me.

by Weijun - Mark Bristow, Today's Gold Medalist

Weijun — Tue, 09 Sep 2008 02:08:15 +0000

Silicon Valley? That's Sun Microsystems.

Congratulations!

by Weijun - LiveCD of OpenSolaris in VMWare

Weijun — Mon, 25 Aug 2008 20:51:22 +0000

Normally I don't like running an OS as a LiveCD on a bare metal machine because accessing CD-ROM is too slow and makes very big noises. However as a VMWare guest, since the CD-ROM is in fact an ISO file on the hard disk, I guess the speed should be quite fast, I'm quite happy to only run it on the LiveCD.

So I creates a new Virtual machine with two CD-ROM drives, put the LiveCD in the 1st one and the VMTools into the 2nd. When the system CD boots up, I will be able to install VMTools from the 2nd CD.

This works quite fine for Ubuntu and the VMTools is installed correctly. But for OpenSolaris 2008.05, it cannot be installed, because the file system that contains /usr is not writable.

I guess in Ubuntu the /usr volume is implemented as a cascaded/hybrid file system, most of the files are from the CD, but you can still add/remove/modify files into the memory that shadows the ones on the CD, and this combined file system looks like a single unified one. OpenSolaris should works the same way, I guess it's only that the designers didn't realize that /usr needs to be modified, so they never make this volume cascaded/hybrid.

by Weijun - F9 (Compile) for NetBeans Missing

Weijun — Sun, 03 Aug 2008 21:28:30 +0000

Just downloaded the latest DEV version of NetBeans, haven't done it for several weeks.

One thing that confuses me is that F9 seems does not work for individual files in a Java project anymore. Pressing F9 has no impact, the edited Java file still shows an asterisk sign in the editor pane header, still dirty, not even saved. Looking at the right mouse menu of the file, and the compile item is grayed not completely.

Strange, isn't it? Then I suddenly realized this might be because of the newly introduced compile-on-save feature. I try to add some runtime error into my Java file and save it. Run, failed! So my guess is correct.

Anyway, I'm still a little uneasy with this feature. When I save the file, if there's any compile-time error, how can I know the compilation failed? I may not have noticed the red lines or the red exclamation mark on the file node. And worse, the output pane does not popped up showing the compilation error info. (Yes, I normally hide it. Off topic, people invent more and more wide screens, why not higher?)

There should be a more friendly way here, right?

by Weijun - my webrev experiment: public, interactive and easy

Weijun — Wed, 11 Jun 2008 21:27:10 +0000

Inside Sun, we use webrev to do code reviews, you can see an example here.

Well, there're several reasons I don't like webrev very much:

It's a pile of static files, you must first create them, and upload them to a public website (possibly one by one).
It used to be a nice archive of what you've done, but now in Mercurial we already have changesets.
It includes no interactive review process

OK, only the first reason is real. I just cannot resist the temptation to create a list.

Recently I've done some experiments on creating a new review style which is meant to be:

Public, the patch can be created and reviewed by anyone
Easy, creation and viewing are both very easy
Richer interaction, request and review can be done interactively along with the patch

I'm using the Google App Engine for a prototype called hgrev. The current implementation is already public and easy. By using the Google Accounts system, I believe the richer interaction should be fairly easy to add. Now it runs in a create-only mode, which means after you create a hgrev request, it cannot be modified anymore. This is not a bad idea before the accounts system is used.

To create a hgrev, you need to provide three info:

A title, possibly a synopsis of a bug item
The base URL, a public accessible URL that your patch is based on. If you're working on 2 patches at the same time on a single file, sorry. Maybe one day the base URL can be also another hgrev request.
The patch itself, which is the raw output of "hg diff". Or if you use Mercurial Queue, the raw content of the patch file.

After you enter these information, a new hgrev request is created, you can send the URL of the request to anyone you ask for a code review. The reviewer can read the patch itself, or read a side-by-side comparison of each file before/after the patch. Since you've already provided the base URL, the reviewer can go back to the Mercurial code repository to read related codes etc.

Take a try at http://hgrev.appspot.com/, I've already included several examples there.

By the way, if the webpage does not work with IE or any other web browser, that's my fault.

by Brad Wetmore - He Is He, Don Quixote: The Lord of La Mancha!

Brad Wetmore — Tue, 03 Jun 2008 16:02:35 +0000

Folks have been asking what I'm up to outside of work. Way too many things for one blog entry, so I'll focus on the most recent.

As you may know, one of the things I'm quite passionate about is music and performance. I'd started with church choirs, but I'd say I got really passionate about music in 5th grade, when I had to choose an instrument for the school band. I can't believe how practical I was back then: I asked myself what instrument(s) will allow me to do the most types of music. (pretty impressive for a 5th grader, no?) The answer was obvious: Percussion. Rock, soul, jazz, classical, latin, marching, tribal, etc., etc., etc.

Here it is, \*mumble-something\* years later, and I'm still at it. Played on 6 continents so far. (Note: If any researchers/penguins in Antarctica are reading, I'll be happy to come bang out a tune.)

My latest gig is playing in the pit (orchestra) for the Saratoga Drama Group's production of "Man of La Mancha". The music actually calls for three percussionists, but we're covering with two. A good friend of mine who is also a percussionists likes to say that "We're busier back there than a one-armed wallpaper hanger." Snare, tom toms, and bass drums, cymbals, castanets, wood blocks, timpani, orchestra bells, finger cymbals, tambourine: The only reason we don't have a xylophone back there is that we're out of room!

(By the way, is there an English spelling book that doesn't use "Xylophone" for the letter "X"?)

Oh yeah, I almost forgot why I chose the title for this blog. Everyone is raving about how tall our Don Quioxote (Walter Mayes) is. He's 6' 7-1/2" (201 cms) tall. Yet, I don't hear anyone emoting about how tall one of the percussionists is. ;) Ah, jealousy is a fickle beast. But at least 6' (183 cms) Michael Johnson finally got to play one of his favorite roles, Sancho Panza. It wouldn't be right to have Sancho taller than Don Quioxote.

I've been really impressed by the overall quality of this show. As the orchestra is onstage in the wings, I haven't seen the full show. But from where I sit, the cast seems really strong, the orchestra solid, the lighting and sound great, and the reviews have been comparing us to professional productions. Even my wife, whose honest opinion I respect, said it's probably one of the best SDG shows she's seen over the years. Community theater can sometimes be hit or miss, this was a definite hit.

This next weekend is the last weekend of the run, so if you feel like a seeing a great show, please come on down. There are a few tickets available still.

by Brad Wetmore - I Have Met "The Man," and The Tail Will Not Be Pretty.

Brad Wetmore — Wed, 05 Mar 2008 14:53:40 +0000

I love "dives." You know those places that you look at from the outside, and say..."hmm..." But with lines out the door, you know they must be doing something right. Once you get inside, you know there's something special going on in the kitchen. My wife has always accused me of taking her to only the "finest" establishments, but this one almost killed her.

A little backstory: As my little brother was graduating from college, he was seduced by the Dark Side and moved to Redmond Washington to work for the large unnamed software company based there. coughcough\*bluescreenofdeath\*coughcough It made for interesting family dinner conversations, as dad was always trying to get his boys to talk smack about each other's company. Sorry, Dad, I'm not Scott McNealy!

Apparently all visitors to the Microsoft campus have to make the pilgrimage to Dixie's BBQ in Bellevue. The walls are adorned with about a dozen maps each with hundreds of colorful pins, each signifying where a previous customer was born. The place is infamous for its colorful characters, pretty good BBQ, and "The Man."

So how does one describe "The Man?" Imagine one of the lowest fiery Circles of Hell, say those reserved for corrupt politicians, people who commit simony, or OpenJDK developers who break the build. Now imagine these people are served a nice BBQ lunch. As this is Hell, the BBQ sauce is punishingly spicy, somewhere just between "Dave's Insanity Sauce" and "Lord, if you would just remove this molten lava from my mouth, I won't ever _______ again!!!" Now, place a couple of gallons of that BBQ sauce in a large cauldron, and allow it to simmer/reduce for several years, to the volume of a small quart pot. Now give this pot to a Bellevue Washington restaurateur named Gene Porter, and have him walk around his restaurant asking if you've met "The Man."

Fortunately, for most people, Gene is nice, and only dips the tip of a toothpick into his concoction, or if you're unlucky, the tip of a spoon. Whatever you do, don't say something stupid like say "I love hot sauce!" For those ~~idiots~~people, Gene scrapes the bottom of the pot. Trust me, you don't want to be anywhere near when that happens.

For years my brother had warned us about "The Man". I've even had some at family picnics. But until last weekend, I'd never had it straight from the pot. Whoa Nelly! Fortunately, I was in control of the camera, and got to capture my wife's reaction. She's not normally that pink! It took 15 minutes and a lot of peanuts, but was finally able to speak again. She gave us a very memorable quote: "That would make a great diet aid!" I wasn't sure if she meant on the way in, or out.

A few other reviews of "Dixie's":

http://seattlepi.nwsource.com/business/131302_momentwith18.html
http://www.seattledining.com/ARCHIVE/restaurants/dixies.htm

by Brad Wetmore - Leave me alone, I'm on vacation!

Brad Wetmore — Thu, 14 Feb 2008 17:02:14 +0000

I've got no qualms about giving my all when I'm working. I've done the long days, the long nights, the long weekends. But when I officially pull the plug and go on vacation, I expect to be able to leave Sun behind, and enjoy some well-deserved time off without any reminders of what I do the rest of the year.

I don't think that's too much to ask. But have you ever tried to unplug yourself completely when you work for a "network" company like Sun?

I first noticed it on a trip to Nepal. I had just finished a rather stressful project, and was glad to be getting away. But as I'm walking between planes in Bangkok, there's a 20 foot ad image of then-CEO Scott McNealy, smiling with his big toothy grin from his perch on the wall, reminding me that "Sun in the . (dot) in dot com."

Trip to Brazil. Sun's being profiled in the in-flight magazine. Trip to Spain/Portugal: Sun's being advertised on a whole wall of posters in a small city. Ok, gloves are off. Hawaii? Nope, there's a high-tech design exhibit in SFO United Terminal featuring all kind of high-tech product designs. I was halfway through before I saw the case that featured a Sun Ray. Dagnabit!!!

Out of all the buildings in Sydney, Australia, our route took us right by the Sydney sales office. Cameroon? I thought for sure, I stood a fighting chance. Nope. I forget what I saw in the Cook Islands, but was not amused.

I guess it's good to work for a company with a global presence. But just for a couple days a year, can't you just leave me alone¹?

On the other hand, I'm glad I don't work for another unnamed large software company. I don't know how many times I've walked by an airport flight status board only to see an infamous "Blue Screen of Death." It does give me a chuckle.

1. Maybe now I'm looking for Sun references just to keep the streak alive.

by Brad Wetmore - "You're a...Gatekeeper? Uh huh. What's a Gatekeeper?"

Brad Wetmore — Mon, 11 Feb 2008 15:12:41 +0000

(You might want to read Kelly O'Hair's "OpenJDK Mercurial Wheel" blog entry before reading this.)

Besides my normal job as a developer in the Java Security and Networking (JSN) and the Java Tools/Libraries (TL) groups, I have been tasked from time to time as the "Gatekeeper" (also known as an "Integrator") for the JSN group. Some of you have asked on the IRC channel #openjdk, "What's a Gatekeeper?" Good question. Ask any of the N gatekeepers, and you'll get N different answers.

Since I'm a musician by night, I had to distill it down to a song that's been running through my head this morning (with apologies to Donny and Marie Osmond, as I'm an unfortunate product of the 1970's):

I'm a little bit Developer,
And I'm a little bit Release Engineer.
I've got a little bit of SHA-1 and Blowfish,
With a whole lot of Makefiles in my soul.
Don't know if it's good or bad,
but I know I love it so...

Ok, scratch those last two lines. Gatekeeper is an under-recognized, thankless, but absolutely necessary (IMHO) job.

A quick bit of terminology:

MASTER repository: The master workspace from which products are eventually built. All changes eventually filter into this set of repositories. Also known as "The Golden Source", "Top Level Workspace", or more concretely:
http://hg.openjdk.java.net/jdk7/jdk7
Group repository: The repository that individual developers clone and where they eventually submit their work for inclusion in the MASTER repository. Developers generally work in the group repository assigned to their functional group. (e.g. JSN, TL, 2D, etc). In my case:

http://hg.openjdk.java.net/jdk7/jsn

Repository Updates: The process by which changes are merged and placed into a shared repository. This is performed by a developer in the case of Dev/Group repositories, or by a special person called a Gatekeeper(below) who merges the Group/MASTER repositories. There are two types of updates:

Rebase: The process of bringing down code from higher-level repositories to local repositories (e.g. MASTER to JSN, or JSN to DEV). Rebasing is done fairly frequently (I try to do it daily).
Integration: The process of pushing up changes from a repository to a higher-level repository (e.g. DEV to JSN, or JSN to MASTER). The gatekeeper is sometimes also known as an "Integrator" as they will be "integrating" changes into the MASTER. Gatekeeper integrations are generally done every two weeks or as needed.

So, what is a Gatekeeper? At a high level, we're the technical liaisons between specific development groups and Release Engineering (RE). It's our job to take changes from developers via the group repositories, merge them with the MASTER repositories, then build/test those changes. If all looks good, move the changes into the appropriate repositories. If all doesn't look good, I put on my archaeologist hat, go figure out what broke, and why. Hearing from your gatekeeper is not the way to start your day.

Why have a gatekeeper? Why not just integrate directly into the MASTER? A couple of reasons:

Less breakage: Assume for a second that developers could integrate their code directly to the MASTER repositories. If new code breaks the build, EVERYONE is affected, not just a smaller subgroup.
Let changes bake with your technical peers before releasing to the world. Each gatekeeper is responsible for a specific functional area. (S)he can run tests specifics to that area, and find problems before they ever reach the MASTER. As brilliant as our RE organization is, they are not going to want to investigate why obj.toString() is now throwing a NoSuchMethodError.
Quiescent Source Base during Integrations: Changsets need to fit well with previous changesets. In a project this large, the build/test cycle can take several hours. Thus, the source base needs to be unchanging during this period so Gatekeepers can build/test/integration with the current bits. If First-Come-First-Served integrations were allowed, your careful build/test cycle could be invalidated by someone changing a single line somewhere. You could hope/pray that your changes are compatible, but that's far too risky. Thus Gatekeepers are assigned specific time slots (currently 12 hours), and are guaranteed only they have write-access to the MASTER repositories during that time. This hierarchy model has proved the most expedient for the large numbers of changes that happen in this project.

So what do I actually do? Again, each gatekeeper will give different answers, but basically, here's what the job involves:

Provide a stable gate for my developers (also affectionately known as "gatelings").
Merge and build the repositories nightly on as many platforms as possible (solaris-sparc/solaris-sparcv9, solaris-i586/solaris-amd64, linux-i586/linux-amd64, and windows-i586). My builds include most repositories (jdk, deploy, langtools, jax\*, etc.). I generally don't build docs/install/etc.
Most gatelings generally only need build the 1-2 repositories they are directly modifying, but sometimes their changes will incompatibly affect other workspaces. Gatekeepers are the last line of defense before that code hits the MASTER, so I need to assure myself that your changes won't break the rest of the product. Developers should be doing this themselves, but it's a sad fact that not everyone is as responsible when it comes to build/testing their code.
Test nightly. Depending on the functional group, there are several test suites available. In my case, I have the developer unit/regression tests (in the test subdirectory of each repository), the JCK, and the internal Sun Software Quality Engineering (SQE) tests.
About a week before an integration, provide builds to the SQE teams. They have a procedure called "Pre-Integration Testing" (aka PIT), which is a much more involved testing process than the gatekeepers could run nightly.. Gatekeepers normally build/test on specific reference OS (e.g. Microsoft Windows Server 2000), but the SQE teams will test on many of the other available platforms (e.g. Windows XP, Windows Vista, etc.). If all goes well, they will issue a test report called a "PIT Certificate," which is their blessing that the expected changes don't appear to break anything.
Copy changesets from one set of repositories to the other. (Rebase/Integration)
Update bug status to reflect the changesets just put into the MASTER.
Breathe a sigh of relief, I'm done! (For this week anyways...). Oh, and...
Pray integrator with the next slot does not call you at home in 6 hours, especially if you have the afternoon/evening integration.

In theory, the MASTER should never be broken, we work pretty hard to make sure that doesn't happen, and it's pretty rare. The group repositories...well, let's just say it does happen on occasion. Don't make me come find you because your integration broke the build, neither of us will have a good day. ;)

That's pretty much it. Gatekeeper officially takes about 50% of time. (I always crack myself up when I say that!)

Only true gearheads/propellerheads need continue.

What's that you say, you want even more specifics? (curious little bugger, aren't you! ;) )

Why have yet another set of repositories for the build/test/integrate phase? Simple, the process can be done in a disposable area (the blue 'JSN Gatekeeper' box above). In case of problems like a bad merge or other breakage, we can simply blow away these repositories and start over.

Ok...how about some pseudo code to make this a little more concrete? Understand I'm doing a lot of handwaving here, otherwise I'll be here all night simplifying the scripts I currently use. (Each gatekeeper usually has their own set of scripts, because each gates tends to have different requirements.)

If I'm doing an integration build to the MASTER, wait until the gate has been released by the previous gatekeeper. Pray the previous gatekeeper didn't introduce any problems.

% hg fclone JSN ws
% hg pull MASTER ws
% cd ws
% hg fmerge/fupdate
% hg foutgoing JSN
% hg foutgoing MASTER
% webrev JSN MASTER

% gnumake long_list_of_options all                                     # on all platforms
% cd jdk/test; jtreg -testjdk:path_to_built_jdk long_list_of_testdirs  # on all plaforms
% cd JCK6a; javatest -cp:path_to_JCK long_list_of_tests                # on all platforms
% kickOffInternalSQETests.sh                                           # on all platforms

I generally build both the product and OpenJDK variants. At this point, examine all the build logs. Everything needs to be clean. If not, find out why.

If we're creating PIT builds, send these bits to the SQE teams for testing. Wait for your PIT Certificate, then repeat the steps above when ready to integrate.

If I'm rebasing (roughly nightly):

% hg foutgoing JSN               # Make sure you're putting the expected bits back.
% hg fpush JSN

If everything looks good and it's integration day:

% hg foutgoing MASTER            # Make sure you're putting the expected bits back.
% hg fpush MASTER
% mail -s "JSN Integration complete" jdk-gk@openjdk.java.net

There are several variations on the theme, but those are the main steps.

I hope that gives you a little more background about what it is we do. There's a lot of gatekeeper lore I could regale you with, such as the noose made out of a power cable reserved for folks guilty of committing really heinous acts of carelessness, but I'll save that for another post.

by Brad Wetmore - Nice Overview for Getting Started with OpenJDK

Brad Wetmore — Mon, 11 Feb 2008 15:08:35 +0000

Lars Westergren posted an article in his blog about what the OpenJDK project is and how it works. I found it to be a great overview, as he did a nice job on culling information from various sources and presenting it in a very coherent manner.