Re: Content Security Policy feedback

Sid Stamm wrote: > I'm not sure I agree with that... take for instance a browser that > only supports SSL v2 (and not 3): That's a difficult "for instance" to accept, because there aren't any. At least, not that anyone uses. > a site concerned with avoiding MITM > attacks might serve different c

Re: Content Security Policy feedback

Lucas Adamski wrote: > Developers rely on the browser security model in countless ways > already. A fundamental attribute of security models is reliability. I am not arguing we should make CSP work a random 50% of the time. I am arguing that CSP is not a "security model", it's a "phew, I would

Re: Content Security Policy feedback

Sid Stamm wrote: > Gervase Markham wrote: >> Security is a multi-faceted beast. > Point taken, and I agree, it was a crappy analogy. > >> Again, CSP is here being used as a front line of >> defence, and it shouldn't be. > I agree with you... optimally, CSP shou

Re: Content Security Policy feedback

Sid Stamm wrote: > Gerv: what are your thoughts on (mis)use of the Report-URI to > determine which browsers support CSP? For example, given a policy "X- > Content-Security-Policy: allow self", Report-URI "http://self.com/ > report" and a tag served "

Re: Content Security Policy feedback

bsterne wrote: > I think that CSP should be considered part of the browser security > model. Mike and others have made the excellent point that there are > significant costs to bear for a website that wants to start using this > model: policy development as well as migrating inline scripts to > ex

Re: Return of i18n attacks with the help of wildcard certificates

On 26/02/09 11:49, Jean-Marc Desperrier wrote: What's truly broken is that the current i18n attack protection relies on the checking done by the registrar/IDN, and that the registrar/IDN can only check the second-level domain name component. Actually, our protection had a bug (that is, there we

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

On 28/02/09 00:32, Jonas Sicking wrote: It'd be good to have a separate pref, network.IDN.blacklist_chars_extra, where users can add additional characters without having to worry about not receiving updates to the list we maintain. If users have to add chars to this list manually, that's Really

Re: Return of i18n attacks with the help of wildcard certificates

On 27/02/09 14:48, Boris Zbarsky wrote: It's not clear to me that the person who added the list even knew the page existed. Neil added the list, and he wrote the second half of the page. So there was mutual knowledge. The list isn't documented on the page because, strictly speaking, it's not

Re: Return of i18n attacks with the help of wildcard certificates

On 03/03/09 14:30, Jean-Marc Desperrier wrote: What about a white version of the hostname display for http sites ? Because it's not reliable information due to MITM. And trying to tell users "white means don't trust it, blue or green means do trust it" is far harder than "trust it if it's pre

Re: IDN spoofing might still be a threat

On 25/03/09 00:09, Jan Schejbal wrote: For example, one of the characters allowed in the policy is n (n with a small dash below it). While their online domain query tool seems to block invalid domains, they show "postbank.de" (postbank.de with the fake n, xn--postbak-pkb.de) as a valid domain, so

Re: IDN spoofing might still be a threat

On 27/03/09 19:37, Jan Schejbal wrote: Well, the problem I see is that in the German language, those characters are not at all common. We only use öäüÖÄÜß (Umlauts = aouAOU with two dots above and "sharp s" looking quite like greek lowercase "beta"), But does the German registry allow the regis

Re: IDN spoofing might still be a threat

On 01/04/09 16:58, Florian Weimer wrote: The ß-β near-collision is not a problem because ß is normalized to ss. I've been joking that the (which once was about buses, not penance) was one of the first IDNs. As a sidenote, the status of ß is one of the big arguments currentl

Re: Content Security Policy - final call for comments

Hi Brandon, Thanks for your continued hard work on this. Are we expecting to see some or all of this in Firefox 3.5, or Firefox-next? On 02/04/09 22:12, Brandon Sterne wrote: If you have feedback that you would like to share regarding Content Security Policy, please do so ASAP as the window fo

Re: IDN spoofing might still be a threat

