tls_socket_read (Decryption has failed.)

[Donn Morrison]

Since moving from Ubunutu 12.04 (armel) to 14.04 (armhf) on a Beagleboard I have a persistent problem using mutt where (especially) larger messages fail to download resulting in the error:

tls_socket_read (Decryption has failed.)

The failure is reproducable in that I can almost never download messages with attachments larger than 10MB (it will inevitably fail at some point during the transfer).

12.04 (armel) had gnutls26 verison 2.12.14-5ubuntu3.8, and I never had this problem. 14.04 uses 2.12.23-12ubuntu2.1. Strangely enough my amd64 machines which also run 14.04 and 2.12.23-12ubuntu2.1 do not have this problem.

In attempting to debug I tried setting GNUTLS_DEBUG_LEVEL=6, which didn't produce any output from libgnutls26. Next I tried forcing mutt to use libgnutls28 (3.2.11-2ubuntu1) with LD_PRELOAD. Then setting GNUTLS_DEBUG_LEVEL=6 and redirecting stderr to a file yields the following log:

...
gnutls[4]: REC[0x16cb240]: Expected Packet Application Data(23)
gnutls[4]: REC[0x16cb240]: Received Packet Application Data(23) with length: 1395
gnutls[4]: REC[0x16cb240]: Decrypted Packet[4742] Application Data(23) with length: 1371
gnutls[6]: BUF[REC]: Inserted 1371 bytes of Data(23)
gnutls[4]: REC[0x16cb240]: SSL 3.3 Application Data packet received. Epoch 0, length: 1395
gnutls[4]: REC[0x16cb240]: Expected Packet Application Data(23)
gnutls[4]: REC[0x16cb240]: Received Packet Application Data(23) with length: 1395
gnutls[4]: REC[0x16cb240]: Decrypted Packet[4743] Application Data(23) with length: 1371
gnutls[6]: BUF[REC]: Inserted 1371 bytes of Data(23)
gnutls[4]: REC[0x16cb240]: SSL 3.3 Application Data packet received. Epoch 0, length: 1378
gnutls[4]: REC[0x16cb240]: Expected Packet Application Data(23)
gnutls[4]: REC[0x16cb240]: Received Packet Application Data(23) with length: 1378
gnutls[4]: REC[0x16cb240]: Decrypted Packet[4744] Application Data(23) with length: 1354
gnutls[6]: BUF[REC]: Inserted 1354 bytes of Data(23)
gnutls[4]: REC[0x16cb240]: SSL 3.3 Application Data packet received. Epoch 0, length: 1395
gnutls[4]: REC[0x16cb240]: Expected Packet Application Data(23)
gnutls[4]: REC[0x16cb240]: Received Packet Application Data(23) with length: 1395
gnutls[2]: ASSERT: gnutls_cipher.c:951
gnutls[2]: ASSERT: gnutls_cipher.c:199
gnutls[2]: ASSERT: gnutls_record.c:1223
gnutls[1]: Discarded message[4745] due to invalid decryption
gnutls[2]: ASSERT: gnutls_record.c:1407
gnutls[2]: ASSERT: gnutls_buffers.c:624
gnutls[4]: REC: Sending Alert[1|0] - Close notify
gnutls[4]: REC[0x16cb240]: Preparing Packet Alert(21) with length: 2 and min pad: 0
gnutls[4]: REC[0x16cb240]: Sent Packet[10] Alert(21) in epoch 1 and length: 31
gnutls[2]: ASSERT: gnutls_record.c:1384
gnutls[2]: ASSERT: gnutls_record.c:334
gnutls[4]: REC[0x16cb240]: Start of epoch cleanup
gnutls[4]: REC[0x16cb240]: End of epoch cleanup
gnutls[4]: REC[0x16cb240]: Epoch #1 freed

So this problem (at least on armhf) seems to affect both gnutls26 and gnutls28.

[Donn Morrison (donn-morrison)]

I dug a little deeper and recompiled gnutls28-3.2.11 from sources provided by "apt-get source" and commented out the block at gnutls_cipher.c:951(see snippet below) which caused the first assertion in the log above. This fixes the problem, that is, I can download attachments in mutt seemingly without problem.

My question now is, what are the implications of removing this check? Any idea why this is only happening on armhf?

    /* Here there could be a timing leakage in CBC ciphersuites that
     * could be exploited if the cost of a successful memcmp is high.
     * A constant time memcmp would help there, but it is not easy to maintain
     * against compiler optimizations. Currently we rely on the fact that
     * a memcmp comparison is negligible over the crypto operations.
     */
// if (unlikely
    if (0 && unlikely
        (memcmp(tag, tag_ptr, tag_size) != 0 || pad_failed != 0)) {
        /* HMAC was not the same. */
        dummy_wait(params, compressed, pad_failed, pad,
               length + preamble_size);

        return gnutls_assert_val(GNUTLS_E_DECRYPTION_FAILED);
    }

[Seth Arnold (seth-arnold)]

It appears your patch disables authentication entirely; if I'm correct, a MITM attacker can modify bytes at will and you're unlikely to discover that they have been modified while in transit.

I'm sorry that I don't have anything better to recommend; it'd be worth running some stressors on your hardware and seeing if they can run to completion, e.g. kernel compiles or http://kernel.ubuntu.com/~cking/stress-ng/

Thanks

[Donn Morrison (donn-morrison)]

Yes, I realise that now. I've tried on a Raspberry Pi with 2.12.20 (armhf)
without problems. What is curious is why it was working before under Ubuntu
12.04. Comparing tag and tag_ptr, I can say that it is in fact the HMAC that
differs, and not the padding check. I'll keep debugging.

On Mon, Feb 09, 2015 at 06:58:52PM -0000, Seth Arnold wrote:
> It appears your patch disables authentication entirely; if I'm correct,
> a MITM attacker can modify bytes at will and you're unlikely to discover
> that they have been modified while in transit.
>
> I'm sorry that I don't have anything better to recommend; it'd be worth
> running some stressors on your hardware and seeing if they can run to
> completion, e.g. kernel compiles or http://kernel.ubuntu.com/~cking
> /stress-ng/
>
> Thanks
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1419436
>
> Title:
> tls_socket_read (Decryption has failed.)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1419436/+subscriptions

[Donn Morrison (donn-morrison)]

After recompiling mutt with openssl instead of gnutls I discovered that openssl was also affected, so I tried another USB ethernet dongle and that seems to have fixed it. At least I can't reproduce the problem with the large IMAP fetch using openssl s_client. I've now blacklisted the module for the onboard ethernet phy_twl4030_usb.

Maybe this bug could be reassigned?

[Seth Arnold (seth-arnold)]

Donn, was it a different kind of usb NIC or the same kind? Perhaps there's a kernel bug to fix or perhaps you just need to throw away the old NIC, depending upon what changed.

Thanks

[Donn Morrison (donn-morrison)]

Sorry, I spoke too soon, I was just able to reproduce it on the new NIC, but it happens much less often.