The Supreme Goodness, Water-Like Xuelei Fan's Blog

These days, I was asked about a strange network delay of input/output stream when migrating a TLS protected application to a new platform. The application is built on top of SunJSSE. They enabled debug with option "-Djavax.net.debug=all", however, because there is no timestamp in the debug output, the debug logging was not of much help.

Is there any way to enable JSSE debug logging with timestamp?  Definitely, the answer is YES.  It is straightforward.

Firstly,  create a class extends PrintStream,and override all println() methods. I used a static nested class here.

    final static class TimestampPrintStream extends PrintStream {
        TimestampPrintStream(PrintStream out) {
            super(out);
        }

        public void println() {
            timestamp();
            super.println();
        }

        public void println(boolean x) {
            timestamp();
            super.println(x);
        }

        public void println(char x) {
            timestamp();
            super.println(x);
        }

        public void println(int x) {
            timestamp();
            super.println(x);
        }

        public void println(long x) {
            timestamp();
            super.println(x);
        }

        public void println(float x) {
            timestamp();
            super.println(x);
        }

        public void println(double x) {
            timestamp();
            super.println(x);
        }

        public void println(char x[]) {
            timestamp();
            super.println(x);
        }

        public void println(String x) {
            timestamp();
            super.println(x);
        }

        public void println(Object x) {
            timestamp();
            super.println(x);
        }


        private void timestamp() {
            super.print("<Thread Id: " + Thread.currentThread().getId() + ">" +
                        "<Timestamp: " + System.currentTimeMillis() + ">    ");
        }
    }
 

Surely, you can change the timestamp() to what kind of codes you like. 

        if (true) {
            AccessController.doPrivileged(new PrivilegedAction<Void>() {
                public Void run() {
                    System.setOut(new TimestampPrintStream(System.out));
                    System.setErr(new TimestampPrintStream(System.err));
                    return null;
                }
            });
        } 

Certificate Types

RFC5280 categorize certificate into two classes: CA certificates and end entity certificates, and CA certificates are divided into three classes: cross-certificates, self-issued certificates, and self-signed certificates.

certificate +- CA certificate

+- cross-certificate

+- self-issued certificate

+- self-signed certificat

     +- end entity certificate

"Cross-certificates are CA certificates in which the issuer and subject are different entities. Cross-certificates describe a trust relationship between the two CAs." [RFC5280]

"Self-issued certificates are CA certificates in which the issuer and subject are the same entity. Self-issued certificates are generated to support changes in policy or operations." [RFC5280]

"Self-signed certificates are self-issued certificates where the digital signature may be verified by the public key bound into the certificate. Self-signed certificates are used to convey a public key for use to begin certification paths." [RFC5280]

Self-signed certificates are speicial slef-issied certificates, so we also can redraw the above tree as:

certificate +- CA certificate

+- cross-certificate

+- self-issued certificate

+- self-signed certificat

     +- end entity certificate

Notes of Self-Signed Certificate

1. "The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate." [RFC5280]

2. "When the trust anchor is provided in the form of a self-signed certificate, this self-signed certificate is not included as part of the prospective certification path." [RFC5280]

Note of Self-Issued Certificate

1. "Name constraints are not applied to self-issued certificates (unless the certificate is the final certificate in the path)." [RFC5280]

2. "However, a CA may issue a certificate to itself to support key rollover or changes in certificate policies. These self-issued certificates are not counted when evaluating path length or name constraints."

3. The pathLenConstraint field of basic constrains extension "gives the maximum number of non-self-issued intermediate certificates that may follow this certificate in a valid certification path."

4. The valude of inhibit anyPolicy extension "indicates the number of additional non-self-issued certificates that may appear in the path before anyPolicy is no longer permitted."

Identify a Self-Issued Certificate

RFC5280 requires that if the names in the issuer and subject field in a certificate match according to the comparison rules of internationalized names in distingushed names, then the certificate is self-issued. Please refer to section 7.1 of [RFC5280] about the comparison rules.

However, RFC3280 does not define the comparison rules, which requires that, "A certificate is self-issued if the DNs that appear in the subject and issuer fields are identical and are not empty." The specificate implies a binary comparison of the subject and issuer fields.

I think a good practice would have the same binary subject and issuer fields while issue a self-issued certificate.

Identify a Self-Signed Certificate

Sounds like a stupid title, just as its name implies, it is self signed, so it is self identifiable, i.e., the public key bound into the certificate could be used to verify the digital signature of the same certificate. Definitely, it's true. OK, we get a bi-steps process:

1. identify that a certificate is a self-issued certificate;

2. Verify the certificate digital signature with the public key bound.

That's a precious process, but not a effective process. Digital signature verify normally hurts a lot of performance, and generally it is not needed to verify the digital signature during build a prospective certification path.

Identify a Self-Signed Certificate Effectively

