Move forward to use java logging in Oracle JSSE provider
Xuelei Fan
xuelei.fan at oracle.com
Sat Aug 27 13:51:01 UTC 2011
Hi,
At present, Oracle JSSE provider, SunJSSE, uses hard coded System.out to
logger the debug information, with Java option "javax.net.debug".
The benefit of the debug mechanism is that it is simple and
straightforward. The drawback is that it is hard to redirect to other
output stream, hard to parse in multi-threads environment[2], and hard
to customize the output[3].
It might be the time to move forward to use java.util.logging in
SunJSSE, so that SunJSSE would benefit from the framework of
java.util.logging.
We may concern about the following issues:
1. the performance impact.
I would suggest use the coding style:
if (logger != null && logger.isLoggable(Level.WARNING)) {
logger.warning(...);
}
When the logging is turned off, the "logger" will be set to "null",
so that there is no additional performance impact.
Java logging uses fine granulated logging level, as would filter out
a lot of unnecessary log information for some configurations.
2. compatibility issue
We would continue support java option, "javax.net.debug". But the log
output may change. For example, in the past, one log item may look like:
keyStore provider is: jks
In the new implementation, we may add additional thread ID and
time-stamp, it may be changed to:
CONFIG: [TH: 9] 2011-08-26 20:48:28.754 PDT
keyStore provider is: jsk
One more example, in the past, the log ClientHello message may look like:
*** ClientHello, TLSv1.1
RandomCookie: GMT: 1314416910 bytes = { 80, 11, 21, 95, 232, 11,
193, 233, 222, 34, 181, 50, 37, 221, 149, 179, 54, 73, 187, 233, 68, 31,
63, 36, 171, 66, 75, 117}
Session ID: {}
Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA]
Extension renegotiation_info, renegotiated_connection: <empty>
***
In the new implementation, it may be changed to:
INFO: [TH: 10] 2011-08-26 20:48:30.460 PDT
ClientHello, TLSv1.1 {
RandomCookie: GMT: 1314416910 bytes = {30:0B:....}
Session ID: {}
Cipher Suites: [TLS_RSA_WITH_AES_128_CBC_SHA]
Extension renegotiation_info, renegotiated_connection: <empty>
}
3. compatibility issue, continue
If java option "javax.net.debug" is defined, the debug options (see
[1] for the define of the option) may be mapped to three logger:
logger "javax.net.ssl.handshake" will support the following debug
options: handshake, keygen, session, seesioncache.
logger "javax.net.ssl.managerment" will support debug options:
keymanager, trustmanager, sslctx, defaultctx.
logger "javax.net.ssl" will support all other debug options.
4. compatibility issue, more continue
If java option "javax.net.debug" is defined, as past, System.out will
be log output stream unless there is customized logger configurations
for above loggers.
5. default implementation
SunJSSE will only implement the logger handler to support
"javax.net.debug" option, application is free to define/customize its
own logging handler.
There is a prototype for your reference,
http://cr.openjdk.java.net/~xuelei/7013776/webrev/.
Your comment is welcome.
Thanks,
Xuelei
[1]: the usage of "javax.net.debug" option:
------------------------
$ java -Djavax.net.debug=help Foo
all turn on all debugging
ssl turn on ssl debugging
The following can be used with ssl:
record enable per-record tracing
handshake print each handshake message
keygen print key generation data
session print session activity
defaultctx print default SSL initialization
sslctx print SSLContext tracing
sessioncache print session cache tracing
keymanager print key manager tracing
trustmanager print trust manager tracing
pluggability print pluggability tracing
handshake debugging can be widened with:
data hex dump of each handshake message
verbose verbose handshake message printing
record debugging can be widened with:
plaintext hex dump of record plaintext
packet print raw SSL/TLS packets
------------------------
[2]: http://monaco.us.oracle.com/detail.jsf?cr=7013776
[3]:http://sim.ivi.co/2009/05/these-days-i-was-asked-about-strange.html
More information about the security-dev
mailing list