Bob mentioned in previous conversation (when I suggested that Mozilla should switch to using the bypass mode only) that he would like to remove the bypass mode code completely. I think this is a good idea. It will simplify work on a few bugs, some of which I have included in the "Blocks" list of this bug. If we are going to do this, then we should do it soon so that we can avoid doing unnecessary extra work. This is all based on the assumption that Oracle is almost done replacing NSS with another SSL implementation throughout all their products. We should verify that and/or verify that Oracle doesn't care if the bypass mode is removed.

You didn't cc any Oracle NSS developers. Are you going to ask them the question by email? The PKCS #11 bypass mode is a good way for NSS to compete fairly with other SSL libraries' software crypto performance. Unfortunately the PKCS #11 bypass mode was implemented in a way that's very difficult to maintain. So its removal is perhaps inevitable.

Who are the current Oracle NSS people? I was told that the NSS developers I from Oracle (Christophe and Alexei) are no longer working on NSS.

In reply to comment 1, Wan-Teh, what are the aspects of bypass mode that make it difficult to maintain? How would you have done it differently and still obtained the performance benefits?

Meena, could you (or somebody else at oracle) comment on this bug regarding how important the PKCS#11 bypass mode in NSS's libssl is to Oracle now and going forward?

I am requesting Julien Pierre who is our security point of contact to reply to this. Regards, Meena

Brian, I am the security lead for one of the Oracle server products which relies on NSS. The use of the NSS PKCS#11 bypass mode is of vital importance to it. The PKCS#11 bypass is enabled in the default server configuration. Not having it would cause a major performance regression. This product not only continues to be supported, but also continues to be sold by Oracle today. There are several other products in Oracle which still use NSS, though they may not all rely on the PKCS#11 bypass in a critical fashion. The assumption that Oracle is almost done replacing NSS with another SSL implementation throughout all its products is an incorrect assumption. I can't give more details than that publicly. As a former NSS developer however, I will say that NSS has always maintained binary compatibility for major releases, and it would be quite surprising to see that change now. The NSS promise of API compatibility was always important to Sun (now Oracle) and my understanding is that it was important to Linux as well, as other security libraries had much less stable APIs.

Thanks for the input Julien. The fact that Oracle is still using NSS in at least some of this products is an important information for this bug. Bypass mode introduces complexity in both the SSL code itself, and in the desire to keep applications using the standard PKCS #11 interfaces. Those are pretty high costs, but keeping Oracle servers on NSS is worth the cost, IMHO. > As a former NSS developer however, I will say that NSS has always maintained binary > compatibility for major releases. That is still true, applications will continue to function if Bypass is removed. (I'll quibble with the use of 'major performance regression', but I will concede performance regression). We do not export any of the Bypass explicit API. Even with this guarrentee, the NSS team has in the past, and continues to into the future, remove unused functionality. FORTEZZA is one example. If Oracle servers are no longer using NSS, then there are no other users of Bypass mode (Red Hat servers do not turn Bypass mode on, as the performance gains are not significant enough to warrant the extra testing). In any case the fact the Oracle is still using NSS and still using Bypass is an important input to this bug. bob

Bob, In reply to Robert Relyea from comment #7) >Bypass mode introduces complexity in both the SSL code itself, and in the >desire to keep applications using the standard PKCS #11 interfaces. Those are >pretty high costs, but keeping Oracle servers on NSS is worth the cost, IMHO. Note that I can't make any promise about future Oracle server products, but currently shipping Oracle products do use NSS and bypass, and typical support life after EOL (which hasn't happened yet) would be 5 years, so that gives you an idea of how long we would like to see this stay in NSS. > That is still true, applications will continue to function if Bypass is > removed. (I'll quibble with the use of 'major performance regression', but I > will concede performance regression). We do not export any of the Bypass > explicit API. Actually libssl exports SSL_CanBypass, as well and the flag SSL_BYPASS_PKCS11 is public in ssl.h . Re: the Fortezza removal, did that code ever actually worked in the NSS shared libs ? I think it was mistakenly exported for legacy reasons during the initial port. Julien

(In reply to Julien Pierre from comment #6) > The assumption that Oracle is almost done replacing NSS with another SSL > implementation throughout all its products is an incorrect assumption. Thanks!

> Re: the Fortezza removal, did that code ever actually worked in the NSS shared > libs ? I think it was mistakenly exported for legacy reasons during the initial port. No it' wasn't a mistake. Fortezza was still used at the time. We still have the public facing functions for ABI compatibility, it just won't actually work when you try to connect to a fortezza server with a fortezza PKCS #11 module installed. We would do the same with bypass. The application could still 'turn it on', it just wouldn't do anything different than what it is already doing. It's mute for now, since you are still using it, we'll keep it around. bob

Just a heads up for people CC'ed here, we decided to remove the bypass mode at last week's NSS meeting in MV. Bug 1303224 will land and ship with NSS 3.28.