Re: Shared security Db in FF-3.5?
On 6 jul, 07:22, Nelson Bolyard nonelsons...@nobolyardspam.me wrote: On 2009-07-03 01:43 PDT, Andrei Korostelev wrote: Does Firefox 3.5 already support multi-process shared secrurity database or it is still single-process? By default, it is still the old single-process cert8 and key3 DBs, as before. 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. Is SecurityDb in Firefox 3 multiuser? Multi-user is a different matter than multi-process. FF 3.5's new cert9 and key3 DB are multi-process capable, but I would NOT describe them as multi-user. They are a pair, and the private keys in the key DB are, of course, private to each individual user. So, each user needs his/her own key DB, and since they are a pair, this implies that each user needs his/her own cert DB too. But with cert9.db, all that user's processes can share a common pair of DBs. Thank you. Are there plans to make this shared Db default, say, in FF 4? ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Shared security Db in FF-3.5?
Nelson Bolyard wrote: By default, it is still the old single-process cert8 and key3 DBs, as before. 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. My understanding is that is you start FF *once* with the setting enabled for the new db format, the base will be converted, and then it will use the new format every time after that point, without any special setting. Maybe even you could externally convert the base, and Fx will use the new format the next time it starts ? 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. ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy Spec questions and feedback
Hi Eric, Some really, really great points here. My thoughts on some of them: On 06/07/09 01:28, EricLaw wrote: Server CSP Versioning Can the server define which version of CSP policies it wants to use, allowing the client to ignore? I know that backward compatibility is the goal, but other successful features (E.g. Cookies) have had tons of problems here as they try to evolve. The current “Handling parse errors” section imposes a number of requirements that might be onerous in the distant future when we’re on version 5 of the CSP feature. User-Agent header What’s the use-case for adding a new token to the user-agent header? It’s already getting pretty bloated (at least in IE) and it’s hard to imagine what a server would do differently when getting this token. I also haven't quite got this straight in my head. I think it would be useful for the spec to contain a lot more detail on what it hopes to achieve with the current versioning system - scenarios where it would be useful, scenarios where it won't help, and so on - and also why we decided not to put a version number in the CSP response itself. Style-src I don’t know what “style attributes of HTML elements” means. It means div style=some CSS here/div frame-ancestors In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT tags that point to HTML pages, correct? I guess so :-) W3C folks have been giving us (IE) a hard time about the number (and scattered documentation) of X- header names http://blogs.msdn.com/ieinternals/archive/2009/06/30/Internet-Explorer-Custom-HTTP-Headers.aspx, and they’ve strongly encouraged us to register our header names (even provisionally) with IANA http://www.iana.org/assignments/message-headers/message-header-index.html rather than using the X- prefix. I'm sure we can do that, particularly if we have buy-in or tacit support from multiple browser vendors. We are early in a Firefox development cycle, so we do have time. HTTP Header: Final It seems like it might be useful for a CSP Header to declare that it’s the “Final” security policy, to prevent meddling by META Header injection and the like. The very existence of meta is now under discussion. But I think that if we do implement a merging algorithm (which I think we should, albeit for multiple headers) a final directive might be useful. Are relative URIs valid for the report-URI/policy-URI? (Seems like this would be a good thing to support). However, if so, is there any interaction/relationship with the BASE tag, which is supposed to also appear early in the head? Very good question. What happens to CSP if I save a CSP-protected document to my local disk? I’d assume it would be ignored (because many restrictions could be broken) but this should be explicit. Also, when saving docs to disk, HTTP headers are lost, so to preserve it, you’d need to explicitly serialize to a META tag, which could get complicated if the document already had a CSP META… Another good one. Gut reaction: The things CSP is supposed to help with are mostly connected with the page being loaded from a particular target site. If it's no longer being loaded from that site, many of them go away. So I think the answer is that CSP protection is removed. We currently restrict HTML loaded from the local disk from accessing other files on the local disk, but not in other ways. Therefore, a site could specify “*.example.com” to match “www.example.com” and “example.com”. Hmm. For people not thinking, this would obey the Rule of Least Surprise, but for people thinking, it would not obey that rule. sigh Doesn’t make sense to me, because “self” is defined to include the scheme. This suggests that we need a selfhost directive, which includes the hostname only. Or we make the same word serve two purposes, doing the obvious thing. Parse Errors: Server detection Parse errors are defined as only being reported on the client. This is probably reasonable, but leads to the possibility that some UA will fail to parse some CSP directive and the server operator will not know about it. Will this be a problem in practice, given that presumably the server owner tests their site with a variety of UAs? We don't ping server owners to say your HTML is unparseable, after all. That would rather increase the amount of traffic on the Internet! ;-) If the “Fail closed” model is used, is there any way for the user to know why the site is broken? Isn’t this going to create a problem, where, say, a FF4 user will “downgrade” to a browser that doesn’t support CSP (say, Opera 9) because the site “works properly there”? Everyone loses. This is a problem with a tighten when the header is used, and then use directives to loosen approach. Content Restrictions had the opposite approach - it started with loose (i.e. the situation as it is without CR support) and tightened using directives. This avoided this problem. Of course, both directions have pros and
Re: Content Security Policy Spec questions and feedback
Hi Eric, Gerv... thanks for getting this thread started. My replies are inline due to the diverse range of discussions going on in this thread. :) I also cut some stuff not relevant to my responses out to shrink the size of this message. On 7/6/09 7:46 AM, EricLaw wrote: On Jul 6, 3:02 am, Gervase Markham g...@mozilla.org wrote: On 06/07/09 01:28, EricLaw wrote: Server CSP Versioning frame-ancestors In addition to IFRAMEs/FRAME tags, this should also restrict OBJECT tags that point to HTML pages, correct? I guess so :-) Right. The goal with frame-ancestors is to be able to specify what sites can embed a protected page in any sort of framing context, no matter the tag. If an HTML/XHTML/etc document has a CSP, then any ancestor frame or embedding entity is verified against the policy. So I guess if a protected HTML document is embedded using OBJECT, then whatever content set the OBJECT tag must be checked. The only time this really gets broken is when plug-ins are involved. For example, there's nothing (short of Flash implementation that supports CSP) to stop a .swf called via OBJECT from loading an HTML page with a CSP set and rendering it as a subframe. Are relative URIs valid for the report-URI/policy-URI? (Seems like this would be a good thing to support). However, if so, is there any interaction/relationship with the BASE tag, which is supposed to also appear early in the head? Very good question. I believe this is an implementation issue... a relative URI eventually gets turned into an absolute URI before being requested. It is at that point (when it has been 'absolutified' or whatever I should call it) when CSP checks are done. Whether or not a BASE tag is present, the UA has to figure out what host to request the content from and over what scheme and port to request it; at this level, relative and absolute URIs should appear the same. I'll try to make this more obvious in the Spec. Doesn’t make sense to me, because “self” is defined to include the scheme. This suggests that we need a selfhost directive, which includes the hostname only. Or we make the same word serve two purposes, doing the obvious thing. I worry about a changed meaning of the keyword based on context, because that can lead to bugs. :) Fears aside, using self in the host position with any additional information (scheme://self or self:port) isn't such a bad idea, and makes sense to me. If the “Fail closed” model is used, is there any way for the user to know why the site is broken? Isn’t this going to create a problem, where, say, a FF4 user will “downgrade” to a browser that doesn’t support CSP (say, Opera 9) because the site “works properly there”? Everyone loses. This is a problem with a tighten when the header is used, and then use directives to loosen approach. Content Restrictions had the opposite approach - it started with loose (i.e. the situation as it is without CR support) and tightened using directives. This avoided this problem. Of course, both directions have pros and cons. Oh, I think Fail Closed is a fine model, but unless there's some way for the user to know why the page is completely busted, it seems likely that they're going to blame the properly-behaving UA rather than the site. Pretty much the same problem one encounters with strict XHTML validation failure-- how do you ensure that the user blames the site, not the UA? The spec states that we put errors in the error/debug console (so an advanced user can see exactly what's going on. Maybe we need to figure out a CSP Broken icon to pop up next to the lock icon in the status bar? I hate to clutter up the UI unless Agreeing with Sacolcor, I think the spec should explicitly note that CSP isn’t intended to apply to User-Scripts, although I think the Greasemonkey guys might find it hard to implement their current feature-set considering where CSP is likely to be implemented in the browser stacks. We need to avoid breaking Greasemonkey/GreasemonkIE. I wholeheartedly agree. I think there's a very legitimate case to be made for the potential security value in preventing unexpected cross-domain data reads. I agree with this, but I subscribe to the UA provided context for HTTP requests school of thought. I think the UA should provide some info about where requests came from to the server (render context like stylesheet or image, and source origin) -- then the Server can decide whether or not to serve the content. Cheers, Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
Re: Content Security Policy Spec questions and feedback
I hate to clutter up the UI unless Oops... I should probably finish my statement. I hate to clutter up the UI unless it provides a significant benefit to the user. -Sid ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security
