Java and security bits

Final Approval Ballot for the Java Smart Card I/O API (JSR 268)

The polls have closed and the results are in. That is, the results for the JCP Final Approval Ballot for JSR 268 (Java Smart Card I/O API). You can read the detailed results on the JCP web site. This happened in sync with the vote on the JDK 6 platform JSRs as explained in Danny's blog. I am also happy to report that this election cost some 2.8 billion USD less than a certain other election ;-)

The actual final release of JSR 268 will happen in sync with the release of JDK 6 later this year. But the javadoc specification and information about the SunPCSC provider implementation is also available as part of the JDK 6 documentation now. Similarly, the reference implementation is bundled with JDK 6 and available for download from java.net.

Finally, let me thank the expert group and everyone else outside and inside of Sun who contributed to this project for getting us to this stage. We're all better off for it.

Posted at 18:17 Nov 07, 2006 by Andreas Sterbenz in JSR 268  |  Comments[3]

My reasons for choosing ZFS

A few weeks ago I migrated the data on my main development and build server to a ZFS pool. Let me explain why performance was not the most important reason to choose ZFS.

Discussions of ZFS and filesystems in general seem to quickly degenerate into performance discussions. Maybe that is because most filesystems are very similar in all other respects, but ZFS has so much more to offer that just talking about performance misses the most important points. Don't get me wrong: performance is clearly a precondition. If a filesystem does not perform competitively, nobody will use it. And ZFS performs very well and is still getting better with performance fixes going in all the time. But my reasons for choosing ZFS were different:

1. Data integrity: ZFS provides much better data integrity than other common filesystems because of 2 key differences: transactions and checksums. ZFS is a transactional copy-on-write filesystem: each operation either succeeds or it does not. Either way you have a consistent on-disk state - if the commit failed you merely revert to the previous state from some 5 seconds ago. All this holds even in the presence of a volatile disk write cache. In addition, ZFS keeps strong hierarchical checksums of all data. They make it possible to reliable verify that the data is valid.

   Compare that to traditional filesystems and the particular problem that made me switch: I had some data on a disk with a UFS filesystem. For some reason the disk stopped responding temporarily (problem with disk? software? a power fluctuation? who knows). After a reboot, Solaris was not happy with the disk and told me to run fsck. I did, and fsck reported some cryptic messages about problems it found and fixed. After that I could access the disk again, but did I lose any files? Did any files get corrupted? There is no way to know! (other than to compare with a backup)

   With ZFS, the disk would not have gotten into this state, plus I could have run zpool scrub to verify that all data on the disk was still intact and not corrupted. As far as I am concerned, this alone is reason enough to use ZFS whenever I can. The choice between strong verifiable data integrity and limited non-verifiable data integrity is no choice at all! All the other ZFS features are merely a bonus, but keep reading.

2. Easy administration: all sysadmins are overworked, so easy administration is important to everyone. But it is even more important to people like myself, who have a full time day job and merely spend a couple of hours a month on sysadmin tasks. In other words, I have lot more time for forget stuff :-( ZFS has built-in support for mirroring and RAID, which has traditionally been performed by a different piece or hardware or software with its own administrative interface. In ZFS, this is integrated and designed to be as simple as possible. You only need to know two commands: zpool and zfs.

3. Easy data migration: if the server ever dies, all I need to do is find another Solaris machine with SATA ports, plug in the disks, and type zfs import. No need to find a machine with a matching hardware RAID controller. No need to find a machine with the matching CPU architecture (SPARC or x86). No need to connect the disks to the right ports in the right order (ZFS finds the data anyway). No RAID configuration data or mountpoint information to migrate (ZFS stores all configuration information in the pool).

   And if I ever want to move the data to a different set of disks, ZFS also includes fast and easy zfs send and zfs receive commands.

4. Snapshots: ZFS supports an unlimited number of constant-time snapshots. If I need to look at the state of a workspace from last week, I just do so. And because ZFS is copy-on-write, snapshots take only as much disk space as is necessary to store the changes.

5. New features are still being added: such as double-parity RAID (RAID-Z2), clone promotion, iSCSI integration, delegated administration, encryption, and improvements to the Solaris install experience (especially liveupgrade).

   And of course since it is completely open source, ports to other platforms are already in progress.

To me ZFS is one of those trailblazing technologies that are destined to be used (or imitated) by everyone. As soon as you hear about the concept for the first time, it makes complete sense and the only question you ask yourself is why didn't I think of that? Just like a portable, multi-threaded, secure programming platform (Java), multicore processors (Niagara UltraSPARC-T1), or transportable easy-to-deploy datacenters (Project Blackbox).

PS: the next entry will be about Java topics again ;-)

Posted at 18:18 Nov 04, 2006 by Andreas Sterbenz in General  | 

