gnutls 2.9.10 breaks exim4 TLS (Denying unsafe (re)negotiation.)

[Andreas Metzler]

Hello,

introduction of safe (re)negotiation in 2.9.10 has broken TLS for
exim4. The interesting bits when running in debug mode seem to be
these:

---------------------------------------------
09:01:12 31398   SMTP>> STARTTLS
09:01:12 31398 waiting for data on socket
09:01:12 31398 read response data: size=18
09:01:12 31398   SMTP<< 220 TLS go ahead
09:01:12 31398 initializing GnuTLS as a client
09:01:12 31398 read D-H parameters from file
09:01:12 31398 initialized D-H parameters
09:01:12 31398 no TLS client certificate is specified
09:01:12 31398 initialized certificate stuff
09:01:12 31398 initialized GnuTLS session
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_ARCFOUR_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: RSA_ARCFOUR_MD5
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x8126dd0]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1
|<2>| EXT[0x8126dd0]: Sending extension SAFE_RENEGOTIATION
|<3>| HSK[0x8126dd0]: CLIENT HELLO was sent [74 bytes]
|<6>| BUF[HSK]: Inserted 74 bytes of Data
|<4>| REC[0x8126dd0]: Sending Packet[0] Handshake(22) with length: 74
|<7>| WRITE: Will write 79 bytes to 0x6.
|<7>| WRITE: wrote 79 bytes to 0x6. Left 0 bytes. Total 79 bytes.
|<7>| 0000 - 16 03 01 00 4a 01 00 00 46 03 01 4b e5 0c 38 0e 
|<7>| 0001 - 93 39 29 cb 86 99 68 28 eb 45 82 6c 9a b4 2b c6 
|<7>| 0002 - 6d 47 c7 6f b5 a8 72 a4 16 ba 97 00 00 18 00 35 
|<7>| 0003 - 00 2f 00 0a 00 05 00 04 00 38 00 32 00 13 00 66 
|<7>| 0004 - 00 39 00 33 00 16 01 00 00 05 ff 01 00 01 00 
|<4>| REC[0x8126dd0]: Sent Packet[1] Handshake(22) with length: 79
|<7>| READ: Got 5 bytes from 0x6
|<7>| READ: read 5 bytes from 0x6
|<7>| 0000 - 16 03 01 00 4a 
|<7>| RB: Have 0 bytes into buffer. Adding 5 bytes.
|<7>| RB: Requested 5 bytes
|<4>| REC[0x8126dd0]: Expected Packet[0] Handshake(22) with length: 1
|<4>| REC[0x8126dd0]: Received Packet[0] Handshake(22) with length: 74
|<7>| READ: Got 74 bytes from 0x6
|<7>| READ: read 74 bytes from 0x6
|<7>| 0000 - 02 00 00 46 03 01 4b e5 0c 3a dd 97 c9 48 e3 12 
|<7>| 0001 - 7f 61 d9 12 53 17 cd 69 94 24 26 34 ce 68 46 ad 
|<7>| 0002 - 0a c8 8b b9 2d a0 20 d6 25 41 21 ae 93 61 3f 1d 
|<7>| 0003 - e1 22 7c 86 f0 08 74 55 af ff 2c 60 bc ae 41 b4 
|<7>| 0004 - b7 3f 32 76 a9 03 12 00 35 00 
|<7>| RB: Have 5 bytes into buffer. Adding 74 bytes.
|<7>| RB: Requested 79 bytes
|<4>| REC[0x8126dd0]: Decrypted Packet[0] Handshake(22) with length: 74
|<6>| BUF[HSK]: Inserted 74 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 1 bytes of Data(22)
|<6>| BUF[REC][HD]: Read 3 bytes of Data(22)
|<3>| HSK[0x8126dd0]: SERVER HELLO was received [74 bytes]
|<6>| BUF[REC][HD]: Read 70 bytes of Data(22)
|<6>| BUF[HSK]: Inserted 4 bytes of Data
|<6>| BUF[HSK]: Inserted 70 bytes of Data
|<3>| HSK[0x8126dd0]: Server's version: 3.1
|<3>| HSK[0x8126dd0]: SessionID length: 32
|<3>| HSK[0x8126dd0]: SessionID: 
d6254121ae93613f1de1227c86f0087455afff2c60bcae41b4b73f3276a90312
|<3>| HSK[0x8126dd0]: Selected cipher suite: RSA_AES_256_CBC_SHA1
|<2>| ASSERT: gnutls_extensions.c:140
|<2>| ASSERT: gnutls_handshake.c:2404
|<3>| Denying unsafe (re)negotiation.
|<2>| ASSERT: gnutls_handshake.c:2776
|<6>| BUF[HSK]: Cleared Data from buffer
09:01:12 31398 LOG: MAIN
09:01:12 31398   TLS error on connection to merkel.debian.org [192.25.206.16] 
(gnutls_handshake): Safe renegotiation failed.
---------------------------------------------

2.9.9 succeeds (log attached). Counterpart (merkel.debian.org) is
running gnutls 2.4.x.

I have not managed to reproduce the error with gnutls-cli. When
looking at exim's tls code
http://git.exim.org/exim.git/blob_plain/HEAD:/exim-src/src/tls-gnu.c
one big difference to gnutls-cli is that exim only uses the specific
gnutls_*_set_priority() functions while gnutls-cli *always* invokes
gnutls_priority_set_direct() in the first place. Perhaps an
unintended dependency on gnutls_priority_*() was introduced?

This is http://bugs.debian.org/579831 FWIW.

cu andreas

-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

2.9.9.merkel
Description: Text document