Big CA certificate bundle causes problems with GnuTLS 3.0.11

[Janne Snabb]

I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
a big pile of CA certificates to verify against. I can not reproduce the
problem with GnuTLS 2.12.14.

Steps to re-produce:

1. Create server key+certificate:

certtool --generate-privkey --outfile foo.key
certtool --generate-self-signed --load-privkey foo.key --outfile foo.crt

(leave all fields empty except expiration and enable signing and
encryption)

2. Start server:

gnutls-serv --x509keyfile foo.key --x509certfile foo.crt --x509cafile
/etc/ssl/certs/ca-certificates.crt

3. Connect with client and observe failure:

gnutls-cli --insecure -p 5556 localhost

4. Start server without CA cert bundle:

gnutls-serv --x509keyfile foo.key --x509certfile foo.crt

5. Connect with client and observe success:

gnutls-cli --insecure -p 5556 localhost


Note that the file /etc/ssl/certs/ca-certificates.crt contains a big
pile of certificates, as distributed by Debian and Ubuntu
"ca-certificates" package. (I am happy to send it if needed.) If I
specify just a sigle CA cert I do not see any problems.

This means that when the problem happens the "certificate request" is
bigger than 16k.

Is this a bug, or is there just too many certificates? I suspect a bug
because GnuTLS 2.12.14 nor OpenSSL does not have any issues. I am happy
to supply any additional information.


gnutls-serv outputs the following when the failure happens:

Set static Diffie-Hellman parameters, consider --dhparams.
Processed 141 CA certificate(s).
HTTP Server listening on IPv4 0.0.0.0 port 5556...done
HTTP Server listening on IPv6 :: port 5556...bind() failed: Address
already in use

* Accepted connection from IPv4 127.0.0.1 port 48518 on Tue May 29
14:18:09 2012
* Received alert '22': Record overflow.
Error in handshake
Error: A TLS fatal alert has been received.


And the gnutls-cli outputs the following:

Processed 141 CA certificate(s).
Resolving 'localhost'...
Connecting to '127.0.0.1:5556'...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate does NOT match 'localhost'
*** Verifying server certificate failed...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.


gnutls-serv output with --debug 9:

