On 2012-05-20 16:24, Phil Pennock wrote:
> I find it interesting that ssltap does show the length=4 packet but
> *not* the length=9 packet which GnuTLS claims it was sent.
Look at the log closer:
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[1] Handshake(22) with
length: 455
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[2] Handshake(22) with
length: 460
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[2] Handshake(22) with
length: 749
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[3] Handshake(22) with
length: 754
4011 GnuTLS<4>: REC[0x1213b00]: Sending Packet[3] Handshake(22) with
length: 4
4011 GnuTLS<4>: REC[0x1213b00]: Sent Packet[4] Handshake(22) with length: 9
There are actually two lines for each sent packet. The "Sending" line
and "Sent" line disagree about the packet length consistently with 5.
Thus there is no packet with length 9 but it is the same packet as the
packet with length 4. I suppose one of the log messages includes a
packet header and the other one does not.
> I begin to suspect a GnuTLS bug. Wild uneducated guess is that it's
> related to the client sending elliptic_curves and ec_point_formats in
> its extensions list, since GnuTLS doesn't support those.
I looked the handshake using Wireshark, it seems to be able to decode it
well. It shows something interesting: It is the client (NSS) who closes
the TCP connection right after receiving the "Server Hello" from
Exim/GnuTLS. It looks like NSS is *receiving* something that it does not
like. It would be good to figure out how to get some debug output from
NSS...
--
Janne Snabb / EPIPE Communications
snabb@??? -
http://epipe.com/
