Wednesday January 16, 2008
I wrote about analyzing the Jetty SSL problem. Eventually it turned out, that this is not a problem of Jetty at all (there is the same problem on Tomcat). The problem in fact is related to the used algorithm for key pair generation and signature. If you use RSA Firefox won’t complain after handshake errors, if you use DSA (which is the default when using keytool) you will run into trouble.
So, it looks like this is a Firefox problem, so I have posted again to mozilla.dev.tech.crypto. We’ll see what they say…
Posted on Jan 16, 2008 at 21:36 (MET) |
Permalink |
Thursday January 10, 2008
For Christmas I treated Petra and myself with a LaCie 2big Network (2-disk RAID) drive. The good thing is that it has in fact 2 hard-drives, which may be operated in Raid 1 mode. That way we now have 500 GB of redundant memory.
On the other hand there are some firmware improvements I’d like to see:
- Power-save (silent!) mode. After some idle time-out, the drives should be able to be shut down.
- Wake on LAN. The drive already comes with an “auto” switch, which lets you remotely shut it down. This switch could also be used for power on.
LaCie - pls. think about it!
(Hat tip to Raible, for blogging about this.)
Update: (13/Mar/08) As Victor pointed out Matt didn’t bought that drive. However, I’m still happy with mine.
Posted on Jan 10, 2008 at 21:17 (MET) |
Permalink |
Wednesday January 9, 2008
Over the holidays I debugged a wierd problem with Jetty and Firefox: When Firefox accesses a Webapp running on Jetty over SSL, this will result in a SSLHandshakeException eventually.
To debug this problem, I use ssltap a little tool from Netscape/Mozilla. ssltab is something like a SSL proxy and writes all SSL traffic going through it to the console.
To install it on Windows it is required to download the ZIP file provided here (Unix/Linux is here, README) and copy bin/ssltap.exe and all file from lib/ to somewhere on your path. Additionally you will need the following DLLs on your path, which can be found in the the Firefox installation directory:
nspr4.dll
plc4.dll
plds4.dll
After that ssltap should be able to start. For example, this will let ssltap listen on port 4443 and forward the requrests to port 8443 on your local machine:
ssltap -sxlp 4443 localhost:8443
In my case ssltap I was able to figured out, that Firefox sends a ClientHelloV2 after the handshake failure:
alloclen = 63 bytes
(63 bytes of 63)
[Wed Jan 09 21:07:12 2008] [ssl2] ClientHelloV2 {
version = {0×03, 0×00}
cipher-specs-length = 36 (0×24)
sid-length = 0 (0×00)
challenge-length = 16 (0×10)
cipher-suites = {
(0×000039) TLS/DHE-RSA/AES256-CBC/SHA
(0×000038) TLS/DHE-DSS/AES256-CBC/SHA
(0×000035) TLS/RSA/AES256-CBC/SHA
(0×000033) TLS/DHE-RSA/AES128-CBC/SHA
(0×000032) TLS/DHE-DSS/AES128-CBC/SHA
(0×000004) SSL3/RSA/RC4-128/MD5
(0×000005) SSL3/RSA/RC4-128/SHA
(0×00002f) TLS/RSA/AES128-CBC/SHA
(0×000016) SSL3/DHE-RSA/3DES192EDE-CBC/SHA
(0×000013) SSL3/DHE-DSS/DES192EDE3CBC/SHA
(0×00feff) SSL3/RSA-FIPS/3DESEDE-CBC/SHA
(0×00000a) SSL3/RSA/3DES192EDE-CBC/SHA
}
session-id = { }
challenge = { 0×2ff5 0×68bd 0×2e11 0×903a 0xd40d 0×8809 0×86f7 0×8e0e }
}
]
This is especially wierd, as SSL v2 is disabled in Firefox 2.0. From analyzing SSL traffic and debugging Jetty I guess it seems that this is a race condition somewhere inside Jetty, which results in some response back to Firefox, which messes up the SSL session.
I have started a new thread in Sun’s JSSE forum and mozilla.dev.tech.crypto. I hope someone can help.
References:
[1] Mozilla Developer Center: Introduction to SSL
[2] Mozilla.org: Using the SSL Debugging Tool
Posted on Jan 9, 2008 at 22:14 (MET) |
Permalink |
Tuesday January 8, 2008
I always thought Apache JServ was the predecessor of Tomcat, and I bragged every once in a while about myself using Tomcat before it even was invented.
Today I stumbled across this post which told me, that Tomcat is in fact based on Sun’s Java Web Server and that JServ was ditched by Apache in favour of the Sun’s code base.
:-)
Posted on Jan 8, 2008 at 15:21 (MET) |
Permalink |