Firefox 2.0, ECC, and Java

Firefox 2.0 was just released today, you should get it! Among many other features it includes support for SSL/TLS ciphersuites that utilize Elliptic Curve Cryptography (ECC). They interoperate very nicely with the ECC support in JDK 6 that I described some time ago (here and here).

As Firefox enables these ciphersuites by default, you can try this out by visiting an ECC enabled HTTPS site such as this one. If you are using Firefox 2.0, it will probably tell you Negotiated ciphersuite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, which means it used ECDSA for authentication and an ephemeral ECDH key to exchange the session key. Sun's Java implementation does not (yet) support ECC out-of-the-box, so you will need to configure the JRE to use an ECC crypto provider such as SunPKCS11 with the NSS library as described in my earlier blog entries.

For the morbidly curious, the JSSE debug output for an ECC TLS handshake with Firefox 2.0 is shown below:

bin/java -cp classes -Djavax.net.debug=ssl SSLServer -password password -port 8083 -p12 pkcs12/secp256r1server-secp256r1ca.p12 -ciphersuites .*_EC.*

Adding NSS provider...
keyStore is : pkcs12/secp256r1server-secp256r1ca.p12
keyStore type is : PKCS12
keyStore provider is : 
init keystore
init keymanager of type SunX509
***
found key for : secp256r1server-secp256r1ca
chain [0] = [
[
  Version: V1
  Subject: CN=dev.experimentalstuff.com, OU=Test Server (secp256r1server-secp256r1ca), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  Signature Algorithm: SHA1withECDSA, OID = 1.2.840.10045.4.1

  Key:  SunPKCS11-NSS EC public key, 256 bits (id 1, session object)
  public x coord: 32131082739532309006052354335386898145283035488892917034979324518693567360460
  public y coord: 108304381050564926916211693822155985180348458417372376821658769170362639725898
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
  Validity: [From: Tue Dec 06 13:30:15 PST 2005,
               To: Thu Jan 14 13:30:15 PST 2010]
  Issuer: CN=dev.experimentalstuff.com, OU=Test CA (secp256r1), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  SerialNumber: [    a0dd4f0c 73b5c23a]

]
  Algorithm: [SHA1withECDSA]
  Signature:
0000: 30 45 02 20 7F BE 32 64   5A 63 B2 21 C9 27 22 E8  0E. ..2dZc.!.'".
0010: 71 9F B0 00 83 A2 D9 43   0E DE A4 BE 92 4E 09 35  q......C.....N.5
0020: D0 4B 41 BC 02 21 00 C0   D0 3E E3 FC 15 78 4B ED  .KA..!...>...xK.
0030: 8D E9 DD 80 B5 FB 89 C3   4A DF 72 F9 DD F2 BD 0A  ........J.r.....
0040: A8 99 A2 F7 E2 C3 BA                               .......

]
***
trustStore is: pkcs12/secp256r1server-secp256r1ca.p12
trustStore type is : PKCS12
trustStore provider is : 
init truststore
adding as trusted cert:
  Subject: CN=dev.experimentalstuff.com, OU=Test Server (secp256r1server-secp256r1ca), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  Issuer:  CN=dev.experimentalstuff.com, OU=Test CA (secp256r1), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  Algorithm: EC; Serial number: 0xa0dd4f0c73b5c23a
  Valid from Tue Dec 06 13:30:15 PST 2005 until Thu Jan 14 13:30:15 PST 2010

