NSS: Unable to verify close_notify in client code?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NSS: Unable to verify close_notify in client code?

Johann 'Myrkraverk' Oskarsson
Hi,

Is it really impossible to verify if the server sent close_notify in a
normal NSS client application?

In both cases, PR_Read() returns zero with no error messages or status
difference of any kind.

I have tentatively verified that ssl3_HandleAlert() is called with
AlertDescription zero == close_notify, using dtrace, when my server
properly terminates the connection with PR_Close().  No such probe
(in the client) fires if I just kill the server (naturally).

My problem is that in the client code *I cannot distinguish the two*
(with or without close_notify) in normal PR_Read() loop.  There appears
to be no publicly available API to retrieve the status of the
recvCloseNotify flag.

And the ssl3_HandleAlert code does not propagate the condition, instead
the internal error = SSL_ERROR_CLOSE_NOTIFY_ALERT variable is simply
ignored, and it returns with SECSuccess.

This is situation is current as of changeset 14194:04fc9a90997b,
Mon Dec 18 11:05:28 2017 +0100.

How is NSS client code supposed to detect proper termination by the
other party?

I would call this a serious breach of security in the NSS public API.


--
Johann | email: invalid -> com | www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | twitter: @myrkraverk
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS: Unable to verify close_notify in client code?

Martin Thomson
See SSL_AlertReceivedCallback().

On 20 Dec. 2017 6:22 am, "Johann 'Myrkraverk' Oskarsson"
<[hidden email]> wrote:

> Hi,
>
> Is it really impossible to verify if the server sent close_notify in a
> normal NSS client application?
>
> In both cases, PR_Read() returns zero with no error messages or status
> difference of any kind.
>
> I have tentatively verified that ssl3_HandleAlert() is called with
> AlertDescription zero == close_notify, using dtrace, when my server
> properly terminates the connection with PR_Close().  No such probe
> (in the client) fires if I just kill the server (naturally).
>
> My problem is that in the client code *I cannot distinguish the two*
> (with or without close_notify) in normal PR_Read() loop.  There appears
> to be no publicly available API to retrieve the status of the
> recvCloseNotify flag.
>
> And the ssl3_HandleAlert code does not propagate the condition, instead
> the internal error = SSL_ERROR_CLOSE_NOTIFY_ALERT variable is simply
> ignored, and it returns with SECSuccess.
>
> This is situation is current as of changeset 14194:04fc9a90997b,
> Mon Dec 18 11:05:28 2017 +0100.
>
> How is NSS client code supposed to detect proper termination by the
> other party?
>
> I would call this a serious breach of security in the NSS public API.
>
>
> --
> Johann | email: invalid -> com | www.myrkraverk.com/blog/
> I'm not from the Internet, I just work there. | twitter: @myrkraverk
> --
> dev-tech-crypto mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-crypto
>
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto
Reply | Threaded
Open this post in threaded view
|

Re: NSS: Unable to verify close_notify in client code?

Hubert Kario
On Tuesday, 19 December 2017 20:44:33 CET Martin Thomson wrote:
> See SSL_AlertReceivedCallback().

though do note that TCP does not reliably deliver data after one side has
closed connection and behaviour of different implementations varies widely
(both on TCP and TLS level):
https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable

> On 20 Dec. 2017 6:22 am, "Johann 'Myrkraverk' Oskarsson"
>
> <[hidden email]> wrote:
> > Hi,
> >
> > Is it really impossible to verify if the server sent close_notify in a
> > normal NSS client application?
> >
> > In both cases, PR_Read() returns zero with no error messages or status
> > difference of any kind.
> >
> > I have tentatively verified that ssl3_HandleAlert() is called with
> > AlertDescription zero == close_notify, using dtrace, when my server
> > properly terminates the connection with PR_Close().  No such probe
> > (in the client) fires if I just kill the server (naturally).
> >
> > My problem is that in the client code *I cannot distinguish the two*
> > (with or without close_notify) in normal PR_Read() loop.  There appears
> > to be no publicly available API to retrieve the status of the
> > recvCloseNotify flag.
> >
> > And the ssl3_HandleAlert code does not propagate the condition, instead
> > the internal error = SSL_ERROR_CLOSE_NOTIFY_ALERT variable is simply
> > ignored, and it returns with SECSuccess.
> >
> > This is situation is current as of changeset 14194:04fc9a90997b,
> > Mon Dec 18 11:05:28 2017 +0100.
> >
> > How is NSS client code supposed to detect proper termination by the
> > other party?
> >
> > I would call this a serious breach of security in the NSS public API.
> >
> >
> > --
> > Johann | email: invalid -> com | www.myrkraverk.com/blog/
> > I'm not from the Internet, I just work there. | twitter: @myrkraverk
> > --
> > dev-tech-crypto mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-tech-crypto

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky┼łova 115, 612 00  Brno, Czech Republic
--
dev-tech-crypto mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-crypto

signature.asc (849 bytes) Download Attachment