FF 33 release removes NSS funcionality

RESOLVED WONTFIX

Status

()

Firefox
Security
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: Joaquin Sanchez Jimenez, Unassigned)

Tracking

33 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0
Build ID: 20141011015303

Steps to reproduce:

Load and initialize FF NSS native library and try to access FF certificates. This only apply to FF 33 on windows distro. On MacOSX FF 33 works as expected. On Linux (tested only in ubuntu 14) works with system NSS, not yet tested with FF 33 NSS.



Actual results:

Error looking up function 'SECMOD_UpdateSlotList'
Error looking up function 'PK11_FindPrivateKeyFromCert'
Error looking up function 'PK11_GetSlotFromPrivateKey'
(Reporter)

Updated

3 years ago
Flags: needinfo?(dkeeler)
(Reporter)

Updated

3 years ago
Component: Untriaged → Security
Joaquin, it would be helpful to know what your goal here is. Is this for a 3rd party app that is separate from Firefox and just uses the libraries that comes with it? Or is this an applet/addon/etc. that runs in Firefox? Also, I gather it needs access to an NSS certificate database. Does this database need to be the one in the user's profile?
Flags: needinfo?(dkeeler) → needinfo?(joaquin.sanchez)
(Reporter)

Comment 2

3 years ago
Hi David:

The application is a java applet (to be platform independant), completly separate from firefox (can run on IE, Chrome/Chromium, Safari and Opera on any operating system, without any privilege and any instalation process, just download and deploy it and run; of course java, and java plugin are needed). 

The applet is deployed (write applet tag in html DOM) via jquery plugin, forcing to start the java plugin in a separate process (don't need dom.ipc.plugins.java.enabled=true). Both, applet and jquery plugin is the client part of a more complex product.

The applet provides capabilities for crypto operations, basically sign, encrypt and ssl support via navigator crypto store. On Windows, MSCAPI for IE, Opera and Chrome and NSS for Firefox; on Linux, NSS or FF NSS for Firefox and NSS Shared DB for Chrome/Chromium; on MacOSX, NSS for Firefox and Keychain for Safari.

About Firefox (in all platforms), the applet only opens FF NSS DB in read only mode (NSS_Init and currently working to use NSS_Init_Context instead). This FF DB is the current profile of the user (or last opened profile: Default=1 in profiles.ini). And of course, the applet cannot add, remove or delete any entry in NSS DB. For example, for signing purposes, from CMS to CAdES, from XMLDSIG to XAdES, and of course from PDFSignature to PAdES, including XMLDSIG/XAdES with binary content and more complex operations like counter-signature or co-signature. In any of the process described, the applet only need to select a FF NSS certificate, and then invoke the SGN_Begin, SGN_Update and SGN_End functions via SGNContext using the NSSPrivateKey corresponding to the first step, and in some cases repeating the process with different algorithms (CAdES or XAdES for example needs additonal signatures).

The applet also needs to be able to reload certificates once started (I reported a bug to JSS, NSS java port, years ago: bug 313985), but SECMOD_UpdateSlotList is removed from FF 33 distro and I don't want to use WaitForAnyTokenEvent function. As I said, some removed functions can be rewritten and others not. Because Tom's comments (FF NSS should be private), I started looking an alternative using PKCS11, but this requires the user using the applet having administration privileges, so this is not suitable, and of course, expecting required functions wasn't removed from NSS distro.
Flags: needinfo?(joaquin.sanchez)

Comment 3

3 years ago
We have similar features as stated in upper comment.

Found out that some exported functions are renamed. Have _Utils postfix, other are just removed.

Also found out that those new functions are not in headers in latest gecko sdk. 
So it's hard to use headers for static linking to nss.

removed:
NSS_Get_sgn_DigestInfoTemplate
PK11_Verify

renamed in %func_name%_Utils:
SGN_CreateDigestInfo
SGN_DestroyDigestInfo

So far I found this could be the reason.
https://blog.mozilla.org/addons/2014/10/01/compatibility-for-firefox-33/
https://bugzilla.mozilla.org/show_bug.cgi?id=1025998

We fixed to port some code from nss to our code and 
use dynamic library loading,
checking if function exist and use new one if not.

The best way to found out what is missing if you are using static linking is
to use Dependency Walker and nss3.dll should be from ff33 folder.
(Reporter)

Comment 4

3 years ago
> We fixed to port some code from nss to our code and 
> use dynamic library loading,
> checking if function exist and use new one if not.

If each release changes exported functions, good luck ;). As I said, sometimes "use new one if not" is possible others not: try to implement SECMOD_UpdateSlotList...