trigger seeding of SecureRandom
done seeding SecureRandom
Listening...
matching alias: secp256r1server-secp256r1ca
Connection from /127.0.0.1
Thread-0, READ: TLSv1 Handshake, length = 185
*** ClientHello, TLSv1
RandomCookie:  GMT: 15888 bytes = { 64, 161, 128, 199, 146, 107, 162, 95, 29, 73, 13, 5, 223, 120, 148, 21, 50, 68, 61, 200, 17, 226, 46, 42, 77, 179, 114, 175 }
Session ID:  {69, 62, 246, 109, 153, 30, 123, 84, 183, 67, 29, 156, 133, 193, 76, 64, 230, 194, 153, 93, 254, 242, 146, 178, 173, 144, 51, 34, 153, 248, 234, 163}
Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA]
Compression Methods:  { 0 }
Unsupported extension server_name, [host_name: dev.experimentalstuff.com]
Extension elliptic_curves, curve names: {secp256r1, secp384r1, secp521r1}
Extension ec_point_formats, formats: [uncompressed]
***
%% Created:  [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA]
*** ServerHello, TLSv1
RandomCookie:  GMT: 1161756607 bytes = { 253, 125, 68, 91, 100, 9, 6, 184, 5, 4, 122, 216, 183, 79, 152, 18, 205, 16, 151, 32, 138, 154, 67, 155, 128, 162, 222, 236 }
Session ID:  {69, 63, 0, 191, 127, 74, 29, 254, 94, 30, 26, 14, 173, 161, 253, 198, 208, 57, 252, 107, 203, 64, 38, 187, 181, 66, 145, 180, 38, 76, 234, 141}
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Compression Method: 0
***
Cipher suite:  TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
*** Certificate chain
chain [0] = [
[
  Version: V1
  Subject: CN=dev.experimentalstuff.com, OU=Test Server (secp256r1server-secp256r1ca), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  Signature Algorithm: SHA1withECDSA, OID = 1.2.840.10045.4.1

  Key:  SunPKCS11-NSS EC public key, 256 bits (id 1, session object)
  public x coord: 32131082739532309006052354335386898145283035488892917034979324518693567360460
  public y coord: 108304381050564926916211693822155985180348458417372376821658769170362639725898
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
  Validity: [From: Tue Dec 06 13:30:15 PST 2005,
               To: Thu Jan 14 13:30:15 PST 2010]
  Issuer: CN=dev.experimentalstuff.com, OU=Test CA (secp256r1), O=Sun Microsystems Laboratories, L=Mountain View, ST=CA, C=US
  SerialNumber: [    a0dd4f0c 73b5c23a]

]
  Algorithm: [SHA1withECDSA]
  Signature:
0000: 30 45 02 20 7F BE 32 64   5A 63 B2 21 C9 27 22 E8  0E. ..2dZc.!.'".
0010: 71 9F B0 00 83 A2 D9 43   0E DE A4 BE 92 4E 09 35  q......C.....N.5
0020: D0 4B 41 BC 02 21 00 C0   D0 3E E3 FC 15 78 4B ED  .KA..!...>...xK.
0030: 8D E9 DD 80 B5 FB 89 C3   4A DF 72 F9 DD F2 BD 0A  ........J.r.....
0040: A8 99 A2 F7 E2 C3 BA                               .......

]
***
*** ECDH ServerKeyExchange
Server key: SunPKCS11-NSS EC public key, 256 bits (id 4, session object)
  public x coord: 41103551421670399341109836546875106890936913242778497772126996963565414237940
  public y coord: 239613684122793889555242688840662389694935726465297515556106527987677658165
  parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7)
