touch-packages team mailing list archive

[Donn Morrison <1419436@xxxxxxxxxxxxxxxxxx>]

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);
    }

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1419436

Title:
  tls_socket_read (Decryption has failed.)

Status in gnutls26 package in Ubuntu:
  New

Bug description:
  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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1419436/+subscriptions