Comment 5

3 years ago
I totally agree. Just stated how we fix ff33 mess. 
If this kind changes goes on, we will not be able to use firefox cert store for signing documents.
Hope that there will be new api if existing will be dropped.
(Reporter)

Comment 6

3 years ago
Read from bug 1025998 comment 29 to the end

I have NEVER requested a new api, NSS is perfect, including multiplatform isolation (only work with its types), but some people do not agree with my point of view.
(Reporter)

Comment 7

3 years ago
Confirmed, FF libnss3.so also exports SECMOD_UpdateSlotList, PK11_FindPrivateKeyFromCert and PK11_GetSlotFromPrivateKey (ubuntu 14).

David, I just need a way to access firefox certificates and make some crypto operations, just why not NSS (perfect for these operations)?. As Dragoslav said, FF wouldn't be usable for these purposes. I DONT want another API, I don't need it (FF people want to build a new one? I think NO).

When working with the public administration, there are many procedures that need to be submitted electronically also require electronic signature. What a user wants is that when using the browser, the certificate that signs the process is that installed in its browser. The solution has to be designed in what the customer expects and not what the developer thinks is the best solution. If Firefox does not allow access to their certificates or perform signing and encryption operations with them, then what solution can give ?. I do not want to repeat again and again, it is not what I want, it's what users expect, and comments such as Tom, what we get is that users can not do what they need to do.

If you do not believe me, check out these blogs (spanish), there are more: 

1. Why do I have to be a computer engineer to perform procedures through the internet with the AEAT (Spanish tax agency):
http://bartolomeborrego.blogcanalprofesional.es/%C2%BFpor-que-tengo-que-ser-ingeniero-informatico-para-poder-realizar-tramites-a-traves-de-internet-con-la-aeat/
2. Came the nightmare of every year:
http://www.forosuse.org/forosuse/showthread.php?t=29670
3. Sick of the websites of the Administration
http://www.kriptopolis.com/node/504

Comment 8

3 years ago
We use nss api our e-banking solutions for signing payments and contracts.
In Slovenia digital signature is legally equal person's handwritten signature.
(Reporter)

Comment 9

