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

Hubert Kario <[email protected]>
Newsgroups gmane.comp.mozilla.crypto
Message-ID <[email protected]>
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"
> 
> <[email protected]> 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
> > [email protected]
> > 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
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-crypto
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAlpLq/EACgkQkqjRuAHS
9fXBzQ/9Gy9aJH3KVYSqZzJWKIfE0ytKx9zQdi9lU5osah0yAxlX1KCJdb386bTR
e6dtDkiJndUNWqP3pFOpbcna120tOZYn05L6yvutXgi+oh3U29XyWFbhvPuko3TW
XqkkVOo/ylw3P4v0sMmBUNz4yPlkU42rudGoqOLbKjbq2lN0lUN5B8q91GKWafTn
X5upOHlzy9joX6QwXsDXGGdvoRWM2CutEQiW81OkxkVxRG00OdZA+afLQwklwDgW
McrGcgTCsWbvKLtg0xdTxcmIcY05XAHQWT/ylYJPqTJ4sTB5ngxLHevsF/7moSJs
xuUkTF5lCBeqfyIqdIDHQSB366Cuk/1UX3ZqhlIqI9lBjETrB0RtRTXoFTBeRuMX
Z2in2sdr43X3ih7XyjBPS0/lX8MemStvmo5xAx4pdmefVYf+trfZayMzzMvvXSyw
jw4gTaIx8JwIuxc/ufWf2cPd7YlffCttr94Uk7AOnS8sC2icc9++bxn/2t1YVlAZ
0hlKfy+M6EPobS6fvTS2MQ1/12UQH1QbjfIXdC4SBIwId7Vj0Ttyzuw6kSm/NrtK
3ox8wsEEF0miH0O4aQg3zBbRB57ERvxJrNIAZ/gdECpOsVfKHmLFgTL3dPN1sEr/
Kf1//Jo9jmEzqgPtDKny5UMC4MNCXbhQcMKBqnAMoSm3rL2uYjM=
=D4cQ
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.