Re: fyi: Strict Transport Security (STS) specification

On Sat, Oct 10, 2009 at 1:19 PM, Florian Weimer wrote: > Does this address the lack of enforcement of the EV certificate > security level (i.e. it is usually sufficient to get any > browser-recognized certificate if I want to attack an EV site, > *without* disabling the EV UI)? Strict-Transport-S

Re: security.OCSP.require in Firefox

On Mon, Oct 12, 2009 at 8:29 AM, Daniel Veditz wrote: > An alternate approach I'd like to lobby our front-end guys on would be to > put up a scary red bar when we can't validate OCSP. Chrome puts up a yellow bar in this case. I see this bar most commonly when at coffee shops before I've agreed t

Straw-main XSSModule for CSP

Hi dev-security, On Friday, I spoke with Sid, Brandon, and dveditz about dividing the Content Security Policy specification into modules targeted at specific threats. This approach as two main benefits: 1) Different browser vendors can implement CSP incrementally by deploying the most important

Re: Comments on the Content Security Policy specification

On Mon, Oct 19, 2009 at 6:43 AM, Johnathan Nightingale wrote: > Not as limited as you might like. Remember that even apparently > non-dangerous constructs (e.g. background-image, the :visited pseudo class) > can give people power to do surprising things (e.g. internal network ping > sweeping, user

Re: Comments on the Content Security Policy specification

On Tue, Oct 20, 2009 at 12:47 PM, Mike Ter Louw wrote: > The threat model of HistoryModule, as currently defined, seems to be > precisely the threat model that would be addressed by a similar module > implementing a per-origin cache partitioning scheme to defeat history timing > attacks. Good poi

Re: Comments on the Content Security Policy specification

On Tue, Oct 20, 2009 at 12:50 PM, Devdatta wrote: > Regarding , History enumeration -- I don't see why it should be part > of CSP. A separate header - X-Safe-History can be used. I think one of the goals of CSP is to avoid having one-off HTTP headers for each threat we'd like to mitigate. Combin

Re: Straw-main XSSModule for CSP

On Tue, Oct 20, 2009 at 1:26 PM, Mike Ter Louw wrote: > I'm not sure if hacking at the straw man should occur on the list or on the > wiki.  Please let me know if it should go to the wiki. I've be inclined to discuss feedback on the mailing list where others can see and comment most easily. > Th

Re: Comments on the Content Security Policy specification

to get the safe history feature. > > Cheers > Devdatta > > 2009/10/20 Adam Barth : >> On Tue, Oct 20, 2009 at 12:50 PM, Devdatta wrote: >>> Regarding , History enumeration -- I don't see why it should be part >>> of CSP. A separate header - X-Safe-Hi

Re: Comments on the Content Security Policy specification

On Tue, Oct 20, 2009 at 1:42 PM, Collin Jackson wrote: > I think we're completely in agreement, except that I don't think > making CSP modular is particularly hard. In fact, I think it makes the > proposal much more approachable because vendors can implement just > BaseModule (the CSP header synta

Versioning vs. Modularity (was Re: Comments on the Content Security Policy specification)

On Tue, Oct 20, 2009 at 3:21 PM, Lucas Adamski wrote: > I've been a firm believer that CSP will evolve over time but that's an > argument for versioning though, not modularity. We are as likely to have to > modify existing behaviors as introduce whole new sets.  It's also not a > reason to split t

Module granularity (Re: Comments on the Content Security Policy specification)

On Tue, Oct 20, 2009 at 3:35 PM, Lucas Adamski wrote: > The problem with modules I see is they will complicate the model in the long > run, as the APIs they govern will not be mutually exlusive.  What if 3 > different modules dictate image loading behaviors?  What if the given user > agent in a sc

ClickJackingModule (was Re: Comments on the Content Security Policy specification)

Thanks Devdatta. One of the nice thing about separating the clickjacking concerns from the XSS concerns is that developers can deploy a policy like X-Content-Security-Policy: frame-ancestors self without having to make sure that all the setTimeout calls in their web app use function objects inst

CSRF Module (was Re: Comments on the Content Security Policy specification)

On Thu, Oct 22, 2009 at 8:58 AM, Mike Ter Louw wrote: > I've added a CSRF straw-man: > > https://wiki.mozilla.org/Security/CSP/CSRFModule > > This page borrows liberally from XSSModule.  Comments are welcome! Two comments: 1) The attacker goal is very syntactic. It would be better to explain wh

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Thu, Oct 22, 2009 at 9:52 AM, Mike Ter Louw wrote: > I agree.  It seems anti-csrf (as currently defined) would be most beneficial > for defending against CSRF attacks that don't require any user action beyond > simply viewing the page (e.g., ). Maybe we should focus the module on this threat m

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Thu, Oct 22, 2009 at 10:15 AM, Mike Ter Louw wrote: > I think this is a good start, and should be an option for sites that don't > want CSP to provide any other CSRF restrictions. I've added an additional > directive to the wiki, but it needs further definition. I think it might be better to

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Thu, Oct 22, 2009 at 12:36 PM, Mike Ter Louw wrote: > In this case, this boils down to: should CSP directives be threat-centric or > content-type-centric?  Alternatively, this may be an example of CSP being > too granular. I suspect we'll need to experiment with different approaches before we

Required CSP modules (was Re: CSRF Module)

See inline. On Thu, Oct 22, 2009 at 2:22 PM, Brandon Sterne wrote: > I'd like to take a quick step back before we proceed further with the > modularization discussion.  I think it is fine to split CSP into modules, > but with the following caveats: > > 1. Splitting the modules based upon differen

Re: Required CSP modules (was Re: CSRF Module)

On Thu, Oct 22, 2009 at 3:58 PM, Lucas Adamski wrote: > The threat-model centric approach won't work in the long run for a few > reasons: I'm not sure what we're arguing about. Do you like Brandon's groupings? They made sense to me. Are there concrete changes you think we should make? > a) th

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Thu, Oct 22, 2009 at 5:22 PM, Brandon Sterne wrote: > Take XSS and history stealing for example.  Assume these are seperate > modules and each is responsible for mitigating its respective threat. > Presumably the safe history module will prevent a site from being able > to do getComputedStyle (

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Mon, Oct 26, 2009 at 6:11 PM, Daniel Veditz wrote: > They have already opted in by adding the CSP header. Once they've > opted-in to our web-as-we-wish-it-were they have to opt-out of the > restrictions that are too onerous for their site. I understand the seductive power of "secure-by-default

Re: CSRF Module (was Re: Comments on the Content Security Policy specification)

On Tue, Oct 27, 2009 at 12:39 PM, Daniel Veditz wrote: > I don't think we're having a technical argument, and we're not getting > the feedback we need to break the impasse in this limited forum. I agree that we're not making progress in this discussion. At a high level, the approach of letting s

Opt-in versus opt-out (was Re: CSRF Module)

On Tue, Oct 27, 2009 at 3:54 PM, Brandon Sterne wrote: > I couldn't find a comment that summarizes the model you are proposing so > I'll try to recreate your position from memory of our last phone > conversation. I'll try to find the time to write a complete specification. > I believe you advoca

Strawman CSP counter proposal

Instead of arguing abstractly about design, I've written up a (mostly!) complete spec for an alternative CSP design: https://wiki.mozilla.org/Security/CSP/Strawman I've purposely gone overboard on the directives, but most of these directives are based on real feature requests I've received from w

Re: Strawman CSP counter proposal

Based on feedback on another list, I added some directives to the strawman. I've also divided the directives into maturity levels (Required / Recommended / Proposed / Experimental). Adam On Wed, Oct 28, 2009 at 2:30 AM, Adam Barth wrote: > Instead of arguing abstractly about desi

Re: Safety of extensions (DefCon presentation)

Jetpack is an opportunity to rethink the extension security model. Ideally, an extension platform would make it easier for developers to write secure extensions. I'm happy to discuss ideas with folks off-list. Adam On Thu, Nov 26, 2009 at 10:01 AM, Ian G wrote: > On 26/11/2009 15:35, Gervase M

Re: Safety of extensions (DefCon presentation)

On Fri, Nov 27, 2009 at 2:39 AM, Gervase Markham wrote: > On 26/11/09 20:32, Adam Barth wrote: >> >> Jetpack is an opportunity to rethink the extension security model. >> Ideally, an extension platform would make it easier for developers to >> write secure extensions.

Re: Safety of extensions (DefCon presentation)

On Sat, Nov 28, 2009 at 11:51 PM, Kálmán „KAMI” Szalai wrote: > Adam Barth írta: >> It's important to separate two concerns: >> >> 1) Malicious extensions >> 2) Honest extensions that have vulnerabilities (benign-but-buggy) >> >> I agree that

Re: Safety of extensions (DefCon presentation)

On Sun, Nov 29, 2009 at 10:19 AM, chris hofmann wrote: > There is some early thinking about the Jetpack security model at > > https://wiki.mozilla.org/Labs/Jetpack/JEP/29#Jetpack_Security_Model This looks like a great start. A few things you might consider: 1) If the Jetpack is not signed with

Re: Safety of extensions (DefCon presentation)

On Sun, Nov 29, 2009 at 6:34 PM, Devdatta wrote: >> 3) One of the things we found in our study (which Adrienne has made >> public at >> ) >> is that many extensions use nsIFile to store extension-local >> persistent state.  You mi

Re: Paper: Weaning the Web off of Session Cookies

On Sun, Jan 31, 2010 at 4:50 PM, Chris Hills wrote: > On 31/01/2010 18:12, Timothy D. Morgan wrote: >> That's handy, but doesn't that mean the website you're accessing will >> still use cookies once you're authenticated? > > Yes it does :/ But I think it's easier to get sites to implement OpenID >

Re: CSP - Cookie leakage via report-uri

Another option is to store the report-uri information in the well-known metadata store. Of course, that assumes that the attacker doesn't control the well-known metadata store... Adam On Tue, Jun 8, 2010 at 3:10 PM, Brandon Sterne wrote: > Hello all, > > I want to bring up an issue that was ra

Re: NSS/PSM improvements - short term action plan

On Fri, Apr 8, 2011 at 3:49 PM, Sid Stamm wrote: > After the few meetings and a couple of hours of discussion in the last > two days, we've made a short list of desired upgrades for NSS/PSM for > the near term.  This message should hopefully serve as a summary of the > technical bits that -- based

Re: NSS/PSM improvements - short term action plan

On Fri, Apr 8, 2011 at 4:02 PM, Jean-Marc Desperrier wrote: > On 09/04/2011 00:52, Adam Barth wrote: >>> >>> - CA locking functionality in HSTS or via CAA >> >> There's significant interest in this feature from chrome-security >> as well. >

Re: NSS/PSM improvements - short term action plan

On Sat, Apr 9, 2011 at 10:44 AM, Eddy Nigg wrote: > On 04/09/2011 01:52 AM, From Adam Barth: >> There's significant interest in this feature from chrome-security >> as well. > > There is however a very limited benefit and would only prevent a particular > t

Re: NSS/PSM improvements - short term action plan

On Sat, Apr 9, 2011 at 12:23 PM, Eddy Nigg wrote: > On 04/09/2011 09:36 PM, From Adam Barth: >> There's no dependencies on the CAs, as far as I understand.  Can you >> explain what you think the CAs will need to adhere to? > > Probably we aren't talking about th

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev

[-dev-tech-crypto] On Wed, May 18, 2011 at 6:17 AM, Jean-Marc Desperrier wrote: > Brian Smith wrote: >> See https://twitter.com/#!/scarybeasts/status/69138114794360832: >> "Chrome 13 dev channel now blocks certain types of mixed content by >> default (script, CSS, plug-ins). Let me know of any si

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev

On Wed, May 18, 2011 at 12:04 PM, Eddy Nigg wrote: > On 05/18/2011 09:45 PM, From Adam Barth: >> We tried aggressively blocking active mixed content by default in the >> Chrome Dev channel, but too much broke.  We're going to unblock it >> again and try to find some

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On Tue, May 31, 2011 at 10:25 AM, Christopher Blizzard wrote: > On 5/31/2011 8:24 AM, Brian Smith wrote: >> >> We have also discussed blocking https+ws:// content completely in our >> WebSockets implementation, so that all WebSockets on a HTTPS page must be >> wss://. That way, we could avoid maki

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith wrote: > Adam Barth wrote: >> > On 5/31/2011 8:24 AM, Brian Smith wrote: >> >> >> >> We have also discussed blocking https+ws:// content completely in >> >> our >> >> WebSockets implemen

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev [and WebSockets in FF6]

On Wed, Jun 8, 2011 at 8:40 AM, Christopher Blizzard wrote: > On 6/7/2011 5:52 PM, Adam Barth wrote: >> On Tue, Jun 7, 2011 at 5:43 PM, Brian Smith  wrote: >>> Adam Barth wrote: >>>>> On 5/31/2011 8:24 AM, Brian Smith wrote: >>>>>> >>

Re: Mixed HTTPS/non-HTTPS content in IE9 and Chrome 13 dev

On Wed, May 18, 2011 at 1:00 PM, Christopher Blizzard wrote: > On 5/18/2011 12:27 PM, Adam Barth wrote: >> Indeed, which is why we experimented with a hard block.  Our plan is >> to move in smaller steps, hopefully in coordination with other browser >> vendors. > &g

Re: CSP and object URLs

On Tue, Jul 26, 2011 at 5:19 PM, Daniel Veditz wrote: > On 7/22/11 7:18 PM, Eli Grey wrote: >> CSP needs a way to support object URLs, of which the scheme is >> implementation specific (e.g. moz-filedata:{GUID} in Firefox, >> blob:{origin}{GUID} in WebKit). How might this be accomplished? > > This

Re: Restricting which CAs can issue certs for which hostnames

That sounds a bit like DNSSEC, where the ability to sign host names is attenuated as it is delegated. Adam On Tue, Aug 30, 2011 at 9:46 AM, Boris Zbarsky wrote: > I was looking at our CA root list, and a lot of them seem like "specialist" > CAs that would only issue certs for a limited range of

Re: measuring use of deprecated web features

DOMMutationEvents :) Adam On Tue, Feb 14, 2012 at 2:34 PM, Jesse Ruderman wrote: > What rarely-used web features are hurting security? What might we > remove if we had data on prevalence? > > https://etherpad.mozilla.org/MeasuringBadThings > ___ > dev

Re: [b2g] Permissions model thoughts

On Mon, Mar 5, 2012 at 12:45 PM, Jim Straus wrote: > Hello - >  I definitely don't like the Android model.  We'll have to figure out > exactly how to communicate permissions requests to users.  On the other > hand, an appropriately vetted and signed app could be given permissions > implicitly in a

Re: B2G Threats/Controls

I won't be able to make the call, but I've left one comment inline: On Tue, Mar 6, 2012 at 10:15 PM, ptheriault wrote: > Chris, > > Below is a summary of threats and controls for further discussion. > Disclaimer: this is my understanding from various conversations, wiki pages, > bugs and IRC ch

Re: "bad" certificate UX concept

It seems like this wouldn't help in the case when your connection has actually been compromised by an attacker because the attacker would just avoid these sensitive names. Adam On Mar 22, 2012 1:27 PM, "Yvan Boily" wrote: > Done. > > I agree that the "sensitive" field list could be challenging

Re: "bad" certificate UX concept

ata. > > Make more sense? > > > On 12-03-22 1:46 PM, Adam Barth wrote: > > It seems like this wouldn't help in the case when your connection has > actually been compromised by an attacker because the attacker would just > avoid these sensitive names. > > Adam &