68869 - tstclnt: write to SSL socket failed: TCP connection reset by peer

Status: RESOLVED FIXED

(NSS :: Tools, defect, P2)

Description

[Sonja Mirtitsch]

Testclient has a wrong password, on Unix the read on the server hits EOF which
is the expected behavior, but on NT the client gets ECONNRESET.

The errormessage is:
tstclnt: write to SSL socket failed: TCP connection reset by peer.

Example output on Unix
=======================
***** TLS Require client auth (bad password) ****
selfserv -v -p 8443 -d
/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/tests_results/security/compaqtor.1/server
-n compaqtor.red.iplanet.com -w nss -r -r -i /tmp/tests_pid.112445 & tstclnt -p
8443 -h compaqtor -q -d
/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/tests_results/security/compaqtor.1/client
redir from
/tmp_mnt/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/security/nss/tests/ssl/sslreq.txt
/tmp_mnt/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/tests_results/security/compaqtor.1/client
tstclnt -p 8443 -h compaqtor -f -d
/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/tests_results/security/compaqtor.1/client
-w bogus -n TestUser redir from
/tmp_mnt/h/hs-sca15c/export/builds/mccrel/nss/nsstip/builds/20010213.1/y2sun2_Solaris8/mozilla/security/nss/tests/ssl/sslreq.txt



selfserv: About to call accept.



selfserv: About to call accept.



selfserv: About to call accept.
selfserv: HDX PR_Read hit EOF returned error -5938:
Encountered end of file.
selfserv: HDX PR_Read returned error -12285:
Unable to find the certificate or key necessary for authentication.
tstclnt: write to SSL socket failed: SSL peer cannot verify your certificate.
test TLS Require client auth (bad password) produced a returncode of 254 as
expected
./ssl.sh: 112973 Terminated

Example NT
===========
**** TLS Require client auth (bad password) ****
selfserv -v -p 8443 -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/sonjant.1/server
-n sonjant.red.iplanet.com -w nss -r -r -i C:/TEMP/tests_pid.236 & tstclnt -p
8443 -h sonjant -q -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/sonjant.1/client
redir from
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/sonjant.1/client
tstclnt -p 8443 -h sonjant -f -d
w:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/tests_results/security/sonjant.1/client
-w bogus -n TestUser redir from
W:/nss/nsstip/builds/20010213.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt
tstclnt: write to SSL socket failed: TCP connection reset by peer.
[6] + Done(134) ?
  266	Abort	tstclnt
test TLS Require client auth (bad password) produced a returncode of 134 as
expected

============================

Note that 134 is ENOTCONN and not ECONNRESET

This behavior has been known for at least 5 months, as a sideeffect it causes
differnt returncodes on NT and Unix

When this bug is fixed please reassign to me, so I can fix the script.

Comment 1

[Wan-Teh Chang]

There is some ifdef _WINDOWS code in tstclnt.c
that I don't quite understand.  For example, if
the -f option is specified (which is true in our
test), tstclnt would call PR_Poll with a zero
timeout and modify the return value so that it
is always > 0.  Such ifdef _WINDOWS code could
explain the different behavior of tstclnt on
Windows.  Moreover, we are not supposed to check
the out_flags fields unless PR_Poll returns a
positive (> 0) value, but tstclnt modifies the
return value of PR_Poll to make it positive.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Bob informs me that the reason this test uses a bad password
is to ensure that the client does NOT send a client certificate
to the server when the server requests it.  

So, I request that the test script be changed.  Instead of 
using a bad password, it should use a nickname that is known
not to exist, e.g.  -n nonexistant   instead of -w badpassword

I don't know the significance of the number 134 in the "done"
message in the NT output, but I'm pretty certain that it 
means neither ENOTCONN nor ECONNRESET.  134 is the value of 
ENOTCONN on UNIX.  On NT, the value is 10057.  The value for
the NSPR equivalent error is -5978.  

main() returns -2 after the PR_Write error.  I'd expect that
to be the return mode (modulo 256).

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

Also, on Unix, the server's PR_Read gets error -12285:
Unable to find the certificate or key necessary for authentication.
which means that the server did not receive the required 
authentication certificate from the client.

The EOF is from the previous run of  tstclnt -q, I believe.

Comment 4

[Wan-Teh Chang]

Nelson is right.  134 is not ENOTCONN or ECONNRESET.
(Winsock errors are defined in winsock.h or winsock2.h,
not errno.h, and are in the 10XXX range.)  In fact,
134 is not related to the error code.  The main()
function in tstclnt returns -2, not the error code.
How the MKS Korn Shell gets 134 from -2 is beyond me.

On Unix, the parent process can only retrieve the
lowest 8 bits of the value the child returns.  This
is the modulo 256 operation that Nelson mentioned.
-2 modulo 256 = 254, which is the expected return
status on Unix.

It is best to modify tstclnt to return a value
in the range 0 through 255.

Comment 5

[Sonja Mirtitsch]

