TLS library problem

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS library problem

linkcheck
I have had a few complaints about emails bouncing over the past
week-ish, specifically from a single dynamic IP. Have now found a few
lines in the logs that seem to indicate the problem. Nothing has been
changed (that I know of) apart from a point or two of the Ubuntu
version, so why is there a problem, what is the cause and what can I do
about it, please?

Log lines are as below for two apparently immediate attempts (sender
redacted):

May 13 12:16:22 BRISTOLWEB postfix/submission/smtpd[12960]: connect from
(redacted)]
May 13 12:16:22 BRISTOLWEB postfix/submission/smtpd[12960]: Anonymous
TLS connection established from (redacted): TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
May 13 12:16:24 BRISTOLWEB postfix/submission/smtpd[12960]: ACA963200DC:
client=(redacted), sasl_method=PLAIN, sasl_username=(redacted)
May 13 12:16:24 BRISTOLWEB postfix/cleanup[12927]: ACA963200DC:
message-id=<d1744276-a395-1e8f-3f19-7147190a024e@(redacted)>
May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: warning: TLS
library problem: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac:s3_pkt.c:532:
May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: lost
connection after DATA (16372 bytes) from (redacted)
May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: disconnect
from (redacted) ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 commands=6/7
May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: connect from
(redacted)
May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: Anonymous
TLS connection established from (redacted): TLSv1.2 with cipher
ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
May 13 12:16:35 BRISTOLWEB postfix/submission/smtpd[12960]: CE4553200DC:
client=(redacted), sasl_method=PLAIN, sasl_username=(redacted)
May 13 12:16:35 BRISTOLWEB postfix/cleanup[12927]: CE4553200DC:
message-id=<388cf74f-ff63-70da-aa61-b65277af849a@(redacted)>
May 13 12:16:37 BRISTOLWEB postfix/submission/smtpd[12960]: warning: TLS
library problem: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
failed or bad record mac:s3_pkt.c:532:
May 13 12:16:37 BRISTOLWEB postfix/submission/smtpd[12960]: lost
connection after DATA (139212 bytes) from (redacted)
May 13 12:16:37 BRISTOLWEB postfix/submission/smtpd[12960]: disconnect
from (redacted) ehlo=2 starttls=1 auth=1 mail=1 rcpt=1 data=0/1 commands=6/7

Versions:
server: Linux Mint 18.1 (Ubuntu 16.04.12)
postfix: 3.1.0
openssl: 1.0.2g


--
Dave Stiles
Reply | Threaded
Open this post in threaded view
|

Re: TLS library problem

Wietse Venema
Linkcheck:
> May 13 12:16:25 BRISTOLWEB postfix/submission/smtpd[12960]: warning: TLS
> library problem: error:1408F119:SSL routines:SSL3_GET_RECORD:decryption
> failed or bad record mac:s3_pkt.c:532:

Choose one or more.

1: broken TCP or broken proxy.

    The TCP content was modified in transit, resulting in TLS MAC
    mismatch. Something bad happens before the TCP checksum is
    (re)computed or after the TCP checksum is verified. The TCP
    stack would not pass packets whose TCP checksum don't match the
    TCP payload.

    This may include middleboxes that modify TCP in transit, for
    example, for traffic shaping purposes. For an example of TCP
    data corruption caused by a traffic shaping middlebox, see
    ftp://ftp.porcupine.org/pub/debugging

2: broken TLS.

    Something bad happened while the sending TLS encrypted data or
    computed the TLS MAC, or while the receiving TLS decrypted data
    or verified the TLS MAC.

3: data-dependent data corruption at any layer in the stack.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: TLS library problem

Wietse Venema
In reply to this post by linkcheck
Linkcheck:

> Thank you for your response, Wietse. Apologies for the delay in my
> reply. I read the document you suggested and noted the possible scenario
> but cannot ascribe it to this situation.
>
> I have been finding out a bit more about the problem.
>
> The sender and his son have been getting problems when sending some
> attachments. A 13K pdf was delivered without error, images from 100K to
> 1M and above are usually stopped on the first attempt with the error
> mentioned. Further immediate attempts (several seconds delay only) to
> send the message seem to succeed on a second or third attempt.

Data corruption errors are difficult to diagnose. The solution is
to replace components one by one until the faulty component is
identified. That includes hosts and the network path between them.

For example if hostA+pathB+hostC fails reliably, but hostA+pathX+hostC
succeeds reliably, then that suggests that the problem is in
hostA+pathB or in pathB+hostC.

> The messages originate from three different computers, all recent ubuntu
> OS, all in the same house. The router is zyxel - several years old and
> never updated but I can find nothing to suggest this may be the culprit.
> The messages go over talktalk broadband on port 587 to my server.
>
> The same attachments sent using the talktalk mail server are accepted
> first try.
>
> None of my other customers has a problem sending attachments. I sent one
> to this sender with 4 20M pictures with no problem.

I suppose those other customers have other network providers.

If that is the case, then I speculate that talktalk is preventing
their customers from sending large email messages directly, and
requires that talktalk customers send through the talktalk server
instead. This is a fairly common malware countermeasure.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: TLS library problem

linkcheck
In reply to this post by linkcheck
Thank you for that, Wietse.

I'm inclined to agree that talktalk is at fault here, allowing a second
try to succeed.

Has anyone here found this problem with talktalk?

--
Dave Stiles