*** ServerHelloDone
Thread-0, WRITE: TLSv1 Handshake, length = 811
Thread-0, READ: TLSv1 Handshake, length = 70
*** ECDHClientKeyExchange
ECDH Public value:  { 4, 203, 29, 110, 133, 147, 5, 220, 231, 168, 164, 2, 246, 207, 244, 15, 53, 226, 183, 34, 159, 145, 237, 3, 5, 116, 206, 129, 26, 185, 56, 23, 1, 77, 143, 62, 113, 35, 33, 205, 197, 222, 186, 246, 230, 80, 110, 6, 58, 209, 190, 83, 64, 171, 238, 106, 235, 142, 14, 116, 83, 177, 185, 159, 119 }
Finalizer, called close()
Finalizer, called closeInternal(true)
Finalizer, SEND TLSv1 ALERT:  warning, description = close_notify
Finalizer, WRITE: TLSv1 Alert, length = 2
SESSION KEYGEN:
PreMaster Secret:
0000: 77 B3 89 45 81 06 95 72   1E EE 7F A8 B6 1A 78 71  w..E...r......xq
0010: 0B 96 16 FE 1B 12 43 69   DE 0A BA 0C A5 3A 41 9D  ......Ci.....:A.
CONNECTION KEYGEN:
Client Nonce:
0000: 00 00 3E 10 40 A1 80 C7   92 6B A2 5F 1D 49 0D 05  ..>.@....k._.I..
0010: DF 78 94 15 32 44 3D C8   11 E2 2E 2A 4D B3 72 AF  .x..2D=....*M.r.
Server Nonce:
0000: 45 3F 00 BF FD 7D 44 5B   64 09 06 B8 05 04 7A D8  E?....D[d.....z.
0010: B7 4F 98 12 CD 10 97 20   8A 9A 43 9B 80 A2 DE EC  .O..... ..C.....
Master Secret:
0000: 1B 70 B1 AF BF 7C 0B C5   BC B0 5A 79 20 98 B7 BF  .p........Zy ...
0010: 39 C3 4E 0F E1 AC BC 67   F2 C4 24 6D 3A 4A E0 C8  9.N....g..$m:J..
0020: 21 78 25 14 92 EC 1A 5B   6F 8F 19 9E 27 4B 71 71  !x%....[o...'Kqq
Client MAC write Secret:
0000: 43 FB F8 40 62 B3 38 AA   F0 A8 5B 99 8A 5D 78 97  C..@b.8...[..]x.
0010: A0 C6 45 06                                        ..E.
Server MAC write Secret:
0000: 9F B5 91 77 85 41 93 B5   B2 AB 8D 7E 94 DC 30 FB  ...w.A........0.
0010: 08 F6 78 A0                                        ..x.
Client write key:
0000: 31 49 24 99 73 3C 66 6D   0C F2 BC A7 6A 34 19 AC  1I$.s<fm....j4..
0010: A3 B0 DA F8 8A 57 18 B1   E5 A2 3F FF 9C 3E 3A A1  .....W....?..>:.
Server write key:
0000: 3F F3 3D 37 44 7C B8 19   60 1E 56 D0 CE D2 20 07  ?.=7D...`.V... .
0010: EE FD 21 85 3F A5 07 5F   81 65 D7 D5 D4 98 03 FF  ..!.?.._.e......
Client write IV:
0000: 0D 75 A3 41 22 59 67 E8   35 E8 F8 DC 35 57 AB AD  .u.A"Yg.5...5W..
Server write IV:
0000: F8 02 F5 1D F5 05 A4 0A   0B 75 78 84 E3 F2 F9 38  .........ux....8
Thread-0, READ: TLSv1 Change Cipher Spec, length = 1
Thread-0, READ: TLSv1 Handshake, length = 48
*** Finished
verify_data:  { 193, 184, 147, 61, 66, 171, 182, 226, 135, 95, 174, 87 }
***
Thread-0, WRITE: TLSv1 Change Cipher Spec, length = 1
*** Finished
verify_data:  { 25, 166, 97, 246, 183, 66, 43, 44, 142, 13, 157, 113 }
***
Thread-0, WRITE: TLSv1 Handshake, length = 48
%% Cached server session: [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA]
%% Invalidated:  [Session-1, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA]
Ciphersuite TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
Thread-0, READ: TLSv1 Application Data, length = 672
Thread-0, WRITE: TLSv1 Application Data, length = 368
Thread-0, called close()
Thread-0, called closeInternal(true)
Thread-0, SEND TLSv1 ALERT:  warning, description = close_notify
Thread-0, WRITE: TLSv1 Alert, length = 32
Thread-0, called close()
Thread-0, called closeInternal(true)

Posted at 23:09 Oct 24, 2006 by Andreas Sterbenz in Java  | 

First public specification of the Java Module System (JSR 277)

The early draft specification of the Java Module System (JSR 277) was posted this week. This is what I have been spending most of my time on recently, working with Stanley Ho (spec lead) on specification issues for the expert group and taking the lead on the core aspects of the alpha implementation.

The specification may seem dense, but the basic concepts are fairly straightforward. Start by reading chapter 1 and section 2.1. They also explain the main rationale for the Java Module System: the standard runtime deployment concepts of Java SE - classpath and jre/lib/ext - are insufficient for large systems that run code from many different parties within the same VM process (for example, Application Servers). People have managed to work around these limitations using the extensible features of the Java platform, in particular ClassLoaders. But that is error prone and the platform should really have a built-in standard solution.

The result are Modules, which have stable names, define their supported APIs, and their dependencies on other modules. A Module is packaged into a Java Module archive (JAM file), which is deployed into a Repository. There will be private, per-user, and per-system Repositories. At runtime, we create Module instances, automatically resolve their dependencies, and setup the appropriate ClassLoaders. This allows different Modules to coexist in the same process without interfering with each other.

The Java Module System takes advantage of JSR 294 which is called Improved Modularity Support in the Java Programming Language. It will result in language and VM specification changes that allow developers to define the module information in a Java source file, which is compiled and verified by javac. This construct will also be understood by the VM, which uses it to enforce access control.

An important aspect of the Java Module system is its pluggability. The Repository class is extensible allowing 3rd parties to deliver their own implementations. Similarly, we want to make Module itself pluggable to allow developers to use module systems not based on JSR 294 within the same framework, as long as that module system follows compatible concepts.

You should understand that the current spefication of JSR 277 is literally an Early Draft. Many details are missing and the API is tentative. The reason it was published is to gather feedback from the community. Send it to the expert group at jsr-277-comments@jcp.org.

Posted at 15:17 Oct 15, 2006 by Andreas Sterbenz in Modularity  |  Comments[7]

No more 'unable to find valid certification path to requested target'

Some of you may be familiar with the (not very user friendly) exception message
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
when trying to open an SSL connection to a host using JSSE. What this usually means is that the server is using a test certificate (possibly generated using keytool) rather than a certificate from a well known commercial Certification Authority such as Verisign or GoDaddy. Web browsers display warning dialogs in this case, but since JSSE cannot assume an interactive user is present it just throws an exception by default.

Certificate validation is a very important part of SSL security, but I am not writing this entry to explain the details. If you are interested, you can start by reading the Wikipedia blurb. I am writing this entry to show a simple way to talk to that host with the test certificate, if you really want to.

Basically, you want to add the server's certificate to the KeyStore with your trusted certificates. There are any number of ways to achieve that, but a simple solution is to compile and run the attached program as java InstallCert hostname, for example

% java InstallCert ecc.fedora.redhat.com
Loading KeyStore /usr/jdk/instances/jdk1.5.0/jre/lib/security/cacerts...
Opening connection to ecc.fedora.redhat.com:443...
Starting SSL handshake...

javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:150)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1476)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:174)
	at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Handshaker.java:168)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:846)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:106)
	at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Handshaker.java:495)
	at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Handshaker.java:433)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:815)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1025)
	at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1038)
	at InstallCert.main(InstallCert.java:63)
Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:221)
	at sun.security.validator.PKIXValidator.engineValidate(PKIXValidator.java:145)
	at sun.security.validator.Validator.validate(Validator.java:203)
	at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(X509TrustManagerImpl.java:172)
	at InstallCert$SavingTrustManager.checkServerTrusted(InstallCert.java:158)
	at com.sun.net.ssl.internal.ssl.JsseX509TrustManager.checkServerTrusted(SSLContextImpl.java:320)
	at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:839)
	... 7 more
Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(SunCertPathBuilder.java:236)
	at java.security.cert.CertPathBuilder.build(CertPathBuilder.java:194)
	at sun.security.validator.PKIXValidator.doBuild(PKIXValidator.java:216)
	... 13 more

Server sent 2 certificate(s):

 1 Subject CN=ecc.fedora.redhat.com, O=example.com, C=US
   Issuer  CN=Certificate Shack, O=example.com, C=US
   sha1    2e 7f 76 9b 52 91 09 2e 5d 8f 6b 61 39 2d 5e 06 e4 d8 e9 c7 
   md5     dd d1 a8 03 d7 6c 4b 11 a7 3d 74 28 89 d0 67 54 

 2 Subject CN=Certificate Shack, O=example.com, C=US
   Issuer  CN=Certificate Shack, O=example.com, C=US
   sha1    fb 58 a7 03 c4 4e 3b 0e e3 2c 40 2f 87 64 13 4d df e1 a1 a6 
   md5     72 a0 95 43 7e 41 88 18 ae 2f 6d 98 01 2c 89 68 

Enter certificate to add to trusted keystore or 'q' to quit: [1]

What happened was that the program opened a connection to the specified host and started an SSL handshake. It printed the exception stack trace of the error that occured and shows you the certificates used by the server. Now it prompts you for the certificate you want to add to your trusted KeyStore. You should only do this if you are sure that this is the certificate of the trusted host you want to connect to. You may want to check the MD5 and SHA1 certificate fingerprints against a fingerprint generated on the server (e.g. using keytool) to make sure it is the correct certificate.

If you've changed your mind, enter 'q'. If you really want to add the certificate, enter '1'. (You could also add a CA certificate by entering a different certificate, but you usually don't want to do that'). Once you have made your choice, the program will print the following:

[
[
  Version: V3
  Subject: CN=ecc.fedora.redhat.com, O=example.com, C=US
  Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4

  Key:  SunPKCS11-Solaris RSA public key, 1024 bits (id 5158256, session object)
  modulus: 1402933022884660852748661816869706021655226675890
635441166580364941191074987345500771612454338502131694873337
233737712894815966313948609351561047977102880577818156814678
041303637255354084762814638611185951230474669455913908815827
173696651397340074281578017567044868711049821409365743953199
69584127568303024757
  public exponent: 65537
  Validity: [From: Wed Jan 18 13:16:12 PST 2006,
               To: Wed Apr 18 14:16:12 PDT 2007]
  Issuer: CN=Certificate Shack, O=example.com, C=US
  SerialNumber: [    0f]

Certificate Extensions: 2
[1]: ObjectId: 2.16.840.1.113730.1.1 Criticality=false
NetscapeCertType [
   SSL server
]

[2]: ObjectId: 2.5.29.15 Criticality=false
KeyUsage [
  Key_Encipherment
]

]
  Algorithm: [MD5withRSA]
  Signature:
0000: 6D F4 2A 63 76 2A 05 70   A2 21 0E 1E 4A 31 BE 6B  m.*cv*.p.!..J1.k
0010: 15 64 D8 BB 35 36 82 B0   0D 2A 96 FA 7A 9F A1 59  .d..56...*..z..Y
0020: CA 90 C3 28 C5 A6 9B 59   05 3B EB B2 8D C9 5E 38  ...(...Y.;....^8
0030: 62 ED 1A D7 93 DF 2A A5   D6 54 94 23 15 A2 0C E5  b.....*..T.#....
0040: 13 40 2C 3E 59 E4 2A EB   51 AC 9E 28 44 23 87 B1  .@,>Y.*.Q..(D#..
0050: 34 0B AC F3 E0 39 CA B8   35 B4 78 07 BF 28 4C C4  4....9..5.x..(L.
0060: 9A 2B A3 E9 04 26 78 19   F0 62 EA 0A B5 BB DC 0B  .+...&x..b......
0070: 90 59 E7 77 90 F8 BC 8A   1B 74 4B 4D C1 F8 3B 6C  .Y.w.....tKM..;l

]

Added certificate to keystore 'jssecacerts' using alias 'ecc.fedora.redhat.com-1'

It displayed the complete certificate and then added it to a Java KeyStore 'jssecacerts' in the current directory. To use it in your program, either configure JSSE to use it as its trust store (as explained in the documentation) or copy it into your $JAVA_HOME/jre/lib/security directory. If you want all Java applications to recognize the certificate as trusted and not just JSSE, you could also overwrite the cacerts file in that directory.

After all that, JSSE will be able to complete a handshake with the host, which you can verify by running the program again:

% java InstallCert ecc.fedora.redhat.com
Loading KeyStore jssecacerts...
Opening connection to ecc.fedora.redhat.com:443...
Starting SSL handshake...

No errors, certificate is already trusted

Server sent 2 certificate(s):

 1 Subject CN=ecc.fedora.redhat.com, O=example.com, C=US
   Issuer  CN=Certificate Shack, O=example.com, C=US
   sha1    2e 7f 76 9b 52 91 09 2e 5d 8f 6b 61 39 2d 5e 06 e4 d8 e9 c7 
   md5     dd d1 a8 03 d7 6c 4b 11 a7 3d 74 28 89 d0 67 54 

 2 Subject CN=Certificate Shack, O=example.com, C=US
   Issuer  CN=Certificate Shack, O=example.com, C=US
   sha1    fb 58 a7 03 c4 4e 3b 0e e3 2c 40 2f 87 64 13 4d df e1 a1 a6 
   md5     72 a0 95 43 7e 41 88 18 ae 2f 6d 98 01 2c 89 68 

Enter certificate to add to trusted keystore or 'q' to quit: [1]
q
KeyStore not changed

I hope that helps. For more information about the InstallCert program, have a look at the source code. I am sure you can figure out how it works.

Posted at 22:28 Oct 09, 2006 by Andreas Sterbenz in Java  |  Comments[1]

Proposed Final Draft of JSR 268 (Smart Card I/O)

The Proposed Final Draft of the Java Smart Card I/O API has just been posted on the JCP web site.

This is largely identical to the Public Draft and only contains some minor clarifications. This version has also been incorporated into recent JDK 6 builds. If you have any last minute feedback about JSR 268, please send it to jsr-268-comments@jcp.org.

PS: I have been rather busy with JDK 7 work recently, but I hope to post another blog entry or two within the next few weeks.

Posted at 13:46 Oct 02, 2006 by Andreas Sterbenz in JSR 268  | 

Security feature planning for JDK 7

We are currently in the process of deciding on the security features to tackle for JDK 7. Actually, we have in various stages of this planning process for quite a while.

There is no shortage of ideas, but we want to get some more community input in order to collect additional requests and to help us prioritize our feature list. This is where this blog comes in:

Let us know your suggestions for features in the security area including topics such as crypto, PKI, SSL, Kerberos, security manager + policy, authorization + JAAS, SASL, XML security, secure coding, performance, ease of use and administration, and everything else related to security. Or if you don't have a specific suggestion but find that there are some things that really annoy you or that you cannot do, we want to hear about that us well.

If you have any suggestions or requests, please leave a comment or (if you prefer) send mail to andreas.sterbenz@sun.com. We appreciate all feedback! If you don't mind, include your company name and an email address so that we can get back to you in case of further questions.

Disclaimer: for completeness, I have to point out that due to our limited resources, we will not be able to accomodate all requests. Also, all Java SE platform features are subject to JCP approval.

Posted at 18:26 Aug 23, 2006 by Andreas Sterbenz in Java  | 

Smart Card I/O updates now part of JDK 6 snapshots

A quick note to point out that the latest JDK 6 snapshot now includes the JSR 268 API and implementation changes from the JCP Public Review specification mentioned earlier. You can download the binaries and source from the JDK 6 java.net site or view the JavaDocs online.

PS: Make sure to read the Open Source progress update from Mark. I am looking forward to this new world myself.

Posted at 11:36 Aug 15, 2006 by Andreas Sterbenz in JSR 268  | 

Public Review of JSR 268 (Smart Card I/O)

The JCP Public Review draft of JSR 268 (Smart Card I/O API for Java SE) was posted on the JCP web site this evening. You can download the specification here.

There are a significant number of clarifications and a few API changes in this version compared to the JCP early draft last year, which is what is currently shipping as part of Sun's Mustang implementation. Probably the most significant API change is the introduction of a new CardTerminals class to support a simpler "wait for card insertion/removal" model. The full set of changes listed in the draft is:

• Added ATR.getHistoricalBytes()
• Described how implementations should open and close logical channels
• Described how implementations should handle GET RESPONSE
• Moved methods from TerminalFactory to a new CardTerminals class
• Added CardTerminals.waitForChange() to replace TerminalFactory.waitForCardPresent()
• Removed INS_* constants from CommandAPDU
• Changed types from byte to int in CommandAPDU and ResponseAPDU (CLA, SW1, etc.)
• Clarified that Properties should be used as configuration parameters if possible
• Numerous Doc clarifications

As mentioned, the docs are available for review on the JCP web site now. The integration of these spec changes and corresponding updates to the SunPCSC provider implementation is scheduled for Mustang b95, which should be posted on the Mustang java.net site by August 11. If you have any comments about this draft, please send them to jsr-268-comments@jcp.org. This draft includes several changes in response to such earlier feedback.

Looking forward, the plan of the expert group is to discuss the remaining open issues and any additional feedback we receive so that we can move towards final release as part of Sun's JDK 6 implementation later this fall. At this point, I also want to express my thanks to all expert group members for their valuable comments, often under a tight schedule. Their insights have led to many improvements to the spec, which will benefit the entire Java community! Thanks!

Posted at 23:34 Jul 18, 2006 by Andreas Sterbenz in JSR 268  | 

Default SSLContext and SSLParameters

They say you cannot claim to have a blog unless you post something at least once a month. That means I am due ;-) So let me talk a bit about a couple of small API changes we made in JSSE: SSLContext.getDefault() and the new SSLParameters class.

The first set of changes relate to the default SSLContext. You are probably familiar with the getDefault() methods in SSLSocketFactory and SSLServerSocketFactory. These default factories are associated with a default SSLContext. Before JDK 6, there were a couple of problems with this SSLContext:

• the only way to configure the key managers and trust managers of the default SSLContext (in the SunJSSE implementation) was via system properties. Although that may be convenient during development, putting passwords into insecure system properties is definitely not appropriate on production systems.

• it was not possible to get an SSLContext object for the default context. That meant it was not usable with APIs that needed to access the SSLContext object. For example, creating an SSLEngine via the SSLContext.createSSLEngine() call.

The fix is pretty straightforward: we introduced the SSLContext.getDefault() and SSLContext.setDefault() methods. SSLSocketFactory.getDefault() and SSLServerSocketFactory.getDefault() were redefined to call SSLContext.getDefault(), unless the legacy security properties are set. SSLContext.getDefault() itself is specified to use the standard Provider architecture and call SSLContext.getInstance("Default").

SSLContext.setDefault() allows an application to programmatically set the default context to any initialized SSLContext object. That makes it possible to move away from using insecure system properties. For Dolphin, we are also considering introducing a framework that allows you to configure default private key and trust anchor stores on a per user and per application basis.

The second change I want to talk about is the new SSLParameters class. It encapsulates the configuration parameters of an SSL endpoint, in particular the ciphersuites, protocol versions, and for servers the client authentication requirements. They can be applied with a single call to SSLSocket.setSSLParameters() or SSLEngine.setSSLParameters().

The purpose of the class is to allow for more convenient configuration. It was introduced to support the embedded light-weight HTTP server API, but it is helpful in other situations as well.

Finally, on a more personal note, today is also the day of my fifth anniversary at Sun. Time sure flies! When I joined, we were just finishing up Merlin (JDK 1.4.0). My first real project was to change the SunJSSE code so that it could utilize JCE crypto providers. Before then, it only called its own internal crypto code using a proprietary API. As it happens, in Tiger I worked on that code again, this time to completely remove the JSSE internal crypto code and have it rely on JCE providers exclusively. And in Mustang, I touched it yet again. This time for the FIPS 140 compliance work, moving the session key generation code so that even that is now handled by JCE providers. We will see if I have to work on that code yet again in Dolphin. Regardless, I am definitely looking forward to my next five years here!

Posted at 15:30 Jul 16, 2006 by Andreas Sterbenz in Java  |  Comments[1]

Mustang Security Docs Updated

I finally got around to updating the security documentation with all the new features added in Java SE 6 that I have been talking about over the past few months ([1], [2], [3], [4], [5]). Let's go through the list on the security enhancements summary page on java.net.

There are the new NSS configuration directives for the Sun PKCS#11 provider, plus the list of ECC mechanisms it now understands. Both of these features work very nicely with the Elliptic Curve Ciphersuites in SunJSSE. I have also updated the pluggability section in JSSE to note that all restrictions have been removed. Last but not least, we have the JSR 268 JavaDocs. BTW, you can expect some more news about the progress of 268 right here in a few weeks.

These Docs are on java.net now. The same features are also in the code of the quietly released Mustang beta2 (see also this overview), but they did not make the beta2 docs bundle. The updated docs will be in the Java SE 6 RC (and GA) docs with some further documentation improvements. There are a few security features that have not been fully documented yet.

Finally, I wanted to point out that in beta2 Iris and Alan fixed the mapped ByteBuffer bug that was pointed out here a couple of months ago. Alan is hoping to have a more complete solution in Dolphin, but in the meantime this should resolve the problem of running out of address space quite adequately.

Posted at 11:06 Jun 16, 2006 by Andreas Sterbenz in Java  | 

ECC Updates and RFC 4492

Mustang build 85 was just posted to java.net. It includes the fix for 6414980, which are the ECC changes I alluded to last time. Specifically it:

• adds support for the Signature algorithms SHA256withECDSA, SHA384withECDSA, and SHA512withECDSA

• changes the default keysize/curve to NIST P-256 for interoperability and NSA Suite B compliance

• fixes a bug in the encoding of the Supported Elliptic Curves Extension in SunJSSE

• updates to the PKCS11 KeyStore to fully support EC keys plus some other KeyStore changes to better interoperate with NSS and other tokens

While on the topic of ECC, I also need to point out that Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) has now been issued as RFC 4492 as announced in this message. Congratulations to all the authors, in particular fellow Sun employees Vipul Gupta and Nelson Bolyard.

Posted at 00:50 May 26, 2006 by Andreas Sterbenz in Java  | 

Slides for Secure Coding Antipatterns: Avoiding Vulnerabilities

I hope you all had a good time at JavaOne this year, whether you attended in person or watched the webcasts and presentation slides online. I certainly enjoyed it, but I am still recovering from the experience of 10:30pm BOFs.

Charlie and I were quite happy with our session about secure coding. Thanks for attending and asking lots of good questions. The slides are available on the JavaOne site, but they contain a number of formatting errors and a small bug. The updated presentation should be posted there within a couple of weeks, but in the meantime you can also download the final version here.

Posted at 22:33 May 19, 2006 by Andreas Sterbenz in Java  |  Comments[1]

Andy B at Stanford

Andy Bechtolsheim, Sun co-founder and employee #1, gave a talk at Stanford this week, see the webcast. It was about High Performance Compute Clusters focusing on the interconnect fabric (Ethernet, Infiniband, Myrinet), so not exactly my area. Still, I find it very refreshing to listen to him. He always speaks his mind (no sugar coating) and he is as confident presenting the 20.000 feet architect's as view as the 10 inch implementer's view, getting down to minute details.

So check out the Stanford webcast. If you like it, you can of course find lots of other material featuring Andy, including the Sun founders panel and a pair of podcasts that explore Sun's history and the Galaxy Opteron servers (part 1 and part 2).

Posted at 14:39 May 14, 2006 by Andreas Sterbenz in General  | 

Java Secure Coding Talk at JavaOne

It's that time of year again - JavaOne season. This year Charlie Lai and I are presenting a session entitled Secure Coding Antipatterns: Avoiding Vulnerabilities. The short short summary is that many security incidents are caused by bugs that follow recurring antipatterns. We use past Java security issues to explain such mistakes and show how to avoid them. See also the session abstract on the JavaOne site.

You may think that you don't have to care about security issues, but you really should care! As it turns out, the majority of security incidents occur in seemingly innocous components that do not appear to be relevant to security at all. The reason is that although Java takes care of a lot of problems for you, such as array bounds checking to avoid buffer overflows, there are still issues all code needs to pay attention to. That is what the talk is all about. Plus, you will even learn the answers to some longstanding questions, for example what the initialized flag and the check() method in java.lang.ClassLoader are all about.

If you are interested, it is TS-1238 on Thursday from 1:30pm to 2:30pm in Gateway 102/103. The Java SE security group also has a Q&A BOF on Thursday from 10:30pm to 11:20pm, also in Gateway 102/103 (BOF-0600).

PS: some other talks I plan to check out: "Solving the Mysteries of the Java Technology Class Loader" (BOF-0300), "Dynamically Typed Languages on the Java Platform" (TS-3886), "Superpackages: Development Modules in Dolphin" (TS-3885), "JSR-277: Java Module System" (BOF-0684), "What Is Happening With New I/O" (BOF-0895), "How to Build a Scalable Multiplexed Server With NIO" (TS-1315), "Confessions of a JVM Software Writer" (BOF-0377), of course the Josh and Neal talks, and various others. (Sorry, no links -- getting tired)

Posted at 03:56 May 10, 2006 by Andreas Sterbenz in Java  |