458251 - SSLServerSocket should ensure that the session cache is configured

Status: RESOLVED WONTFIX

(JSS Graveyard :: Library, defect, P2)

Description

[Dean Roberts]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Build Identifier: 

When a JSS SSLServerSocket has requireClientAuth or requestCientAuth turned on but the client does not provide a certificate (this is allowable and not necessarily uncommon in SSL) the VM will core.

I have tested this against Sun's JDK 1.5.0_11 and our own VM implementation.  The problem appears to be an issue in a JSS native.

Thread: main (priority 5) (LOCATION OF ERROR)
 NATIVE   org/mozilla/jss/ssl/SSLSocket.socketRead([BIII)I
 0000003c org/mozilla/jss/ssl/SSLSocket.read([BII)I
 00000007 org/mozilla/jss/ssl/SSLInputStream.read([BII)I
 00000005 org/mozilla/jss/ssl/SSLInputStream.read([B)I
 000000d8 jss/SimpleJSSServer.run()V
 00000009 jss/SimpleJSSServer.main([Ljava/lang/String;)V

Reproducible: Always

Steps to Reproduce:
1.  Run the test server and client provided.  Appropriate keystores are also provided

The keystore and key passwords are change!tn0w


Expected Results:  
SSLServerSocket should likely throw an SSLException with reason no_certificate

It would appear that any client can actually bring down any server that has client authentication enabled by simply not sending a client certificate.

Comment 1

[Dean Roberts]

Attachment: Test case and keystore files

Comment 2

[Dean Roberts]

Just a simplification to the reproduce steps.

I have not included a test client or test client keystore as you can just use a browser as the client.

Run the server with the attached NSS keystore.

Use a browser to initiate an HTTPS connection to the test server:
   https://127.0.0.1

The browser will tell you that the server certificate is unknown ... so accept it.  The browser will also likely tell you that the server is claiming to be Dean Roberts and not 127.0.0.1.  Likewise accept that.

The browser will receive the servers Certificate request message and will provide no client certificate, since it has none.

The VM running the server will core.

Comment 3

[glen beasley]

The crash was due to the fact the SSL server session ID cache was never configured. JSS should ensure the session ID cache is configured, so I am 
changing the summary to work on the bug. 

Dean thanks for the test program:

Before creating any JSS SSL server socket you must  configure the server session ID cache by calling the method SLServerSocket.configServerSessionIDCache

http://www.mozilla.org/projects/security/pki/jss/javadoc/org/mozilla/jss/ssl/SSLServerSocket.html#configServerSessionIDCache(int,%20int,%20int,%20java.lang.String)
see also:
http://www.mozilla.org/projects/security/pki/nss/ref/ssl/sslfnc.html#1143851

        // We have to configure the server session ID cache before
        // creating any server sockets.
        SSLServerSocket.configServerSessionIDCache(100, 100, 100, null);

        SSLServerSocket listenSocket = new SSLServerSocket(443);

also after your accept you may want to force the handshake for debugging
        SSLSocket socket = (SSLSocket) listenSocket.accept();
        try {
            socket.forceHandshake();
        } catch (SocketException socketException) {
            System.out.println("forceHandshake" + socketException.getMessage());
        }

http://mxr.mozilla.org/security/source/security/jss/org/mozilla/jss/tests

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Glen, can you put a real stack trace into this bug?  
Can you identify the line of code that crashed?

Comment 5

[BMO Automation]

JSS development has moved from the Mozilla community to the Dogtag PKI community. Please re-file this bug at https://github.com/dogtagpki/jss if it is still relevant. Thank you!