On 04/04/09 22:26, Florian Weimer wrote: (IMHO, the answer to the homograph issue is to give users better indicators and tools to see what's going on. I don't agree; that's pushing security decisions down to the user, which is OK for 0.1% but bad for 99.9%, because they are not qualified, and

Re: Content Security Policy - final call for comments

On 02/04/09 22:12, Brandon Sterne wrote: We have been working hard lately to finish documenting the Content Security Policy proposal, What's the story on inline

Re: Content Security Policy - final call for comments

On 06/04/09 18:12, Sid Stamm wrote: Personally, I don't like the idea of honoring redirects for logging... if a meta tag can be injected into a page (with a CSP header or not) and the site hosts an open redirect, suddenly cookies can be stolen from all visitors to a site. Surely not? If Site An

Re: Content Security Policy - final call for comments

On 07/04/09 07:36, Daniel Veditz wrote: Maybe this does point out the need for some kind of version number in the header, so future browsers can take appropriate action when encountering an old header. For example, assuming "none" for any newly added types. I much prefer forwardly-compatible de

Re: IDN spoofing might still be a threat

On 07/04/09 08:50, Florian Weimer wrote: So if a user mistypes the site's name, he or she is out of luck? Homographs are almost never typos. It's very difficult to type www.payp-"cyrillic a"-l.com on a US keyboard :-) Individual writing systems tend to have this strange insistence that all of

Re: Content Security Policy - final call for comments

On 07/04/09 16:28, Sid Stamm wrote: Since the user's entire request header is in the report, any cookies sent with the request header to Angelic get forwarded on. While Be-Evil doesn't actually get forwarded cookies, the cookies are buried in the content of the report that is forwarded under the

Re: Content Security Policy - final call for comments

On 07/04/09 16:28, Sid Stamm wrote: Since the user's entire request header is in the report, any cookies sent with the request header to Angelic get forwarded on. While Be-Evil doesn't actually get forwarded cookies, the cookies are buried in the content of the report that is forwarded under the

Re: Content Security Policy - final call for comments

On 07/04/09 18:02, Brandon Sterne wrote: 1. Bugs may be present in the CSP design which require future compatibility breakage. These obviously cannot be foreseen and, though we desire it, we can't guarantee forward compatibility. There are two sorts of possible breakage - syntax and functional

Re: Content Security Policy - final call for comments

On 08/04/09 21:49, Brandon Sterne wrote: Defining a new header seems like a non-starter to me. We are going to be hard-pressed to get one new header standardized, so throwing one away seems very wasteful. As I said, I think the possibility of needing a breaking change in syntax is tiny. If

Re: Content Security Policy - final call for comments

On 08/04/09 23:09, Sid Stamm wrote: Additionally, knowing the portion of users whose browsers enforce CSP (and thus are benefiting from the minimal effort put into serving a CSP header) might be an interesting metric that web admins can present to their managers. ;) I don't think you need a CSP

Re: Content Security Policy - final call for comments

On 10/04/09 16:46, Brandon Sterne wrote: I'm not 100% thrilled with the idea either, mostly because parsing the U-A string could be challenging for some sites. But it does seems to be the least bad idea I've heard. We can certainly minimize U-A bloat by making our subproduct something like "CSP

Re: Content Security Policy discussion (link)

On 26/06/09 22:42, Bil Corry wrote: It's been brought up this morning on the WASC Web Security list too: http://www.webappsec.org/lists/websecurity/archive/2009-06/msg00086.html The linked blogpost suggests using the page itself as an E4X document to bypass the restrictions. Dead clev

Re: Content Security Policy discussion (link)

On 29/06/09 18:02, Brandon Sterne wrote: That is clever. Yes, I think you're right that we should enforce a valid MIME type for the external script files. We probably also want to whitelist application/json for sites utilizing JSON feeds. It does make you think, what other brokennesses can we

Re: Content Security Policy - Relaxed Restrictions Mode(s)

On 02/07/09 01:20, Jonas Sicking wrote: I think it should work. Otherwise myForm.addEventListener("submit", function(event) { if (!checkform()) { event.preventDefault(); return false; } }, false); should, according to web searches, make it work in IE too. But Jonas knows more about this t

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 suc

Re: Content Security Policy Spec questions and feedback

