[Pkg-openldap-devel] Bug#861838: long list of acceptable CA names breaks libldap

[Ryan Tandy]

Control: severity -1 important
Control: tag -1 security

So it's actually pretty simple, gnutls_handshake is telling us to call 
it again, but we're not - we're just pressing onwards and trying to 
send/receive application data.

With GNUTLS_DEBUG_LEVEL=9 it becomes pretty clear:

gnutls[5]: REC[0x55ab8f3e3c30]: SSL 3.3 Handshake packet received. Epoch 0, length: 16384
gnutls[5]: REC[0x55ab8f3e3c30]: Expected Packet Handshake(22)
gnutls[5]: REC[0x55ab8f3e3c30]: Received Packet Handshake(22) with length: 16384
gnutls[5]: REC[0x55ab8f3e3c30]: Decrypted Packet[3] Handshake(22) with length: 16384
gnutls[4]: HSK[0x55ab8f3e3c30]: CERTIFICATE REQUEST (13) was received. Length 19590[16380], frag offset 0, frag length: 16380, sequence: 0
gnutls[3]: ASSERT: buffers.c[_gnutls_parse_record_buffered_msgs]:1268
gnutls[5]: REC[0x55ab8f3e3c30]: Preparing Packet Application Data(23) with length: 14 and min pad: 0
gnutls[9]: ENC[0x55ab8f3e3c30]: cipher: NULL, MAC: MAC-NULL, Epoch: 0
gnutls[5]: REC[0x55ab8f3e3c30]: Sent Packet[2] Application Data(23) in epoch 0 and length: 19
gnutls[5]: REC[0x55ab8f3e3c30]: SSL 3.3 Handshake packet received. Epoch 0, length: 3210
gnutls[5]: REC[0x55ab8f3e3c30]: Expected Packet Application Data(23)
gnutls[5]: REC[0x55ab8f3e3c30]: Received Packet Handshake(22) with length: 3210
gnutls[5]: REC[0x55ab8f3e3c30]: Decrypted Packet[4] Handshake(22) with length: 3210
gnutls[3]: ASSERT: handshake.c[_gnutls_recv_hello_request]:3400
gnutls[3]: ASSERT: record.c[_gnutls_recv_in_buffers]:1328
gnutls[3]: ASSERT: record.c[_gnutls_recv_int]:1473

Apparently this was already known by others.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=849807

> One example where this happens is libldap, which runs into this if
> gotten an non-blocking fd (as currently sssd does, see #849756),
> causing sssd-ldap to corrently sending passwords unencrypted.

Not non-blocking in this case, but it's the same issue. And I think the 
bug applies. Looking at tcpdump and it looks like if we send credentials 
while the handshake is complete, they go out unencrypted. Raising the 
severity based on that.

Actually it looks like 3.6.0 may force us to deal with this anyway, 
looking at https://gitlab.com/gnutls/gnutls/blob/master/NEWS.

** libgnutls: Refuse gnutls_record_send() and gnutls_record_recv()
   calls prior to handshake being complete. Addresses gitlab issue #158.

I haven't figured out exactly what change made this start happening. It 
first appears in jessie; in wheezy and earlier, gnutls_handshake appears 
to handle the retry internally.