Re: Cipher suits, signature algorithms, curves in Firefox

Zoogtfyz wrote: > This is my recommendation for changes to the supported ciphersuits in > Mozilla Firefox. I performed rigorous compatibility testing and everything > works as advertized. I used Firefox telemetry data, SSL Pulse data, and my > own tests to verify that

Re: AES-256 vs. AES-128

Julien Vehent wrote: > The original thread [1] had a long discussion on this topic. The DJB batch > attack redefines the landscape, but does not address the original concerns > around AES-256 resistance. To me, the main question is to verify whether > AES-256

Re: PKCS#11 platform integration

David Woodhouse dw...@infradead.org wrote: The sysadmin should be able to configure things for *all* users according to the desired policy, rather than forcing each user to set things up for themselves. And in turn the *developers* of the operating system distribution should be able to set

Re: Problems with FF and internal certificates

On Fri, May 1, 2015 at 9:11 AM, Tanvi Vyas tv...@mozilla.com wrote: On Apr 27, 2015, at 2:03 PM, Michael Peterson michaelpeterson...@gmail.com wrote: Now, in the album I posted above (https://imgur.com/a/dmMdG), the last two screenshots show a packet capture from Wireshark. It appears that

Re: FF 37 - ssl_error_no_cypher_overlap with java SSL and java generated self-signed certificates

Gervase Markham g...@mozilla.org wrote: On 07/04/15 17:32, Hanno Böck wrote: Are you using DSA? Firefox removed DSA recently (which is good - almost nobody uses it and it's a quite fragile algorithm when it comes to random numbers). Hanno's probably hit the nail on the head here.

Re: What's My Chain Cert?

Rob Stradling rob.stradl...@comodo.com wrote: The README [1] says: If multiple certificate chains are found, the shortest one is used. That's a good strategy for a browser to employ when deciding which chain to show in its certificate viewer, but it's unlikely to be the best strategy when

Re: Remove Legacy TLS Ciphersuites from Initial Handshake by Default

Ryan Sleevi ryan-mozdevtechcry...@sleevi.com wrote: On Mon, March 16, 2015 1:06 pm, Erwann Abalea wrote: Phase RSA1024 out? I vote for it. Where's the ballot? :) This is a browser-side change. No ballot required (the only issue *should* be non-BR compliant certificates issued before the BR

Re: Interested in reviving PSS support in NSS

Hanno Böck ha...@hboeck.de wrote: Brian Smith br...@briansmith.org wrote: Having new oids with sane pre-defined parameters would vastly simplify things. Back when I wrote that code I thought changing the standard is harder than implementing the non-optimal spec, but I might've been wrong

Re: Interested in reviving PSS support in NSS

Ryan Sleevi ryan-mozdevtechcry...@sleevi.com wrote: - It assumes all the parameters can be expressed via a SECOidTag. That is, it's missing hash alg, mgf alg, salt length (e.g. the RSASSA-PSS-params construction) I believe there are only a small number of (hashAlgorithm, mgf alg, salt

Re: Interested in reviving PSS support in NSS

[+antoine] Hanno Böck ha...@hboeck.de wrote: Unfortunately the code never got fully merged. Right now the state is that code for the basic functions exists in freebl, but all upper layer code is not merged. There are multiple upper layers and, depending on your goals, some should be

Re: Reducing NSS's allocation rate

On Mon, Nov 10, 2014 at 9:04 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: In your analysis, it would be better to use a call stack trace depth larger than 5 that allows us to see what non-NSS function is calling into NSS. I've attached to the bug a profile that uses a stack trace

Re: Reducing NSS's allocation rate

On Mon, Nov 10, 2014 at 6:51 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: I've been doing some heap allocation profiling and found that during basic usage NSS accounts for 1/3 of all of Firefox's cumulative (*not* live) heap allocations. We're talking gigabytes of allocations in short

Re: Road to RC4-free web (the case for YouTube without RC4)

On Sun, Jun 29, 2014 at 11:18 AM, Hubert Kario hka...@redhat.com wrote: The number of sites that prefer RC4 while still supporting other ciphers are very high (18.6% in June[1], effectively 21.3% for Firefox[6]) and not changing much. The percent of servers that support only RC4 is steadily

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

On Thu, Oct 2, 2014 at 9:03 AM, davpj...@ozemail.com.au wrote: Maybe there is something that can be done to hep this situation? Maybe these old private certificates need to be cleaned out on upgrade? Or maybe something in the code that is going nuts trying to validate these private

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

On Tue, Aug 5, 2014 at 9:51 AM, mjle...@gmail.com wrote: Since updating to 31, I have not been able to log into a self signed web page: Secure Connection Failed An error occurred during a connection to taiserver:444. Certificate key usage inadequate for attempted operation. (Error code:

David Keeler is now the module owner of PSM

Hi, Amogst other things, PSM is the part of Gecko (Firefox) that connects Gecko to NSS and other crypto bits. David Keeler has taken on most of the responsibility for keeping things in PSM running smoothly and so it makes sense to have him be the module owner. After asking the other PSM module

ChaCha20-Poly1305 in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

On Thu, Jul 10, 2014 at 4:53 AM, Henri Sivonen hsivo...@hsivonen.fi wrote: On Tue, Jul 1, 2014 at 11:58 PM, Brian Smith br...@briansmith.org wrote: I am interested in discussing what we can do to help more server side products get better cipher suites by default, and on deciding whether we

Curve25519 and/or Curve41417 and/or Alternatives in Gecko/Firefox (was Re: Road to RC4-free web (the case for YouTube without RC4))

On Thu, Jul 10, 2014 at 5:33 AM, Kurt Roeckx k...@roeckx.be wrote: [snip] An other alternative is using curve25519. It's also not standardized yet, but at this time it seems more likely to be standardized first. Thanks for bringing up curve25519. I'd like to share a recent paper written by

Re: Road to RC4-free web (the case for YouTube without RC4)

On Thu, Jul 10, 2014 at 5:00 AM, Hubert Kario hka...@redhat.com wrote: - Original Message - From: Brian Smith br...@briansmith.org snip However, it is likely that crypto libraries that make the two changes above will also have support for TLS_ECDHE_*_WITH_AES_*_GCM cipher suites too

Re: Road to RC4-free web (the case for YouTube without RC4)

On Tue, Jul 1, 2014 at 7:15 PM, Julien Pierre julien.pie...@oracle.com wrote: On 7/1/2014 14:05, Brian Smith wrote: I think, in parallel with that, we can figure out why so many sites are still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and start the technical evangelism

Re: Road to RC4-free web (the case for YouTube without RC4)

On Wed, Jul 2, 2014 at 5:28 AM, Hubert Kario hka...@redhat.com wrote: On 7/1/2014 14:05, Brian Smith wrote: I think, in parallel with that, we can figure out why so many sites are still using TLS_ECDHE_*_WITH_RC4_* instead of TLS_ECDHE_*_WITH_AES* and start the technical evangelism

Re: Road to RC4-free web (the case for YouTube without RC4)

On Wed, Jul 2, 2014 at 5:08 AM, Hubert Kario hka...@redhat.com wrote: Also, see Gavin's email here about adding such prefs in general. He basically says, Don't do it. Note that Gavin is the Firefox module owner: https://groups.google.com/d/msg/mozilla.dev.platform/PL1tecuO0KA/e9BbmUAcRrwJ

Re: Intent to unimplement: proprietary window.crypto functions/properties

On Fri, Jun 27, 2014 at 9:19 AM, David Keeler dkee...@mozilla.com wrote: On 06/27/2014 07:37 AM, Nathan Kinder wrote: On 06/27/2014 12:13 AM, Frederik Braun wrote: To be frank, I have only ever seen the non-standard crypto functions used in attacks, rather than in purposeful use. That

Re: Announcing Mozilla::PKIX, a New Certificate Verification Library

On Mon, Apr 28, 2014 at 4:45 PM, Erwann Abalea eaba...@gmail.com wrote: The chain builder can test all possible issuers until it finds a valid one (that's what OpenSSL does, for example). The AKI is only here to say pssst, this is most probably the certificate you should try first. Right. We

Re: OCSP stapling problems

On Tue, Mar 11, 2014 at 3:20 AM, Hanno Böck ha...@hboeck.de wrote: I wanted to bring up an issue regarding OCSP stapling. I filled this bug shortly after Firefox 27 came out: https://bugzilla.mozilla.org/show_bug.cgi?id=972304 Short conclusion: If you have enabled OCSP stapling on your

Re: Where are others SHA256 cipher suits in Firefox 27?

On Wed, Feb 5, 2014 at 9:54 PM, Rasj rasj...@gmail.com wrote: Where are others? For example: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) See https://briansmith.org/browser-ciphersuites-01.html. Also, please look at the archives of this mailing list. There have been several DOZEN of emails about the

Re: Sites which fail with tls 1.0

On Wed, Feb 5, 2014 at 5:39 PM, cl...@jhcloos.com wrote: Is the retry logic in nss or in mozilla-central? And if the latter, can anyone help narrow the search? I didn't find anything relevant in comm-central. It is in mozilla-central, in security/manager/ssl/src/nsNSSIOLayer.cpp. See these

Re: Sites which fail with tls 1.0

On Mon, Jan 27, 2014 at 2:22 PM, cl...@jhcloos.com wrote: In case anyone is keeping a list, while helping a relative I determined that timewarnercable.com's login server (wayfarer.timewarnercable.com) will not work with tls 1.1 or 1.2. The connection fails after the client right after the

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 6:19:42 AM UTC-7, Kurt Roeckx wrote: 2) NIST is a US government standards board that drives a lot of compliance regulation. There are companies what will want to be able show that they are NIST

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

On Mon, Jan 27, 2014 at 10:49 AM, ripber...@aol.com wrote: On Monday, January 27, 2014 10:52:44 AM UTC-7, Brian Smith wrote: On Mon, Jan 27, 2014 at 9:26 AM, ripber...@aol.com wrote: I can't speak for FF - and I've certainly read enough standards to say that there are too many standards. I

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

On Sun, Dec 15, 2013 at 8:46 AM, Kurt Roeckx k...@roeckx.be wrote: But some people are also considering disabling it by default, as I think all other where talking in this thread, not just reduce the preference. For the same reason, the server ciphersuite that we recommend at

Re: Proposal to Remove legacy TLS Ciphersuits Offered by Firefox

On Fri, Dec 13, 2013 at 10:48 PM, marlene.pr...@hushmail.com wrote: I present a proposal to remove some vulnerable/deprecated/legacy TLS ciphersuits from Firefox. I am not proposing addition of any new ciphersuits, changing of priority order, protocol removal, or any other changes in

David Keeler is now a PSM peer

Hi all, Please join me in welcoming David Keeler as a PSM peer! Amongst many other things, David implemented the HSTS preload list, integrated OCSP stapling into Firefox, and is current implementing the OCSP Must-Staple feature, which is a key part of our goal of making certificate status

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Tue, Nov 19, 2013 at 9:14 AM, Kurt Roeckx k...@roeckx.be wrote: On Mon, Nov 18, 2013 at 06:47:08PM -0800, Wan-Teh Chang wrote: On Mon, Nov 18, 2013 at 4:57 PM, Brian Smith br...@briansmith.org wrote: Also, AES implementations are highly optimized, well-audited, well-tested, and are more

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

Re: oddball, old cipher suite in firefox client hello

On Fri, Nov 1, 2013 at 1:28 AM, Jeff Hodges j...@somethingsimilar.com wrote: /* New non-experimental openly spec'ed versions of those cipher suites. */ #define SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA 0xfeff #define SSL_RSA_FIPS_WITH_DES_CBC_SHA 0xfefe Does anyone know what spec this

Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

On Fri, Oct 4, 2013 at 6:52 PM, Ludovic Hirlimann ludovic+n...@mozilla.com wrote: Hi, AFAIK NSS still contains code for SSL2 , but no product uses it. SSL2 has been turned off at least 2 years ago. By removing SSL2 code we get : Smaller librarie faster compile time + test

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

Mountie Lee moun...@paygate.net wrote: SEED was adopted to encourage escaping ActiveX dependency in Korea e-commerce environment. Many people at Mozilla, including us platform engineers, want this too. Our goal is to get rid of plugins on the internet completely. And, also, personally I think

Re: set default on for SHA2 for TLS1.1+ on firefox

On Wed, Oct 2, 2013 at 2:28 AM, Mountie Lee moun...@paygate.net wrote: Hi. currently SHA2 hash algorithm is used in TLS1.1 and 1.2 mozilla firefox is supporting it now. Hi, Are you referring to the TLS_*_SHA256 cipher suites, or something else? I believe that we support SHA256-based

Re: Removing SSL 2.0 from NSS (was Re: Removing dead code from NSS)

On Mon, Oct 7, 2013 at 3:20 PM, Robert Relyea rrel...@redhat.com wrote: On 10/07/2013 12:44 PM, Wan-Teh Chang wrote: On Mon, Oct 7, 2013 at 11:17 AM, Brian Smith br...@briansmith.org wrote: I think it is likely that some vendors of NSS-based products with very conservative backward

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Thu, Sep 12, 2013 at 7:06 AM, Julien Vehent jul...@linuxwall.info wrote: It seems that AES-256 is always 25% to 30% slower than AES-128, regardless of AES-NI, or the CPU family. The slowest implementation of AES-256 has a bandwidth of 21MBytes/s, which is probably fast enough for any

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Mon, Oct 7, 2013 at 6:05 PM, Mountie Lee moun...@paygate.net wrote: SHA2 hash required in e-commerce transaction by the korean regulation. and which is also used in TLSv1.1+. Hi, First, we will be enabling TLS 1.2 in Firefox very soon. But, I think you may be referring to SHA-2-based

Re: Removal of generateCRMFRequest

sst...@mozilla.com wrote: Do we have telemetry on how frequently these APIs are used? I expect that, of the small percentage of people that are using these APIs, they are using them (except signText) very infrequently--like once a year. When I talked to Ehsan and Andrew Overholt about this, we

Re: Removal of generateCRMFRequest

On Sat, Sep 28, 2013 at 7:52 AM, Sean Leonard dev+mozi...@seantek.com wrote: On 9/27/2013 5:51 PM, Robert Relyea wrote: I don't have a problem with going for an industry standard way of doing all of these things, but it's certainly pretty presumptuous to remove these features without

Re: Removal of generateCRMFRequest

On Mon, Apr 8, 2013 at 2:52 AM, helpcrypto helpcrypto helpcry...@gmail.com wrote: While awaiting to http://www.w3.org/TR/WebCryptoAPI/ Java applets for client signning, signText and keygen are needed. Also things like Handling smart card events or Loading PKCS #11 modules is being use by

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Thu, Aug 22, 2013 at 11:21 AM, Robert Relyea rrel...@redhat.com wrote: So looking at this list, I think we have a major inconsistency. We put Ephemeral over non-ephemeral, but we put 128 over 256. While I'm OK with Ephemeral (PFS) over non-ephermal (non-pfs), I think in doing so we are

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Mon, Aug 26, 2013 at 2:24 PM, Brian Smith br...@briansmith.org wrote: Something to note is that MSIE has always put AES-128 cipher suites ahead of AES-128 cipher suites. They also put RSA cipher suites ahead of PFS cipher suites, though. I meant: MSIE has always put AES-128 cipher suites

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Thu, Aug 15, 2013 at 10:15 AM, Chris Richardson ch...@randomnonce.orgwrote: I believe this plan would have poor side effects. For example, if Apple ships clients with a broken ECDSA implementation [0], a server cannot detect detect if a connecting client is an Apple product and avoid the

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Fri, Aug 16, 2013 at 11:13 AM, Camilo Viecco cvie...@mozilla.com wrote: Hello Brian I think this proposal has 3 sections. 1. Unifing SSL behavior on browsers. 2. Altering the criteria for cipher suite selection in Firefox (actually NSS) 3. removing certain cipher suites from the default

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Fri, Aug 16, 2013 at 5:58 PM, Wan-Teh Chang w...@google.com wrote: On Fri, Aug 16, 2013 at 3:36 PM, Rob Stradling rob.stradl...@comodo.com wrote: Wan-Teh, why do you think Firefox should specify a preference for ECDSA over RSA? Because ECDSA is more secure than RSA, and ECC

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Mon, Aug 12, 2013 at 6:52 AM, Gervase Markham g...@mozilla.org wrote: On 09/08/13 18:12, Brian Smith wrote: No, each combination is hard-coded into its own distinct code point that is registered with IANA: https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls

Re: Proposal to Change the Default TLS Ciphersuites Offered by Browsers

On Fri, Aug 9, 2013 at 3:27 AM, Gervase Markham g...@mozilla.org wrote: * Can you provide some background or references on exactly how ciphersuite construction and choice works? Can I invent e.g. TLS_DHE_ECDSA_WITH_AES_128_MD5 or some other random combination of elements? Can any combination

Proposal to Change the Default TLS Ciphersuites Offered by Browsers

Please see https://briansmith.org/browser-ciphersuites-01.html First, this is a proposal to change the set of sequence of ciphersuites that Firefox offers. Secondly, this is an invitation for other browser makers to adopt the same sequence of ciphersuites to maximize interoperability, to minimize

Re: libnss3.so available on FireFox on Android?

See https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules/WeaveCrypto.js#123 and https://bugzilla.mozilla.org/show_bug.cgi?id=583209 and https://bugzilla.mozilla.org/show_bug.cgi?id=648407 On Tue, Jul 30, 2013 at 11:58 PM, hv hishamkanni...@gmail.com wrote: Hi, I was not

Re: libnss3.so available on FireFox on Android?

On Wed, Jul 31, 2013 at 1:58 AM, Robert Relyea rrel...@redhat.com wrote: On 07/30/2013 04:27 PM, Brian Smith wrote: See https://mxr.mozilla.org/**mozilla-central/source/** services/crypto/modules/**WeaveCrypto.js#123https://mxr.mozilla.org/mozilla-central/source/services/crypto/modules

Re: Removal of Revocation Lists feature (Options - Advanced - Revocation Lists)

Julien Pierre wrote: If this is about removing the feature from NSS altogether on the other hand, I would like to state that we have several several products at Oracle that use NSS and rely on the ability to have CRLs stored in the database, and processed during certificate validation. I am

Re: Removal of Revocation Lists feature (Options - Advanced - Revocation Lists)

Robert Relyea wrote: Oh, in that case I can say we have customers that definately need to use CRLs that have been loaded and stored in the database. To be clear, I don't know of any reason to consider the processing of already-loaded CRLs as a requirement for Firefox. Oh, then I'd say we

Re: Removal of Revocation Lists feature (Options - Advanced - Revocation Lists)

Sean Leonard wrote: Brian Smith wrote: The Revocation Lists feature allows a user to configure Firefox to poll the CAs server on a regular interval. As far as I know, Firefox is the only browser to have such a feature. Other browser either ignore CRLs completely or download CRLs

Re: Removal of Revocation Lists feature (Options - Advanced - Revocation Lists)

Robert Relyea wrote: Brian, I was under the impression you wanted to remove the CRL autofetching feature (where you enter a URL and a fetching time and the CRL will automatically be fetched). When I looked at the UI, it looked like it had both the URL fetching feature as well as the ability

Removal of Revocation Lists feature (Options - Advanced - Revocation Lists)

Hi all, I propose we remove the Revocation Lists feature (Options - Advanced - Revocation Lists). Are there any objections? If so, please explain your objection. A certificate revocation list (CRL) is a list of revoked certificates, published by the certificate authority that issued the

Re: Root Certificates in Firefox OS (was Re: NSS in Firefox OS)

Rob Stradling wrote: I presume that Firefox OS trusts NSS's Built-in Root Certificates [1], but what (if anything) does Firefox OS do for EV SSL? As you found, Firefox OS doesn't have an EV UI, and in fact I just disabled the EV validation logic in B2G for performance reasons, given that it

Re: Firefox behavior for CDP and AIA

Rick Andrews wrote: I know that FF allows you to choose a CRL and it will check status against that CRL when it finds a cert issued by the CRL issuer. Does anyone know if FF uses the CDP in the cert or the cert's issuer name as a key to find the CRL? I assume you are talking about the

Re: Clarification regarding SEC_PKCS7VerifyDetachedSignatureAtTime

What does this mean for building Firefox? If you want to build a development snapshot of Firefox against a systemwide installed NSS, and you want to build Firefox 22 aurora at this time, you have the following choices: - don't build Firefox 22 aurora until Mozilla cleaned up the

Removal of generateCRMFRequest

See https://bugzilla.mozilla.org/show_bug.cgi?id=524664 (bug 524664) and See https://developer.mozilla.org/en-US/docs/JavaScript_crypto/generateCRMFRequest My understanding is that keygen is supposed to replace window.crypto.generateCRMFRequest. I have no idea how common

Re: Ensuring certificate chain when creating certificates in memory without db.

passf...@googlemail.com I use SSL_ConfigSecureServer with a certificate which was created in memory (no db). The certificate was created with the CERT_CreateCertificate passing the CA's issuer. The same cert was also signed with the CA's key. The CA cert was also created on the fly, i.e.

NSS 3.14.2 BETA 3 tagged ; NSS 3.14.2 BETA 3 + one patch now required to build mozilla-central

Hi all, I tagged NSS 3.14.2 BETA 3 and pushed it to mozilla-inbound to fix build breakage of ASAN and dxr builds. Also, now mozilla-central contains a patch for bug 834091. That patch adds a new public function to libsmime, SEC_PKCS7VerifyDetachedSignatureAtTime, which fulfills a last-minute

NSS 3.14.2 BETA 1 (NSS_3_14_2_BETA1) tagged and is now the minimum version for Gecko 20

Today I tagged the CVS HEAD with the NSS_3_14_2_BETA1 tag and imported it into Gecko (pushed to inbound). We expect to finalize the NSS 3.14.2 release in late January, 2013. In the interim, you can pull and build NSS betas from CVS: After mozilla-inbound is merged into mozilla-central, NSS

NSS_3_14_2_BETA2 landed, with some patches backported to mozilla-beta (was CVS HEAD tagged NSS_3_14_1_BETA1 and pushed it to mozilla-inbound)

Brian Smith wrote: Brian Smith bsm...@mozilla.com https://bugzilla.mozilla.org/show_bug.cgi?id=816392 This change was backed-out before it reached mozilla-central from mozilla-inbound because NSS crashes during startup on Android (and probably B2G). See bug 817233. After the backout, I

CVS HEAD tagged NSS_3_14_1_BETA1 and pushed it to mozilla-inbound

I tagged the CVS HEAD as NSS_3_14_1_BETA1 and pushed it to mozilla-inbound. If you are building Firefox or a Gecko-based application using --use-system-nss, you need to use the NSS 3.14.1 beta release, as that is now the minimum required version to build Gecko. Thanks for the help from

How does SMIME work in NSS (was Re: NSS in Firefox OS)

Vishal wrote: On Saturday, October 20, 2012 10:33:58 PM UTC+5, Brian Smith wrote: Anders Rundgren wrote: Anyway, I guess that Firefox OS uses NSS? Is it still is based on the idea that key access is done in the application context rather than through a service? B2G (Firefox OS) does

Re: NSS 3.14 release

julien.pie...@oracle.com wrote: Oracle still ships NSS with many products even though we are no longer actively involved with its development. It is important to have somebody at least monitoring the bugs filed/fixed in the NSS component in bugzilla. See

Re: NSS 3.14 release

Julien Pierre wrote: I know what code changes are necessary. I'm only a developer on a couple of NSS applications at this point, not an NSS maintainer. If this was only about those couple of apps, it wouldn't be an issue. But there are other apps in Oracle that could be affected. I can safely

Re: NSS in Firefox OS

Anders Rundgren wrote: Anyway, I guess that Firefox OS uses NSS? Is it still is based on the idea that key access is done in the application context rather than through a service? B2G (Firefox OS) does use NSS. Nothing has changed regarding the process separation between Gecko and the private

Re: undefined reference to '_InterlockedIncrement' when compiling nss under MinGW

weizhong qiang wrote: Thanks for the instruction. I tried the build of nss on with mozillabuild tool (with MS VC and MS SDK, using MS compiler for compilation) on Win7. And the build did pass. But the build with MinGW/MSYS (using gcc for compilation) still failed. I hope the build (with MS

Re: Accessing Mozilla NSS library functions in JavaScript-XPCOM

Brian Teh wrote: Currently, my extension uses the NSS library which is coded in C++. But due to 6-week release cycle for Thunderbird, I am wondering whether are there examples on how to use Mozilla NSS for JavaScript-XPCOM, to avoid the need for re-compiling the binary components? Currently,

Re: Alternative for SGN_DecodeDigestInfo

Robert Relyea wrote: Why are they linking with Freebl anyway? It's intended to be a private interface for softoken. It's a very good way to find yourself backed into a corner. Right. This was a long time ago. You helped me add the J-PAKE implementation to Softoken after we discovered this

Re: Combining OCSP stapling with advance MITM preparation

Kai Engert wrote: The domain owner could configure their server to include this OCSP response in all TLS handshakes, even though this OCSP response is unrelated to the server certificate actually being used. For complete protection, the real domain holder would have to staple all the OCSP

Re: Recent builds of NSS on Windows?

Today, a buggy old/legacy modutil.exe binary we are using, made me try building NSS using mingw. Once again. The only way I recommend building NSS on Windows is with Microsoft Visual C++ and the mozilla-build package located at

Re: To NSS-Java or not to NSS-Java, thats the question.

helpcrypto helpcrypto wrote: IMHO, this is some that needs some clarification, as Mozilla *IS* supporting it developing JSS but at the same time saying we do not support it, Some people who are part of the Mozilla project maintain JSS. I will help review patches to JSS if/when the members of

Re: Alternative for SGN_DecodeDigestInfo

Robert Relyea wrote: On 03/24/2012 03:05 PM, VJ wrote: I'm trying to use RSA_HashCheckSign() function to verify the message. How are you even Linking with RSA_HashCheckSign()? I don't know what platform JV is on, but I know on Mac OS X, all the internal symbols in FreeBL and maybe other

Re: Mozilla Team-about the upcoming branding changes at Symantec/VeriSign, and working to implement them in Mozilla/Firefox

Geoffrey Noakes wrote: The *only* change we are asking of Mozilla is to change Verified by: VeriSign, Inc. in the hover-over box to Verified by Norton: In Firefox, we show the name of the organization that issued the intermediate certificate (the subject O= field of the intermediate

Re: Google about to fix the CRL download mechanism in Chrome

Eddy Nigg wrote: On 02/09/2012 12:18 AM, From Nelson B Bolyard: BTW, this proposal wouldn't be a problem if it would cover, lets say the top 500 sites and leave the rest to the CAs. There would be probably also the highest gains. Effectively, we would be making the most popular servers on the

Re: Regarding PSM with external SSL library

Ashok Subash wrote: Hi Brian, We have made some progress. We could statically build nss and link on our platform. Do you mean statically link NSS into Firefox? If so, there are several gotchas that need to be taken into account. See Wan-Teh's patch at

Re: Removal of NSS and/or NSPR from the API exposed to addons

Mike Hommey wrote: But linux users are not necessarily up-to-date with the latest NSS. I seriously doubt the number of users with the very last system nss exceeds 10% of the linux user base except in exceptional good timing cases (like when ubuntu is released with the latest version), but

Review of changes to the HTTP spec

HTTPbis seems to be in its final stages. Although it is supposed to be a somewhat minor revision, quite significant changes have been made to the spec. We should review the changes and make sure we provide our feedback before it is too late. In particular, if there is some change that we think

Documentation of differences between our networking stack and other browsers' stacks and security bug triaging

I think that we should start some documentation (e.g. a wiki) that documents the differences between our implementation and other browsers' implementations, along with a justification for the difference and/or a link to a bug about resolving the difference. Examples of differences, off the top

Re: Removal of NSS and/or NSPR from the API exposed to addons

Eitan Adler wrote: Brian Smith wrote: If the system NSS isn't new enough, then Firefox's local version of NSS would be used. From a packager point of view, please don't automagically detect these things. If the system NSS is supported provide an option --with-system-nss which if not set

Re: Review of changes to the HTTP spec

Thanks Wan-Teh. - Original Message - From: Wan-Teh Chang w...@google.com To: mozilla's crypto code discussion list dev-tech-crypto@lists.mozilla.org Sent: Thursday, January 19, 2012 9:57:29 AM Subject: Re: Review of changes to the HTTP spec On Thu, Jan 19, 2012 at 1:43 AM, Brian

Re: Removal of NSS and/or NSPR from the API exposed to addons

Mike Hommey wrote: Please note that this is going to be a problem on systems that have system nspr and nss libraries that other system libraries use. I am intending to avoid changing how NSS is linked on Linux, at least at the beginning. My priorities are are Android and Windows first, then

Re: Removal of NSS and/or NSPR from the API exposed to addons

Benjamin Smedberg wrote: I have no particular opinion about whether this is a good idea for NSS. I do think that we should not do this for NSPR unless we decide to remove support for binary XPCOM components in Firefox (per the ongoing discussion in dev.planning). Many of our XPCOM code

Re: libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

Sean Leonard wrote: The most glaring problem however is that when validation fails, such as in the case of a revoked certificate, the API returns no certificate chains My understanding is that when you are doing certificate path building, and you have to account for multiple possibilities

Re: Removal of NSS and/or NSPR from the API exposed to addons

Mike Hommey wrote: In the long run, for performance reasons, we should probably prefer the system NSS libraries to our own, whenever the system NSS libraries are available and are the right version, because at least some of them are likely to already have been loaded into RAM by other

libpkix maintenance plan (was Re: What exactly are the benefits of libpkix over the old certificate path validation library?)

We (me, Kai, Bob, Wan-Teh, Ryan, Elio, Kai) had a meeting today to discuss the issues raised in this thread. We came to the following conclusions: Ryan seems to be a great addition to the team. Welcome, Ryan! Gecko (Firefox and Thunderbird) will make the switch to libpkix. See Ryan's comments

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

Jean-Marc Desperrier wrote: Brian Smith a écrit : 3. libpkix can enforce certificate policies (e.g. requiring EV policy OIDs). Can the non-libpkix validation? EV policy have been defined in a way that means they could be supported by a code that handles an extremely tiny part of all

Re: Regarding PSM with external SSL library

Ashok Subash wrote: We'll go with your suggestion of using NSS after size reduction for this project for our security requirements. But right now we cannot upgrade to latest firefox due to the current schedule and resources we have for this project. We will follow the guidelines listed in the

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

Ryan Sleevi wrote: IIRC, libpkix is an RFC 3280 and RFC 4158 conforming implementation, while non-libpkix is not. That isn't to say the primitives don't exist - they do, and libpkix uses them - but that the non-libpkix path doesn't use them presently, and some may be non-trivial work to

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

Gervase Markham wrote: On 04/01/12 00:59, Brian Smith wrote: 5. libpkix has better AIA/CRL fetching: 5.a. libpkix can fetch revocation information for every cert in a chain. The non-libpkix validation cannot (right?). 5.b. libpkix can (in theory) fetch using LDAP in addition to HTTP

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

Robert Relyea wrote: 7. libpkix can actually fetch CRL's on the fly. The old code can only use CRL's that have been manually downloaded. We have hacks in PSM to periodically load CRL's, which work for certain enterprises, but not with the internet. I am not too concerned with the fetching

Re: What exactly are the benefits of libpkix over the old certificate path validation library?

Brian Smith wrote: Robert Relyea wrote: When I browse with libpkix enabled (which also enables the intermediate fetching), connecting to HTTPS websites (like mail.mozilla.com) ... is much slower, at least when the browser starts up. We may be able to fix this with persistent caching

Re: Developing pkcs11 module for Firefox

Robert Relyea wrote: On 01/04/2012 09:04 AM, Anders Rundgren wrote: There is a capi module in the NSS source tree, but it purposefully does not surface removable CAPI modules under the assumption that such devices already have PKCS #11 modules. While it may be true that they have PKCS#11

  1   2   >