|<2>| ASSERT: pkcs11.c:459
|<2>| ASSERT: mpi.c:249
|<2>| ASSERT: gnutls_dh_primes.c:293
|<2>| ASSERT: dn.c:362
|<2>| ASSERT: dn.c:481
HTTP Server listening on IPv4 0.0.0.0 port 5556...done
HTTP Server listening on IPv6 :: port 5556...bind() failed: Address
already in use
|<4>| REC[0xa1cd60]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0xa1cd60]: Allocating epoch #1
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0xa1cd60]: SSL 3.0 Handshake packet received. Epoch 0, length: 202
|<4>| REC[0xa1cd60]: Expected Packet Handshake(22)
|<4>| REC[0xa1cd60]: Received Packet Handshake(22) with length: 202
|<4>| REC[0xa1cd60]: Decrypted Packet[0] Handshake(22) with length: 202
|<3>| HSK[0xa1cd60]: CLIENT HELLO was received. Length 198[198], frag
offset 0, frag length: 198, sequence: 0
|<3>| HSK[0xa1cd60]: Client's version: 3.3
|<2>| ASSERT: gnutls_db.c:265
|<2>| ASSERT: gnutls_db.c:297
|<3>| EXT[0xa1cd60]: Parsing extension 'SERVER NAME/0' (14 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SUPPORTED ECC/10' (12 bytes)
|<3>| HSK[0xa1cd60]: Selected ECC curve SECP192R1 (5)
|<3>| EXT[0xa1cd60]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11'
(2 bytes)
|<3>| EXT[0xa1cd60]: Parsing extension 'SIGNATURE ALGORITHMS/13' (28 bytes)
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.1) RSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.2) DSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0xa1cd60]: rcvd signature algo (5.1) RSA-SHA384
|<3>| EXT[0xa1cd60]: rcvd signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0xa1cd60]: rcvd signature algo (6.1) RSA-SHA512
|<3>| EXT[0xa1cd60]: rcvd signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.1) RSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.2) DSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.1) RSA-SHA1
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.2) DSA-SHA1
|<3>| EXT[0xa1cd60]: rcvd signature algo (2.3) ECDSA-SHA1
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: EC (4) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Requested PK algorithm: RSA (1) -- ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: certificate[0] PK algorithm: RSA (1) - ctype: X.509 (1)
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>| HSK[0xa1cd60]: Removing ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1 (C0.13)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
(C0.27)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
(C0.2F)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1 (C0.14)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
(C0.30)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
(C0.12)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256 (00.67)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
(00.45)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256 (00.9E)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256 (00.6B)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
(00.88)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_128_GCM_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_AES_256_CBC_SHA256
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1
|<3>| HSK[0xa1cd60]: Removing ciphersuite: DHE_DSS_ARCFOUR_SHA1
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0xa1cd60]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| HSK[0xa1cd60]: Requested cipher suites[size: 80]:
|<3>| 0xc0, 0x09 ECDHE_ECDSA_AES_128_CBC_SHA1
|<3>| 0xc0, 0x23 ECDHE_ECDSA_AES_128_CBC_SHA256
|<3>| 0xc0, 0x2b ECDHE_ECDSA_AES_128_GCM_SHA256
|<3>| 0xc0, 0x0a ECDHE_ECDSA_AES_256_CBC_SHA1
|<3>| 0xc0, 0x24 ECDHE_ECDSA_AES_256_CBC_SHA384
|<3>| 0xc0, 0x2c ECDHE_ECDSA_AES_256_GCM_SHA384
|<3>| 0xc0, 0x08 ECDHE_ECDSA_3DES_EDE_CBC_SHA1
|<3>| 0xc0, 0x13 ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0xa1cd60]: Selected Compression Method: NULL
|<3>| HSK[0xa1cd60]: Safe renegotiation succeeded
|<3>| EXT[0xa1cd60]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0xa1cd60]: Sending extension SUPPORTED ECC POINT FORMATS (2 bytes)
|<3>| HSK[0xa1cd60]: SessionID:
176537c551ca398133358e980be582adc4243490f0d5d9559384190fd366d705
|<3>| HSK[0xa1cd60]: SERVER HELLO was queued [87 bytes]
|<3>| HSK[0xa1cd60]: CERTIFICATE was queued [816 bytes]
|<3>| HSK[0xa1cd60]: signing handshake data: using RSA-SHA256
|<3>| HSK[0xa1cd60]: SERVER KEY EXCHANGE was queued [365 bytes]
|<3>| EXT[0xa1cd60]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0xa1cd60]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0xa1cd60]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0xa1cd60]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0xa1cd60]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0xa1cd60]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0xa1cd60]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0xa1cd60]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0xa1cd60]: sent signature algo (2.3) ECDSA-SHA1
|<3>| HSK[0xa1cd60]: CERTIFICATE REQUEST was queued [17029 bytes]
|<3>| HSK[0xa1cd60]: SERVER HELLO DONE was queued [4 bytes]
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 87
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[1] Handshake(22) in epoch 0 and length: 92
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 816
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[2] Handshake(22) in epoch 0 and length: 821
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 365
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[3] Handshake(22) in epoch 0 and length: 370
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 17029
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[4] Handshake(22) in epoch 0 and length:
16389
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 645
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[5] Handshake(22) in epoch 0 and length: 650
|<4>| REC[0xa1cd60]: Preparing Packet Handshake(22) with length: 4
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[6] Handshake(22) in epoch 0 and length: 9
|<2>| ASSERT: gnutls_buffers.c:974
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0xa1cd60]: SSL 3.3 Alert packet received. Epoch 0, length: 2
|<4>| REC[0xa1cd60]: Expected Packet Handshake(22)
|<4>| REC[0xa1cd60]: Received Packet Alert(21) with length: 2
|<4>| REC[0xa1cd60]: Decrypted Packet[1] Alert(21) with length: 2
|<4>| REC[0xa1cd60]: Alert[2|22] - Record overflow - was received
|<2>| ASSERT: gnutls_record.c:627
|<2>| ASSERT: gnutls_record.c:633
|<2>| ASSERT: gnutls_record.c:1111
|<2>| ASSERT: gnutls_buffers.c:1175
|<2>| ASSERT: gnutls_handshake.c:1269
|<2>| ASSERT: gnutls_handshake.c:2827
Error in handshake
|<4>| REC: Sending Alert[2|80] - Internal error
|<4>| REC[0xa1cd60]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0xa1cd60]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0xa1cd60]: Sent Packet[7] Alert(21) in epoch 0 and length: 7
|<2>| ASSERT: gnutls_record.c:238
|<4>| REC[0xa1cd60]: Start of epoch cleanup
|<4>| REC[0xa1cd60]: End of epoch cleanup
|<4>| REC[0xa1cd60]: Epoch #0 freed
|<4>| REC[0xa1cd60]: Epoch #1 freed

