dev-security list is coming to an end

Mozilla's "mailman" servers, and the crazy mail/NNTP/WebForums mirroring, are being decommissioned soon and this list will no longer work. Most such lists are being migrated to https://discourse.mozilla.org for web-based forums, but as there are already discussions on this topic there this list is

Re: Support for EdDSA

For NSS-specific development questions you should try in the dev-tech-crypto mailing list, or the matrix chat at https://chat.mozilla.org/#/room/#nss:mozilla.org -Dan Veditz On Thu, Mar 18, 2021 at 4:50 AM Rishabh Kumar via dev-security < dev-security@lists.mozilla.org> wrote: > Hello All, > > I

Re: Scope of Dev-Security List

On 10/5/2013 4:00 PM, farr...@furcadia.com wrote: > Well, I was very disappointed not to find any discussion here of the > issues and challenges that W3C's decision on DRM for HTML5 would > bring for security. > > I sort of expected people to be all over that here, when I saw the > group name. Th

Re: Restricting privileged internal pages from chrome or about URIs with Content Security Policy

On 9/17/2013 9:38 AM, Frederik Braun wrote: There were and probably will be XSS bugs in some of parts of our browser part that is heavily using HTML and JavaScript. There have been since the beginning of Firefox. Chrome XSS is about the worst bugs because the attackers don't have to mess with

Re: Request for feedback on crypto privacy protections of geolocation data

On 9/10/2013 10:09 AM, Hanno Schlichting wrote: > As of this moment, we filter out any AP that has been detected in two > different places (where different means more than ~1km away from each > other). This is very conservative approach and we'll relax that > later. What do you mean by filtered ou

Re: Request for feedback on crypto privacy protections of geolocation data

On 9/10/2013 3:46 AM, Gervase Markham wrote: > On 10/09/13 00:25, R. Jason Cronk wrote: >> Does this give Mozilla the >> ability to historically track me if I move my device? > > Yes; this is why publishing the full raw stumbled data sets is sadly > going to be not possible. Why would we have tw

Re: Request for feedback on crypto privacy protections of geolocation data

On 9/9/2013 11:21 PM, Chris Peterson wrote: > The primary motivation for hashing the MAC+SSID was to avoid uploading > the SSID (which is considered private data in some European countries) "private" means we can't even /look/ at it, rather than merely can't store it? I believe Europe also conside

Re: Security concerns for a "browser support" API

On 9/4/2013 11:05 AM, Monica Chew wrote: > Looking through http://www.mozilla.org/en-US/firefox/releases/ I see > several minor release fixes that involve flipping a pref (like > 18.0.1). How much easier would our lives be if we didn't have to > chemspill for preference changes? We don't have to c

Re: [webdev] Why not CORS:*?

On 8/26/2013 6:27 PM, Matt Basta wrote: > It should be noted that CORSing without discretion can render CSRF > protection completely useless. "Without discretion" is echoing back whatever you find in the Origin: header and adding "Access-Control-Allow-Credentials: true" indiscriminately. Access-

Re: [webdev] Why not CORS:*?

On 8/26/2013 5:52 PM, Daniel Veditz wrote: > CORS: * is always safe for a public site, or at least as safe as your > application is for users of pre-CORS browsers. (maybe not so great for > intranet sites.) Meant to include a link to the authoritative blog on the subj

Re: [webdev] Why not CORS:*?

Not sure why you've cc'd our vulnerability reporting address; did you mean dev-security@lists.mozilla.org instead? On 8/26/2013 2:10 PM, Peter Bengtsson wrote: > So, when you know that your URL does not potentially trigger any > sensitive changes without the user being explicitly aware of

Re: War on Mixed Content - Why?

On 8/15/2013 11:21 AM, ianG wrote: > On 15/08/13 13:22 PM, Mikko Rantalainen wrote: >> Why not issue a new signature every day and be done with >> broken revocation lists?) > > You'll upset people if you start talking like that :) Not really, it's a serious proposal for dealing with the revocatio

