Re: Shared security Db in FF-3.5?
Nelson Bolyard wrote: [...] In NSS 3.12, you must tell NSS every time it is initialized whether it is using old (Berkeley, default) or new (Sqlite3) DBs. This may be done in any of (at least) 3 different ways, including an environment variable, a directory name prefix, or a programmatic function call (IIRC). Oh, too bad. I think it would be better then if Firefox were to programmatic set it to use sqlite3 when the sqlite3 file exists. An annoying limitation is that the certificate file*must* be in the profile directory, there's no way to set an absolute path, so it's still hard to use it as a multi-application db. hmm. I think that is a Firefox limitation, not an NSS limitation. But I could be wrong about that. Yes, it is a Firefox limitation. I think there's already a bug open about that. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Comments on the Content Security Policy specification
First, let me state up front some assumptions I'm making: * Authors will rely on technologies that they perceive are solving their problems, * Authors will invariably make mistakes, primarily mistakes of omission, * The more complicated something is, the more mistakes people will make. I think CSP is orders of magnitude too complicated to be a successful security mechanism on the Web. I believe that if one were to take a typical Web developer, show him this: X-Content-Security-Policy: allow self; img-src *; object-src media1.com media2.com; script-src trustedscripts.example.com ...and ask him does this enable or disable data: URLs in embed or would an onclick='' handler work with this policy or are framesets enabled or disabled by this set of directives, the odds of them getting the answers right are about 50:50. Similarly, given the following: X-Content-Security-Policy: allow https://self:443 ...I don't think a random Web developer would be able to correctly guess whether or not inline scripts on the page would work, or whether Google Analytics would be disabled or not. I think that this complexity, combined with the tendency for authors to rely on features they think are solvign their problems, would actually lead to authors writing policy files in what would externally appear to be a random fashion, changing them until their sites worked, and would then assume their site is safe. This would then likely make them _less_ paranoid about XSS problems, which would further increase the possibility of them being attacked, with a good chance of the policy not actually being effective. Other comments: I'm concerned about the round-trip latency of fetching an external policy file. Would the policy only be enforced after it is downloaded, or would it block page loading? The former seems like a big security problem (you would be vulnerable to an XSS if the attacker can DOS the connection). The latter would be unacceptable from a performance perspective. Applying a lockdown policy in the meantime would likely break the page (e.g. no scripts or images could be fetched). I think CSP should be more consistent about what happens with multiple policies. Right now, two headers will mean the second is ignored, and two metas will mean the second is ignored; but a header and a meta will cause the intersection to be used. Similarly, a header with both a policy and a URL will cause the most restrictive mode to be used (and both policies to be ignored), but a misplaced meta will cause no CSP to be applied. A policy-uri to a third-party domain is blocked supposedly to prevent an XSS from being able to run a separate policy, but then the policy can be inclued inline, so that particular hole doesn't seem to be actually blocked. I don't think UAs should advertise support for this feature in their HTTP requests. Doing this for each feature doesn't scale. Also, browsers are notoriously bad at claiming support accurately; since bugs will be present whatever happens, servers are likely to need to do regular browser sniffing anyway, even if support _is_ advertised. On the long term, all browsers would support this, and during the transition period, browser sniffing would be fine. (If we do add the advertisment, we can never remove it, even if all browsers support it -- just like we can't remove the Mozilla/4.0 part of every browser's UA string now.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Shared security Db in FF-3.5?
On Mon, Jul 6, 2009 at 12:09 AM, Andrei Korostelevand...@korostelev.net wrote: Thank you. Are there plans to make this shared Db default, say, in FF 4? Yes, there are, and now is a good time in the Firefox development cycle to start that work. But it seems that the right people to do that are bogged down by their other important work (such as FIPS validation). The Linux version of the Chromium browser uses NSS and is using the NSS shared databases. It creates them in the ~/.pki/nssdb directory, following the NSS team's proposal at https://wiki.mozilla.org/NSS_Shared_DB_And_LINUX Wan-Teh ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Comments on the Content Security Policy specification
Ian Hickson wrote on 7/16/2009 5:51 AM: I think that this complexity, combined with the tendency for authors to rely on features they think are solvign their problems, would actually lead to authors writing policy files in what would externally appear to be a random fashion, changing them until their sites worked, and would then assume their site is safe. This would then likely make them _less_ paranoid about XSS problems, which would further increase the possibility of them being attacked, with a good chance of the policy not actually being effective. I think your point that CSP may be too complex and/or too much work for some developers is spot on. Even getting developers to use something as simple as the Secure flag for cookies on HTTPS sites is still a challenge. And if we can't get developers to use the Secure flag, the chances of getting sites configured with CSP is daunting at best. More to my point, getting developers to use *any* security feature is daunting, so any solution to a security issue that doesn't involve protection by default is going to lack coverage, either due to lack of deployment, or misconfigured deployment. And since protection by default (in this case) would mean broken web sites, we're left with an opt-in model that achieves only partial coverage. At first glance, it may seem like a waste of time to implement CSP if the best we can achieve is only partial coverage, but instead of looking at it from the number of sites covered, look at it from the number of users covered. If a large site such as Twitter were to implement it, that's millions of users protected that otherwise wouldn't be. I think CSP should be more consistent about what happens with multiple policies. Right now, two headers will mean the second is ignored, and two metas will mean the second is ignored; but a header and a meta will cause the intersection to be used. Similarly, a header with both a policy and a URL will cause the most restrictive mode to be used (and both policies to be ignored), but a misplaced meta will cause no CSP to be applied. I agree. There's been some discussion about removing meta support entirely and/or allowing multiple headers with a intersection algorithm, so depending on how those ideas are adopted, it makes sense to ensure consistency across the spec. I don't think UAs should advertise support for this feature in their HTTP requests. Doing this for each feature doesn't scale. Also, browsers are notoriously bad at claiming support accurately; since bugs will be present whatever happens, servers are likely to need to do regular browser sniffing anyway, even if support _is_ advertised. On the long term, all browsers would support this, and during the transition period, browser sniffing would be fine. (If we do add the advertisment, we can never remove it, even if all browsers support it -- just like we can't remove the Mozilla/4.0 part of every browser's UA string now.) This is under discussion too; if you have an interest, here's the most recent thread where it's being discussed: http://groups.google.com/group/mozilla.dev.security/browse_thread/thread/571f1495e6ccf822#anchor_1880c3647a49d3e7 - Bil ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Shared security Db in FF-3.5?
On Sun, Jul 5, 2009 at 10:22 PM, Nelson Bolyardnonelsons...@nobolyardspam.me wrote: However, FF 3.5 has the code to support shared-access cert9 and key4 DBs, based on sqlite3. You can force FF 3.5 to use that by setting an environment variable. Is non-shared security Db still the case with upcoming Firefox 3.5? The old non-shared security DBs are still the default in FF 3.5. What is the environment variable? Thanks, -Kyle H___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Shared security Db in FF-3.5?
On Thu, Jul 16, 2009 at 1:46 PM, aerow...@gmail.com wrote: What is the environment variable? Set the environment variable NSS_DEFAULT_DB_TYPE to sql. All environment variables used by NSS are documented at https://developer.mozilla.org/en/NSS_reference/NSS_environment_variables Wan-Teh ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
