Subject: [TLS] close_notify race condition

From: Florian Weimer <[email-masked]>
Date: Tue, 13 Nov 2012 14:17:47 +0100

I'm not sure if this has been discussed before, it probably has. 
Section 7.2.1 of RFC 5246 says this:

"If the application protocol will not transfer any additional data, but 
will only close the underlying transport connection, then the 
implementation MAY choose to close the transport without waiting for the 
responding close_notify."

This advice is of questionable value when running TLS over TCP, and the 
other side is still sending data.  In that case, closing the transport 
will generate a TCP RST segment because TCP treats this as a data loss 
event.  This RST segment (generated by the party which sent the 
close_notify alert) can be received before the close_notify alert is 
read from the TCP receive buffer, essentially flushing it.  As a result, 
the close_notify alert is lost, and what started as an orderly 
connection shutdown looks like a potentially hostile connection truncation.

-- 
Florian Weimer / Red Hat Product Security Team

---

From: [email-masked] (Martin Rex)
Date: Tue, 13 Nov 2012 23:44:17 +0100 (CET)

> connection shutdown looks like a potentially hostile connection truncation.

Which probably means that when your application protocol is full duplex,
you should also use application-level protocol framing and application
level state signaling in order to distinguish graceful connection
closures from any other kind of connection less (which is not necessarily
hostile).

The "recommendation" to purge a TLS session from the session cache
when no close-notify alerts have been exchanged have always been
obviously bogus (and would be quite detrimental to TLS session
resume ratio between a Web Browser and a Web Server).

But what is your actual question?

-Martin

---

From: Nico Williams <[email-masked]>
Date: Tue, 13 Nov 2012 17:56:06 -0600

On Tue, Nov 13, 2012 at 4:44 PM, Martin Rex <[email-masked]> wrote:
> > [...]
> [...]

I took Florian's post to be a query for what people think of this
matter.  My take is that Florian is correct, this race exists, and the
advice in the RFC should be corrected, though in practice correcting
that advice will hardly correct behavior in deployed systems.

Nico
--

---

From: Florian Weimer <[email-masked]>
Date: Wed, 14 Nov 2012 10:02:11 +0100

> closures from any other kind of connection less (which is not necessarily

A protocol which is essentially half-duplex, but permits request 
pipelining could exhibit this, too.  Not sure if this already falls 
under "full duplex".

> But what is your actual question?

I was merely sharing an observation.  I think it would make sense to 
reconsider this piece of advice if the document is updated.