Re: [TLS] Working Group Last Call for

[Martin Rex <[e-mail]>]

Martin Rex wrote:
> 
> 2. SSLv2 deficiencies: "Sessions can be easily terminated"
> 
>     o Sessions can be easily terminated.  A man-in-the-middle can easily
>      insert a TCP FIN to close the session and the peer is unable to
>      determine whether or not it was a legitimate end of the session.
> 
>    I think this exaggerates the usefulness of the closy_notify(0)
>    warning level alert as used in practice.  By using an application
>    level framing protocol to mark boundaries of data, it is fairly
>    easy for application callers to compensate for this "lack" of SSLv2.
>    Many applications that use a framing protocol look only at their
>    own framing rather than waiting for the close_notify alert exchange
>    to _complete_.

The semantics of the close_notify(0) Alert in TLSv1.2 (mostly unchanged
from TLSv1.0).  Quoting from

http://tools.ietf.org/html/rfc5246#section-7.2.1

   Unless some other fatal alert has been transmitted, each party is
   required to send a close_notify alert before closing the write side
   of the connection.  The other party MUST respond with a close_notify
   alert of its own and close down the connection immediately,
   discarding any pending writes.  It is not required for the initiator
   of the close to wait for the responding close_notify alert before
   closing the read side of the connection.

When pages are reloaded/refreshed or when users navigate before a
web pages has completed loading all elements, it happens regularly
that connections get terminated prematurely.

In some situations the TLS-level close-notify might suggest a
different behaviour than the common and likely app-level decision.

What should a server do when processing an upload-request (HTTPS PUT),
sends back a 200/201 to the Browser.  Does (or should) the server wait
for the clients TLS close-notify and should the server rollback the
PUT if the clients close-notify is not sent?  If a server actually
did rollback in absence of the client'c TLS close-notify, that would
actually open(!) a vulnerability, i.e. an attacker could remove the
clients TLS close-notify from the network causing the server to think
it should rollback while the client believes the transaction was
successful.  A "secure communication closure protocol" would need three
legs, but that is clearly prohibited by the TLS spec for the 
close_notify alert.


-Martin