Tuesday, December 22, 2009

Chrome, SSL and Tomcat - or other JSSE-based engines

If you try to use Chromium with a java server running https - be aware of  this bug:
http://bugs.sun.com/view_bug.do?bug_id=6728126

Chrome will use a nice TLS extension - RFC4507, SessionTicket - to allow servers to reuse the session without a second roundtrip and without having to cache the session ( which is quite tricky if you use load balancing - there is no easy way in java to do so ). Of course - JSSE doesn't support the extension, the bug is that it can't even ignore it. Besides saving the roundtrip this also saves some CPU time on both ends - good thing chrome added this.

I spent some time today trying to figure out what was happening - the good news seems to be that it's fixed in recent jdk builds. Unfortunately ubuntu doesn't have the fix yet (not even Karmic), and probably Mac is also behind.

Filed a chrome bug as well - I think reversing the order of SessionTicket and hostname extension would solve this.

The server name extension is another nice thing - it allows chrome to specify which host it's looking for in the first ClientHelo packet - so server can send the right certificate. The "Host" header will be sent after the encryption is started - this is why many https servers require one IP address per host and can't do virtual hosting with SSL.

1 comment:

jowdjbrown said...

These powerful little tools are just another great reason to hop on the Google Chrome train. chrome extension development