Finder wrote:
I'd seen the references in ssl3con.c but wasn't sure why they were being called. Your analysis at least made me think of the workaround; I disabled all the DHE_* ciphers from the SSL server, and now TBird/PSM works. So I at least have a workaround.
I would like to help with the ssltap idea, but would need some help with that. At least with ethereal, I was seeing the client hello going out, server hello coming back, and then nothing (TBird would then give the error). I think it's because the server was saying that some DHE ciphers were okay to use; and TBird/PSM was trying to see if it could comply, but was unable to generate any DH keypairs. It has no key material to work with nor any DH parameters for the keypairs.
In SSL, the client hello includes a list of cipher suites that are supported/allowed by the client. The server picks one, which must be one that the server also supports and for which the server has been properly configured, and then sends back to the client the server hello, saying "I picked this one". The client must then use the ciphersuite chosen by the server.
For a DHE ciphersuite, the server must send an additional message to the client, immediately after the server certificate. That "server key exchange" message contains the DH params.
I'm guessing that the server negotiated a DHE ciphersuite but then either a) didn't send any server key exchange message, or b) sent a server key exchange message with invalid params.
Output from ssltap (preferably) or ethereal would help determine if that hypothesis is correct. If it is, then this is a server problem, and no change to the client SSL code is required. However, it might be possible to create a better error message, saying something like "mizzing or invalid Server Key Exchange message".
> I could get more
network detail from an ssltap, but I'd need to know where to get a pre-built binary for MS windows (I have never built Mozilla for windows, and don't have the bandwidth just now to learn). But I think it's not going to tell you anything new; I think we'd have to figure out in PSM how to disable trying DH ciphers if there are no DH keys present in the cert store.
For DHE, no DH keys or params are required in the client cert store. The server sends them to the client.
Let me know how I can help further pinpoint the problem.
You can get ssltap.exe and the associated DLLs from ftp://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_9_2_RTM/WIN954.0_OPT.OBJ/nss-3.9.2.zip
ssltap operates like a transparent (or "reverse") proxy (sort of), sitting between the client and server. You don't configure your client to treat it
as a proxy, but rather you point your client to it as if it was the server.
The simplest way to run it usually is to run it on the server machine (to
avoid cert hostname mismatch errors) on a different port than the port
where the normal server runs. It doesn't decrypt anything. It just
formats the data that can be interpreted (e.g. is in the clear).
ssltap -sxlp <tapped-port> <serverhostname>:<serverport>
Where <serverport> is the normal server's normal port number, and <tapped-port> is the port served by ssltap.
e.g.
ssltap -xslp 1993 myhost:993
Then point your client at port 1993 instead of 993 (your get the idea).
ssltap will write output to stdout (and maybe stderr) which you will want to save. It also saves certs it finds in files named cert.nnn, where nnn starts over at 001 each time you start ssltap. ssltap only handles one connection at a time, presently. So, you don't want lots of clients trying to access the <tapped-port>
-- Nelson B _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