On 08/07/09 09:02, Daniel Veditz wrote: The UA approach may be a botch, but it was an attempt at something like a less-verbose Accept-type header (six bytes in the UA, many more as a separate header which would have to be sent with every request, with no servers today actually understanding anyth

Re: Content Security Policy Spec questions and feedback

On 07/07/09 19:18, Sid Stamm wrote: I personally want to eradicate the META tag (http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html). This should be discussed more in depth to decide if we should remove META support, if we should support multiple HTTP headers, etc. My comment: Why

Re: Content Security Policy Spec questions and feedback

On 08/07/09 18:22, Bil Corry wrote: If the hosting company is providing an interface to add one or more additional CSP headers, then wouldn't it be just as easy for them to provide an interface that constructs a single header? The scenario here is that they have a set policy, which an individua

Re: Comments on the Content Security Policy specification

On 29/07/09 23:23, Ian Hickson wrote: * Remove external policy files. I'm not sure how that's a significant simplification; the syntax is exactly the same just with an extra level of indirection, and if that makes things too complicated for you, don't use them. * Remove policies. Do

Re: Comments on the Content Security Policy specification

On 30/07/09 18:51, Daniel Veditz wrote: * Remove external policy files. I'd be happy to drop those, personally. Some people have expressed bandwidth concerns that would be solved by a cacheable policy file. Can we quantify that? At this stage, it's looking like most policies won't be signi

Re: Comments on the Content Security Policy specification

On 10/08/09 19:50, Brandon Sterne wrote: Working examples will be forthcoming as soon as we have Firefox builds available which contain CSP. We shouldn't need to wait for working builds to try and work out the policies, should we? Although perhaps it would be a lot easier if you could test th

Re: Comments on the Content Security Policy specification

On 10/08/09 22:56, Sid Stamm wrote: I tried to find in my notes and email archives how exactly we decided to move the keywords out, and couldn't find anything specific. Anyway, I added an "options" directive to the spec[0] that captures this change. I also added a thread on the wiki discussion pa

Re: Comments on the Content Security Policy specification

On 12/08/09 00:11, Ian Hickson wrote: I think in almost all cases, multiple headers will be a sign of an attack or error, not the sign of cooperation. OK. I think that's a fair challenge. Can someone come up with a plausible and specific scenario where multiple headers would be useful? The o

Re: security.OCSP.require in Firefox

On 14/10/09 05:17, Daniel Veditz wrote: Like the slashed-lock that indicates mixed mode (and is far too subtle for my tastes) I expect a lot of users wouldn't even notice, but hope that enough will to nudge things in the right direction. Right. The intended effect is on the site owner, not on t

Re: Comments on the Content Security Policy specification

On 15/10/09 22:20, Brandon Sterne wrote: I think we face a decision: A) we continue to allow inline styles and make external stylesheet loads be subject to the "allow" policy, or B) we disallow inline style and create an opt-in mechanism similar to the inline-script option [2] C) We do A, but d

Re: Comments on the Content Security Policy specification

On 20/10/09 21:20, Sid Stamm wrote: While I agree with your points enumerated above, we should be really careful about scope creep and stuffing new goals into an old idea. The original point of CSP was not to provide a global security infrastructure for web sites, but to provide content restrict

Re: Comments on the Content Security Policy specification

On 21/10/09 17:25, Sid Stamm wrote: Additional Directives are not a problem either, unless they're mandatory for all policies (which is not the case ... yet). I'm still more in favor of extension via new directives than extension by modifying existing ones: this seems more obviously backward com

Re: Comments on the Content Security Policy specification

On 23/10/09 01:50, Daniel Veditz wrote: blocking inline-script is key to stopping XSS. We added the ability to turn that bit of CSP off as an interim crutch for complex sites trying to convert, but if our proof-of-concept site has to rely on it we've clearly failed and will be setting a bad examp

Re: how to test CSP

On 26/10/09 08:46, Nilesh Kumar wrote: "Grab a preview build of Minefield Download a copy of the latest trunk builds of Firefox which have CSP support. The text you quote should have provided a link. and load this page to see how CSP works. For each individual test, a CSP-supporting browser

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

On 27/10/09 09:33, Adam Barth wrote: > My technical argument is as follows. I think that CSP would be better > off with a policy language where each directive was purely subtractive > because that design would have a number of simplifying effects: CSP's precursor, Content Restrictions http://www.

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

On 28/10/09 16:23, Gervase Markham wrote: > On 27/10/09 09:33, Adam Barth wrote: >> My technical argument is as follows. I think that CSP would be better >> off with a policy language where each directive was purely subtractive >> because that design would have a number o

Re: A new false issued certificate by Comdo?

On 05/11/09 18:20, Florian Weimer wrote: > Okay, then Mozilla has got a significant problem because some CAs > issue certificates for domains not delegated from the ICANN root. > These CA roots should not be on Mozilla's root CA list. Which ones? Gerv

