Re: [TLS] Tr: Behaviour when TLS fails

[Martin Rex <[e-mail]>]

=?iso-8859-15?Q?Julien_=C9LIE?= wrote:
> 
> Would it be possible to have some more information about how to behave when
> a TLS negotiation fails?

I have no experience with STARTTLS-style extensions for protocols
such as NNTP or HTTP, but I think I know where the "should close down"
suggestion" because of the "indeterminate state" of the connection
comes from.  I also don't see a need for a MUST close down here.

The possibility to get back in sync on a connection after a SSL/TLS
handshake error (or a fatal SSL alert after a successful handshake)
is probably not a feature that most SSL/TLS stacks
offer in their APIs because it is not really deterministic.

A SSL/TLS stack could try to  recv(,,,MSG_PEEK) from the network socket
and apply heuristics whether anything that arrived during the
timeout might be a leftover SSL record from the failed SSL/TLS handshake
(or data) which would need to be cleared from the connection.  
But it is completely unclear how much SSL/TLS handshake (or data) messages
may still be in the network pipe when one side detects a fatal handshake
(or data) error and aborts.

Even in the successful TLS session closure case, when the connection is
gracefully completed with the CloseNotify closure alerts it is common
behaviour that the closure alert of one side dies unread in the network
pipe.  TLS v1.1 (and newer) explicitly mentions this characteristic for the
successful closure and describes what would have to be done/changed to
reuse a network connection of a _successfully_ closed SSL/TLS communication:

   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.

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  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.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

I can not think of a good and robust way to clear a network
connection from SSL/TLS errors, and even if someone came up with
a workable scheme, it would take much to long to be adopted by the
installed base and probably not usable/useful for several years.
Btw. not all (network) pipes offer "PEEK" and how long do you wait?

-Martin
_______________________________________________
TLS mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/tls