Big CA certificate bundle causes problems with GnuTLS 3.0.11

Discussion:

Janne Snabb

2012-05-29 14:46:18 UTC

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
***@epipe.com - http://epipe.com/

Phil Pennock

2012-05-29 15:31:10 UTC

Permalink

Post by 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.

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

Post by Janne Snabb
|<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

Phil Pennock

2012-05-29 15:39:28 UTC

Permalink

*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

Nikos Mavrogiannopoulos

2012-05-29 20:34:33 UTC

Permalink

Post by Phil Pennock

Post by 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.

[...]

Post by Phil Pennock
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

Michal Suchanek

2012-05-29 20:37:56 UTC

Permalink

Post by Phil Pennock

Post by 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.

"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))

----------------------------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

Nikos Mavrogiannopoulos

2012-05-29 20:48:50 UTC

Permalink

Post by Michal Suchanek

Post by Phil Pennock
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

Sam Varshavchik

2012-05-29 23:04:48 UTC

Permalink

This post might be inappropriate. Click to display it.

Janne Snabb

2012-05-30 03:10:15 UTC

Permalink

Post by Sam Varshavchik
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
***@epipe.com - http://epipe.com/

Phil Pennock

2012-05-30 03:47:54 UTC

Permalink

Post by Janne Snabb
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

Janne Snabb

2012-05-29 21:17:19 UTC

Permalink

Post by Michal Suchanek
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
***@epipe.com - http://epipe.com/

Nikos Mavrogiannopoulos

2012-05-29 21:24:47 UTC

Permalink

Post by Janne Snabb

If the *server* chooses to trust a pile of CA's in the same way as web
https://tools.ietf.org/html/rfc5246#section-7.4.4
"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.

Post by Janne Snabb
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

Nikos Mavrogiannopoulos

2012-05-29 20:36:55 UTC

Permalink

Post by 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.

[...]

Post by Janne Snabb
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