Re: Mixed-content XHR & Websockets

On 7/23/2013 6:34 AM, Nicholas Wilson wrote: > I think having uniformity here is clearly helpful. I do recognise that > the WebSocket API spec requires mixed-content connections to be > blocked, but there might still be room for discussion on the benefits > of it, especially while you're adjusting

Re: Firefox behavior with CDPs and AIAs

On 4/11/2013 5:12 PM, Camilo Viecco wrote: It is possible (but not supported) to use have FF download the CRLs specified by the certificate. There are (of course) many caveats: Which is why we don't support it. 6. There will be a non-trivial performance hit (specially network bases) as some

Re: Firefox behavior with CDPs and AIAs

On 4/11/2013 5:16 PM, r.andr...@computer.org wrote: Thanks; I had already posted this to dev.tech.crypto... Oh, sorry then. I looked before replying and didn't see it, guess it's an unreliable feed. -Dan Veditz ___ dev-security mailing list dev-s

Re: Firefox behavior with CDPs and AIAs

On 4/11/2013 1:26 PM, Rick Andrews wrote: Sid Stamm suggested dev.security... -Original Message- From: Ian Melven [mailto:imel...@mozilla.com] you might also try asking this on mozilla.dev.tech.crypto :) Sid was wrong :-) The guys who know the technical guts of our crypto implementa

Re: Content Type Dependencies

