Closed Bug 508184 Opened 15 years ago Closed 8 years ago

Implement TLS keying material exporters in Mozilla Firefox


(Core :: Security: PSM, enhancement)

Not set





(Reporter: douglas, Unassigned)




(1 file, 2 obsolete files)

TLS keying material exporters
( allow additional
keying material to be derived ("exported") from the master secret used in the TLS (a.k.a. SSL) connection; this
exported keying material can then be used at the application layer for a
variety of purposes.  It would be good if Mozilla eventually had support for this.

A patch exists already for implementing keying material exporters in NSS (see bug #507359).

This bug is for exposing the keying material exporter at the Mozilla application layer via Javascript.  In particular, it introduces a new method called window.crypto.tlsExportKeyingMaterial(label, numBytes, contextValue), where contextValue can be null.  This method name or signature is not standardized anywhere.

FYI, I have also implemented this for OpenSSL/Apache/PHP, and a patch for that is
available at in
case interoperability testing is desired.
Product: Firefox → Core
QA Contact: firefox → toolkit
Attached patch Updated patch to match HEAD (obsolete) — Splinter Review
Note: I just ported this patch. I have not reviewed the original patch in any meaningful day.
Attached patch This time marked as a patch (obsolete) — Splinter Review
Comment on attachment 597805 [details] [diff] [review]
This time marked as a patch

Eric thanks for updating the patch. You also need to set review flags if you want this to go forward. Asking review to brian.
Attachment #597805 - Flags: review?(bsmith)
Attachment #597804 - Attachment is patch: true
Comment on attachment 597805 [details] [diff] [review]
This time marked as a patch

Eric: you attached the NSS patch to the wrong bug.  This bug
is about the JavaScript interface.  The NSS bug for TLS
keying material exporter is bug 507359.  In any case, it's
not necessary to attach a new patch.
Attachment #597805 - Attachment is obsolete: true
Attachment #597805 - Flags: review?(bsmith)
Attachment #597804 - Attachment is obsolete: true
We should have a new component for DOMCrypt (window.crypt).

It seems reasonable to me to expose this to JS, especially for use with the rest of DOMCrypt. But, the returned key material should probably be a key object as defined by DOMCrypt.

However, there are some issues w.r.t. offline use and connection management. For an HTTPS page, we might not have a valid SSL connection at all, if we loaded it from the cache. And, also, we might have MULTIPLE SSL connections for a host for which we send requests and receive responses, and each of those connections might be in a different SSL session. And/or the connection from which we loaded the page might not be open anymore. All of these connection management issues need to be specified before we can move forward with it.

Douglas, I looked at your patch. Besides the big connection management issue, there is also a thread-safety issue: generally, in Firefox we can only access SSL sockets on the socket transport service thread, not on the main thread where this code runs.
Component: Security → Security: PSM
QA Contact: toolkit → psm
Is there anybody working on this right now ? 

I made proof of concept of TLS "second channel authentication" for openssl and nss. I PRELOAD some api functions without modifing any source code. I catching handshakes and using RFC5705 material exporters. (multiple scenarios were tested including apache2/mod_ssl vs firefox)

I amd tryin to resolve issue "multiple TLS sessions/connections" with "Origin-Bound Certificates: Now called "Channel ID" "

Origin-Bound Certificates: Now called "Channel ID"
Transport Layer Security (TLS) Channel Ids draft-balfanz-tls-channelid-00

This should imho simplify issue when client/browser using one TLS Session based using Origin-Bound Certificates identity (or other client certificate ) for connection with same server.

Server will identity client by certificate and authentificate new connections automatically when there is primary TLS channel with this peer allready.
There's no clear use-case for this nor any particular party driving its implementation -> wontfix (this isn't to say that this will never happen, but rather to reflect that we are not working on this and we do not plan to).
Closed: 8 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.