gnutls-cli output with --debug 9:

|<2>| ASSERT: pkcs11.c:459
|<4>| REC[0x24e4120]: Allocating epoch #0
|<2>| ASSERT: gnutls_constate.c:717
|<4>| REC[0x24e4120]: Allocating epoch #1
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_AES_128_CBC_SHA1
(C0.09)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_128_CBC_SHA256 (C0.23)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_128_GCM_SHA256 (C0.2B)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_AES_256_CBC_SHA1
(C0.0A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_256_CBC_SHA384 (C0.24)
|<3>| HSK[0x24e4120]: Keeping ciphersuite:
ECDHE_ECDSA_AES_256_GCM_SHA384 (C0.2C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_ECDSA_3DES_EDE_CBC_SHA1
(C0.08)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA1
(C0.13)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_CBC_SHA256
(C0.27)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_128_GCM_SHA256
(C0.2F)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_256_CBC_SHA1
(C0.14)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_AES_256_GCM_SHA384
(C0.30)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: ECDHE_RSA_3DES_EDE_CBC_SHA1
(C0.12)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA1 (00.33)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_CBC_SHA256
(00.67)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_CAMELLIA_128_CBC_SHA1
(00.45)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_128_GCM_SHA256
(00.9E)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA1 (00.39)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_AES_256_CBC_SHA256
(00.6B)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_CAMELLIA_256_CBC_SHA1
(00.88)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_RSA_3DES_EDE_CBC_SHA1 (00.16)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA1 (00.32)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_CBC_SHA256
(00.40)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_CAMELLIA_128_CBC_SHA1
(00.44)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_128_GCM_SHA256
(00.A2)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA1 (00.38)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_AES_256_CBC_SHA256
(00.6A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_CAMELLIA_256_CBC_SHA1
(00.87)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_3DES_EDE_CBC_SHA1 (00.13)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: DHE_DSS_ARCFOUR_SHA1 (00.66)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA1 (00.2F)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_CBC_SHA256 (00.3C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_CAMELLIA_128_CBC_SHA1 (00.41)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_128_GCM_SHA256 (00.9C)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_256_CBC_SHA1 (00.35)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_AES_256_CBC_SHA256 (00.3D)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_CAMELLIA_256_CBC_SHA1 (00.84)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_3DES_EDE_CBC_SHA1 (00.0A)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_ARCFOUR_SHA1 (00.05)
|<3>| HSK[0x24e4120]: Keeping ciphersuite: RSA_ARCFOUR_MD5 (00.04)
|<3>| EXT[0x24e4120]: Sending extension SERVER NAME (14 bytes)
|<3>| EXT[0x24e4120]: Sending extension SAFE RENEGOTIATION (1 bytes)
|<3>| EXT[0x24e4120]: Sending extension SUPPORTED ECC (12 bytes)
|<3>| EXT[0x24e4120]: Sending extension SUPPORTED ECC POINT FORMATS (2
bytes)
|<3>| EXT[0x24e4120]: sent signature algo (4.1) RSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (4.2) DSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (4.3) ECDSA-SHA256
|<3>| EXT[0x24e4120]: sent signature algo (5.1) RSA-SHA384
|<3>| EXT[0x24e4120]: sent signature algo (5.3) ECDSA-SHA384
|<3>| EXT[0x24e4120]: sent signature algo (6.1) RSA-SHA512
|<3>| EXT[0x24e4120]: sent signature algo (6.3) ECDSA-SHA512
|<3>| EXT[0x24e4120]: sent signature algo (3.1) RSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (3.2) DSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (3.3) ECDSA-SHA224
|<3>| EXT[0x24e4120]: sent signature algo (2.1) RSA-SHA1
|<3>| EXT[0x24e4120]: sent signature algo (2.2) DSA-SHA1
|<3>| EXT[0x24e4120]: sent signature algo (2.3) ECDSA-SHA1
|<3>| EXT[0x24e4120]: Sending extension SIGNATURE ALGORITHMS (28 bytes)
|<3>| HSK[0x24e4120]: CLIENT HELLO was queued [202 bytes]
|<4>| REC[0x24e4120]: Preparing Packet Handshake(22) with length: 202
|<9>| ENC[0x24e4120]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0x24e4120]: Sent Packet[1] Handshake(22) in epoch 0 and
length: 207
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0, length: 87
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 87
|<4>| REC[0x24e4120]: Decrypted Packet[0] Handshake(22) with length: 87
|<3>| HSK[0x24e4120]: SERVER HELLO was received. Length 83[83], frag
offset 0, frag length: 83, sequence: 0
|<3>| HSK[0x24e4120]: Server's version: 3.3
|<3>| HSK[0x24e4120]: SessionID length: 32
|<3>| HSK[0x24e4120]: SessionID:
176537c551ca398133358e980be582adc4243490f0d5d9559384190fd366d705
|<3>| HSK[0x24e4120]: Selected cipher suite: ECDHE_RSA_AES_128_CBC_SHA1
|<3>| HSK[0x24e4120]: Selected compression method: NULL (0)
|<3>| EXT[0x24e4120]: Parsing extension 'SAFE RENEGOTIATION/65281' (1 bytes)
|<3>| EXT[0x24e4120]: Parsing extension 'SUPPORTED ECC POINT FORMATS/11'
(2 bytes)
|<3>| HSK[0x24e4120]: Safe renegotiation succeeded
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 816
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 816
|<4>| REC[0x24e4120]: Decrypted Packet[1] Handshake(22) with length: 816
|<3>| HSK[0x24e4120]: CERTIFICATE was received. Length 812[812], frag
offset 0, frag length: 812, sequence: 0
|<2>| ASSERT: dn.c:1190
|<2>| ASSERT: verify.c:395
|<2>| ASSERT: verify.c:642
|<2>| ASSERT: dn.c:362
|<2>| ASSERT: dn.c:481
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 365
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 365
|<4>| REC[0x24e4120]: Decrypted Packet[2] Handshake(22) with length: 365
|<3>| HSK[0x24e4120]: SERVER KEY EXCHANGE was received. Length 361[361],
frag offset 0, frag length: 361, sequence: 0
|<3>| HSK[0x24e4120]: Selected ECC curve SECP192R1 (5)
|<3>| HSK[0x24e4120]: verify handshake data: using RSA-SHA256
|<2>| ASSERT: signature.c:304
|<2>| ASSERT: gnutls_buffers.c:974
|<4>| REC[0x24e4120]: SSL 3.3 Handshake packet received. Epoch 0,
length: 16384
|<4>| REC[0x24e4120]: Expected Packet Handshake(22)
|<4>| REC[0x24e4120]: Received Packet Handshake(22) with length: 16384
|<4>| REC[0x24e4120]: Decrypted Packet[3] Handshake(22) with length: 16384
|<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
17025[16380], frag offset 0, frag length: 17025, sequence: 0
|<2>| ASSERT: gnutls_buffers.c:819
|<2>| ASSERT: gnutls_buffers.c:1031
|<2>| ASSERT: gnutls_handshake.c:1269
|<2>| ASSERT: gnutls_handshake.c:2515
*** Fatal error: A TLS packet with unexpected length was received.
|<4>| REC: Sending Alert[2|22] - Record overflow
|<4>| REC[0x24e4120]: Preparing Packet Alert(21) with length: 2
|<9>| ENC[0x24e4120]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
|<4>| REC[0x24e4120]: Sent Packet[2] Alert(21) in epoch 0 and length: 7
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.
|<4>| REC[0x24e4120]: Start of epoch cleanup
|<4>| REC[0x24e4120]: End of epoch cleanup
|<4>| REC[0x24e4120]: Epoch #0 freed
|<4>| REC[0x24e4120]: Epoch #1 freed
Processed 141 CA certificate(s).
Resolving 'localhost'...
Connecting to '127.0.0.1:5556'...
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- The hostname in the certificate does NOT match 'localhost'
*** Verifying server certificate failed...


--
Janne Snabb / EPIPE Communications
snabb@... - http://epipe.com/

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Phil Pennock-26]

On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
> a big pile of CA certificates to verify against. I can not reproduce the
> problem with GnuTLS 2.12.14.

It appears to be commit 67f4dba6 from March 20th:
"Avoided waiting for peer's retransmission to ensure receipt of finished
 messages, and used a 'timer'-like to retransmit packets."

-  data_size = _mbuffer_get_udata_size(bufel) - handshake_header_size;
+  if (hsk->length > 0 &&
+        (hsk->end_offset-hsk->start_offset >=  data_size))

> |<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
> 17025[16380], frag offset 0, frag length: 17025, sequence: 0
> |<2>| ASSERT: gnutls_buffers.c:819
> |<2>| ASSERT: gnutls_buffers.c:1031
> |<2>| ASSERT: gnutls_handshake.c:1269
> |<2>| ASSERT: gnutls_handshake.c:2515
> *** Fatal error: A TLS packet with unexpected length was received.

The "was received" code is:
----------------------------8< cut here >8------------------------------
  _gnutls_handshake_log ("HSK[%p]: %s was received. Length %d[%d], frag offset %d, frag length: %d, sequence: %d\n",
                         session, _gnutls_handshake2str (hsk->htype),
                         (int) hsk->length, (int)data_size, hsk->start_offset, hsk->end_offset-hsk->start_offset+1, (int)hsk->sequen
ce);
----------------------------8< cut here >8------------------------------

hsk->length is read from the Handshake->length (uint24); data_size is
the size of the CertificateRequest (received buffer size less 4 for the
handshake header (type 1 octet, length 3 octets).

hsk->start_offset is always 0.
hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].

So the check added in 67f4dba6 is going to always reject a fragmented
handshake packet.

-Phil

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Phil Pennock-26]

On 2012-05-29 at 11:31 -0400, Phil Pennock wrote:
> It appears to be commit 67f4dba6 from March 20th:

*cough* March 20th, 2011.  Sorry.

Branches:
  master, remotes/origin/ecc, remotes/origin/gnutls_3_0_12_x,
  remotes/origin/gnutls_3_0_x, remotes/origin/gnutls_3_0_x-2,
  remotes/origin/master, remotes/origin/ocsp

First tag to have this was gnutls_2_99_0.

-Phil

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos]