On 4/5/2013 5:26 PM, jeremy.ral...@gmx.ch wrote: a comment in nsIContentPolicy.idl says /* When adding new content types, [...] My first thought was that it should be enough to look for all files that #include nsIContentPolicy.h und rebuild the specific subtrees, Note that nsIContentPolicy is

Re: Browser restrictions on cross origin data access

On 12/8/2012 3:04 PM, Jesper Kristensen wrote: Related things: XSS is unrelated to my question. CORS allows me to do the opposite of what I want. CSP restricts how my code can access any data, whereas I want to restrict how any code can access my data. CSP may or may not in the future try to pr

Re: ssl error

On 8/4/12 6:06 PM, Gus Richter wrote: >> If you are still seeing the problem what IP >> addresses do you get for the sites? I get 63.245.217.58 and >> 63.245.217.86 > > getfirebug.com 63.245.217.58 > blog.getfirebug.com 64.99.80.30 A reverse lookup on the latter g

Re: ssl error

On 8/10/12 6:29 AM, alex.mayo...@gmail.com wrote: > FWIW the results on Nightly here are as follows: > > https://blog.getfirebug.com/2012/07/13/firebug-1-10-0/ no > warning, but no padlock for HTTPS is shown. That's "normal" -- the site includes a few images from http://getfirebug.com/ and the pa

Re: ssl error

I don't get a cert error when following either of those links. According to DNS the firebug blog is at the same address as the website, but I get a completely different (and correct) cert when I go to the blog. Are you still seeing the problem? Both of the sites you list are in our PHX data center

Re: IDN TLD whitelist, and .com

On 7/5/12 1:37 AM, Gervase Markham wrote: > Recently, it was decided that a whitelist was not scalable in the face > of hundreds of new TLDs, and that we had to come up with a new approach. > We did, based on some suggestions from the Unicode Consortium: > > https://wiki.mozilla.org/IDN_Display_Al

Re: New MITM cert incident - Cyberoam

On 7/4/12 10:34 AM, John Nagle wrote: > A CA called Cyberoam appears to have issued a wildcard cert to > enable MITM attacks for "deep packet inspection" [...] > > They're not a CA trusted by Mozilla, apparently. They're not a CA. Businesses wishing to use the Cyberoam devices need to install

Re: Implications of new TLDs

On 6/22/12 2:39 AM, Gervase Markham wrote: > I suspect few businesses use existing real TLDs as their > external subdomains. However, I also suspect quite a few use > future TLDs! [...] And I bet a load use ".corp" (6 > applicants) and ".inc" (11 applicants). We've already seen confusion with some

test dev-security mail

Mailman was down yesterday and some of the lists didn't come back. If you're seeing this mail then dev-security is working. -Dan Veditz ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security

Re: Fixing SSL quickly (not), or why certs need business identity data.

On 3/30/12 4:20 PM, Kevin Chadwick wrote: > Perhaps even a mozilla CA, a Google CA, and a Microsoft CA with an > attacker having to compromise all three to be successful. Kai proposed something somewhat along those lines, with the browser vendors (possibly among others) being Vouching Authorities

Re: Fixing SSL quickly (not), or why certs need business identity data.

On 3/30/12 6:47 AM, ianG wrote: > I've been asking them for years to add the CA's name to the chrome. > But they still don't. Thus totally mangling any concept of who is > saying what to whom when why whether. Most of the time I think that'd be a good idea, too. We sort of have it, but not "at a

Re: Man-in-the-browser malware

On 2/22/12 10:47 AM, Florian Weimer wrote: >> Another number of fascination: a good set of false Id costs o(1000). > > I find it hard to believe that false passports and driving licenses > cost more than real ones. Why should they? There's probably a significant price difference between "good" o

Re: Is Mozilla actively working to introduce CAless TLS public key checking?

On 1/12/12 12:10 AM, Henri Sivonen wrote: > Is Mozilla actively working on a TLS public key checking system that > has real trust agility (not DNSsec!) and that doesn't require CAs to > work (but that can work in parallel with the CA system)? Not "actively", no. It's too early to determine if that

Re: Policy discussion list that is read-only for the public

On 1/11/12 7:38 PM, Kyle Hamilton wrote: > Right now, the security group (particularly the participants in > the CABF from Mozilla) There have been zero discussions about CABF stuff on the private security-group mailing list. The only time I recall PKI-in-general topics coming up is in the heat of

Re: Certificate is not trusted because no issuer chain was provided

A common server configuration error is to not include the chain of intermediates. Sometimes Firefox can figure it out if the listed intermediate has already been used by another site that session-- "working" does not always mean "fixed". In this case, however, the site does appear to serve a workin

Re: OCSP Tracking

On 9/8/11 11:20 AM, Zack Weinberg wrote: > On 2011-09-08 10:57 AM, Daniel Veditz wrote: >> Yes, OCSP supposedly traded off a little privacy for immediacy over >> CRLs. Except that many OCSP deployments in practice just respond >> based on the data in the CRL. > > Peter

Re: RES: Programmatically find the current Firefox profile folder

On 9/6/11 8:46 AM, Walter do Valle wrote: > I know that script. However, as I said in my original e-mail, it fell in > some security issues. It's not possible to call this script without > requesting some privileges. And that request generates an "ugly" dialog box > asking user about permission. I

Re: OCSP Tracking

On 9/6/11 11:07 AM, Devdatta Akhawe wrote: > Sure. But I think users would be very surprised to find that every > time they visit a SSL site, some server somewhere is noting down what > site they visited, and when. Yes, OCSP supposedly traded off a little privacy for immediacy over CRLs. Except th

Re: Restricting which CAs can issue certs for which hostnames

On 8/31/11 3:52 PM, Hill, Brad wrote: > Mozilla could add a certificate it controls to the trusted root > store with which it cross-signs other CA certs, adding a > nameConstraints in the process, yes? In theory. In practice Firefox uses the historical certificate verification code and not the NSS

Re: Help about signed javascripts

The script "principal" comes from the page origin, so in order to run privileged script the page itself needs to be in the signed archive. What you're trying to do simply won't work. It's been this way for a long time because the type of mixing you are trying to do led to security holes. Although

Re: Hulu using ETags to circumvent privacy protection methods

On 8/17/11 5:21 AM, Jean-Marc Desperrier wrote: > Also, at the moment it seems that Firefox's private mode doesn't > properly protect against this. That's a problem. We've tried hard to prevent disk writes in Private Browsing mode, but I think the cache got a pass because performance in Private Br

Re: CSP and object URLs

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 is a better conversation for public-web-secur...@w3.org where

Re: Question regarding anti-phishing protection in Firefox 3/4

On 3/31/11 12:23 AM, Florian Coulmier wrote: > That is very interesting, because in google official API, they > don't mention the goog-phish-shavar, but only the > googpub-phish-shavar. I assume "pub" stands for "public" and is the list they want people to use through the API if you don't have an

Re: embedding local video in a remote page

On 3/22/11 7:47 AM, pike wrote: > In an installation that uses firefox, I need to embed videofiles that > are located on the local hard disk into webpages that are served by a > remote machine. Browsers and plugins don't allow web content to reference local files for security reasons (as you surmi

Re: Question regarding anti-phishing protection in Firefox 3/4

On 3/24/11 10:04 AM, Florian Coulmier wrote: >> Hum, strange. It is flagged as phishing under both Firefox and Chrome >> for me. I have tried on several computers. >> Could it be a country-based policy ? I don't believe so. At least there's nothing in the request that signifies the country and Goo

Re: Security Problem?

On 2/25/11 8:40 PM, Gus Richter wrote: > The question I have is this: > 1. This is MY Bookmarks Toolbar and includes links of MY choosing. > How is it possible that one of my links can be changed by some > outside source? > 2. If it is as easy as it seems, then could a destructive change > (read se

Re: "Unable to add module", but why?

Forwarding question to the mozilla.dev.tech.crypto group. Is this a module you're creating yourself, or one you know works fine with Firefox for other people? On 1/21/11 6:21 PM, Lbm wrote: > Hi, first of all I hope I'm posting this question in the right place. > > Anyway, I've been trying to ad

Re: Fw: Important notice about your addons.mozilla.org account

On 12/27/10 5:41 PM, Logan wrote: > Good Evening; > I was quite surprised to see this in my email this evening. I'm not sure what > this is about or even if it's legit. Can someone please take a look at it and > let me know. > Thank you, > Walter Reinhart This is legit http://blog.mozilla.com/se

Re: Does the png module contains the fixes of vu643615 and vu576029

On Nov 23, 2010, at 11:27 AM, Brian Lu wrote: > The README file under modules/libimg/png says that its version > is 1.2.35 (contained in Thunderbird 3.1.6), while the bug > https://bugzilla.mozilla.org/show_bug.cgi?id=492200 says it has > upgraded to 1.2.37. The bug _summary_ says "upgrade libpng

Re: CSP policy questions

On 10/7/10 12:45 PM, =JeffH wrote: > Ok, suppose I have this origin i wish to protect > "https://www.example.com";, the origins "http://example.com"; and > "https://example.com"; redirect to the former, I'm not sure of the relevance of the re-directs here. You don't include plain example.com in

Re: Network Solutions serving malware from parked domains

Follow-ups set to mozilla.dev.security On 8/16/10 4:52 PM, Gen Kanai wrote: > This is pretty involved so worth reading in detail. > > http://blog.armorize.com/2010/08/more-than-50-network-solutions.html > > Personally, I hate domain parking and I think ICANN should outlaw it, > but that's a

Re: CSP: JSON or XML for report-uri?

On 6/11/10 11:38 PM, Bil Corry wrote: > I noticed that the "details" page [...] states that the > violation report is an XML document [... b]ut the spec > itself states that it's JSON data. It was changed to JSON after some of the initial feedback. -Dan ___

Re: CSP - Cookie leakage via report-uri

On 6/11/10 1:31 PM, Sid Stamm wrote: > On 6/11/10 1:19 p, Devdatta wrote: >> Sid : do you have feedback from developers that this data is >> absolutely necessary for debugging ? > > Potentially the data stored in the cookies could control what resources > are requested by a page, or an attack cou

Re: test -- why so quiet

On 5/16/10 2:21 PM, Michael Kohler wrote: > On 05/16/2010 11:19 PM, Daniel Veditz wrote: >> This group, admittedly low traffic, seems suspiciously quiet. Are >> posts working? >> -Dan > > Works fine. Thanks. I hadn't seen anything since the HITB spam on April 22

test -- why so quiet

This group, admittedly low traffic, seems suspiciously quiet. Are posts working? -Dan ___ dev-security mailing list dev-security@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security

Re: CSP : What does "allow *" mean?

On 3/13/10 6:13 AM, Nick Kralevich wrote: > On Fri, Mar 12, 2010 at 5:24 PM, Brandon Sterne > wrote: >> 2) How does one specify a wildcard for any protocol? >> >> I don't think we should allow that. Do you have a reason to >> believe we should? > > IMHO, any policy language needs to cover the e

Re: Allow CSP on HTML tags

On 2/28/10 6:43 PM, Axel Dahmen wrote: > Actually I still can't find a fair reason for omitting the option of > allowing HTML tags to provide CSP directives. > > * By means of the intersection algorithm, a CSP directive can > only tighten security but not loosen. > > * Disallowing tags would c

Re: Who is using NSS in their projects?

On 3/2/10 10:06 AM, davidwboswell wrote: > I had seen references to Apache using NSS in mod_nss so I included it > as a featured application and then blogged about it. In the comments > on that post though, there were questions if Apache was really using > NSS or not. If I'm completely mistaken h

Re: Does it ever make sense that a web page can have chrome privs?

On 2/23/10 6:15 PM, Boris Zbarsky wrote: > On 2/23/10 8:14 PM, Natch wrote: >> I was thinking (in bug 491243) that channels shouldn't inherit chrome >> privileges ever unless they are data, javascript or chrome channels >> (or that sort). > > That's already the case. The documents can end up priv

Re: MFSA 2010-03 exploitable with disabled Javascript?

On 2/21/10 10:45 PM, Manuel Reimer wrote: > my distributor, so far, didn't publish an updated package, so I'll have > to keep with an old Firefox for some days. > > For all of the current holes, disabling Javascript seems to be OK for > the meantime, according to your advisories, so I did so. > >

Re: Where to report suspicions about a FireFox add-on?

I didn't see any mail to amo-admins, nor to secur...@mozilla.org so I wanted to follow up. What URLs are you seeing that aren't on the s3 service? Nothing jumped out at me browsing the code, but knowing what I'm looking for would help me find it if it's purposefully hidden. On 2/14/10 2:45 AM, Ree

Fix for the TLS renegotiation bug

I'm surprised not to see it mentioned here yet, but Firefox nightlies implement the new TLS spec to prevent the renegotiation flaw. The fixes in NSS can also be used to build your own patched version of moz_nss for apache. Huge thanks to Nelson Bolyard for implementing the spec in NSS and Kai Enge

Re: Firefox Add-ons

On 2/6/10 12:50 PM, David E. Ross wrote: > At , you can even enter bug reports > against the addons.mozilla.org site. However, there is no provision for > entering bug reports against individual add-ons. Not for garden variety bugs, true. But for security problems M

Re: Firefox Add-ons

On 2/6/10 8:08 AM, David E. Ross wrote: > Add-ons there go through some degree of review before being available to > the public; before such reviews are concluded, add-ons require a user to > logon to his or her own account and receive a warning that the review is > still underway. Unfortunately t

Re: Paper: Weaning the Web off of Session Cookies

On 1/27/10 12:20 PM, Timothy D. Morgan wrote: > Cool, there are some great UI ideas there. I particularly like the > examples that eliminate favicons. ;-) > > I would think that moving toward HTTP authentication schemes, such as > digest, would make it much easier to automate a good identity mana

Re: Paper: Weaning the Web off of Session Cookies

On 1/26/10 12:57 PM, Timothy D. Morgan wrote: > I would like to bring your attention to a paper I published today: > > http://www.vsecurity.com/download/papers/WeaningTheWebOffOfSessionCookies.pdf > > It includes a few minor security problems with HTTP authentication > dialog boxes and password

Re: Firefox addon security question

On 12/21/09 12:15 PM, EricLaw wrote: > Thanks for confirming, all! > > Is there somewhere "official" that extensions that do this should be > reported? > > thanks, > Eric secur...@mozilla.org functions as an overall contact address for any security concern related to the Mozilla project. If it's

Re: A new false issued certificate by Comdo?

On 11/5/09 5:16 AM, Paul van Brouwershaven wrote: > What do you think of this certificate with the CN > "owa.b3cables.co.uk\ ", again issued by Comodo. > > Serial: D2D0DAD5A1C3E785844AA3C72CA2B191 > > Not in CRL number 2361 Last Update Nov 5 12:35:19 2009 GMT CA's can prune expired certs from t

Re: A new false issued certificate by Comdo?

On 11/5/09 10:37 AM, Kyle Hamilton wrote: > then why not create an internal build of Firefox, embed your own root > into it, and issue certificates from that root to the boxes that need > it? You don't need a special build, of course. Anyone can easily add a new root into modern desktop browsers.

Re: Does softoken implement ECC?

On 11/2/09 3:57 AM, Ahmed Samy wrote: > > I want to Know.Does the softoken exists with Firefox3 implement ECC > algorithm? thanks in advance. ECC is not a single algorithm, but Firefox has support ECC for quite a while. https://wiki.mozilla.org/FIPS_Validation Technical questions about it would

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

On 10/27/09 2:33 AM, Adam Barth wrote: > I understand the seductive power of "secure-by-default" here. If only she loved me back. > This statement basically forecloses further discussion because it does > not advance a technical argument that I can respond to. In this > forum, you are the king a

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

On 10/22/09 6:09 PM, Adam Barth wrote: > I agree, but if you think sites should be explicit, doesn't that mean > they should explicitly opt-in to changing the normal (i.e., non-CSP) > behavior? They have already opted in by adding the CSP header. Once they've opted-in to our web-as-we-wish-it-were

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

On 10/22/09 3:58 PM, Lucas Adamski wrote: CSS is content importing.. oh but IE allows CSS "expressions" so its a XSS vector too. IE8 has killed expressions off, our CSP spec says -moz-binding has to come from chrome: or resource: (that is, be built in). https://wiki.mozilla.org/Security/CSP/S

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

On 10/22/09 10:31 AM, Mike Ter Louw wrote: Any ideas for how best to address the redirect problem? In the existing parts of CSP the restrictions apply to redirects. That is, if you only allow images from foo.com then try to load an image from a redirector on foo.com it will fail if the redire

Re: Comments on the Content Security Policy specification

On 8/11/09 3:19 AM, Gervase Markham wrote: Here's some possibilities for www.mozilla.org, based on the home page - which does repost RSS headlines, so there's at least the theoretical possibility of an injection. To begin with: allow self; options inline-script; blocking inline-script is key t

Re: security.OCSP.require in Firefox

On 10/13/09 5:14 PM, Lucas Adamski wrote: For the small percentage of (power) users that can really understand the implications of a question like "the OCSP URL provided by this certificate does not appear to be valid at this moment, would you like to continue", Just to be clear at no point did

Re: security.OCSP.require in Firefox

On 10/13/09 10:12 AM, Eddy Nigg wrote: #B is important because we are already month after the alleged bug happened, plenty of time to get the act together. I think this warrants some actions, a review and renewed confirmation of compliance might be a good thing to do in this case. These certs w

Re: security.OCSP.require in Firefox

On 10/13/09 9:23 AM, Johnathan Nightingale wrote: The temptation to attach UI to this problem sets off "blame the user" alarms for me - do we think that uses will make better decisions with this information? Like I say, I don't think we're at WONTFIX on this question, but I don't think it's an ea

Re: security.OCSP.require in Firefox

On 10/12/09 3:13 AM, Rob Stradling wrote: Perhaps the time has come for the browsers to "force" all of the other CAs to take their OCSP responsibility seriously, by requiring OCSP by default. Firefox cannot take that step unilaterally, otherwise _we_ are the broken one in users eyes. An alte

Re: security.OCSP.require in Firefox

On 10/10/09 7:47 AM, Alexander Konovalenko wrote: Why is security.OCSP.require option set to false by default? Currently there is no requirement that CA's support OCSP for non-EV certificates, so some CA's don't. It would be nice if they then didn't put OCSP URLs into their certs, but some do a

Re: dependent pages

bill wrote: > window.open still provides for "dependent" status > (https://developer.mozilla.org/en/DOM/window.open ) > but it does not seem to work. > I know that many in the community don't like a window to be dependent, > but it is important for a company intranet application (no outside access)

Re: Comments on the Content Security Policy specification

Ian Hickson wrote: >> If a large site such as Twitter were to implement it, >> that's millions of users protected that otherwise wouldn't be. > > Assuming they got it right. If they don't some researcher gets an easy conference talk out of bypassing the restrictions and poking fun at them, and t

Re: dns-prefetch

Bil Corry wrote: > Jean-Marc Desperrier wrote on 7/24/2009 1:09 PM: >> The most serious attack seem to me to be than the attacker can know >> *when* exactly you read any given mail. > > I hadn't thought of that, but I do now see that as a reason to turn > it off entirely for any messaging applica

Content Security Policy updates

Sid has updated the Content Security Policy spec to address some of the issues discussed here. https://wiki.mozilla.org/Security/CSP/Spec You can see the issues we've been tracking and the resolutions at the Talk page: https://wiki.mozilla.org/Talk:Security/CSP/Spec There are still a few open iss

Re: CRMF encoding issues with window.crypto.generatedCRMFRequest()

Moving discussion to mozilla.dev.tech.crypto, but do go ahead and file bugs. I doubt 3.5 behaves any differently than 3.0 (you did mean 3.0.10, right? If you're using Firefox 2 please stop). nk wrote: > Hi all, > I am researching the window.crypto.generatedCRMFRequest() function > available on Fir

Re: Comments on the Content Security Policy specification

Jean-Marc Desperrier wrote: > In fact a solution could be that everytime the browser reject > downloading a ressource due to CSP rules, it spits out a warning on the > javascript console together with the minimal CSP authorization that > would be required to obtain that ressource. > This could help

Re: Comments on the Content Security Policy specification

Ian Hickson wrote: > This isn't intended to be a "gotcha" question. My point is just that CSP > is too complicated, too powerful, to be understood by many authors on the > Web, and that because this is a security technology, this will directly > lead to security bugs on sites (and worse, on site

Re: Comments on the Content Security Policy specification

Ian Hickson wrote: > * Authors will rely on technologies that they perceive are solving their > problems, XSS is a huge and persistent problem on the web. If this solves that problem authors will use it. > * Authors will invariably make mistakes, primarily mistakes of omission, CSP is designe

Re: Content Security Policy Spec questions and feedback

Gervase Markham wrote: >> What if we change the rules? Suppose we add a "head" keyword to the >> script-src directive. Older clients will think that's a host named >> "head" and strip all the in-line scripts the site relies on. > > So we have an "inline metadata" bug in the spec, in that we are p

Re: Content Security Policy Spec questions and feedback

Sid Stamm wrote: > You raise some excellent questions... you know, I hadn't really thought > about what to do about reporting inline script violations. I think the > intention was to just *not run* the violating script, but reporting the > violation is definitely a good idea since much of XSS happ

Re: Content Security Policy Spec questions and feedback

EricLaw wrote: > --- > Versioning > --- > 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. T

Re: Content Security Policy Spec questions and feedback

Sid Stamm wrote: >> Also, the “blocked-headers” is defined as required, but not all >> schemes (specifically, FTP and FILE) do not use headers. > Removed the requirement to send "request-headers" from the XML schema > (implied optional). Just jumping off here on a related topic: What do we send as

Re: Content Security Policy discussion (link)

pceelen wrote: > To prevent this we should have some requirements about the static > nature of the js files. One mechanism that might implement this is > adding requirements for static js files by requiring code-signed > javascript files (is this possible at the moment? > http://www.mozilla.org/pro

Re: Content Security Policy - final call for comments

Gervase Markham wrote: > - "but a declared (unexpanded) policy always has the "allow" directive." > I think you need to make it more clear that "allow" is mandatory. But > what was the logic behind making it so? Why not assume "allow *", which > is what browsers do in the absence of CSP anyway? "a

Re: IDN spoofing might still be a threat

Gervase Markham wrote: > On 01/04/09 16:58, Florian Weimer wrote: >> This highlights a significant problem with IDNA implementations: IDNA >> only makes sense as some sort of opaque hashing mechanism to get a >> resource from DNS. Yes, that's what it is. Given DNS is only defined for 7-bit ASCII t

Re: Work-around for Moxie Marlinspike's Blackhat attack

Jean-Marc Desperrier wrote: > Until a better solution is deployed, here is the work around to make > Moxie Marlinspike's attack ineffective. Note that the "better fix" will be a default change for this very pref, and any user-modified value will continue to take precedence. Please remember to undo

Re: UniversalBrowserRead CAPS in V2.0.0.18 and 3.0.4

[EMAIL PROTECTED] wrote: > I would lose Bookmarks wouldn't I. No, you'd have to explicitly delete your profile data for that to happen. It may be an option in the uninstaller (it's been a while since I've used it) but it's definitely not the default. ___

Re: Using alwaysLowered from chrome extension does not seem to work

alwaysLowered results in setting the flag CHROME_WINDOW_LOWERED, or at least "may" depending on privilege and parent window. The comment near that code is not reassuring, lumping it in with "features that are more operating hints than appearance instructions." http://mxr.mozilla.org/mozilla/source

Re: Bypassing or disabling firefox security to allow 'alwaysLowered' window

rael wrote: > On Sep 1, 11:48 am, Daniel Veditz <[EMAIL PROTECTED]> wrote: >> It looks like there's an extra check, in addition to having the right >> privelege (UniversalBrowserWrite) the window in question must have a >> chrome parent: >> >> http://

Re: Add own algorithm to NSS

??? wrote: > I want to add my own cipher algorithm to NSS library, like gost engine > in openssl, is it possible? > If yes can anyone explain the procedure See the patches that added Camellia and are trying to add SEED to NSS: https://bugzilla.mozilla.org/show_bug.cgi?id=361025 https:

Re: Bypassing or disabling firefox security to allow 'alwaysLowered' window

Bill Lear wrote: > Thanks for the note. I realize that you can do this, but in our > application, a kiosk, there will be no interaction with the user to > accept these, as they will already have been accepted at the time of > installation. > > In any case, it appears there is no way to get around

Re: Undesired XMLHttpRequest 401 behaviour

Paul Cohen wrote: > 1. Client -> Server: HTTP GET "http://foo:[EMAIL PROTECTED]/new- > > Another question is: Why is the username and password sent in the URL? Is it? Not what I see when I run a packet sniffer. If the UN/PW is being sent in the GET message I'd expect the server to return a 404 --

Re: Bypassing or disabling firefox security to allow 'alwaysLowered' window

rael wrote: >>> netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesRead"); >>> netscape.security.PrivilegeManager.enablePrivilege("UniversalPreferencesWrite"); >>> netscape.security.PrivilegeManager.enablePrivilege("UniversalBrowserWrite"); >>> netscape.security.PrivilegeManage

Re: changing javascript contexts / SOP

Melanie Naumann wrote: > The idea: Treating single script tags separately. My idea is to tag the > scripts (e.g. with additional html attributes) to enable a finer-grained > access control for accessing documents via DOM trees. > > The problem: Somehow I have to treat script code of different scri

  1   2   >