Re: A new false issued certificate by Comdo?

On 05/11/09 15:24, Ian G wrote: > It's not "utter nonsense" it's intellectual property. The claim that > IANA/ICANN controls the letters '.int' inside a corporation is > fundamentally based on intellectual property. Also, the notion that the > internetworking protocols cannot be used internally a

Re: Safety of extensions (DefCon presentation)

On 25/11/09 18:47, Kálmán „KAMI” Szalai wrote: Today, one of leading IT portal published an article about FIrefox with this title: "Firefox is not safety because of its extensions". That's like saying "Windows is not safe because of applications". Installing an extension is like installing an

Re: Safety of extensions (DefCon presentation)

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. I'm happy to discuss ideas with folks off-list. Why off-list? This is mozilla.dev.security :-)

Re: Why is it an error to have both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only ?

On 12/03/10 22:45, Nick Kralevich wrote: To me, it seems valuable to support both X-Content-Security-Policy and X-Content-Security-Policy-Report-Only, as it allows sites to test new restrictions without disrupting their current restrictions. That's a very good point IMO. Gerv _

Re: NSS/PSM improvements - short term action plan

On 09/04/11 18:05, Adam Barth wrote: In addition to thinking about orderly transitions to new certificates (as you mention), there's also the case of disorderly transitions. For example, what happens if the site's private key gets compromised and it wishes to move to a new certificate before it p

Re: NSS/PSM improvements - short term action plan

On 12/04/11 14:22, Stephen Schultze wrote: On 4/8/11 6:49 PM, Sid Stamm wrote: - Implement subscription-based blocklisting of certs via update ping (remove need to ship patch) Is there a bug for this? Not that I know of; if there isn't, we need one. Would this permit blocklisting of CA cer

Re: NSS/PSM improvements - short term action plan

On 13/04/11 18:54, Stephen Schultze wrote: I don't totally understand your point about addons and graphics drivers. I guess I'm just not familiar enough with the codebase there. Sorry. What I meant was, the current plan is to leverage the existing system where Firefox pings us every day to dow

Re: NSS/PSM improvements - short term action plan

On 13/04/11 20:15, Stephen Schultze wrote: On 4/13/11 2:02 PM, Brian Smith wrote: Gervase Markham wrote: On 12/04/11 14:22, Stephen Schultze wrote: On 4/8/11 6:49 PM, Sid Stamm wrote: - Implement subscription-based blocklisting of certs via update ping (remove need to ship patch) Would it

Re: NSS/PSM improvements - short term action plan

Here's an imcomplete status update; further information from anyone would be welcome: On 08/04/11 23:49, Sid Stamm wrote: > Bucket A: > - Move to libpkix for all cert validation (bug 479393) The code is now checked in; bug 651246 tracks flipping the necessary pref. Brian Smith is working on the d

Re: NSS/PSM improvements - short term action plan

s I can remember were: Sid Stamm Brian Smith Lucas Adamski Chris Hofmann Kai Engert Bob Relyea Gervase Markham I think there were several other people there, but my memory is failing me. > I can tell you there are NSS developers who never heard about this until now. I apologise if we ha

Re: Hulu using ETags to circumvent privacy protection methods

On 17/08/11 13:21, Jean-Marc Desperrier wrote: > http://ashkansoltani.org/docs/respawn_redux.html > http://www.schneier.com/blog/archives/2011/08/new_undeletable.html > Some interesting precisions by Ashkan there in comments : "clearing the > cache AND deleting all other forms of storage (HTML5, Fl

Re: Restricting which CAs can issue certs for which hostnames

On 30/08/11 17:46, 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 > hostnames. Could we formalize this, and have CAs indicate any such > restrictions as part of their application, then enfo

Re: OCSP Tracking

On 06/09/11 03:48, Devdatta Akhawe wrote: > I was surprised to note that DigiNotar had a log of all IPs who had > requested an OCSP lookup for the bad certs. This seems like a very bad > idea on the OCSP server's part. Well, the list of IPs has been passed to Google, who are now able to warn peop

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

Hi Ben, On 11/01/12 17:07, Ben Bucksch wrote: > The majority of discussions here on this list are policy discussions > that are not specifically about bugs that are still embargoed, but > either general "what should we do about this whole class of problems" or > about security bugs that are alread

