Re: [TLS] Sending fatal alerts over TCP

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B03F421F8560 for <>; Tue, 20 Dec 2011 13:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.174
X-Spam-Status: No, score=-10.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 0WvRj0m9qzUL for <>; Tue, 20 Dec 2011 13:25:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 00E3021F84BA for <>; Tue, 20 Dec 2011 13:25:47 -0800 (PST)
Received: from by (26) with ESMTP id pBKLPhDH014764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 20 Dec 2011 22:25:44 +0100 (MET)
From: Martin Rex <>
Message-Id: <>
To: (Florian Weimer)
Date: Tue, 20 Dec 2011 22:25:43 +0100 (MET)
In-Reply-To: <> from "Florian Weimer" at Dec 20, 11 01:15:31 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:25:48 -0000

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.