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 printl

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 ke

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. F IPS 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"). C onfiguring SunJ

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 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 avai