Re: Firefox removes UI for site identity
I also have a question for Mozilla on the removal of the EV UI. This issue started with a posting by Mozilla on August 12, but despite 237 subsequent postings from many members of the Mozilla community, I don't think Mozilla staff ever responded to anything or anyone - not to explain or justify the decision, not to argue. Just silence. So my question to Mozilla is, why did Mozilla post this as a subject on the mozilla.dev.security.policy list if it didn't plan to interact with members of the community who took the time to post responses? In the future, if Mozilla has already made up its mind and is not interested in hearing back from the community, it might be better NOT to start a discussion on the list soliciting feedback. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Germany's cyber-security agency [BSI] recommends Firefox as most secure browser
Congratulations to Mozilla and its Firefox team! Here is a ZDNet article [1] from today: “Germany's cyber-security agency [BSI] recommends Firefox as most secure browser” “Germany's BSI tested Firefox, Chrome, IE, and Edge. Firefox was only browser to pass all minimum requirements for mandatory security features” BSI (translated as the Federal Office for Information Security) is “the German upper-level federal agency in charge of managing computer and communication security for the German government. Its areas of expertise and responsibility include the security of computer applications, critical infrastructure protection, Internet security, cryptography, counter eavesdropping, certification of security products and the accreditation of security test laboratories.” [2] BSI found that Firefox is the *only* browser to support *all* of the BSI requirements for a secure browser. Here is what the ZDNet article says about EV certificates: According to the BSI's new guide, to be considered "secure," a modern browser must satisfy these minimum requirements: *** - *Must support extended validation (EV) certificates* Here is what Sec. 2.1b) of the full BSI report says: The web browser MUST meet the following requirements for certificates and their verification: — A list of certificates of trusted certificate issuers (CA Certificates) MUST be provided. — Certificates with domain-based validation (Domain Validated-Zertrifikate, DV), with Organization-based validation (Organizational-Validated-Zertifikate, OV) and certificates with Extended Validation Certificates MUST be supported. I hope the Mozilla community will celebrate this honor, but will also reconsider its proposal to drop support for EV certificates – that would mean that Firefox no longer meets all BSI requirements for a secure browser. [1] https://www.zdnet.com/article/germanys-cyber-security-agency-recommends-firefox-as-most-secure-browser/ [2] https://en.wikipedia.org/wiki/Federal_Office_for_Information_Security ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Updated website owner survey data on identity, browser UIs, and the EV UI
On September 21, I sent a message to the Mozilla community with the results of a survey of all of Entrust Datacard’s customers (both those who use EV certificates, and those who don’t) concerning what they think about website identity in browsers, browser UIs in general, and EV browser UIs in particular. [1] The data we published was based on 504 results collected over two days (a pretty good response). The survey was distributed in a way that each customer could only respond once. We left the survey open, and can now publish updated results from a combined total of 804 separate certificate customers (300 more than last time). The results mirror the results we first reported two weeks ago – and based on Paul Walsh’s data on when survey results should be considered statistically significant [2], this means that the updated survey results are very solid. Here is a summary of the updated respondent results for the six questions listed below. (1) 97% of respondents agreed or strongly agreed with the statement: "Customers / users have the right to know which organization is running a website if the website asks the user to provide sensitive data." (This is the same result as for the prior sample.) (2) 94% of respondents agreed or strongly agreed with the statement “Identity on the Internet is becoming increasingly important over time.” (This is 1% higher than in the prior sample.) (3) When respondents were asked “How important is it that your website has an SSL certificate that tells customers they are at your company's official website via a unique and consistent UI in the URL bar?” 76% said it was either extremely important or very important to them. Another 13% said it was somewhat important (total: 89%). (This is 2% higher than in the prior sample.) (4) When respondents were asked “Do you believe that positive visual signals in the browser UI (such as the EV UI for EV sites) are important to encourage website owners to choose EV certificates and undergo the EV validation process for their organization?” 72% said it was either extremely important or very important to them. (This is down 1% from the prior sample.) Another 18% said it was somewhat important. (This is up 1% from the prior sample.) The total is the same at 90%. (5) 92% agreed or strongly agreed with the statement: “Web browser security indicators should be standardized across different browsers to make the UI easier for users to understand.” (No change from prior sample.) (6) Finally, when asked “Do you think browsers should standardize among themselves on a common Extended Validation UI so that it appears roughly the same in all browsers?” 89% said yes. (This is down 2% from the prior sample.) Here is the distribution of respondents by number of employees: 804 enterprise responses total (versus 504 in prior sample). There was an increase in survey participation by smaller companies in these updated results. Organization Size by Employee Count 12.34% 1 to 99 employees 15.53% 100 to 499 employees 9.71% 500 to 999 employees 24.13% 1,000 to 4,999 employees 17.20% 5,000 to 19,999 employees 18.72% 20,000 or more employees 2.36% Don't know Clearly organizations of all sizes think website identity is important, that the EV UI should be retained, and that the browser UI design should be standardized across different browsers. While any survey can certainly be improved, this is the only data anyone has provided to the Mozilla community concerning what website owners think about browser UIs, and what they would like to see. We again recommend that Mozilla consider adopting the binary Apple UI, which works in both desktop and mobile environments and distinguishes between EV/identity sites (with a green lock symbol and URL) and DV/anonymous sites (with a black lock symbol and URL) – check it out in an iPhone. (Apple did not eliminate the EV UI, as some has erroneously said.) This is easy for users to understand at a glance. To see how it looks, compare apple.com (EV) to google.com (DV) on an iPhone using Safari. Paul has suggested that color difference alone is not sufficient, and there should be something more to distinguish the EV UI from the DV UI – that sounds good to me, but if Mozilla and Apple align, we will have made progress on getting a common UI across multiple browsers. As others have said on this string, there are no recent browser or academic studies that that say an improved EV UI can’t work with users. The only study that has been cited to support removal of the EV UI is a Google study that essentially asked what users *do* know about UIs today (answer: users don’t understand the current EV UI and don’t rely on it to make security decisions). I believe the reason for this result is that the EV UI is constantly changing (the Chrome EV UI has gone through three major changes in the last 12 months, with no user education – so why sho
Re: Website owner survey data on identity, browser UIs, and the EV UI
On Saturday, September 21, 2019 at 6:19:29 PM UTC-7, Ryan Sleevi wrote: > On Sat, Sep 21, 2019 at 7:52 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server > > certificate customers over three days (19-21 September 2019) concerning > > website identity in browsers, browser UIs in general, and EV browser UIs in > > particular. We have received 504 responses from customers to date, and > > more responses are still coming in. Respondent company size ranged all the > > way from 1-99 employees to over 20,000 employees. > > > Thanks for sharing this interesting marketing data by Entrust DataCard. > It's always good to see the marketing teams able to reach out to their > customers, as it gives hope that there's improvements being made to ensure > timely revocation. > > Since numbers like "92%" sound quite large, unless and until they're put > into context, I wanted to make sure there was a clear picture about what > those 504 responses represent. > > 1) Based on Entrust Datacard's CP/CPS, it only issues OV/EV certificates. > Is this correct? This is largely to account for self-selection issues, > since one might expect 100% of respondents that have already chosen a > particular service to, well, respond in similar numbers. > > 2) Related, looking at the numbers published by Firefox Telemetry, over a > two month period of connections made by Firefox users, only a small > fraction, approximately 0.3%, encounter certificates from Entrust DataCard. > This is roughly 120 million connections out of 39.49 billion. Does that > match Entrust DataCard's analysis about the size of its customer base? > > You can check the math at telemetry.mozilla.org, > using CERT_VALIDATION_SUCCESS_BY_CA as the metric. Based on RootHashes.inc, > it appears Entrust DataCard operated CAs are the buckets 10, 18, 109, 110, > 111, 112, 163, and 164, which matches the 8 CAs Entrust has disclosed in > CCADB that are trusted by Mozilla. Three of these CAs have seemingly not > been used to verify any connections, while of the remaining 5, it seems > that only Entrust Root Certification Authority - G2 sees any real use. > > 3) Are the numbers Entrust DataCard provided in > https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf > still accurate? That is, do EV certificates account for only 0.48% of the > certificate population? > > If those numbers are correct, this seems like it's a survey that represents > a small fraction of Entrust DataCard's customers (unless Entrust DataCard > only a few thousand customers), which represents a small fraction of > connections in Mozilla Firefox (approximately 0.3% over a 2 month period), > regarding certificates that account for only 0.48% of the certificate > population. > > Is that the correct perspective? The data I posted is correct, so I'm not really sure what point(s) you are making. Does Google Chrome have any data from its own surveys of website owners' opinions it's willing to share? It's one thing to be a critic of the work of others, it's another thing to actually create useful and meaningful data yourself and share with the Mozilla community. What data from Chrome can you share with us? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Website owner survey data on identity, browser UIs, and the EV UI
The Mozilla community seeks broad input before important security decisions like changing the Firefox UI, but it almost never receives any input from one important group – website owners themselves. To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server certificate customers over three days (19-21 September 2019) concerning website identity in browsers, browser UIs in general, and EV browser UIs in particular. We have received 504 responses from customers to date, and more responses are still coming in. Respondent company size ranged all the way from 1-99 employees to over 20,000 employees. Here is a summary of the respondent results so far for the six questions listed below. (1) *97%* of respondents agreed or strongly agreed with the statement: "Customers / users have the right to know which organization is running a website if the website asks the user to provide sensitive data." (2) *93%* of respondents agreed or strongly agreed with the statement “Identity on the Internet is becoming increasingly important over time.” (3) When respondents were asked “How important is it that your website has an SSL certificate that tells customers they are at your company's official website via a unique and consistent UI in the URL bar?” *74%* said it was either extremely important or very important to them. Another *13%* said it was somewhat important (total: *87%*). (4) When respondents were asked “Do you believe that positive visual signals in the browser UI (such as the EV UI for EV sites) are important to encourage website owners to choose EV certificates and undergo the EV validation process for their organization?” *73%* said it was either extremely important or very important to them. Another *17%* said it was somewhat important (total *90%*). (5) *92%* agreed or strongly agreed with the statement: “Web browser security indicators should be standardized across different browsers to make the UI easier for users to understand.” (6) Finally, when asked “Do you think browsers should standardize among themselves on a common Extended Validation UI so that it appears roughly the same in all browsers?” *91%* said yes. Here is the distribution of respondents by number of employees: 504 enterprise responses total Organization Size by Employee Count 11;40%1 to 99 employees 12.72%100 to 499 employees 9.65%500 to 999 employees 26.10%1,000 to 4,999 employees 17.76%5,000 to 19,999 employees 20.83%20,000 or more employees 1.54%Don't know It’s important for Mozilla to consider all relevant information when making security decisions – and the opinions of these website owners are important. They believe users have a right to know which organization is running a website before users hand over sensitive information, and they think browser UIs should be standardized across all browsers, including a standardized EV UI. For this reason, we urge Mozilla to listen to website owners and not eliminate the EV UI in Firefox 70. Instead, Mozilla should work with other browsers to come up with common UI design elements, including for the EV UI, and engage in minimal user training on what the unified UIs mean. We again recommend the binary Apple UI to all browsers, which works in both desktop and mobile environments and distinguishes between EV/identity sites (with a green lock symbol and URL) and DV/anonymous sites (with a black lock symbol and URL) – check it out in an iPhone. (Apple did not eliminate the EV UI, as some has erroneously said.) This is easy for users to understand at a glance. Taking away the EV UI in Safari means users have no easy way of knowing whether a site asking them for sensitive information has a known identity (little or no phishing) or is anonymous (lots of phishing). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: An honest viewpoint: Move Extended Validation Information out of the URL bar
Here is another comment from a major anti-phishing service – PhishLabs - about the value of EV certificates in detecting malicious websites. Its CTO, John LaCour, is willing to go on the record, and he concludes with this statement: “So should web browsers provide a visual indicator to users that their site uses an EV certificate?I think it is useful information for a class of users. It seems like there should be a way to indicate EV without it confusing or misleading other classes of users.“ I agree – and think the Apple binary UI is the way to go – and I hope Mozilla will consider it instead of eliminating the EV UI and hiding the data from Firefox users. Over time, that could drive EV identity data from the security ecosystem. Here are John’s comments in full: Kirk, Thanks for your question about how PhishLabs uses certificates to help evaluate web site legitimacy. First, let me be clear that, whether or not a web site is legitimate, secure, compromised, etc. has nothing to do with whether it has a digital certificate for TLS or not. Or even what kind of certificate it is.We’ve seen compromised sites with EV certificates – though exceedingly rarely (< 10 / year), as well as popular legitimate sites without a certificate. Every day we scan millions of web sites and URIs that may be malicious. Our technology can often, with very high confidence, classify a site or specific URI as malicious or not automatically.Sometimes, though, we aren’t sure.In those cases we often fallback to a set of heuristics to help us make a determination.One of the very strong signals we use as to whether is a site is legitimate and secure is if it has an EV Certificate. I believe this is a result of correlation – a strong one that can be used with confidence – that the site owners are known and that they are more likely to practice better security hygiene.On the email thread you mentioned, there was some discussion about Google Safe Browsing and if and how that should be used. We’ve found in our tests that GSB only correctly identifies roughly 50% of the known malicious sites we query against it.And we proactively share all of these bad URIs with Google. So should web browsers provide a visual indicator to users that their site uses an EV certificate?I think it is useful information for a class of users. It seems like there should be a way to indicate EV without it confusing or misleading other classes of users. Thanks for the opportunity to chime in. John -- John LaCour CTO, PhishLabs ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: An honest viewpoint: Move Extended Validation Information out of the URL bar
On Friday, September 6, 2019 at 4:17:44 PM UTC-7, Oliver wrote: > On Friday, September 6, 2019 at 11:44:30 AM UTC-7, browser...@gmail.com wrote: > > > Thanks for the update Jonathan, the article I read didn't mention the > > funding source, but the article wasn't the point of my post. > > > > Bottom line, why strip out of view the only browser mechanism that > > identifies the owner of a website? Why not force the CA's to improve the EV > > validation process and create a ubiquitous user experiences around EV > > across ALL browsers so that visitors can begin to see the commonality of > > EV's purpose? > > > > For the betterment of a safer and more trustworthy Internet, why digress > > from the concept of web identity verification instead of trying to make it > > better? > > The problem is that EV does not provide a owner identity that is actually > useful to end users: > > * the public name of many companies is not their incorporated name (e.g. > https://www.thesslstore.com) > > * Unlike hostnames, company names are not globally (as we've seen > repeatedly, mentioned earlier was Stripe, Inc). By design this is not a > fixable problem - unlike a hostname you cannot say a CA isn't allowed to > issue certs to "special" or "high profile" company names. Let's take > nissan.com, giving it an EV cert would not help a user distinguish it from > Nissan Motors because the EV cert will just say Nissan, Inc or whatever. > > These problems are both uncorrectable, by design. There is no amount of > "extra" validation a CA can do that fixes them. If a company is incorporated > with a given name a CA cannot refuse to issue an EV cert with that name. > > The only true identity for a given webpage is the URL, and many years of > effort have gone into getting users to look at the address bar to verify they > are where they think they are. Modern browsers highlight the one part that > matters (the hostname) to further help users verify this. EV certs only serve > to confuse this by inserting an additional string the the url bar, or by > randomly (from the PoV of the user) overloading the padlock with different > colors. *** > --Oliver I don't think using the URL alone to make trust decisions is enough for a user to determine whether or not to trust a website. On this point, Google and I seem to be in agreement. "People have a really hard time understanding URLs," says Adrienne Porter Felt, Chrome's engineering manager. "They’re hard to read, it’s hard to know which part of them is supposed to be trusted, **and in general I don’t think URLs are working as a good way to convey site identity.** So we want to move toward a place where web identity is understandable by everyone—they know who they’re talking to when they’re using a website and they can reason about whether they can trust them. But this will mean big changes in how and when Chrome displays URLs. We want to challenge how URLs should be displayed and question it as we’re figuring out the right way to convey identity." https://www.wired.com/story/google-wants-to-kill-the-url/ ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
Last week I posted reasons why Mozilla shouldn’t remove the EV UI from Firefox. In addition to the discussion on how the EV UI can inform users when a website does or does not have confirmed identity before they choose to type in their password or credit card number (after a little user training), I also mentioned that EV certificate Subject information (organization name, etc.) is currently used by browser phishing filters and by anti-phishing services. I was then asked to corroborate that, and so I have communicated with some of our sources (the Labor Day holiday has slowed things down) to ask them for an authorized statement. As some have suggested on this list, there may be reluctance by some services that use EV cert data to repeat on a public list what they have told us in private over the years both for competitive reasons and also to avoid giving phishers clues as to how to beat their algorithms. However, I did receive authority to post the following statement from someone who works for a major browser phishing filter (but without disclosing the person's name or company). Here is the authorized statement: “A browser phishing filter representative has confirmed that (1) their research teams do look at EV certificate attributes and do feel there is signal there for phish/malware detection, and (2) they would like to have continued access to this EV data.” I think this establishes the point I made last week – that EV data is valuable for anti-phishing efforts and so EV should be supported by the browsers. I’m still concerned that removing the EV UI in Firefox could cause some EV sites to stop using EV certificates which in turn would eliminate the availability of their EV website data from the security ecosystem. This possible adverse outcome should be considered by Mozilla before it removes its EV UI. If and when I am authorized to post more statements from others, I will. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Friday, August 30, 2019 at 11:38:55 AM UTC-7, Peter Bowen wrote: > On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > I'll just reiterate my point and then drop the subject. EV certificate > > subject information is used by anti-phishing services and browser phishing > > filters, and it would be a loss to the security ecosystem if this EV data > > disappears (meaning that the decision on removal of the EV UI has greater > > repercussions than just whether or not users can tell in the primary UI if > > their website does or does not have any confirmed identity information). > > > > Kirk, > > I have to admit that the first time I ever heard of browser phishing > filters and Internet security products (such as Trend Micro, Norton, > Mcafee, etc) differentiating between DV and EV SSL certificates as part of > their algorithm is in this thread, from you. As someone who has a website, > I would really appreciate it if you could point to where this is > documented. This morning I looked at a couple of network security vendor > products I've used and couldn't find any indication they differentiate, but > if there are ones that do it would certainly influence my personal decision > on the kind of certificates to use and to recommend others to use. > > I'm not personally aware of anyone doing this. Are you aware of any > product literature that discusses this? > > Thanks, > Peter I have some emails out asking permission to share information that was given to us in the past. If I receive permission, I will post something further. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
> OK, I'll try one last time to see if you are willing to share Google > information that you have with this group on the question at hand (Do browser > phishing filters and anti-virus apps use EV data in their anti-phishing > algorithms). > > This is super easy, and doesn't even require you to do any work, like > contacting Google Safe Browsing and asking them to participate in this > conversation. > > Here's the question, and all I'm asking you to do is answer "Yes," "No," or > "I Don't Know" > > **Based on your personal knowledge, does Google Safe Browsing use any EV > certificate Subject information in its anti-phishing algorithms?** > > This will be useful information to everyone on this list. > > Thanks for your cooperation. I want to withdraw the question above that I posed to Ryan - I posted this last night in frustration, but I was wrong to put someone on the spot like that. I'll just reiterate my point and then drop the subject. EV certificate subject information is used by anti-phishing services and browser phishing filters, and it would be a loss to the security ecosystem if this EV data disappears (meaning that the decision on removal of the EV UI has greater repercussions than just whether or not users can tell in the primary UI if their website does or does not have any confirmed identity information). I hope Mozilla will pivot to a redesigned EV UI (instead of removing it entirely) like the Apple UI (green lock and URL when EV identity is present, black lock symbol/UI for anonymous sites). That solution (1) seems to satisfy the concerns Mozilla started with (that users don't understand specific ownership data presently shown in the Firefox UI), (2) allows users to know the identity status of a website before they enter their password or credit card number, (3) would allow for easy user training on the meaning of the new Firefox UI, (4) would continue to incentivize enterprise website owners to continue using EV certificates, thereby continuing to populate the security ecosystem with very useful data related to website domains that can be used for anti-phishing purposes, (5) work very well in a mobile environment where space is limited, (6) probably represent a modest engineering effort to make the change and maintain it, and (7) start the process of creating a common UI among different browsers (Apple is there already), which can only be good for user security. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 6:15:44 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > What the heck does it mean when sometimes you say you are posting "in a > > personal capacity" and sometimes you don't? > > > It sounds like you were very prescient in your inability to remember > things, as you mentioned at > https://groups.google.com/d/msg/mozilla.dev.security.policy/cCeLZuxAOvQ/iM1cbmxjDgAJ > > Hope that helps explain how things work. I sometimes include it to help jog > the memory of folk who tend to forget, so sorry that the extra reminder > sounds like it might have confused you. > > > > does GSB use any EV certificate identity data in its phishing algorithms. > > My understanding is that the answer is yes, > > > > That's a good question, but I'm not sure where your understanding came > from! I was hoping you could share more, since that would definitely be the > easiest way to confirm it. It sounds like you're not sure, and you don't > have any evidence handy. If you can find out more information, can you > report back? It seems like you have some contacts or some information that > led you to your conclusion, I'm sure there is no one more effective or > efficient at finding an answer than you. > > I've never heard of that, so of course, I wouldn't know where to start. On > the other hand, if you're not sure, it might be clearer not to definitively > state that's how things work, or presume they work? That might make it a > bit clearer about what's real and what's imagined, in case you're just > misremembering things. After all, if you don't know, and I don't know, and > no one else here knows, maybe it's worth focusing on the things we do know > instead of speculating? > > The information I have about use of EV identity data for anti-phishing > > algorithms was all provided in private communications, so I would not be > > able to name any names without permission. I have already emailed two > > people about this, > > > > Great! Then it sounds like we're on track to having you report back once > you know more. I look forward to hearing how they've solved this, as it > sounds like EV might have be valuable even when the UI isn't shown. That > would be great validation that you don't need to show prominent UI to get > user benefit. OK, I'll try one last time to see if you are willing to share Google information that you have with this group on the question at hand (Do browser phishing filters and anti-virus apps use EV data in their anti-phishing algorithms). This is super easy, and doesn't even require you to do any work, like contacting Google Safe Browsing and asking them to participate in this conversation. Here's the question, and all I'm asking you to do is answer "Yes," "No," or "I Don't Know" **Based on your personal knowledge, does Google Safe Browsing use any EV certificate Subject information in its anti-phishing algorithms?** This will be useful information to everyone on this list. Thanks for your cooperation. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 5:28:29 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote: > > > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > > Could you point to the browsing phishing filters and anti-phishing > > > > services > > > > > that do? It might be an opportunity for you to find out how they deal > > > > with > > > > > this, and report back, so we don't have to presume anything. > > > > > > > > Let's hear directly from the experts - can you get someone from Google > > > > Safe Browsing to post to this list, and then we can all ask him or her > > our > > > > questions and get the definitive answers. Thanks. > > > > > > > > > I think it’s a great idea to hear from the experts! > > > > > > So far, it’s hard to tell who they are, because you haven’t been able to > > > provide any details about who does what you describe. It sounded > > initially > > > like a hypothetical, but now that you’ve stated it’s factual, perhaps you > > > could provide sources? And then ask folks at those organizations and > > report > > > back? It seems that you’re passionate about this, and I can’t think of > > > anyone better suited to demonstrate whether or not this actually happens > > > than someone as passionate for the truth as you. I’m sure you’ll be able > > to > > > find out whether or not the world works like you described and report > > back > > > to us all. > > > > > > Look forward to hearing more about who actually does this, and how they > > > solve the very obvious security risks. I’m assuming that if we don’t hear > > > back, it might mean no one actually does this, or that perhaps no one has > > > solved this obvious security issues. > > > > Uh... Ryan... some of the experts work down the hall from you. Google > > Safe Browsing. This was the question I posed to you: > > > > "Can you get someone from Google Safe Browsing to post to this list, and > > then we can all ask him or her our questions and get the definitive > > answers." > > > > What is your response? > > > > Oh, I thought I made it clear, I'm posting in a personal capacity. > > As you're the one making the claim, I was hoping you might demonstrate > whether there's any truth. I certainly wouldn't want to bother anyone just > because someone on the Internet said something. I'm sure no one would get > any work done if they had to respond to everyone who had a half-baked idea > about how things might work. > > Of course, that also wouldn't help answer the question I asked of you, in > the context of what you claimed: > "Could you point to the browsing phishing filters and anti-phishing > services that do? It might be an opportunity for you to find out how they > deal with this, and report back, so we don't have to presume anything." > > What is your response? What the heck does it mean when sometimes you say you are posting "in a personal capacity" and sometimes you don't? To me, it always appears that your postings on the Mozilla list are always the same as your postings on the CA/Browser Forum list and are always for the purpose of promoting Google's policies and objectives. Is there really a difference? Ryan, seriously - please (acting in a personal capacity, or in an official capacity, you choose) pull in a Google Safe Browsing expert so we can all get some answers on this fairly important question - does GSB use any EV certificate identity data in its phishing algorithms. My understanding is that the answer is yes, but there is an easy way to confirm that (or change that) by talking to a Google Safe Browsing expert, and it's in your hands. The information I have about use of EV identity data for anti-phishing algorithms was all provided in private communications, so I would not be able to name any names without permission. I have already emailed two people about this, but if you're not even willing to put this group in contact with GSB or provide any information from GSB (either yes or no on whether GSB uses EV cert identity information), then I'm not going to bother any further. Your unwillingness to help the group on this list get that information from GSB speaks volumes. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > Could you point to the browsing phishing filters and anti-phishing > > services > > > that do? It might be an opportunity for you to find out how they deal > > with > > > this, and report back, so we don't have to presume anything. > > > > Let's hear directly from the experts - can you get someone from Google > > Safe Browsing to post to this list, and then we can all ask him or her our > > questions and get the definitive answers. Thanks. > > > I think it’s a great idea to hear from the experts! > > So far, it’s hard to tell who they are, because you haven’t been able to > provide any details about who does what you describe. It sounded initially > like a hypothetical, but now that you’ve stated it’s factual, perhaps you > could provide sources? And then ask folks at those organizations and report > back? It seems that you’re passionate about this, and I can’t think of > anyone better suited to demonstrate whether or not this actually happens > than someone as passionate for the truth as you. I’m sure you’ll be able to > find out whether or not the world works like you described and report back > to us all. > > Look forward to hearing more about who actually does this, and how they > solve the very obvious security risks. I’m assuming that if we don’t hear > back, it might mean no one actually does this, or that perhaps no one has > solved this obvious security issues. Uh... Ryan... some of the experts work down the hall from you. Google Safe Browsing. This was the question I posed to you: "Can you get someone from Google Safe Browsing to post to this list, and then we can all ask him or her our questions and get the definitive answers." What is your response? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > In this case, the use of EV certificates, and the presumption of > > > reputation, would lead to actively worse security. > > > > > > Did I misunderstand the scenario? > > > > Don't argue with me, argue with the browser phishing filters and > > anti-phishing services who do, in fact, use EV website information to > > protect users as I described. Presumably they know what they are doing. > > > Sorry that it sounded like I'm arguing. I'm just trying to understand the > premise, since it so obviously has security holes that would make EV > certificates more dangerous for any user who relied on such services. > > Could you point to the browsing phishing filters and anti-phishing services > that do? It might be an opportunity for you to find out how they deal with > this, and report back, so we don't have to presume anything. Let's hear directly from the experts - can you get someone from Google Safe Browsing to post to this list, and then we can all ask him or her our questions and get the definitive answers. Thanks. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 12:17:22 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > Sure, I’m happy to explain, using Bank of America as an example. > > > Kirk, > > Thanks for providing this example. Could you help me understand how it > helps determine that things are safe? For example, the reputation system > you described, which is more akin to code signing than what is generally > practiced an anti-phishing, seems like if it was implemented, it would > leave users at significant risk from compromise on EV sites. That is, if an > EV-using site was compromised and displayed a phishing form, the fact that > it had "good" reputation would actually be actively harmful to users > security, because it would make it harder to provide timely responsiveness. > That is, it would be a false negative. > > In this case, the use of EV certificates, and the presumption of > reputation, would lead to actively worse security. > > Did I misunderstand the scenario? Don't argue with me, argue with the browser phishing filters and anti-phishing services who do, in fact, use EV website information to protect users as I described. Presumably they know what they are doing. And go argue with Facebook, which has just decided that binding confirmed identity information to Facebook posts will help in combating fraud, fake identities, foreign powers, etc. Presumably they also know what they are doing. There's also a difference between EV code signing and EV websites. For EV code signing, this creates a permanent artifact associated with the signed code that helps applications decide whether or not to trust the code - and it has become a de facto requirement in some environments. For EV certificates, the appeal for website owners over the past 10 years has been that they get a distinctive EV UI that they believe protects their consumers and their brands (again, don't argue with me but argue with them - but these website owners include many of the top enterprises and brands, so presumably they are smart people too with significant technical skills and have made their own EV decisions on a rational basis, even if you disagree with them or have a different commercial interest in supporting or not supporting website identity). EV identity information as used by phishing filters and anti-phishing services is an *incidental* benefit (but a huge one), and is not a benefit that most EV website owners are focused on - and website owners may not be willing to continue using EV certs for their websites for this incidental anti-phishing benefit alone if the EV UI goes away. So again - why don't Mozilla and Chrome move to the simple, binary Apple UI which tells users at a glance whether or not the site has been identified (green URL and lock symbol, yes / black URL and lock symbol, no) so users can be informed and make their own decisions, instead of making the EV and DV UIs the same and hiding EV information from users. And please conduct one more Google research paper - but this time, don't just ask users what they *know* about the Chrome UI (and then show them websites without any training or other information - the Chrome UI has changed so often in recent years that no one knows what it means anymore - from green "Secure" for DV phishing sites until last year, to turning the EV UI gray). Instead, research what users *can* know with 30 seconds of training. I'll bet the Apple binary UI (identity / no identity) will be easy for users to understand. Now that would be research worth using. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote: > On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote: > > This string is about Mozilla’s announced plan to remove the EV UI from > > Firefox in October. Over time, this will tend to eliminate confirmed > > identity information about websites from the security ecosystem, as EV > > website owners may decide it’s not worth using a n EV certificate if > > browsers decide to hide the data from users. As noted in my last > > message, this will be a tragedy for users, as browser phishing filters > > and other anti-phishing services currently rely on website EV data in > > their algorithms for protecting users. > > Can you provide more detail (preferably with citations) about how browser > phishing filters, and specifically Google Safe Browsing (used by Firefox), > rely on EV data? > > It's not clear to me how this could possibly be useful in detecting phishing > given the data that you've previously published[1] showing that an extremely > small number sites with EV certificates were detected as phishing. > > Jonathan > > [1] > https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf Sure, I’m happy to explain, using Bank of America as an example. The EV data securing the domain www.bankofamerica.com is as follows: CN = www.bankofamerica.com SERIALNUMBER = 2927442 OU = eComm Network Infrastructure 2.5.4.15 = Private Organization O = Bank of America Corporation 1.3.6.1.4.1.311.60.2.1.2 = Delaware 1.3.6.1.4.1.311.60.2.1.3 = US L = Chicago S = Illinois C = US This data uniquely and unambiguously identifies the owner of the domain as “Bank of America Corporation”, a Delaware, US corporation with the Delaware registry serial number 2927442 – no other corporation in the world can get that place of incorporation and serial number. There’s no “Stripe” problem here – even if a phisher or academic could create a new corporation in another state (e.g., Kentucky) in the name of “Bank of America Corporation” and then get an EV cert, it would show state of incorporation as Kentucky and show a different serial number –it’s easy for phishing algorithms to notice the difference and know these are not the same organization who own the websites. Phishing services tend to capture and retain this kind of website identity information and use it in their algorithms to create a “reputation” for specific domains and for specific organizations named in EV certificates that they re-use later. Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose it’s only secured by a DV certificate. In that case, this is the only certificate information available to the anti-phishing service: CN = bankofamerica-alerts.com That could be a site owned by the real Bank of America, or owned by a phisher – who knows, as there is no identity information available about the site. So a phishing service would be very cautious. Now suppose the new website “bankofamerica-alerts.com” is instead secured by an EV certificate. The certificate identity information for that site would be as follows: CN = bankofamerica-alerts.com SERIALNUMBER = 2927442 OU = eComm Network Infrastructure 2.5.4.15 = Private Organization O = Bank of America Corporation 1.3.6.1.4.1.311.60.2.1.2 = Delaware 1.3.6.1.4.1.311.60.2.1.3 = US L = Chicago S = Illinois C = US Only the CN field would be different from the EV certificate securing www.bankofamerica.com. Anti-phishing services will notice this similarity, and will likely rely on the “reputation” already established for the site www.bankofamerica.com (and for the organization “Bank of America Corporation, Delaware serial number 2927442”) and so feel confident based on that good reputation that the new EV website “bankofamerica-alerts.com” is unlikely to be a phishing site. This helps speed up decisions on which sites are likely safe for users and which should be flagged for phishing. Anti-phishing algorithms like lots of data, particularly strongly confirmed data like EV data. Website owners who use EV certificates today do so because they believe EV certs protect their customers and their brands, chiefly through the EV UI. If the browsers eliminate the EV UI and hide identity data from users, over time website owners may stop using EV certificates, and the EV identity data will disappear from the security ecosystem – a real loss. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
This string is about Mozilla’s announced plan to remove the EV UI from Firefox in October. Over time, this will tend to eliminate confirmed identity information about websites from the security ecosystem, as EV website owners may decide it’s not worth using a n EV certificate if browsers decide to hide the data from users. As noted in my last message, this will be a tragedy for users, as browser phishing filters and other anti-phishing services currently rely on website EV data in their algorithms for protecting users. It’s interesting to note that others in the security ecosystem, such as Facebook, are going exactly the opposite direction from Mozilla to deal with fraudsters operating under false names or posting anonymously (like phishers do), and are now actually *requiring* the use of third-party confirmed identity information before they are allowed to use Facebook’s platform. I include a link to today’s New York Times article on Facebook’s policy changes [1], and also Facebook’s actual announcement of the new rules requiring identity confirmation before posting. [2] I hope Mozilla will reconsider its plan to remove the EV UI and instead work on a better, more streamlined design for a new Firefox UI that tells users when confirmed identity is present, and when it is not. Apple seems to be handling this UI challenge well – just compare the UI on an iPhone for apple.com (green lock symbol, green URL for EV identity) to the UI for mozilla.org (black lock symbol, black URL for DV). Easy for users to see the difference, no need for users to scrutinize the actual EV identity information (unless they want to), tells users in a simple, binary way whether or not the website has confirmed identity behind it or is anonymous. And it fits nicely on mobile devices like iPhones – I assume Firefox is going to continue to show users at least what URL they’re at (like now), so that copying the Apple UI instead of the Chrome UI seems like it would be a relatively easy engineering task. By making the Mozilla and Apple UIs the same, we would also be taking a step forward in standardization of browser UIs, which makes it easier to educate users on how to understand what the UI means – something we should all support. @Mozilla – please give Facebook’s announcement on the importance of identity some consideration before you make a final decision on changing the Firefox UI. *** Facebook Announcement: Updates to Ads About Social Issues, Elections or Politics in the US People should know who is trying to influence their vote and advertisers shouldn’t be able to cover up who is paying for ads. That’s why over the past few years, we’ve made important changes to help ensure more transparency and authenticity in ads about social issues, elections or politics. Today, we’re sharing additional steps we’re taking to protect elections and prepare for the US 2020 election. Those steps include strengthening the authorization process for US advertisers, showing people more information about each advertiser and updating our list of social issues in the US to better reflect the public discourse on and off Facebook. New Disclaimer Requirements In 2018, we started requiring advertisers to get authorized before running ads about social issues, elections or politics. We also save those ads in an Ad Library so they’re publicly available for seven years. The authorization process already requires advertisers in the US to provide identification to confirm who they are and where they are located. Advertisers must also place a “Paid for by” disclaimer on their ads to communicate who is responsible for them. Despite these requirements, there are a number of cases where advertisers have attempted to put misleading “Paid for by” disclaimers on their ads. That’s why, starting mid-September, advertisers will need to provide more information about their organization before we review and approve their disclaimer. If they do not provide this information by mid-October, we will pause their ads. While the authorization process won’t be perfect, it will help us confirm the legitimacy of an organization and provide people with more details about who’s behind the ads they are seeing. Advertisers will have five options for providing more information, three of which demonstrate they are registered with the US government. If they choose one of the three government resource options, they will be allowed to use their registered organization name in disclaimers and the “i” icon that appears in the upper right-hand corner of their ads will read “Confirmed Organization.” In addition to providing their US street address, phone number, business email and a business website matching the email, they must provide one of the following: 1. Tax-registered organization identification number (i.e. EIN) 2. A government website domain that matches an email ending in .gov or .mil 3. Federal Election Commis
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
Most of the comments against EV certificates on this list have been focused on whether or not the current Firefox EV UI is relied on by Firefox users to make security decisions. (Actually, I have only seen a Google paper on this issue in Chrome, no research from Firefox.) But there is an ecosystem of anti-phishing browser filters (e.g., Google Safe Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as well as others that use the current identity information in EV certs to make better determinations of positive and false positive phishing sites and thereby protect users, as well as for other user security purposes. Many on this discussion would like to see EV certs disappear entirely and move all websites to DV certs. But remember, if EV certs disappear, so does all the EV identity information that’s being used today by security software to protect users. So my question to those who want EV certificates to disappear is this: OK, then what is *your* plan for protecting users? Browser filters will be weaker without EV information (and some browser filters today miss 20% of phishing sites at zero hour, according to NSS studies). How will you replace the EV information that’s being used today by phishing filters and services to protect users? Any decision on removing the EV UI in Firefox should consider all the related impacts on user security, and not just focus on a single issue (namely, “Do users rely on the EV UI?”), especially when the current Firefox EV UI is doing no harm. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
