Re: Road to RC4-free web (the case for YouTube without RC4)
On Saturday 08 November 2014 10:29:06 Kosuke Kaizuka wrote: On Thu, 23 Oct 2014 01:35:08 +0900, Kosuke Kaizuka wrote: On Wed, 22 Oct 2014 00:59:53 -0700, Brian Smith wrote: 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 dropping (1.771% in April[3], 1.194% in May[2], 0.985% in June[1]). Because of that, disabling RC4 should be possible for many users. The big exception for that was YouTube video servers[4] which only recently gained support for TLS_RSA_WITH_AES_128_GCM_SHA256. Sorry that I couldn't say more earlier, but please see this message from Adam Langley of Google about YouTube working on TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: http://www.ietf.org/mail-archive/web/tls/current/msg14112.html And TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 support is coming -- it's already enabled in some locations. Excellent news! It has not enabled yet in Japan. https://www.ssllabs.com/ssltest/analyze.html?d=r4---sn-uxaxovg-5goz.googlevi deo.com TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_RC4_128_SHA Now we can use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256! Yup, it's working also in Europe. -- Regards, Hubert Kario -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Reducing NSS's allocation rate
Hi, 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 browsing sessions. That is *insane*. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about this. I've written several patches that fix problems, one of which has r+ and is awaiting checkin; check the dependent bugs. This is making Ryan Sleevi is nervous and he wanted me to post something here about my plans. So here they are: I want to reduce unnecessary allocations. I want to do so in a very non-intrusive fashion: I'm aware that NSS is security-sensitive code, and TBH it's not that enjoyable to read or modify. I will plug away at this as long as there is low-hanging fruit to be found, which may not be that much longer. Nick -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Reducing NSS's allocation rate
On Mon, November 10, 2014 6:51 pm, Nicholas Nethercote wrote: Hi, 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 browsing sessions. That is *insane*. Could you explain why it's insane? I guess that's sort of why I poked you on the bug. Plenty of allocators are rather smart under such churn, and NSS itself uses an Arena allocator designed to re-use some (but understandably not all) allocations. Is there a set of performance criteria you're measuring? For example, we're spending X% of CPU in the allocator, and we believe we can reduce it to Y%, which will improve test Z. Not to be a pain and discourage someone from hacking on NSS (we always need more NSS hackers), but I guess I'm just trying to understand the complexity (and locally caching / lazy instantiating always adds some degree of complexity, though hopefully minor) vs performance (which is hopefully being measured) tradeoffs. Further, if we aren't continuously monitoring this, meaning it's not a metric integrated as something we watch, then it seems very easy that any improvements you make can quickly regress, which would be unfortunate for your work. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Reducing NSS's allocation rate
Personally, I would like to encourage your efforts. If you are able to move many of these allocations from heap-based with locks, to something stack-based instead, this will improve NSS server performance tremendously. I would be surprised if it was a significant boost to client apps like Firefox, though. On the other hand, I'm not sure that there is that much low-hanging fruit, based on the stacks you list in the bug. Many are dictated by the design of NSS, the PKCS#11 API, and the current softoken implementation. Working within these constraints is not so simple. Keep in mind that many things you might want to change cannot be, in order to preserve NSS API binary compatibility. Julien On 11/10/2014 18:51, Nicholas Nethercote wrote: Hi, 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 browsing sessions. That is *insane*. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about this. I've written several patches that fix problems, one of which has r+ and is awaiting checkin; check the dependent bugs. This is making Ryan Sleevi is nervous and he wanted me to post something here about my plans. So here they are: I want to reduce unnecessary allocations. I want to do so in a very non-intrusive fashion: I'm aware that NSS is security-sensitive code, and TBH it's not that enjoyable to read or modify. I will plug away at this as long as there is low-hanging fruit to be found, which may not be that much longer. Nick -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
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 browsing sessions. That is *insane*. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about this. I've written several patches that fix problems, one of which has r+ and is awaiting checkin; check the dependent bugs. 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. The checks done in mozilla::pkix's CheckPublicKeySize can easily be optimized. But, first check how often the call stack contains CheckPublicKey vs VerifySignedData; CheckPublicKey can be optimized even more than VerifySignedData. My original plans for VerifySignedData was for it to have a cache added to it, if/when performance testing showed that there was a performance problem. It is likely that such a cache is important, even without the heap thrashing that you are concerned about. Also, there is already a bug on file about caching and coalescing SSL server cert verification results in SSLServerCertVerification. This is trickier than the type of caching you can do in VerifySignedData but it is potentially a bigger win. Also, I think recent changes to Gecko's connection management (the parallelism to a new host restricted to 1 bug being fixed) made it more important to do at least the coalescing part. Note that when bug 1036103 is fixed (which will be basically whenever I get around to posting one more patch), it will be possible to avoid any of the NSS CERT_* API during certificate verification, if people are willing to do a little (probably quite a bit, actiually) refactoring. That that, except for the calls to SECKEY_DecodeDERSubjectPublicKeyInfo and SECKEY_ExtractPublicKey in CheckPublicKeySize, mozilla::pkix allocates no memory at all, ever (once CheckNameConstraints is replaced, which is the thing that is one patch away from happening). Cheers, Brian -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Reducing NSS's allocation rate
On Mon, Nov 10, 2014 at 8:53 PM, Brian Smith br...@briansmith.org wrote: I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1095272 about this. I've written several patches that fix problems, one of which has r+ and is awaiting checkin; check the dependent bugs. 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 depth of 10. Nick -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
