mainGnuTLS - Support: sr #107495, gnutls_bye() blocks on network...

 
 

sr #107495: gnutls_bye() blocks on network issues

Submitter:  None
Submitted:  Fri 15 Oct 2010 07:40:15 AM UTC
   
 
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Email:  -email is unavailable- Open/Closed:  Closed
Operating System:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Fri 15 Oct 2010 08:51:26 AM UTC, comment #6: 

Of course you are not required. You are not required to use TLS either. You use those fascilities if you care about specific attacks, and in this case about truncation attacks. If you don't care you don't have to use them.

Anonymous
Fri 15 Oct 2010 08:46:37 AM UTC, comment #5: 

Notice in the RFC section you referenced:

_ It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection._

Judging from the comments, it seems we should just use GNUTLS_SHUT_WR instead of GNUTLS_SHUT_RDWR.


re: _Since openldap uses select you could use gnutls_bye with GNUTLS_SHUT_WR, and once the socket is readable try to read
with gnutls_record_recv() which should return 0 (EOF). If it is not readable within some time limit terminate the connection with error._

OpenLDAP only calls gnutls_bye during a session teardown, so the connection is already being terminated. Nobody is going to be attempting to read anything more from the socket at that point, there's no point in select'ing on it for readability.

Howard Chu <hyc>
Fri 15 Oct 2010 08:26:03 AM UTC, comment #4: 

On why this is required see the TLS protocol:
http://tools.ietf.org/html/rfc5246#section-7.2.1
But how would you distinguish a network error from
a truncation attack? Both should be detected by TLS.

Since openldap uses select you could use gnutls_bye with GNUTLS_SHUT_WR, and once the socket is readable try to read
with gnutls_record_recv() which should return 0 (EOF). If it is not readable within some time limit terminate the connection with error.



Anonymous
Fri 15 Oct 2010 08:12:41 AM UTC, comment #3: 

I'm not sure what mechanism is used in OpenLDAP (I'm the developer of nss-pam-ldapd and I don't know too much about OpenLDAP internals). ITS#6673 has a backtrace that may be helpful though.

I suspect OpenLDAP uses a blocking socket and uses select() to do polling. As a user of the OpenLDAP API, the socket is mostly hidden for me. As a workaround for this problem I get the socket from OpenLDAP and use setsockopt() to set SO_RCVTIMEO and SO_SNDTIMEO.

I don't understand why you need to negotiate a disconnect though. If the TCP connection is severed for some reason or the other end is not responsive I don't see the extra security in trying to negotiate a disconnect. Am I missing something?

Anyway, thanks for your response.

Arthur

Anonymous
Fri 15 Oct 2010 08:07:35 AM UTC, comment #2: 

This how is the typical TLS session closure works. In TLS the connection closes if both peers agree on it (very few implementations though do that right). If you want to set timeout or sockets to non blocking I/O you should do it to the underlying layer (sockets). You could also non wait for reply from the peer (by specifying to _WR only flag to _bye) but then you will be vulnerable to attacks that terminate the connection prematurely.

Anonymous
Fri 15 Oct 2010 07:56:53 AM UTC, comment #1: 

How do you shut down the connection?  gnutls_bye() needs to talk to the other server to negotiate a disconnect, otherwise things will be insecure (it was one of the security issues with SSLv2).

Does it really block if you set the socket in non-blocking mode?

/Simon

Simon Josefsson <jas>
Group administrator
Fri 15 Oct 2010 07:40:15 AM UTC, original submission:  

The problem is that when a network problem occurs (a TCP connection is severed with iptables in this test) GnuTLS blocks on a read() when shutting down the connection.

This was a problem originally submitted to the nss-pam-ldapd project [0]. This was reported to the OpenLDAP project [1] where it was determined that it is probably a bug in GnuTLS (the problem is not there when using OpenSSL).

I don't use the GnuTLS API myself so I don't know any details about it. If you need more info, feel free to ask though.

[0] http://bugs.debian.org/596983
[1] http://www.openldap.org/its/index.cgi?selectid=6673

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by nmav (Updated the item)
  • -email is unavailable- added by hyc (Posted a comment)
  • -email is unavailable- added by jas (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follows 1 latest change.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-11-01 nmav Open/ClosedOpen Closed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code