So, should I just fix the testclient's returncodes and the script, and the rest
of the problem (different behavior due to strange ifdef WINDOWS on NT) can be
ignored?

Comment 6

[Wan-Teh Chang]

Assigned the bug to Nelson.

Comment 7

[Nelson Bolyard (seldom reads bugmail)]

I'm narrowing the scope of this bug.  This bug is now about just one
issue, namely, this message:
tstclnt: write to SSL socket failed: TCP connection reset by peer.

Comment 8

[Sonja Mirtitsch]

At least that is what I intended it for originally!

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Sonja,
Is this problem still occuring?
Does it only occur on NT?
or does it also occur on other operating systems?

Comment 10

[Sonja Mirtitsch]

Still occuring.
No, Win NT and Win 2K
see #ifdef _WINDOWS in tstclnt.c
paste in yesterday's QA of clio
---------------------

ssl.sh: TLS Require client auth (bad password) ----
selfserv -D -p 8443 -d ../server -n clio.red.iplanet.com \
         -w nss -r -r -i ../tests_pid.756  &
selfserv started at Mon Jun 11 01:13:51 PDT 2001
tstclnt -p 8443 -h clio -q -d . <
W:/nss/nsstip/builds/20010611.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt

tstclnt -p 8443 -h clio -f -d . -w bogus -n TestUser \
        <
W:/nss/nsstip/builds/20010611.1/blowfish_NT4.0_Win95/mozilla/security/nss/tests/ssl/sslreq.txt
tstclnt: write to SSL socket failed: TCP connection reset by peer.
[6] + Done(134) ?
  596	Abort	tstclnt
ssl.sh: WARNING! Testclient returned 134, expect 
             254 (no error as tmp workaround)

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

This is a good catch!

There are numerous problems here.  

First, when the server demands client authentication, and the attempts to 
connect to the server without doing client authentication, both the client 
and the server should report error codes.  But in the log files the server 
does not always report an error for this.  

Second, On Unix it is reporting EOF received and on NT it is reporting 
connection reset by peer.  Neither of these is the expected error message
for this type of situation.   These are both socket errors, not SSL/TLS
errors.  We expect to see an SSL/TLS error number.

For TLS and SSL we expect to see the log look something like this:

tstclnt -p 8443 -h windmere -f -d . -T -n TestUser -w bogus \
        < D:/nss_tip/mozilla/security/nss/tests/ssl/sslreq.txt
selfserv: HDX PR_Read returned error -12285:
Unable to find the certificate or key necessary for authentication.
tstclnt: write to SSL socket failed: SSL peer cannot verify your certificate.

I'm working on fixing this now. 

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

I have checked the fix into rev 1.21 of ssl3con.c.  On my NT box, 
the logfile from ssl.sh now contains these excerpts:

ssl.sh: TLS Require client auth (bad password) ----
selfserv -D -p 8443 -d ../server -n windmere.red.iplanet.com \
         -w nss -r -r -i ../tests_pid.344  &
selfserv started at Wed Jun 13 14:04:21 PDT 2001
tstclnt -p 8443 -h windmere -q -d . < D:/nss_tip/mozilla/security/nss/tests/ssl/
sslreq.txt
tstclnt -p 8443 -h windmere -f -d . -w bogus -n TestUser \
        < D:/nss_tip/mozilla/security/nss/tests/ssl/sslreq.txt
selfserv: HDX PR_Read returned error -12285:
Unable to find the certificate or key necessary for authentication.
tstclnt: write to SSL socket failed: SSL peer cannot verify your certificate.
[6] + Done(134) ?
  306   Abort   tstclnt
ssl.sh: WARNING! Testclient returned 134, expect
             254 (no error as tmp workaround)
ssl.sh: TLS Require client auth (bad password) produced a returncode of 134, exp
ected is 134 PASSED

and

ssl.sh: SSL3 Require client auth (bad password) ----
selfserv -D -p 8443 -d ../server -n windmere.red.iplanet.com \
         -w nss -r -r -i ../tests_pid.344  &
selfserv started at Wed Jun 13 14:04:30 PDT 2001
tstclnt -p 8443 -h windmere -q -d . < D:/nss_tip/mozilla/security/nss/tests/ssl/
sslreq.txt
tstclnt -p 8443 -h windmere -f -d . -T -n TestUser -w bogus \
        < D:/nss_tip/mozilla/security/nss/tests/ssl/sslreq.txt
selfserv: HDX PR_Read returned error -12285:
Unable to find the certificate or key necessary for authentication.
tstclnt: write to SSL socket failed: SSL peer cannot verify your certificate.
[12] + Done(134) ?
  388   Abort   tstclnt
ssl.sh: WARNING! Testclient returned 134, expect
             254 (no error as tmp workaround)
ssl.sh: SSL3 Require client auth (bad password) produced a returncode of 134, ex
pected is 134 PASSED

If you get different results than this on Unix, please file a bug about that.