On 05/29/2012 05:31 PM, Phil Pennock wrote:

> On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
>> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
>> a big pile of CA certificates to verify against. I can not reproduce the
>> problem with GnuTLS 2.12.14.
[...]
> hsk->length is read from the Handshake->length (uint24); data_size is
> the size of the CertificateRequest (received buffer size less 4 for the
> handshake header (type 1 octet, length 3 octets).
> hsk->start_offset is always 0.
> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
> So the check added in 67f4dba6 is going to always reject a fragmented
> handshake packet.


Correct. I've committed a fix at:
http://git.savannah.gnu.org/gitweb/?p=gnutls.git;a=commitdiff;h=6299e8a8c7371da1e674419c36cbcbe1630aef0a
regards,
Nikos


_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos-2]

On 05/29/2012 04:46 PM, Janne Snabb wrote:

> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
> a big pile of CA certificates to verify against. I can not reproduce the
> problem with GnuTLS 2.12.14.
>
> Steps to re-produce:
[...]
> Note that the file /etc/ssl/certs/ca-certificates.crt contains a big
> pile of certificates, as distributed by Debian and Ubuntu
> "ca-certificates" package. (I am happy to send it if needed.) If I
> specify just a sigle CA cert I do not see any problems.
> This means that when the problem happens the "certificate request" is
> bigger than 16k.