Re: Update on "NSS/PSM improvements - short term action plan"?

On 27/02/12 16:41, Sid Stamm wrote: > On 2/27/12 6:30 AM, Stephen Schultze wrote: >> Hey Sid, can you give an update on this action plan? > > Here's what I know: And this page may also be enlightening with regard to the current priorities for the security team: https://wiki.mozilla.org/Security/R

Re: [GSoC 2012] TLS 1.2 in Firefox

On 15/03/12 15:25, Arvind S Raj wrote: Hello everyone, I couldn't find a specific mailing list for GSoC related discussion so thought I'd email the security developers list and ask about this. Hi Arvind, There isn't one; here is fine :-) I came across former ideas of Mozilla in security and

Re: Scope of B2G applications

On 16/03/12 04:27, Lucas Adamski wrote: Gaia app: consists of a1, b1, c1. A typical local app, with a static codebase that is installed once, authenticated by a code signature and prohibited from dynamically loading additional code. So no remote request for JS? No eval and friends? Do we use CS

Re: Scope of B2G applications

On 16/03/12 14:53, Kevin Chadwick wrote: If you don't need background data. You can disable that and get no automatic update checks. Turning off updates, including security updates, doesn't sound to me like an awesome solution to the problem of being nagged about them... "Hey, if you cancel

Re: "bad" certificate UX concept

On 22/03/12 20:15, Yvan Boily wrote: > If we did this, would it be feasible to analyze user input into DOM > elements and raise warnings if personal data is entered into documents > loaded from "bad" sites? I would expect such sites to take the data as soon as it's entered and spirit it away via

Re: Fixing SSL quickly

On 28/03/12 02:29, John Nagle wrote: >The CA Browser Forum is tightening up standards. > The rules on certs change July 12, 2012, and will be much tighter > thereafter. There will be three levels of certs - "domain control > only", "organization validated", and "extended validation". > "Domain

Re: stealing saved passwords

