[PATCH] SSL: shutdown cleanly when other endpoint starts shutdown

[Judson Wilson]

> > > As far as I understand, just looking for TCP FIN should be good
> > > enough for this task.
> >
> > TCP FIN can not be authenticated. A man in the middle can make one.
>
> The same is true for close_notify with your patch.

close_notify is encrypted using the current session state.
A MITM cannot spoof a close_notify if it does not have the keys.


> Just keeping in mind that no close_notify means that the
> response may be truncated should work.  Note well that
> if it's client who closes the connection it's likely that the
> response is truncated (or the HTTP layer has enough
>  information to check that it wasn't).

Sorry if this is incorrect, but isn't it easy to tell if a
response is truncated in HTTP/1.1 at the
HTTP protocol layer?

Again I want to reiterate that truncation is NOT my
concern (although I agree it IS important). My
setting involves releasing keys to a trusted monitor
with read-only privileges, on the client's behalf
(such as an exfiltration detector). The client needs
to protect the integrity of its session, and must
ensure that the key can not be used to masquerade
as the client to the server.


On Wed, Dec 9, 2015 at 5:34 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> On Tue, Dec 08, 2015 at 01:21:41PM -0800, Judson Wilson wrote:
>
> > > As far as I understand, just looking for TCP FIN should be good
> > > enough for this task.
> >
> > TCP FIN can not be authenticated. A man in the middle can make one.
>
> The same is true for close_notify with your patch.  Just keeping
> in mind that no close_notify means that the response may be
> truncated should work.  Note well that if it's client who closes
> the connection it's likely that the response is truncated (or the
> HTTP layer has enough information to check that it wasn't).
>
> --
> Maxim Dounin
> http://nginx.org/
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20151209/f2845ec6/attachment.html>