If we send the close notify alert, don't reset the reader because the

counterparty might want to send us a matching close notify under the
currently existing key state. New logic is if we send the alert our
writer is reset (we will send nothing more), but leave the reader as
is. The reader will then be reset if and when we get a close notify,
or if the counterparty doesn't send one, we'll just end the connection
normally. This will also deal with the case where there is some
application data queued still in the recv buffer.

Don't close in ~TLS_Channel: applications should do this explicitly
when the application-level protocol is ended.  Otherwise we'd send a
close_notify upon, for instance, an uncaught exception unwinding the
stack.

Add an enum for the maximum size of any TLS ciphertext packet
including header. Handy for apps.

If we get a bad alert size report size we got.

0 files changed, 0 insertions, 0 deletions