SHA-256 support
Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 - Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that translates to They can use the NSS version number info to work out the answer for other NSS-using applications. Is anyone from the NSS team able to easily provide that info? I could go repo and Bugzilla-mining, but I'd be worried about making a mistake. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: How do you sign a FireFox .xpi add-on file using Jarsigner?
On Wednesday, November 13, 2013 11:19:45 PM UTC+1, Mike Price wrote: Does anyone know the secret to using Java's jarsigner.exe to sign a FireFox .xpi add on? I have seen a few references that seem to imply that this can be done successfully, but I can't get it to create an installable version of my .xpi file. Any particular reason for not wanting to use NSS signtool? https://developer.mozilla.org/en/docs/Signing_a_XPI lists some alternatives (jarsigner didn't make it to the list). I can sign it with jarsigner and the verify command says the signature is valid, but it always results in a this file is corrupt message when I attempt to install the add-on into FireFox. I have followed the directions for re-arranging the contents of the archive so that zigbert.rsa is the first file in the archive, but it just doesn't work. It complains that the manifest hash is invalid which is strange since I don't do anything to change this file. Any ideas out there as to how to get this to work? This seems to be an old, known compatibility issue: http://www.jensign.com/JavaScience/www/comparejar/ Greets, Stefan -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Can NSS Signtool.exe access signing certificate keys from an HSM?
On Tuesday, November 12, 2013 6:46:33 PM UTC+1, Mike Price wrote: We are trying to implement signing of xpi files using the NSS Signtool.exe. However, we need to access our certificate keys from our HSM server instead of having the keys installed in the local keystore on the signing machine. Does anyone have information on how to set this up and what the command-line syntax looks like? If you can make HSM work from within normal firefox profile, up to the point where certificates from HSM are listed in the Firefox uptions GUI, then yes. Use: signtool.exe -k keyname -d /path/to/above/firefox/profile/directory +your other usual parameters. see https://developer.mozilla.org/en-US/docs/NSS_tools_:_signtool -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers
On Sun, Nov 10, 2013 at 4:39 AM, Kurt Roeckx k...@roeckx.be wrote: On Sat, Nov 09, 2013 at 02:57:48PM -0800, Brian Smith wrote: Last week, I also learned that ENISA, a European standards group, recommends Camellia alongside AES as a future-proof symmetric cipher algorithm; see [4]. They recommend: - *_AES_*_GCM_* - *_CAMELLIA_*_GCM_* - *_AES_*_CCM_* Thanks. I filed bug 940119 about adding the TLS_ECDHE_*_CAMELLIA_GCM_* cipher suites. As I already mentioned a few time, I'm still missing some of the *_AES_*_GCM_* ciphers, specially the DHE ones. It should be easy to add TLS_DHE_*_GCM_* cipher suites to NSS. However, I am not sure it is a good idea to add TLS_DHE_*_GCM_* or TLS_RSA_*_GCM_* cipher suites to Firefox (or other browsers, for that matter). Regarding the TLS_DHE_* variants, I think that we should spend some effort on advocating support for the TLS_ECDHE variants first. In particular, you mentioned that Apache 2.2 doesn't support ECDHE. Well, I'd rather work on backporting Apache 2.4's ECDHE support to Apache 2.2 than add the TLS_[DHE_]RSA_*_GCM_* cipher suites to Firefox. Unfortunately, DHE cipher suites don't work well in current Apache 2.2 either, because of the hard-coded 1024-bit parameters. I don't think it would be reasonable to backport the better DHE support from Apache trunk to Apache 2.4 since there are compatibility issues with doing so. Also, ultimately, we'd like to use TLS_ECDHE_* cipher suites for performance reasons. Regarding the TLS_RSA_* variants, like I said before, I think we should avoid adding new cipher suites for RSA key exchange to Firefox, to encourage websites to use the ECDHE variants, which help toward minimizing the fallout of a private key compromise. I am currently expecting that the One-RTT variant of the TLS 1.3 handshake will require ECDHE support anyway. Regardless, I think we can avoid adding those things for now, and revisit this later when we see what happens with TLS 1.3 and when we see how successful (or not) our advocacy attempts are. I think we probably want to still disable Camellia cipher suites by default in the long term anyway, but I did not disable them in Firefox Nightly yet. In order for it to make sense to continue offering Camellia cipher suites long term, we would need to improve NSS's support for Camellia to add the ECDHE variants of the Camellia cipher suites. Currently, I think the best course of action is to let the current configuration ship, then disable Camellia support, and eventually add ECDHE_*_WITH_CAMELLIA_* support to NSS, so that it is ready in case some problem with AES is found. I don't understand the part where you want to disable it. Originally I was very concerned about the TLS ClientHello message size, because we were under the impression that we had to keep it under 256 bytes. That is the reason I prioritized starting this discussion so highly, in fact. But, at IETF88, we learned that there may be another workaround to the interop problems such that we don't have to keep our ClientHello message size under 256 bytes. Still, we shouldn't be wasteful with our ClientHello message size, since we'll always want to keep it under ~1400 bytes for performance and reliability reasons. 1400 bytes might sound like a lot now, but people have already been talking about TLS extensions that could easily eat up the majority of that space. Also, AES implementations are highly optimized, well-audited, well-tested, and are more likely to be side-channel free. Camellia doesn't get used very often. Yet, some websites (most famously, Yahoo!), prefer Camellia over AES, even when we offer AES at higher priority in the handshake. I am not sure how much the performance or existence of lack of side-channel-free implementations of Camellia matter yet. In Firefox, we've kept Camellia enabled for now, and added some telemetry to measure how often each cipher is used, to inform our future decision making here. Cheers, Brian -- Mozilla Networking/Crypto/Security (Necko/NSS/PSM) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SHA-256 support
SHA-256 was added in NSS 3.8 , according to : http://www-archive.mozilla.org/projects/security/pki/nss/ On 11/18/2013 07:00, Gervase Markham wrote: Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 - Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that translates to They can use the NSS version number info to work out the answer for other NSS-using applications. Is anyone from the NSS team able to easily provide that info? I could go repo and Bugzilla-mining, but I'd be worried about making a mistake. Gerv -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: SHA-256 support
On 11/18/2013 07:00 AM, Gervase Markham wrote: Hi everyone, Following Microsoft's announcement re: SHA-1, some CAs are asking browser and OS vendors about the ubiquity of SHA-256 support. It would be a help to them if we could say: - Which version of NSS first supported SHA-256 I quick look at the cvs logs shows that it was supported at least by nss 3.7. (There's an NSS_3_7_RTM tag for revision 1.4 for sha512.c, which has sha512, sha384, and sha256 support). - Which versions of Mozilla/Firefox/SeaMonkey/Thunderbird that translates to The cvs logs include tags for various Mozilla/Firefox/Thunderbird/Seamonkey releases (the code predates mozilla's move to hg). The earliest mozilla release was Mozilla 1.3. The earliest thunderbird release was 0.2 (essentially every thunderbird release). The earliest firefox release was 0.8 (essentially every release of firefox). The earliest seamonkey was 1.0 (again, essentially every release of seamonkey). They can use the NSS version number info to work out the answer for other NSS-using applications. Yes, though the upshot is if your nss-based ap isn't Netscape or AOL branded, it almost certainly has SHA-2 support. (heck even AOL branded things like photon has the SHA-2 support). Is anyone from the NSS team able to easily provide that info? I could go repo and Bugzilla-mining, but I'd be worried about making a mistake. SHA-256/SHA-512 code has been in for a very long time. Nelson checked in the initial revision around Nov 2002, and the first NSS release (3.7) was sometime between Nov 2002 and Mar 2003. The change predates the mass tri-license work done in 2004 (I see gerv's tri-license changes in the logs). I think it's safe to say if your NSS ap is newer than a decade old, you have SHA-2 support. The one caveat is that SHA-224 support was added much later, but SHA-256, SHA-384, and SHA-512 have all been supported for a while. Gerv smime.p7s Description: S/MIME Cryptographic Signature -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