On 11/04/12 08:54, Jesse Ruderman wrote: 1) If a site sends an STS header, and the user has any data (cookies, passwords, etc) that are not https-only, immediately mark that data as https-only. (This helps if a site uses STS, but the user's privacy settings cause the password storage to outlive t

Fwd: Mozilla Scheduled Downtime - 2012/04/26 - 0500-1200 PST

Forwarding to NSS and NSPR communities. Downtime is from 0500-1200 PST (7 hours). Gerv Original Message Subject: Mozilla Scheduled Downtime - 2012/04/26 - 0500-1200 PST Date: Thu, 26 Apr 2012 03:04:07 +0800 From: Shyam Mani Organization: Mozilla Corporation To: dev-plann...@li

Re: Implications of new TLDs

On 04/06/12 19:10, John Nagle wrote: >Many new TLDs appear to be coming. This may affect how Mozilla > interprets input in the URL bar, and has security implications. But to a lesser degree than for Chrome. They use the PSL to determine what is a URL and what is a search; that may not be scal

Re: Implications of new TLDs

On 06/06/12 16:13, Johnathan Nightingale wrote: >> Until now, this was mostly a curiosity, but if there's a >> "FACEBOOK" TLD, people are going to scream if it behaves like >> that. > > Yep. That's a problem. Unless it never works. If we announce we are not going to support this hijacking of bare

Re: Proposed Feature: Application Reputation system

On 11/06/12 11:11, Henri Sivonen wrote: > Could privacy be enhanced by having a Mozilla-hosted server bounce a > TLS connection to Google's API endpoint? That is, Mozilla would see > the user's IP address but wouldn't see the contents of the TLS > connection and Google would see the contents of the

Re: Proposed Feature: Application Reputation system

Hi Sid, On 08/06/12 23:02, Sid Stamm wrote: > == System Attributes == > > * List Size: roughly 300 domains and 100 app signers in whitelist (small) Taking Google's whitelist daily and removing warnings for domains and signers on the whitelist seems like a fairly obvious win. It reduces warning f

Re: Proposed Feature: Application Reputation system

On 11/06/12 21:56, Justin Dolske wrote: > I'd note a slight concern from our own (Firefox) experience with similar > things in antivirus software, where new releases of Firefox are > sometimes blocked because whatever reputation scheme they're using is > too specific to just the filename/contents.

Re: Proposed Feature: Application Reputation system

On 12/06/12 15:39, Kevin Chadwick wrote: > Leaving aside server/device security which may affect user security and > also completely anonymised data matching to connection details or > substitued user ids. An example being homesafe violating the long > standing and well serving principle of simple

Re: Implications of new TLDs

> Many of the TLDs are from domain speculators who want to resell > domains, but a sizable fraction are world-famous brands. Those > will be expected to work as bare words. I'm really not convinced that's so. Do you have any evidence that people are expecting that, or can you point to the place i

Re: Implications of new TLDs

On 14/06/12 19:55, John Nagle wrote: >Top-level A records are already allowed. Try > > http://ai/ The CCTLDs have a different arrangement with ICANN from the GTLDs. ICANN has a lot less control over them. Can you find a GTLD where there is a top-level A record? Gerv __

Re: Implications of new TLDs

On 16/06/12 15:46, Zack Weinberg wrote: > I have remembered the security case for not honoring top-level A > records: it has to do with abbreviated DNS names used in intranets. > Suppose http://ai.example.com/ is an internal-use-only server for > example.com employees, whose computers have all been

Re: Implications of new TLDs

On 16/06/12 15:46, Zack Weinberg wrote: > I disagree; this is the place to work out whether it is Mozilla's > opinion that top-level A records are inappropriate. We have the > technical ability to refuse to honor such records, Can you outline how we might do that? Would we need our own DNS resolv

Re: Implications of new TLDs

On 19/06/12 17:24, Zack Weinberg wrote: > I think we do need our own DNS resolver eventually (mostly because > DNSSEC) but it's not necessary for this. We'd just have to refuse to do > the DNS query at all for URLs whose hostname component did not contain a > dot, and/or which was equal to or a su

Re: Implications of new TLDs

On 20/06/12 17:34, Zack Weinberg wrote: > Ugh, you're right; I forgot about /etc/hosts and WINS names. > > There might be something clever we can do to detect these, but I'm not > sure what it would be offhand; the operating system APIs I know about > are deliberately designed to hide the details

Re: Proposed Feature: Application Reputation system

On 30/06/12 18:01, secguard...@yandex.com wrote: >> ** This proxy would strip the last octet out of IP addresses for pings > > I'm not an expert here, but would that be sufficient for IPv6? We should certainly make sure we do enough for IPv6. Although if Google is using the IP address for geoloca

IDN TLD whitelist, and .com

As some participants may recall, our IDN TLD whitelist was created in response to the "payp-cyrillic-a-l.com" incident of 2005. http://www.shmoo.com/idn/ Since that time, we have whitelisted over 50 TLDs after having inspected their anti-spoofing policies. http://www.mozilla.org/projects/securit

Re: IDN TLD whitelist, and .com

Hi Dan, Sorry for the delay here. On 05/07/12 16:39, Daniel Veditz wrote: > 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. >>

Re: IDN TLD whitelist, and .com

On 05/07/12 21:12, hillb...@gmail.com wrote: > May I suggest the following additions? Hi Brad, We are basing our algorithm on that in the UTR. Perhaps your feedback is better directed to Mark Davis, who maintains it? Or are you saying these restrictions are already in that document, and we mis

Re: Changing the SSL indicator

On 20/07/12 09:39, Jan Schejbal wrote: > Except for 2010, every year since 2008 has had at least one significant > change to the SSL indicator. This means that each time we finally > managed to teach users what to look for, that changed. And what we've ended up with now is an indicator that's real

Re: IDN TLD whitelist, and .com

On 05/07/12 16:39, Daniel Veditz wrote: However, given that it was a .com domain which started all this fuss, I thought it was worth posting publicly in case anyone had any comments. Have they revoked all the previously spoofing domains? Have they audited all their existing domains to make sure

Re: IDN TLD whitelist, and .com

On 11/10/12 22:05, John Nagle wrote: I would argue against this exception for ".com" and ".net". If someone is mounting an attack, it would probably be in those TLDs. Not if they aren't included. Discriminating against domain owners in .com or .net because of what some criminals may or ma

Re: IDN TLD whitelist, and .com

On 12/10/12 20:59, Justin Dolske wrote: Seems like it should be fairly simple for NetSol to generate a list of grandfathered domains. Have they done so and reviewed it? They tell me that they have, and worked with some domain owners to transition to new domains. "As with the introduction of

Re: IDN TLD whitelist, and .com

On 13/10/12 23:37, Dan Veditz wrote: I'm only a little concerned about grandfathering. I _am_ concerned that the whitelisting mechanism supersedes the proposed algorithm and allows for arbitrary charaters on labels above the level of the domain that the registrar issues and can vet. Not arbitra

Re: IDN TLD whitelist, and .com

On 16/10/12 21:14, Dan Veditz wrote: On 10/15/12 11:36 AM, Gervase Markham wrote: Can we do a hybrid system, where for whitelisted TLDs we accept registered domains as found and then apply the algorithm to the rest of the labels [...] Hmm. Possible, but certainly more confusing. Ideally, the

Re: Security fallout of hiding tabs-on-bottom mode

On 12/11/12 16:45, Johnathan Nightingale wrote: Every community has conservative elements. They are helpful; they remind us who we are when we forget. But conservative forces prevent change (by definition!) and we have important aspects of our code that need changing. I don't believe that the dis

Re: Security fallout of hiding tabs-on-bottom mode

On 15/11/12 06:21, Johnathan Nightingale wrote: We've bifurcated this thread in a way that I think is growing unhelpful. Gavin's commenting in the d.a.f one with a clearer state of the world, and I don't see a lot of value in having two threads in different newsgroups for this topic. You are qu

Re: Proposal: tougher CA standards in "private browsing" mode.

On 24/03/13 16:43, John Nagle wrote: > If, in private browsing mode, Mozilla can detect a MITM attack, > the user should be warned with a high-visibility warning. Er, if we could detect an MITM attack in any mode, there should be a high visibility warning. :-) > This includes any cert in the chai

