On Mon, Mar 03, 2014 at 09:33:45PM +0000, Viktor Dukhovni wrote:
> The advertised message length (in the MAIL FROM:<...> SIZE= message
> from the Exim SMTP client) works out to: 31 * 8189 + 3302 bytes.
> (Exim seems to send 8189 bytes of plaintext per SSL write).
It is interesting that the difference between the MAIL FROM: message
size and the data received before the fatal alert is 1023 bytes.
> On the wire we do indeed seem to observe random padding from Exim,
> where the client's TLS records are randomly somewhat larger than
> expected.
>
> The connection breaks after transmitting the 31 full length frames
> while sending the final frame. The final TCP packet before OpenSSL
> complains contains a full TLSv1 record of length 2464, which is
> quite a bit shorter than what I would expect. I think something
> is wrong on the sending side, but this one has me stumped.
>
> Can you verify the length of the plaintext payload?
What was the real message size, and what was its last line?
Was the message content (with CRLF line endings) 256138 bytes?
Wireshark shows the received text ending with
[6781168.980137] php5-cgi[13658] general protection ip:6aae67 sp:7fff1c9fc6c0 error:0 in php5-cgi[400000+74a000]\r\n
The fact that it ends at a line boundary, suggests that perhaps
this is the real end of the message, in which case the connection
did break just before ". CR LF".
It is also interesting that the payload of the last packet is
decrypted successfully by wireshark, perhaps wireshark does not
check the MAC.
--
Viktor.
