Closed Bug 292238 Opened 19 years ago Closed 10 years ago

javascript function crypto.signText returns "error:internalError"

Categories

(Core :: Security: PSM, defect)

Product:
Core
Component:
Security: PSM
Version:
1.7 Branch
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla-bugzilla, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0

a call to crypto.signText returns "error:internalError" if the issuer of your
certificate "is not trusted", ie. none of the CAs in the CA-chain has been set
to  "This certificate can identify mail users".  


Reproducible: Always

Steps to Reproduce:
1. import a key+certificate with at least keyUsage 'digitalSignature'
2. disable all trust settings for all CAs in the CA chain of this certificate.
The 'Purposes' column of the ceritifcate should say '<Issuer Not Trusted>'
3. create a small HTML page containing a call to crypto.signText(). E.g.g
<html><body><span onclick="alert(window.crypto.signText('some text',
'ask'))"></body></html>
4. activate the call to crypto.signText and confirm to sign the text with the
certificate of step 1.


Actual Results:  
crypto.signText() returned the string "error:internalError" 

Expected Results:  
Firefox should either:
A) return the signature, just like it does when the issuer of the certificate is
trusted, or
B) not offer the user to sign the text with this certificate 

This problem may have the same cause as bug #247285. However I could not
reproduce the bug with the javascript console method described in that report,
because on my system calling crypto.signText in the console always results in
internalError, regardless of whether the issuer is trusted. 
Anyway, *this* issue has not been resolved yet.
This bug also appears in Mozilla v1.7.8.

Please, change the severity to minor because this bug is not severe at all
(there is a very easy workaround: just enable trust settings for CAs of your
certificate)
Severity: normal → minor
Assignee: nobody → kengert
Component: General → Security: UI
Product: Firefox → Core
QA Contact: general
Version: unspecified → 1.7 Branch
Whiteboard: [kerh-coz]
Some easier instructions to reproduce:

1. Generate a new user certificate at http://wiki.rcpt.to:8180/pkcs/ca.html
2. Do not import the CA certificate (it should also fail if importing it but not trusting it for email signing)
3. Attempt to sign anything using http://wiki.rcpt.to:8180/pkcs/convert.html

The problem, as recently discussed on mozilla.dev.tech.crypto, is that nsCrypto::SignText calls through SEC_PKCS7CreateSignedData and sec_pkcs7_add_signer to CERT_VerifyCert, which performs inappropriate trust checks (for this particular operation) on the user certificate being used.
Easy workaround for this bug ("error:internalError"):

If you are a user: Just enable trust setting to identify mail users
for the CA of your certificate.

If you are a web application programmer: Just tell users to enable trust
setting to identify mail users for the CAs of their certificates.

Sorry for my English.
There is easier test method. 

1. Generate your key in http://mikolaj.cx/pkcs/key.html
2. Activate your master password in security option.
3. Write something and click sign button in http://wiki.rcpt.to:8180/pkcs/convert.html
4. You can meet popup window for signing. Give a master password.
5. But it's internal error yet.
QA Contact: ui
Mass change owner of unconfirmed "Core:Security UI/PSM/SMime" bugs to nobody.
Search for kaie-20100607-unconfirmed-nobody
Assignee: kaie → nobody
I have confirmed this issue: I just hit this bug in firefox 27.0a1 (2013-10-05).

Using bulbank.bg, online banking clients are walked through how to use client certificates in order to sign online money movement transactions.  They must install a CA certificate (from bulbank), and then create and install a user certificate signed by the former.

All of this succeeds, and the user cert successfully identifies a user, however attempts to sign using that certificate fail.  The issue is the very same as mentioned here, a user must manually adjust trust settings in order to sign with their user cert.

For a normal human, I imagine the result is that they go and use internet explorer for their bank (I have three friends in bulgaria who do so).

For me, I dumped the network interactions and noticed the signature was 'error:internalError'.  A google search lead me to this bug.

My point is, it seems like a very minor improvement in error handling here might raise the visibility of the failure to the point where we could gauge how many folks waste hours of their life on it, and then walk away in frustration.

Should this bug really remain 'unconfirmed'?
AIUI the likelier fix will be removing these functions completely...
Status: UNCONFIRMED → NEW
Component: Security: UI → Security: PSM
Ever confirmed: true
Whiteboard: [kerh-coz]
This problem occurs if you try the simple code var r=crypto.signText("something","ask"); before you load any webpage.

After you have load any webpage, then you try the same code, the problem will not appear.

So in fact, it is very easy to confirm this. If you do not believe me, you can try it out. By the way, I am using firefox 27.0.
See Also: → 964202
Bug 1030963 removed this functionality entirely.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.