3 years ago
(In reply to Dragoslav Mlakar from comment #8)
> In Slovenia digital signature is legally equal person's handwritten
> signature.

Also in Spain, and in "general" all countries with a digital signature law
(In reply to Joaquin Sanchez Jimenez from comment #2)
> The applet is deployed (write applet tag in html DOM) via jquery plugin,
> forcing to start the java plugin in a separate process

If that's the case, it may work best to distribute the appropriate NSS libraries along with your applet. That way, you know exactly what's available.

> About Firefox (in all platforms), the applet only opens FF NSS DB in read
> only mode (NSS_Init and currently working to use NSS_Init_Context instead).
> This FF DB is the current profile of the user (or last opened profile:
> Default=1 in profiles.ini).

Just as an FYI, this might not be safe in general. For instance, if Firefox is modifying the DB at the same time that your applet is trying to read it, your applet could crash.
(Reporter)

Comment 11

3 years ago
(In reply to David Keeler (:keeler) [use needinfo?] from comment #10)
> (In reply to Joaquin Sanchez Jimenez from comment #2)
> > The applet is deployed (write applet tag in html DOM) via jquery plugin,
> > forcing to start the java plugin in a separate process
> 
> If that's the case, it may work best to distribute the appropriate NSS
> libraries along with your applet. That way, you know exactly what's
> available.

This is not true. If the applet loads its own version of NSS, this may be a problem if the FF NSS is not compatible. Of course, if FF NSS has changed the problem arises in both cases.

> > About Firefox (in all platforms), the applet only opens FF NSS DB in read
> > only mode (NSS_Init and currently working to use NSS_Init_Context instead).
> > This FF DB is the current profile of the user (or last opened profile:
> > Default=1 in profiles.ini).
> 
> Just as an FYI, this might not be safe in general. For instance, if Firefox
> is modifying the DB at the same time that your applet is trying to read it,
> your applet could crash.

In my case, it is not possible. If user opens FF certstore, there is no way to get focus on html page and the applet cannot be showed or loaded; if my applet is visible, it is modal, so the user cannot open FF certstore. If FF NSS DB is kept opened, there is no way my applet and FF access to certstore at the same time and viceversa. My applet leaves open FF NSS DB and closes on html page unload event. I have tested that FF and my applet working correctly.

Comment 12

3 years ago
Not quite related to this issue. But is there any progress in mozilla about webcrypto api?

Supporting also this would make sign possible from javascript.
https://www.youtube.com/watch?v=MNzTCoxr2ek
(In reply to Dragoslav Mlakar from comment #12)
> Not quite related to this issue. But is there any progress in mozilla about
> webcrypto api?
> 
> Supporting also this would make sign possible from javascript.
> https://www.youtube.com/watch?v=MNzTCoxr2ek

The tracking bug for webcrypto is bug 865789. The majority of the spec has been implemented and enabled in Firefox 34.

Comment 14

3 years ago
So in 34 you can already use certificate from store to sign stuff or not?
Is there any example to have a quick start?
Currently WebCrypto doesn't have direct access to the browser's certificate store. It can be used to create a new key/certificate to sign data, but it can't access preexisting ones. See also bug 879677, which could address that issue.

In general, though, signing data with WebCrypto looks like this: https://hg.mozilla.org/mozilla-central/annotate/d7c76fe69e9a/dom/crypto/test/test_WebCrypto.html#l888

Here's an introduction to WebCrypto if that helps: https://timtaubert.de/blog/2014/10/keeping-secrets-with-javascript/

Comment 16

3 years ago
Thank you for your explanation and points where to look for more info.
This is very promising. Just one question more if I may.

Is there any roadmap with milestones for this feature? Accessing already stored private keys.
We are making some decisions about changing our existing digital signature product 
and any info would be very helpful.

Comment 17

3 years ago
On beta channel version 38 (20150409) this is again broken? NSS api is changed again?
Is there and valuable blogs, notes what is going on?

Comment 18

2 years ago
(In reply to Dragoslav Mlakar from comment #17)
> On beta channel version 38 (20150409) this is again broken? NSS api is
> changed again?
> Is there and valuable blogs, notes what is going on?

On some platforms, to trim unused code, NSS functions not used by Firefox itself are not available. As mentioned in comment 4, it's probably a better idea to include a proper version of standalone NSS.

Comment 19

2 years ago
(In reply to :Cykesiopka from comment #18)
> (In reply to Dragoslav Mlakar from comment #17)
> > On beta channel version 38 (20150409) this is again broken? NSS api is
> > changed again?
> > Is there and valuable blogs, notes what is going on?
> 
> On some platforms, to trim unused code, NSS functions not used by Firefox
> itself are not available. As mentioned in comment 4, it's probably a better
> idea to include a proper version of standalone NSS.

I forgot to mention that it isn't really communicated anywhere because the NSS libs included with Firefox are treated more as internal implementation details.

Comment 20

2 years ago
As far as I can tell, the two mainstream certificate database formats used by NSS and Firefox have been stable. So there probably won't be an compat issues with using standalone NSS.

Comment 21

2 years ago
Anyways, thanks all for filing the bug and taking the time to comment and answer questions.

It looks like at this point, the use cases being asked here are not something we really want to support, or can be done via other means.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.