From MozillaWiki
Jump to: navigation, search

Meeting notes.

curtisk: security reviews

  • moved radar to public wiki
  • already done 2x as many reviews for 6 as for 5
  • thunder wants to talk about identity with secteam/infrasec again soon (Identity/Verified_Email_Protocol)
  • ping curtis if things are missing from Security/Radar
  • early meetings being conducted before things land on m-c serve as a guide for future interactions with security team

Riccardo (XSS filter)

  • Scope is to provide firefox with filter for reflected xss attacks
  • Find things in parameters (via taint tracking/string matching) to see if untrusted content is being used to make a javascript
  • IE 8 (proxy request inspection before parsing with regex, then tweaks document) and chrome (embedded checks in the calls to JS API -- no deleting needed, just abort the calls) do this
  • IE 8's approach causes more attack surface
  • There are false positives (where attacker can disable scripts by tweaking URL parameters) For example, framebusting scripts could be disabled. You could DoS a page.
  • So far, it is implemented on top of CSP (built a JS interface), but was hard since the JS engine is decoupled from content in a way that it's hard to find the origin of the calls into JS.
  • If you can predicate also on the content of the script, you can decide which inline scripts to run.
  • Implementation is done except performance and accuracy evaluation.
  • working on a paper for a deadline one week or two from now
  • More tests in development
  • Thinking about test pilot study to see if it works in the wild.
  • This implementation is not limited to detecting entire script elements injected… it's possible for code to add to an existing script element. This implementation looks for a whole parameter somewhere inside a script tag *AND* for the entire script anywhere in the URL.
  • Lucas suggested we do a design review with the security team about this feature.

Lucas (Roadmap spreadsheet):

  • Last round of voting is up in the spreadsheet
  • Lots of votes for UI experiments, sandboxing content, CSP, plugin work, CA issues
  • Lucas will morph this into roadmap and then bring to the product team
  • This roadmap is just major efforts (small things can be quickly be knocked off regardless of priority)
  • Email feedback to Lucas

Brian (Mozilla ID, DNS SEC)

  • ID: crypto stuff they're doing … want to get Mozilla Verified Email working in all browsers (means JS library for crypto, NSS in Firefox)
    • Problem is generating random numbers in JS
    • Investigating solution for this
    • All of mozilla ID is about security (authentication) so we should get involved.
  • W2SP
    • Cookie stealing attacks... discussion with Ben Adida coming up
    • TLS optimizations from Collin Jackson; Brian wants to figure out how to apply them.
    • Brian talked to Peleus (adobe) who mentioned Adobe will be implementing their own flash sandbox.
    • Lucas suggests adding features so plugins can do their own sandboxing.
  • Spoke with Limi about toolbarless app tabs (pending security review next week)
    • No advancements in discussion yet
    • Limi's point is that most people don't understand security indicators in that part of the UI anyway.
    • Brian's recommendation is that we improve them instead of removing them.
    • Lucas says that if we can guarantee it's all on one domain, it's probably okay to remove the URL bar and stuff.
    • Brian: If the site you pin decides to fake the url bar, they could defraud you.
    • Prepare for security meeting next wednesday
  • Spoke with Limi about cert manager UI
    • Chaining in the UI is not clear. Limi recommends removing the UI.
    • Limi suggests we move corporate-related certificate management into site-specific
    • Limi: only experts can understand the CA model anyway
    • Brian suggests that it's hard enough for us to understand the UI (as security people), that it's tough to make it useful for the general public.
  • Starting to threat modeling websockets today. Lots of people, come help (today).
  • Brian wants to recruit people to work on an effort to propose a DNSSEC-type project to be initiated and done. Contact him if you want to work on DNSSEC.
    • Was working on hooks to let folks like Dan Kaminsky write add-ons to do this, but it became really hard to figure out how to deal with multiple add-ons, and many people don't want PSM overridden.
    • shaver/sayrer are having Discussions with google folks on this topic.
    • Makes sense to do this since there are more CA requests coming into the pipeline. Need to start thinking about alternatives for trust.
    • Brandon suggests we're just transferring trust to registrars (a smaller set of authorities).
    • Brian suggests that orgs want '.cn' sites, so there should be a way to indicate authenticity that don't rely on the government running the cc TLDs.
    • If we're going to accept CAs that are government run to bless certs for entities not under their control, we have to think about a better route. Ideally, we need objective criteria.
    • Dvedtiz: technological fix for this to some extent would be nice. Can we domain constrain some of the CAs?
    • bsmith: some korean websites are .com, so we can't restrict the government-mandated CA to .kr.
    • Fundamentally, restricting CAs is a fairness issue. How do we delegate limited trust in a way that's fair? This becomes policy/geopolitics.
    • Bsmith: I think DV can be replaced with DNSSEC; it tells you that if there is a problem the problem is at the web site you're connecting to or the registrar. Problem moves from the client side to the server side.
  • Silisec meetup Thur 7:00pm at Faultline in Sunnyvale.