Closed
Bug 958702
Opened 10 years ago
Closed 8 years ago
CSP 1.1: (followup) hash-source on multiprocess Gecko
Categories
(Core :: DOM: Security, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: grobinson, Assigned: grobinson)
References
Details
(Whiteboard: [domsecurity-backlog])
On multiprocess Gecko, CSPUtils.jsm, which computes the hashes of content to compare them against the hashes delivered in the policy, runs in the child process. Code running in the child process does not have access to NSS, which provides the functionality of the nsICryptoHash used to compute the hashes. Therefore, the calls to create nsICryptohash on multiprocess Gecko result in NS_ERROR_XPC_CI_RETURNED_FAILURE.
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → grobinson
Comment 1•10 years ago
|
||
WebRTC now also loads NSS in the child process. It is worth considering loading NSS in the child process for this too. However, NSS is pretty heavy-weight and I worry that on multi-process we'll regress memory usage too much. A lighter-weight alternative to loading all of NSS would be to use the NSSLOWHASH API: NSSLOWHASH_NewContext; NSSLOWHASH_Begin; NSSLOWHASH_Update; NSSLOWHASH_End; NSSLOWHASH_Destroy; This would likely save a significant amount of overhead. It would save even more overhead if we used OS-provided hashing libraries where available. For example, on Windows there's http://msdn.microsoft.com/en-us/library/windows/desktop/aa380202%28v=vs.85%29.aspx There is the Digest class in security/manager/ssl/src/ScopedNSSTypes.h. I'd modifying the Digest class to deal with these considerations (using NSSLOWHASH and/or CAPI or whatever). I suggest avoiding nsICryptoHash. Let me know if I can help in some way.
Comment 2•10 years ago
|
||
How about a JS library that can compute hashes? Performance should be ok …
Assignee | ||
Comment 3•9 years ago
|
||
(In reply to Florian Bender from comment #2) > How about a JS library that can compute hashes? Performance should be ok … That could work, but it seems to me that content processes should be able to do crypto natively. The issue here is our crypto library (NSS) is a monolith that adds a lot of overhead.
Comment 4•8 years ago
|
||
This one got fixed when we re-implemented CSP in C++ which got enabled within Bug 925004.
Status: NEW → RESOLVED
Closed: 8 years ago
Component: Security → DOM: Security
Resolution: --- → WORKSFORME
Whiteboard: [domsecurity-backlog]
You need to log in
before you can comment on or make changes to this bug.
Description
•