Right now we always use the server's RSA keys to wrap and unwrap the TLS session ticket keys for the shared-memory session ID cache. This won't work with a pure-ECC server that doesn't have any RSA keys. Our test suite passes because even when ECC is enabled, our test servers have both RSA and ECC keys. Rather than using the code in http://lxr.mozilla.org/security/ident?i=getWrappingKey to support wrapping and unwrapping with ECDH keys, I think a better solution is to just use our wrapping key (the sym key returned by getWrappingKey) to wrap and unwrap the TLS session ticket keys. Then we only need to communicate one key (the wrapping key) via the shared memory SID cache to the other server processes. Nelson, Bob, what do you think?
I don't know why session tickets weren't already encrypted by the symmetric wrapping key to begin with. That's the most logical key to use. bob
Our server side implementation of TLS STE has no way to export the key used to wrap and unwrap the session tickets. It is shared among the servers that share a shared memory session cache, but a group of server processes that share a shared-memory session cache isn't big enough to need STE. A set of servers that needs STE is a set of servers that occupy multiple physical boxes and a shared memory cache will not suffice for them to share the STE wrapping keys. So, we need an API by which the application can wrap-out and unwrap-in the keys used to wrap (and MAC) the Session tickets. This is part of the price we pay for the ongoing perception that NSS is just a browser (client) library and not also a server library. :(
You need to log in before you can comment on or make changes to this bug.