Re: [TLS] Sending fatal alerts over TCP

Nico Williams <nico@cryptonector.com> Wed, 21 December 2011 22:31 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D76511E80CD for <tls@ietfa.amsl.com>; Wed, 21 Dec 2011 14:31:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.593
X-Spam-Level:
X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_33=0.6]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wntwF0bOk88M for <tls@ietfa.amsl.com>; Wed, 21 Dec 2011 14:31:22 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by ietfa.amsl.com (Postfix) with ESMTP id EEAAA11E80C0 for <tls@ietf.org>; Wed, 21 Dec 2011 14:31:21 -0800 (PST)
Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id 6F2D810058 for <tls@ietf.org>; Wed, 21 Dec 2011 14:31:21 -0800 (PST)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; q=dns; s=cryptonector.com; b=h2vUhcYy8DYXo5k6cJoOb 24Kx2SeBxmWY3AwvKdGvY8aFYfgSCAJ6kZvrxADVNcYX/8OMOMi3jtgUBD8vbFyG dE2J93R9lLObUYrrwVFXdSmgCgb59qmYQ87YGno18CM8SO6OLZn+GKI5R//WFnDF cB0k6dshXpZ0Zl0f/vlmhg=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dy547Yoer4c379DYI52Z Sl48158=; b=grKUhRQvEvy7Bl/dTf+Ie9117U0B+ItgWML0H++rZ+iThTsSUTAL L2mob62Q3T0JDRMm3R+pz8GzV8C0o0968ox8gIQoOaiK91s7S/+eV751DT6e3MVH IBlVx1X9rjRWJi1mHa5NTVVPTkq8gz+Xsv5vwPf0/MtQvcRibNra79g=
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id 53FB310056 for <tls@ietf.org>; Wed, 21 Dec 2011 14:31:21 -0800 (PST)
Received: by dajz8 with SMTP id z8so7374240daj.31 for <tls@ietf.org>; Wed, 21 Dec 2011 14:31:20 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.192.42 with SMTP id hd10mr16856959pbc.84.1324506680587; Wed, 21 Dec 2011 14:31:20 -0800 (PST)
Received: by 10.68.32.227 with HTTP; Wed, 21 Dec 2011 14:31:20 -0800 (PST)
In-Reply-To: <201112212140.pBLLeb3b022306@fs4113.wdf.sap.corp>
References: <CADMpkcJ2P+AV4GJuXZRs4c_4f_xkQy2kivsrmqS0pBTmpZPD+g@mail.gmail.com> <201112212140.pBLLeb3b022306@fs4113.wdf.sap.corp>
Date: Wed, 21 Dec 2011 16:31:20 -0600
Message-ID: <CAK3OfOiaJCN+XKzj9Rihkpu5HbO6MANCBbR=R-6k+V4tmTpZHA@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: mrex@sap.com
Content-Type: text/plain; charset=UTF-8
Cc: tls@ietf.org
Subject: Re: [TLS] Sending fatal alerts over TCP
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2011 22:31:22 -0000

Stevens suggests[0] doing a shutdown(2) of SHUT_WR then read(2)ing or
select(2)ing (or more modern equivalent) for read events on the same
socket to wait for the FIN|ACK from the peer; read(2) is supposed to
return 0 at that point (though I suppose it could also actually read
data if there's data to be read, as only the write-side of the socket
will have been shutdown at that point).

That wouldn't be an indication that the application received the fatal
alert, of course.  Nothing short of waiting for the peer to close its
end of the socket will do, but we can't wait forever.

Setting SO_LINGER with a zero l_linger is out, and a non-zero value is
useless unless the thread is willing to block in close(2) -- a
terrible waste of resources.

It may well be that the best thing to do is to shutdown(socket,
SHUT_WR) then queue up the socket for a later close(2) with SO_LINGER
and zero l_linger.  This gives the peer application a pretty good
chance to receive the fatal alert and close the socket normally, while
also limiting resource usage on the side that sent the alert.  And if
you already have an event-based async I/O framework you can trivially
set a timer upon which to close() the socket, and even process any
further data sent by the peer.

[0] Unix Network Programming volume 1, 2nd ed., section 7.5, page 189
/ fig. 7.8.

Nico
--