Thank you for reporting this. A quick solution to avoid this issue is to
restrict the CAs that you enable to the server to the minimum required
(a typical server needs to trust only the authorities that signed the
user's certificates).

regards,
Nikos


_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Michal Suchanek]

On 29 May 2012 17:31, Phil Pennock <help-gnutls-phil@...> wrote:

> On 2012-05-29 at 21:46 +0700, Janne Snabb wrote:
>> I am experiencing a TLS handshake problem when GnuTLS 3.0.11 server has
>> a big pile of CA certificates to verify against. I can not reproduce the
>> problem with GnuTLS 2.12.14.
>
> It appears to be commit 67f4dba6 from March 20th:
> "Avoided waiting for peer's retransmission to ensure receipt of finished
>  messages, and used a 'timer'-like to retransmit packets."
>
> -  data_size = _mbuffer_get_udata_size(bufel) - handshake_header_size;
> +  if (hsk->length > 0 &&
> +        (hsk->end_offset-hsk->start_offset >=  data_size))
>
>> |<3>| HSK[0x24e4120]: CERTIFICATE REQUEST was received. Length
>> 17025[16380], frag offset 0, frag length: 17025, sequence: 0
>> |<2>| ASSERT: gnutls_buffers.c:819
>> |<2>| ASSERT: gnutls_buffers.c:1031
>> |<2>| ASSERT: gnutls_handshake.c:1269
>> |<2>| ASSERT: gnutls_handshake.c:2515
>> *** Fatal error: A TLS packet with unexpected length was received.
>
> The "was received" code is:
> ----------------------------8< cut here >8------------------------------
>  _gnutls_handshake_log ("HSK[%p]: %s was received. Length %d[%d], frag offset %d, frag length: %d, sequence: %d\n",
>                         session, _gnutls_handshake2str (hsk->htype),
>                         (int) hsk->length, (int)data_size, hsk->start_offset, hsk->end_offset-hsk->start_offset+1, (int)hsk->sequen
> ce);
> ----------------------------8< cut here >8------------------------------
>
> hsk->length is read from the Handshake->length (uint24); data_size is
> the size of the CertificateRequest (received buffer size less 4 for the
> handshake header (type 1 octet, length 3 octets).
>
> hsk->start_offset is always 0.
> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
>
> So the check added in 67f4dba6 is going to always reject a fragmented
> handshake packet.
>

Now what I do not get is how a pile of CA certificates is fragmenting
the packets.

Sounds like a security hole. CA cert piles should be local to either
side, only one CA cert relevant for the session. Technically there can
be more than one cert in the trust chain but not pile of them.

Thanks

Michal

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos-2]

