Robert Relyea wrote:
> The NSS team has just RTM'ed NSS 3.12.6.
> The primary feature of NSS 3.12.6 is support for the TLS
Renegotiation Indication Extension, RFC 5746.
>
> Release notes are forthcoming with other additions and bug fixes.
>
> In addition, a new version of JSS has been released, JSS 4.3.2 which
allows application to control the default behaviors in using the extension.
>
> For JSS 4.3.2 see:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=530575
>
There are no artifacts on the ftp site for JSS 4.3.2:
ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/
Has 4.3.2 been marked RTM?
Unfortunately, Sun's JRE requires signed jars for JCE providers,
so the Mozilla signed jar file is pretty useful.
Thank you.
Yes, it's released, at least in source form.
I herewith speculate that this will have been the final release of JSS.
At about the same time as Oracle's acquisition of Sun, three of Sun's
NSS development team members left Sun. One of them was Sun's lead JSS
developer. I was another of them.
> Unfortunately, Sun's JRE requires signed jars for JCE providers,
> so the Mozilla signed jar file is pretty useful.
Signed bits may be available directly from Sun. It's also conceivable
that IBM or some other other big proponents of Java may be able to sign
those bits if they find it in their interest to do so.
Perhaps it would be possible to install your own root cert and sign it
yourself?
Probably not the simplest procedure. If you get it working it would be
nice to post a description for others.
- Marsh
Interesting thought. NSS even includes a JAR signing tool that was
originally written for this purpose (among others). But I suspect that
Sun's JVM requires that the signature come from one of a very select few
roots any not just any old trusted root. Hope I'm wrong!
Everything, I've read indicates that a JCE Provider's signing cert must
be signed by a cert from Sun (or maybe IBM).
http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6
http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
:
> You will receive an email message containing two plain-text file
> attachments: one file containing this code-signing certificate and
> another file containing its own CA certificate, which authenticates its
> public key. Please also allow five business days from receipt of your
> request for processing.
>
> 5. Use keytool to import the certificates received from the CA.
>
> Once you have received the two certificates from the JCA Code
> Signing Certification Authority, you can use keytool to import them
> into your keystore.
>
> First import the CA's certificate as a "trusted certificate":
>
> keytool -import -alias <alias for the CA cert> \ -file <CA cert file
> name> \ -keystore <keystore file name> \ -storepass <keystore
> password>
>
> Then import the code-signing certificate:
...
This would seem to imply that you can add your own CA for code-signing
purposes.
If you think about it, Sun once had developers too who presumably needed
to test their code without being given access to the official code
signing CA.
- Marsh
On 4/30/2010 1:11 PM, Marsh Ray wrote:
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
> :
>> You will receive an email message containing two plain-text file
>> attachments: one file containing this code-signing certificate and
>> another file containing its own CA certificate, which authenticates its
>> public key. Please also allow five business days from receipt of your
>> request for processing.
>> ...
>> First import the CA's certificate as a "trusted certificate":
So, it turns out that the entire Java crypto infrastructure is built
atop plain old unauthenticated RFC-822 email after all.
Could any attackers could be so organized as to intercept port 25 email
and quietly substitute their own root CA certificate, thereby gaining
trusted code execution access to the systems which will later be used to
build officially-signed crypto provider packages?
http://en.wikipedia.org/wiki/Operation_Aurora
- Marsh
Here you are importing the certificate into a keystore which is
only used to sign your jar file. It's not a keystore that contains
the root CA used to verify all JCE providers when loaded by the JVM.
I'm not sure where they stored away the root CA(s).
I have read that the OpenJDK doesn't have this restriction;
unfortunately, I cannot switch at this time. That will probably
be the long term solution.
Since, the restriction is primarily on the actual crypto algorithms,
I'm going to see if I can rebuild with the 3 SSL classes in a separate
jar ahead in the classpath.
Thank you.
But if that were the case, why would they send you CA cert and instruct
"First import the CA's certificate as a 'trusted certificate'" and "Then
import the code-signing certificate"?
Regardless, one shouldn't go about trusting CA certs as they land in
your inbox. It's the equivalent of clicking on a link in email to
"verify your PayPal account information".
> I'm not sure where they stored away the root CA(s).
The doc mentions
"sun.security.provider.JavaKeyStore" and
"com.sun.crypto.provider.JceKeyStore"
If, in fact, there is something magic about the signatures on
code-signing certs, strace and/or grep should be able to answer that.
> I have read that the OpenJDK doesn't have this restriction;
> unfortunately, I cannot switch at this time. That will probably
> be the long term solution.
I think so, too. :-)
- Marsh
Marsh, I think you're assuming that that CA cert is self-signed.
I'll bet it chains to a Sun CA, and must do so to work.
I believe Red Hat's NSS team can also sign the "Mozilla-JSS"
JCE providers.
In fact, you can apply for a signing certificate for "Mozilla-JSS"
for your organization from Sun. The instructions are at
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html#signed-jar
Wan-Teh
I just wanted to post a follow-up, that I was able to build a second
jss-ssl.jar which just contained org.mozilla.jss.ssl.* and put it in
the classpath ahead of jss.jar and use the new API.
For completeness, I attempted also including JSSProvider or
CryptoManager in the jar and when I did that I got the expected error:
java.lang.SecurityException: class "org.mozilla.jss.CryptoManager"'s
signer information does not match signer information of other classes in
the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
Thank you.
> There are no artifacts on the ftp site for JSS 4.3.2:
> ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/
Check again. You may find it has been updated.
Thank you.