Warnings about non-default certs in Private Browsing Mode?

I wanted to raise a suggestion from John Nagle to the status of a new thread. John suggested that, in Private Browsing Mode only, Firefox should inform the user if they make a secure connection using a certificate which is not one of the default set in NSS's root store. The logic is that if a user

Re: Warnings about non-default certs in Private Browsing Mode?

On 27/03/13 16:19, Ian Melven wrote: > another very common MITM situation is a captive portal on public wireless. True; I think a warning is entirely appropriate in that situation. > personally, i'm reluctant to conflate network attacks with private browsing > mode, > i believe it's already diff

Re: Proposal: tougher CA standards in "private browsing" mode.

On 02/04/13 12:20, Florian Weimer wrote: > In a corporate setting, intercepting proxies are fairly common, and > displaying a warning would be annoying to users. (Didn't some browser > vendor already try that?) It depends what UI you use. For example, if we had a red padlock... ;-) Seriously, th

Re: It's time to remove plugin support from Firefox mobile

On 10/05/13 18:54, David Keeler wrote: > * The only plugin that most users care about is Flash. Adobe stopped > development for Flash on Android in November of 2011, which is a year > and a half ago[1]. and it's no longer available for new installations. > * Popular sites that use plugins ha

Re: use of LZMA in Gecko

On 12/06/13 17:35, Jonathan Kew wrote: > The proposed WOFF 2.0 format[1], under discussion in the W3C webfonts > working group, includes the use of the LZMA entropy coder as a > better-compressing alternative to zlib. Very related bug: https://bugzilla.mozilla.org/show_bug.cgi?id=366559 Gerv ___

Re: Circumventing Security Systems With Dubious HTTP Responses

On 03/07/13 17:41, Boris Zbarsky wrote: > This is not the case. If a multipart response is sent, we will render > all the parts one after another. I know this is true if the MIME type is multipart/x-mixed-replace, but there are other multipart MIME types. Is it true for them also? > You can see

Re: Mixed-content XHR & Websockets

On 23/07/13 14:34, Nicholas Wilson wrote: > created to enable exactly these sorts of use cases, surely! It's clear > though that the app has to be served over HTTPS. And, it makes > connections to WebSocket-enabled servers on your local network that > aren't on the wide internet, so it's infeasible

Re: Mixed-content XHR & Websockets

On 25/07/13 13:18, Nicholas Wilson wrote: > On 24 July 2013 17:22, Gervase Markham wrote: >> Have you considered giving the managed servers certs minted from a local >> company CA, and trusting that root cert in the copies of Firefox? Or >> does that not work either? > &g

<    1   2   3   4   >