[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-tls
Subject:    Re: [TLS] close_notify race condition
From:       Florian Weimer <fweimer () redhat ! com>
Date:       2012-11-14 9:02:11
Message-ID: 50A35E13.20509 () redhat ! com
[Download RAW message or body]

On 11/13/2012 11:44 PM, Martin Rex wrote:

>> 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.

> 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).

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.

-- 
Florian Weimer / Red Hat Product Security Team

[prev in list] [next in list] [prev in thread] [next in thread]