Self-signed, in another words, the key bound into the certificate is the same as the key used to sign the certificate. Could we identify it by comparing the key bound and the key used to generate the certificate signature? Here comes the authority key identifier extension and the subject key identifier extension, refer to RFC3280/RFC5280 for details.

To facilitate certification path construction, the specification requires that the authority key identifier extension and the subject key identifier extension MUST be appear in all conforming CA certificate. "There is one exception; where a CA distributes its public key in the form of a "self-signed" certificate, the authority key identifier MAY be omitted."

With the help of the two key identifier extensions, we get the following steps:

1. identify that a certificate is a self-issued certificate;
2. for conforming CAs, if the subject key identifier extension appears, but no authority key identifier extension, it is a self-signed certificate; if the both appear, it is a self-signed certificate when the KeyIdentifier is identical.
3. for non-conforming CAs, Verify the certificate digital signature with the public key bound.

Suggested Practices:

1. Always issue certificate with subject key identifier extension and authority key identifier extension.

2. Always include the keyIdentifier field in the authority key identifier extension.

3. Always have the same binary subject and issuer fields while issue a self-issued certificate.

4. Only issue self-issued certificate as CA certificate.

5. For TLS, always send the intermediate self-issued certificate within the response certificate list, otherwise, the recepient normally cannot build a certification path to its trust anchors.

The Problemtic Practices Encountered

1. A self-signed CA certificate issues 1+ self-issued end entity certificates.

There is no problem to issue such self-issued End-Entity certificate, but I'm afraid many PKIX libraries would not be able to handle it properly. If your application dependents on third party's PKIX library, and if you have to issue such certificates, please do check the library and make sure it supports such cases.

2. A self-signed CA certificate issues a self-issued certificate as an indirect CRL issuer.

It is special example of self-issed end-entity certificate. Some CRL verification library cannot handle such a indirect CRL issuer correctly, please double check the library to make sure such indirect CRL issuer is supported.

Java SE SDK support the above two problemtic cases at OpenJDK 7 build 60. If you application have to support above cases, you need OpenJDK 7 build 60 at least.

TLSAES defines AES ciphersuites for TLS, and from TLS version 1.1, the AES cipher suites are merged in TLS specification. The AES supports key lengths of 128, 192 and 256 bits.  However, the TLSAES specification only defines ciphersuites for 128-bits and 256-bits keys.

In Java security context, there is a important concept, "jurisdiction policy". The JCA framework includes an ability to enforce restrictions regarding the cryptographic algorithms and maximum cryptographic strengths available to applets/applications in different jurisdiction contexts (locations). Any such restrictions are specified in "jurisdiction policy files".

Due to import control restrictions by the governments of a few countries, the jurisdiction policy files shipped with the JDK from Sun Microsystems specify that "strong" but limited cryptography may be used. An "unlimited strength" version of these files indicating no restrictions on cryptographic strengths is available for those living in eligible countries (which is most countries). But only the "strong" version can be imported into those countries whose governments mandate restrictions. The JCA framework will enforce the restrictions specified in the installed jurisdiction policy files. 

According to the default jurisdiction policy, AES_128 is the "strong" cryptography, but AES_256 is one of "unlimited strength" cryptographies, which means that AES_256 cannot be used with the default installed JDK jurisdiction policy files 

From JDK1.4.2, the SunJSSE provider supports a number of AES_128 and AES_256 cipher suites. In 1.4.2, AES_256 cipher suites were not enabled, even if the unlimited strength JCE jurisdiction policy files were installed. From J2SE 5.0, AES_256 cipher suites are enabled automatically if the unlimited strength JCE jurisdiction policy files are installed.

OK, then here comes the conclusion now:

1. For JDK 1.4.2, one need to explicit set the AES cipher suites in the codes in order to get it enabled. 

2. For AES 128 cipher suites, one can use it with the default installed JDK.

3. TLS does not define AES_192 cipher suites. 

4. For AES 256 cipher suites, one need to use the "unlimited strength" jurisdiction policiy files.

For JDK 6, the "unlimited strength" jurisdiction policiy files could be downloaded from "Other Downloads" on http://java.sun.com/javase/downloads/index.jsp, and there is a README file inside, which describe the export/import issues, and how to install the additional policies. Please DO read the export/import lines and make sure you are allowed to use those "unlimited strength" policies.

In the Java™ 6 Security Enhancements, it says that "The SunJSSE provider now supports an experimental FIPS 140 compliant mode.  When enabled and used in combination with the SunPKCS11 provider and an appropriate FIPS 140 certified PKCS#11 token, SunJSSE is FIPS 140 compliant."  Except that, we cannot find any more document on how to enable FIPS mode and how the FIPS mode works with SunJSSE. Normally, developers could a few hints from Andreas blog,. The Java PKCS#11 Provider and NSS, althought it is far from enough to understand the FIPS mode of SunJSSE. The following is a unpublished document, hope it helps.

FIPS 140 Compliant Mode for SunJSSE

