280869 - NSS API usability problem with multiple server SSL certs

Status: NEW

(NSS :: Libraries, enhancement, P2)

Description

[Chris Newman]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021104 Chimera/0.6

The NSS API does not provide a convenient way to set up and manage an SSL
configuration indepedent of a socket/file descriptor.  This becomes a problem
when a server application needs multiple SSL certs selected based on STARTTLS or
the IP address to which the client connects.  With the current APIs the only
choice is to waste a file descriptor per SSL server cert (and file descriptors
are a limited resource in scalable servers), or to write a complete NSPR I/O
stub layer which returns PR_NOT_IMPLEMENTED_ERROR for each function (that's on
the order of 50 stub functions).

My preferred fix for this problem would be to allow SSL_ImportFD(0, 0) to create
a noop PRFileDesc with no underlying OS file descriptor.  An acceptable
alternative would be a new NSPR function "PR_GetNoopIOMethods()" similar to
PR_GetDefaultIOMethods(), then use that in combination with PR_CreateIOLayerStub
to pass as the second argument to SSL_ImportFD.

Reproducible: Always

Comment 1

[Wan-Teh Chang]

Chris, are you talking about the SSL "model sockets"?

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Wan-Teh,  As you will recall from iPlanet days, there is a certain server
that uses its own implementation of NSPR, with its own PRIOMethods for 
the bottom layer in the "stack" of PRFileDescs.  That implementation had
NULL pointers for some functions, having implemented only the functions 
they found to be used by SSL at that time.  Subsequently, libSSL was 
enhanced to call certain PRIOMethods in the lower (socket's) layer, and
consequently a crash resulted when SSL called one of the methods that had
a null method pointer.

Consequently, the NSS team at Sun is taking the position that any product
that uses its own PRIOMethods must implement *all* the methods, with no 
NULL pointers, and any unimplemented methods must contain valid code
that sets the error code for "not implemented" and returns an indication
of failure.  I believe this has always been the position of the NSPR team
as well, but you're in a better position to speak to that than I am.

In the short term, this requirement that all methods have non-NULL pointers
means that each server product that implements its own bottom layer NSPR
PRFileDesc must implement its own PRIOMethods table and a full set of PRIOMethods.  

As I view his request, Chris is asking that NSPR implement a full set of
these "nor implemented" methods, and make a function available that 
returns a PRIOMethods table that points to all those functions.

I believe that Chris is now implementing such a thing himself for his 
server, and I have asked him to contribute it to NSPR.  

Comment 3

[Chris Newman]

Attachment: Example of noop I/O layer.

I'm attaching code for the no-op I/O layer from higher-level code which I've
tested as part of the async I/O library I sustain.  I've verified that this
allows the creation of a no-op NSPR I/O layer to which an SSL configuration can
be attached without wasting a file descriptor, and that the result can be used
as a model fd when a real TCP SSL connection is created.

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

I just discovered that Chris added his attachment to this bug months ago.
I think bugzilla failed to notify me by email of his attachment.
So, belated thanks, Chris!

Wan-Teh, should this be added to NSS or to NSPR?  
Seems like the function to create a pseudo socket for use as a model socket
could be an NSS function or an NSPR one.  Which do you suggest?

Comment 5

[Wan-Teh Chang]

Let's add this to NSS first.  I can't think of anything
else that could use a noop I/O layer.

Alternatively, you could add a new SSL function that creates
a stand-alone SSL I/O layer (without a lower I/O layer), which
you can use as a model SSL socket.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Unsetting target milestone in unresolved bugs whose targets have passed.

Comment 7

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, and this bug has priority 'P2'.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 8

[Marco Castelluccio [:marco]]

We have modified the bot to only consider P1 as high priority, so I'm cancelling the needinfo here.