Re: [TLS] Sending fatal alerts over TCP

Martin Rex <mrex@sap.com> Tue, 20 December 2011 21:53 UTC

Return-Path: <mrex@sap.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 F063311E80A4 for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 13:53:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.189
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqE6BP675kGZ for <tls@ietfa.amsl.com>; Tue, 20 Dec 2011 13:53:22 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 245AF11E8097 for <tls@ietf.org>; Tue, 20 Dec 2011 13:53:21 -0800 (PST)
Received: from mail.sap.corp by smtpde02.sap-ag.de (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 <mrex@sap.com>
Message-Id: <201112202153.pBKLrIVh001975@fs4113.wdf.sap.corp>
To: mrex@sap.com
Date: Tue, 20 Dec 2011 22:53:18 +0100 (MET)
In-Reply-To: <201112202125.pBKLPh03000374@fs4113.wdf.sap.corp> 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
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
Reply-To: mrex@sap.com
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: 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 4.2.2.13, 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 4.2.2.13:

     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.

-Martin