Concern

I’ve just merged the contents of my branch of Classpath that I was doing the SSL/NIO work in back into the generics branch. This completes three of the four objectives I set out for my Summer of Code project, with the fourth being optional. These objectives were:

1. That the SSL library in GNU Classpath be rewritten to use the NIO model of the JSSE (that is, to write an implementation of the SSLEngine class).
2. That the blocking-IO SSL classes in GNU Classpath be rewritten to use the NIO classes.
3. That a complete unit test suite be written, which exercises the library with both partial and complete sample SSL connections. These tests should be integrated into the Mauve test suite (see http://sourceware.org/mauve/).
4. (Optional, if there is time) That we augment a free Java servlet container (such as GNU Gumdrop) as a test-bed for this library, set up such an instance on a public web server, and run some performance and scalability tests on this server.

The last on the list will have to wait, because Classpath’s non-blocking IO is not in good enough shape to handle a project like this, in my opinion. I’m going to be working on fixing that when I get a chance.

This is good enough to satisfy me for this project. All things considered, it went remarkably well. One major factor in it all coming together so well is the environment that I did my coding in: when I wrote the original version of Jessie, I was unemployed, just out of college (undergrad), and typing on a laptop on my mom’s couch. For the Summer of Code, I took a month of vacation off of work, and sat on my mom’s couch again and coded on my (now much faster, and with a keyboard and battery that works) laptop. The comfort and total lack of distraction really helped, and I was able to finish the bulk of the work in only a few weeks.

I’m pretty satisfied with how the code turned out. A big problem with the original implementation was that it did a lot of work in one class, meaning that class was thousands of lines long, and hard to understand. Now, that work is split between a server and a client class, and it does this inside a switch statement, so it’s pretty easy to tell what block of code is doing what.

This was a lot of fun, and I hope I’ll do it again next year!

I’m trying to write some unit tests for Jessie, but I’ve hit a wall: apparently, no software exists that can generate an X.509 certificate with Diffie-Hellman keys, instead of RSA or DSS.

You see, there’s two ways to exchange TLS keys with Diffie-Hellman: one is “ephemeral,” where the server and client generate a brand-new key pair on each connection, and the server signs those parameters with its key, and RSA or DSS key that it includes in its certificate. The other uses the Diffie-Hellman keys present in the server’s certificate, which are signed by the certificate authority. But, I can’t seem to be able to generate such a certificate with OpenSSL, GNU’s keytool implementation, or even Sun’s keytool!

So, since it seems like no TLS software supports generating these certificates, that no-one ever tests these cipher suites in their implementation, and probably don’t work.

Good news! I found the issue that was preventing Jessie from connecting to Google’s SSL server, and now I can establish client connections successfully to a number of different servers. I’ve also added preliminary support for pre-shared key exchange algorithms, and fixed a handful of bugs in the code.

Very soon now the code should be ready to merge back into the generics branch. My goal was to make sure I didn’t introduce any regressions to Classpath (a definite danger when you rewrite something from scratch), and right now it looks damn close. I’m overall pretty satisfied with the code: it’s a lot better than the existing code, and is much more modular and extensible.

One thing I wish TLS had was a way for servers and clients to specify the version of the software they were running. This could be easily accomplished with an extension, it’s just a matter of proposing the standard.

I’ve just checked in another huge chunk of code (and after only three days! It’s astounding how productive I am right now) that implements client-side handshaking and adds support for the legacy blocking-IO API. I’ve also done the necessary step of moving the long-running code from the server handshake into delegated tasks, which are run in helper threads, to avoid blocking the main IO thread. This essentially means that all the pieces comprising this project are in place, and that all that remains is to fix up the rough edges and to polish it up. In other words, I’ve gotten to nearly the 90% mark in a week and a half

But, right now, HTTPS client connections using the URLConnection work again. The only issue right now is that I can’t connect to https://www.google.com/, because their SSL server is returning an error to me! But other HTTPS servers I’ve tried work fine.

Other things I’d like to work on before the summer is over:

• Support for pre-shared key ciphersuites (PSK), described in RFC 4279.
• Support for OpenPGP certificates; still only a draft, but GNUTLS supports these. There are a few free Java OpenPGP versions I could use, but I think the best way may be to write a wrapper for GnuPG.
• Support for secure remote password (SRP) ciphersuites. Also just a draft, but Classpath already has support for SRP built-in. Again, GNUTLS supports these already.
• Kerberos support, from RFC 2712.
• Elliptic curve cryptography cipher suites, from RFC 4492.

I’ve been able to get Firefox to connect to an HTTPS server implemented with the GNU Classpath ssl-nio branch. Some exciting screenshots of the test: the main browser window, and the certificate used.

There are still some bugs left in session continuation, and the test server I’m using seems to dislike the way I handle closed sessions, but I’m getting closer! Next to do is to implement the client-side handshake (this should be pretty easy, now that I’ve got a server handshake sorted out), then to implement a version of SSLSocket around SSLEngine. Then I’ll need to try to add some of the unit tests (along with a few more) to Mauve.

I’m also going to be implementing TLSv1.1, with TLSv1 and SSLv3 compatibility modes, instead of TLSv1, since the 1.1 spec was finalized earlier this year. GNUTLS implements 1.1, but as far as I know, Jessie will be the only JSSE implementation that implements this version of the spec.