On 05/29/2012 10:37 PM, Michal Suchanek wrote:

>> hsk->start_offset is always 0.
>> hsk->end_offset is always (hsk->length - 1) [because this isn't DTLS].
>>
>> So the check added in 67f4dba6 is going to always reject a fragmented
>> handshake packet.


> Now what I do not get is how a pile of CA certificates is fragmenting

> the packets.

In the TLS protocol the server advertises its CA certificates so a
client would know which certificate to present. If a server trusts all
the certificates in the system, the server would advertise all of them
(their DNs actually).

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Janne Snabb]

On 2012-05-30 03:37, Michal Suchanek wrote:
> Now what I do not get is how a pile of CA certificates is fragmenting
> the packets.
>
> Sounds like a security hole. CA cert piles should be local to either
> side, only one CA cert relevant for the session. Technically there can
> be more than one cert in the trust chain but not pile of them.

If the *server* chooses to trust a pile of CA's in the same way as web
browsers (clients) typically do, this will happen, see:

https://tools.ietf.org/html/rfc5246#section-7.4.4

It also says:

"If the certificate_authorities list is empty, then the client MAY send
any certificate of the appropriate ClientCertificateType, unless there
is some external arrangement to the contrary."

...which suggests that in cases like this it might be a good idea or at
least acceptable *not* to put anything in the certificate_authorities
list when the server sends the Certificate Request. It is unclear how
various client side implementations implement the "MAY" part of the
above RFC quote. Do they send a client certificate if the CA list is
empty? Which one will they send if they have several?

It feels like there should be a way in the GnuTLS API to define whether
the list of trusted CAs is to be advertised in Certificate Request or
not. (Maybe there is a way but I am missing it?)

I encountered this issue with Exim SMTP server with the default
configuration that is packaged in Debian and Ubuntu. If the
administrator enables TLS but does not specify which CAs to trust, in
Ubuntu 12.04 it will trust 152 of them (basically the same ones as
trusted by Mozilla NSS plus a couple of more) and advertise all of them
in Certificate Request. I am sure there are many mail servers out there
which are sending more than 16 kb of data in every TLS handshake
basically just to say "we trust everyone".

