On Mon, Mar 03, 2014 at 07:05:45PM +0000, Tony Finch wrote:
> On the server (OpenSSL end) I see:
>
> 2014-03-03 18:28:23 +0000 1WKXbD-0006CZ-Dm TLS error (SSL_read): error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac
> 2014-03-03 18:28:23 +0000 SMTP connection from pip.srcf.societies.cam.ac.uk [131.111.179.83]:39651 I=[131.111.8.135]:25 lost while reading message data
>
> On the client (GnuTLS end) I see:
>
> TLS error on connection to ppsw.cam.ac.uk [131.111.8.135] (recv):
> A TLS fatal alert has been received.: Bad record MAC
>
> This has occurred with at least GnuTLS 2.8.6-1+squeeze2 (Debian) and
> 2.12.14-5ubuntu3.6
>
> With the latter client they negotiate TLS 1.0 and cipher suite
> TLS_RSA_WITH_AES_256_CBC_SHA
>
> There's a pcap of the connection corresponding to the failure above, plus
> a throwaway private key for decrypting the stream at
> http://www-uxsup.csx.cam.ac.uk/~fanf2/tmp/
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).
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?
I guess a note to the GnuTLS list is in order.
--
Viktor.
