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 [email protected] - http://epipe.com/ -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
