Re: [TLS] Sending fatal alerts over TCP

Martin Rex <> Tue, 20 December 2011 21:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F063311E80A4 for <>; Tue, 20 Dec 2011 13:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.189
X-Spam-Status: No, score=-10.189 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fqE6BP675kGZ for <>; Tue, 20 Dec 2011 13:53:22 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 245AF11E8097 for <>; Tue, 20 Dec 2011 13:53:21 -0800 (PST)
Received: from by (26) with ESMTP id pBKLrJQW023810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 22:53:19 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
Date: Tue, 20 Dec 2011 22:53:18 +0100 (MET)
In-Reply-To: <> from "Martin Rex" at Dec 20, 11 10:25:43 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Subject: Re: [TLS] Sending fatal alerts over TCP
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 20 Dec 2011 21:53:23 -0000

Martin Rex wrote:
> Florian Weimer wrote:
> > 
> > TCP has the property that connection shutdowns can overtake application
> > data if connections are used in full-duplex mode.
> > 
> > Here's an example:
> > 
> >   X sends a fatal TLS alert to Y
> >   X shuts down the connection
> >   Y sends data to X
> >   X receives from Y, sends RST to signal data loss to Y
> >   Y receives RST
> > 
> > At this point, when Y tries to send further data, it will receive EPIPE
> > from the sockets API.  When it tries to read data, it will receive
> > ECONNRESET.  According to the socket API sepcification, there is no way
> > to access the initial TLS alert.  Note that this behavior is not related
> > to the SO_LINGER socket option.
> Could you point me to the particular section of the socket API spec
> that defines such behaviour (for the TCP stack of Y) to be correct?
> The way that I read rfc1122 section, the TCP stack of Y is
> only allowed to kill data upon the Y app performing a close operation
> on the socket.  If the app on Y does not call close when receiving
> the EPIPE from send(), then the data must IMHO remain readable,
> and the ECONNRESET will follow the TLS alert.

Application calling close() upon receiving EPIPE from send()
refers to "shutdown(socket,SHUT_WR)" in terms of BSD sockets.

With respect to this paragraph of rfc1122

     A host MAY implement a "half-duplex" TCP close sequence, so
     that an application that has called CLOSE cannot continue to
     read data from the connection.  If such a host issues a
     CLOSE call while received data is still pending in TCP, or
     if new data is received after CLOSE is called, its TCP
     SHOULD send a RST to show that data was lost.

This means that a TCP implementation could decide to treat
shutdown(socket,SHUT_WR) and shutdown(socket,SHUT_RD) always and
exactly the same as shutdown(socket,SHUT_RDWR), i.e. not support
a unidirectional/partial closure.

Who is inappropriately calling shutdown(socket,SHUT_WR) after a
failed send() in the scenario that you're looking at?  If there is
none such code, then the TCP stack is not conforming to rfc1122.