In Sun's Java SE implementation version 6 or later, the SunJSSE provider, which contains the SSL/TLS implementation, can be configured to operate in a FIPS 140 compliant mode instead of its default mode. This document describes the FIPS 140 compliant mode (subsequently called "FIPS mode").

Configuring SunJSSE for FIPS Mode

SunJSSE is configured in FIPS mode by associating it with an appropriate FIPS 140 certified cryptographic provider that supplies the implementations for all cryptographic algorithms required by SunJSSE. This can be done in one of the following ways:

1. edit the file ${java.home}/lib/security/java.security and modify the line that lists com.sun.net.ssl.internal.ssl.Provider to list the provider name of the FIPS 140 certified cryptographic provider. For example if the name of the cryptographic provider is SunPKCS11-NSS, change the line from

     security.provider.4=com.sun.net.ssl.internal.ssl.Provider

   to

     security.provider.4=com.sun.net.ssl.internal.ssl.Provider SunPKCS11-NSS

   The class for the provider of the given name must also be listed as a security provider in the java.security file.

2. at runtime, call the constructor of the SunJSSE provider that takes a java.security.Provider object as a parameter. For example, if the variable cryptoProvider is a reference to the cryptographic provider, call new com.sun.net.ssl.internal.ssl.Provider(cryptoProvider).

3. at runtime, call the constructor of the SunJSSE provider that takes a String object as a parameter. For example if the cryptographic provider is called SunPKCS11-NSS call new com.sun.net.ssl.internal.ssl.Provider("SunPKCS11-NSS"). A provider with the specified name must be one of the configured security providers.

Within a given Java process, SunJSSE can be used either in FIPS mode or in default mode, but not both at the same time. Once SunJSSE has been initialized, it is not possible to change the mode. This means that if one of the runtime configuration options is used (option 2 or 3), the configuration must take place before any SSL/TLS operation.

Note that only the specified configured provider will be used by the SunJSSE for any and all cryptographic operations. All other cryptographic providers including those included with the Java SE implementation will be ignored and not used.

Difference Between FIPS Mode and Default Mode

In FIPS mode, SunJSSE behaves in a way identical to default mode, except for the following differences.

In FIPS mode:

• SunJSSE will perform all cryptographic operations using the cryptographic provider that was configured as described above. This includes symmetric and asymmetric encryption, signature generation and verification, message digests and message authentication codes, key generation and key derivation, random number generation, etc.

• If the configured cryptographic provider reports any error by throwing an exception, SunJSSE will abort the current operation and propagate the exception to the application.

• If the configured cryptographic provider believes it had a critical error such as a self test failure per FIPS guidelines, it needs to remain in an error state until it is re-initialized. The application using the SunJSSE configured with the FIPS cryptographic module will have to be restarted. This ensures that the FIPS module will not allow critical errors to compromise security.

• Only TLS 1.0 and later can be used. SSL 2.0 and SSL 3.0 are not available. Any attempt to enable SSL 2.0 or 3.0 will fail with an exception.

• The list of ciphersuites is limited to those that utilize appropriate algorithms. The current list of possible ciphersuites is given below. Any attempt to enable a ciphersuite not on the list will fail with an exception.

Ciphersuites Usable in FIPS Mode

The following is the current list of ciphersuites which can be used by SunJSSE in FIPS mode with their names and the id as assigned in the TLS protocol provided that the configured cryptographic FIPS module supports the necessary algorithms. Note that although SunJSSE uses the prefix SSL_ in the name of some of these ciphersuites, this is for compatibility with earlier versions of the specification only. In FIPS mode, SunJSSE will always use TLS 1.0 or later and implement the ciphersuites as required by those specifications.

SSL_RSA_WITH_3DES_EDE_CBC_SHA	0x000a
SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA	0x0016
TLS_RSA_WITH_AES_128_CBC_SHA	0x002f
TLS_DHE_DSS_WITH_AES_128_CBC_SHA	0x0032
TLS_DHE_RSA_WITH_AES_128_CBC_SHA	0x0033
TLS_RSA_WITH_AES_256_CBC_SHA	0x0035
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	0x0038
TLS_DHE_RSA_WITH_AES_256_CBC_SHA	0x0039
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA	0xC003
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA	0xC004
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA	0xC005
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA	0xC008
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA	0xC009
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	0xC00A
TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA	0xC00D
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA	0xC00E
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA	0xC00F
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA	0xC012
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	0xC013
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	0xC014
TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA	0xC017
TLS_ECDH_anon_WITH_AES_128_CBC_SHA	0xC018
TLS_ECDH_anon_WITH_AES_256_CBC_SHA	0xC019

Conclusion

When SunJSSE is configured in FIPS 140 compliant mode together with an appropriate FIPS 140 certified cryptographic provider, for example Network Security Services (NSS) in its FIPS mode, SunJSSE is FIPS 140 compliant.