--
Janne Snabb / EPIPE Communications
snabb@... - http://epipe.com/

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Nikos Mavrogiannopoulos-2]

On 05/29/2012 11:17 PM, Janne Snabb wrote:

> On 2012-05-30 03:37, Michal Suchanek wrote:
>> Now what I do not get is how a pile of CA certificates is fragmenting
>> the packets.
>>
>> Sounds like a security hole. CA cert piles should be local to either
>> side, only one CA cert relevant for the session. Technically there can
>> be more than one cert in the trust chain but not pile of them.
>
> If the *server* chooses to trust a pile of CA's in the same way as web
> browsers (clients) typically do, this will happen, see:
>
> https://tools.ietf.org/html/rfc5246#section-7.4.4
>
> It also says:
>
> "If the certificate_authorities list is empty, then the client MAY send
> any certificate of the appropriate ClientCertificateType, unless there
> is some external arrangement to the contrary."
>
> ...which suggests that in cases like this it might be a good idea or at
> least acceptable *not* to put anything in the certificate_authorities
> list when the server sends the Certificate Request. It is unclear how
> various client side implementations implement the "MAY" part of the
> above RFC quote. Do they send a client certificate if the CA list is
> empty? Which one will they send if they have several?

Most send any certificate selected by the user.


> It feels like there should be a way in the GnuTLS API to define whether
> the list of trusted CAs is to be advertised in Certificate Request or
> not. (Maybe there is a way but I am missing it?)


There is. Check client certificate authentication at:
http://www.gnu.org/software/gnutls/manual/html_node/Certificate-credentials.html#Certificate-credentials

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Sam Varshavchik]

Nikos Mavrogiannopoulos writes:

> In the TLS protocol the server advertises its CA certificates so a
> client would know which certificate to present. If a server trusts all
> the certificates in the system, the server would advertise all of them
> (their DNs actually).

IIRC, this occurs only when client certificates are enabled. Yes, I would  
think that in that case only the certificates that the server trusts, should  
be loaded.

I would think that in most situations an organization would have only their  
own CA trusted, and loaded into a TLS server. I suppose I can imagine a  
situation where an org would, in some context, decide that accepting a  
client cert signed by any public CA to be acceptable, and then use it for  
some particular purpose. But I don't think this would be the case for most  
practical situations. And, in those cases, loading the public CA certs would  
be a security hole. Depending on the purpose the client cert is being used  
for, and how, it wouldn't take much imagination to get some public CA to  
sign something that looks good enough to 0wn JOO.

So, I would take a hard look at why someone really wants to load a public CA  
bundle, in the first place, to validate client certs.

I suppose someone might want, for some odd reason, to blow a wad of cash on  
having some public CA sign some certs, for their clients, even though it's  
trivial to set up your own cert, and do it yourself for free. But, still, in  
that case, at the very least you should only load /that/ CA, and not the  
whole bundle.



_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Janne Snabb]

On Tue, 29 May 2012, Sam Varshavchik wrote:

> I suppose someone might want, for some odd reason, to blow a wad of cash on
> having some public CA sign some certs, for their clients, even though it's
> trivial to set up your own cert, and do it yourself for free. But, still, in
> that case, at the very least you should only load /that/ CA, and not the whole
> bundle.

Google is one big e-mail sender that presents a client certificate signed
by one of the ~150 "well-known" CAs (I have not checked which one). There
are other similar but smaller mail senders also.

--
Janne Snabb / EPIPE Communications
snabb@... - http://epipe.com/

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls

[Phil Pennock-26]

On 2012-05-30 at 03:10 +0000, Janne Snabb wrote:
> Google is one big e-mail sender that presents a client certificate signed
> by one of the ~150 "well-known" CAs (I have not checked which one). There
> are other similar but smaller mail senders also.

Equifax, apparently:

52394 SSL verify ok: depth=2 cert=/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
52394 SSL verify ok: depth=1 cert=/C=US/O=Google Inc/CN=Google Internet Authority
52394 SSL peer: /C=US/ST=California/L=Mountain View/O=Google Inc/CN=smtp.gmail.com

Hrm, Exim needs a +tls_peer_issuerdn log selector.

-Phil

_______________________________________________
Help-gnutls mailing list
Help-gnutls@...
https://lists.gnu.org/mailman/listinfo/help-gnutls