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

 
 

sr #107495: gnutls_bye() blocks on network issues

Submitted by:  None
Submitted on:  Fri 15 Oct 2010 07:40:15 AM UTC  
 
Category: NonePriority: 5 - Normal
Severity: 3 - NormalStatus: None
Privacy: PublicAssigned to: None
Originator Email: -unavailable-Open/Closed: Closed
Operating System: None

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission 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>
Project 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 File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follows 1 latest change.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 01 Nov 2010 12:27:17 PM UTCnmavOpen/ClosedOpen=>Closed

    Back to the top


    Powered by Savane 3.1-cleanup