Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 9, 2019, at 4:21 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/9/2019 3:17 PM, Paul Walsh wrote:
>>> On Oct 9, 2019, at 3:06 PM, Ronald Crane via dev-security-policy 
>>>  wrote:
>>> 
>>> On 10/9/2019 2:24 PM, Paul Walsh via dev-security-policy wrote:
>>> it indefinitely.
 [PW] Here’s the kink Ronald. I agree with you. Mozilla’s decision to 
 implement DoH is going to make everything much worse for the security 
 world - it’s insanely bad 
>>> This is off-topic.
>> [PW] I agree. But no more off-topic than URL shortening services, security 
>> systems for phishing detection and other aspects of this conversation. So 
>> let’s go back to talking about Firefox UI/UX for website identity.
> 
> Huh? I understand the conversation to be about phishing, and URL-shortening 
> services are relevant to phishing. DoH is not relevant to phishing unless 
> it's spectacularly-incorrectly designed.

[PW] My point is this - a massive number of security solutions will become 
useless thanks to DoH. I don’t know if they can all be updated to work, but I 
know it will require a lot of work. Browser changes have a massive impact on 
other stakeholders who are also responsible for keeping society safe from harm 
while using the internet. 

> 
 Incumbent security systems do help to provide a “dent” in the problem. But 
 the dent isn’t good enough as per my previous commentary.
 
 As far as I can tell, absolutely nothing different has been tested in the 
 past 10 years (sure, AI and other fancy words have been added, but not 
 really helping much). Attacks and breaches are increasing, not decreasing.
 
 If Firefox had a new separate icon for website identity it would be the 
 single biggest improvement to internet safety we’ve seen in the past 10 
 years - way bigger than encryption - in my opinion - I don’t have data to 
 substantiate that particular assertion.
>>> Since a foundation-supported whitelist would work without much user 
>>> training or intervention, I'd suspect it'd work better than any UI. But 
>>> that, also, is supposition.
>> [PW] If you don’t have any UI, how does the whitelist work? According to 
>> your theory the existing system works.
> 
> I was a little imprecise. I meant that there would be no positive indicator. 
> The UI would be similar to the scare-screen that FF uses to warn about cert 
> problems. Users wouldn't see it unless they tried to visit a site not listed 
> in the whitelist. Thus it would require less user training and intervention 
> than a positive indicator. It would not be invulnerable, of course. Phishers 
> would attempt to train users to ignore it. But they would do that for any 
> positive indicator, as well. The scare-screen has the advantage of being 
> in-your-face scary, so I intuit (no data to support this idea) that it'd be 
> more effective than any positive indicator.

[PW] I love this concept Ronald. We haven’t yet launched a mobile solution 
designed with this in mind because we haven’t classified enough domains, 
sub-domains and social media accounts. We’ve verified more than the total 
number of EV certs on the market, but it’s still not even close enough to 
execute your UX recommendation. Most people would get too upset with that UX. I 
love it, but it’s not quite there yet. It would likely work better for 
enterprises as it’s a more flexible version of URI-based “Zero Trust”. 

It is possible to train people to look for a new indicator - in the same way 
you can train them to use a new feature or icon for other things. 


> 
>> Whitelist = EV certificates.
> 
> No "=". EV certs would be one input of several. Many authentic domains 
> lacking EV certs are well-known and would be included in the whitelist. Any 
> domain already on a well-run blacklist (e.g., GSB) would *not* be included in 
> the whitelist. Any domain that appears to be phishing would be submitted for 
> verification to the appropriate contact(s) of the domain(s) that it appeared 
> to be phishing (e.g., "microsftpaypal.com" would get submitted to both MS and 
> Paypal). Pending verification, it would not be added to the whitelist. The 
> whole thing would be run by a well-trusted foundation (e.g., Mozilla) so 
> there's no need for complex reputation-based distributed review systems, 
> cryptotokens, etc.

Yes I like all of this. My intention was to tease out, the fact that we are in 
agreement on more than one might have first concluded. You see, I think most 
people assume I’m a “CA lover” when I talk about website identity. Fact is, I 
think some are good, some are not good - just like any other type of 
company/solution. This is like a political debate. As soon as you’re in favor 
of one thing, you must be in favor of all things on that side of the debate. 
Thank you for providing me with an opportunity to say this. 


> 
>> I provided data and insight to how website identity UI can work
> Please cite a 

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 9, 2019, at 4:19 PM, Peter Gutmann  wrote:
> 
> Paul Walsh via dev-security-policy  
> writes:
> 
>> The data suggests that automatically issued DV certs for free is a favorite
>> for criminals.
> 
> True, but that one's just an instance of Sutton's Law, they go for those
> because they're the least effort.  I was at a talk yesterday by a pen-tester
> who talked about phishing CEOs and the like and a throwaway comment he used at
> one point was "we got a cert [for their phishing site] from Let's Encrypt". It
> was completely casual, just a built-in part of the process, because the years
> of training people to look for the padlock/ green bar/dancing unicorns means
> that that's what the bad guys do to make the phish look more convincing. If
> Let's Encrypt didn't exist, the phrase would have been "we bought a cheap cert
> from GoDaddy".  If browsers only allowed EV certs, it would have been "we
> bought an EV cert through a shell corporation" or "... from an underground
> market”.

I don’t disagree with any of this. But you’re responding to one point I made. 
When it’s taken in context of other points it has more meaning. I’ll even add 
to it Peter to further your point and my support for it… If every mainstream 
browser implemented a great icon for website identity and almost all consumers 
relied on it, the risk of EV certs being obtained by threat actors would 
increase. This is why I have also said that I think CAs would need to “tighten 
up their belts” when it comes to their processes for verification and 
revocation. 

My point still stands in regards to the need for new UI for website identity 
because everyone relies on the lock on dangerous websites. 

Right now, there is *NO* bar for criminals - zero. We’ve done the opposite to 
what we could have done with email spam decades ago - charge such a small 
amount to send an email that it would increase the cost of spam. Not saying it 
would work but you get my point. 

> 
> Point is, once you've got some universally-recognised signalling mechanism
> that a site is OK, it'll be used by the bad guys to make their attacks totally
> convincing, whether it's DV certs, EV certs, free certs, expensive certs, or
> whatever.

I agree. But also Peter, there are new blockchain-based solutions for “KYC” 
(know your customer) that can be used in conjunction with existing processes, 
couple with a few additional techniques. I’d do this if I were running a CA 
that charges for website identity, but I don’t. 

> 
>> I can’t add any more evidence to prove that something needs to be done about
>> Let’s Encrypt as an entire initiative is an overall failure in my opinion.
> 
> It's actually been phenomenally successful.  Browsers won't allow you to
> encrypt a connection without a certificate, and Let's Encrypt enables that. It
> hands out magic tokens to turn on encryption in browsers, nothing more,
> nothing less, and it's been very successful at that.

Perhaps you can comment on the cost of this greatness? I’ve cited a lot of 
stats that suggest everyone has a friend, colleague or family member who has 
been  victim of an attack of some kind, either directly or indirectly thanks to 
Let’s Encrypt SSL certificates - notwithstanding everything we agree on above. 
I have personally spoken to people who have lost their entire lifes savings in 
a phishing attack because they relied on the padlock - which almost certainly 
was issued by Let’s Encrypt - who could have had checks to reduce the risk - 
not necessarily completely mitigate it. 

Right now they do absolutely nothing in the same way 4chan and 8chan were 
amazing for freedom of speech but... That’s not ok. We all have an obligation 
to try to reduce the risk of our technology being used for bad. Now we’re down 
the rabbit hole of another topic - but it is important to discuss as it gets to 
the heart of the lack of research by anyone who is advocating for HTTPS 
EVERYWHERE and the negative impact it’s having thanks to the lack of UI for 
website identity. 

- Paul


> 
> Peter.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/9/2019 3:17 PM, Paul Walsh wrote:

On Oct 9, 2019, at 3:06 PM, Ronald Crane via dev-security-policy 
 wrote:

On 10/9/2019 2:24 PM, Paul Walsh via dev-security-policy wrote:
it indefinitely.

[PW] Here’s the kink Ronald. I agree with you. Mozilla’s decision to implement 
DoH is going to make everything much worse for the security world - it’s 
insanely bad 

This is off-topic.

[PW] I agree. But no more off-topic than URL shortening services, security 
systems for phishing detection and other aspects of this conversation. So let’s 
go back to talking about Firefox UI/UX for website identity.


Huh? I understand the conversation to be about phishing, and 
URL-shortening services are relevant to phishing. DoH is not relevant to 
phishing unless it's spectacularly-incorrectly designed.



Incumbent security systems do help to provide a “dent” in the problem. But the 
dent isn’t good enough as per my previous commentary.

As far as I can tell, absolutely nothing different has been tested in the past 
10 years (sure, AI and other fancy words have been added, but not really 
helping much). Attacks and breaches are increasing, not decreasing.

If Firefox had a new separate icon for website identity it would be the single 
biggest improvement to internet safety we’ve seen in the past 10 years - way 
bigger than encryption - in my opinion - I don’t have data to substantiate that 
particular assertion.

Since a foundation-supported whitelist would work without much user training or 
intervention, I'd suspect it'd work better than any UI. But that, also, is 
supposition.

[PW] If you don’t have any UI, how does the whitelist work? According to your 
theory the existing system works.


I was a little imprecise. I meant that there would be no positive 
indicator. The UI would be similar to the scare-screen that FF uses to 
warn about cert problems. Users wouldn't see it unless they tried to 
visit a site not listed in the whitelist. Thus it would require less 
user training and intervention than a positive indicator. It would not 
be invulnerable, of course. Phishers would attempt to train users to 
ignore it. But they would do that for any positive indicator, as well. 
The scare-screen has the advantage of being in-your-face scary, so I 
intuit (no data to support this idea) that it'd be more effective than 
any positive indicator.



Whitelist = EV certificates.


No "=". EV certs would be one input of several. Many authentic domains 
lacking EV certs are well-known and would be included in the whitelist. 
Any domain already on a well-run blacklist (e.g., GSB) would *not* be 
included in the whitelist. Any domain that appears to be phishing would 
be submitted for verification to the appropriate contact(s) of the 
domain(s) that it appeared to be phishing (e.g., "microsftpaypal.com" 
would get submitted to both MS and Paypal). Pending verification, it 
would not be added to the whitelist. The whole thing would be run by a 
well-trusted foundation (e.g., Mozilla) so there's no need for complex 
reputation-based distributed review systems, cryptotokens, etc.



I provided data and insight to how website identity UI can work

Please cite a specific URL of a paper showing the data on this. It should have 
a description of its hypothesis, methods, and quantitative results data. 
Something like that really could help push this conversation forward. Please do 
not cite marketing papers like 
https://www.metacertprotocol.com/assets/metacert_white_paper.pdf .

[PW] I’m confused. I never cited that paper. There is zero evidence to suggest 
that the paper we wrote can or will success. We believe it can and will, but 
there’s no evidence in there. Why are you asking me not to cite something that 
I didn’t cite.

I did however, provide a massive amount of data and referenced many companies I 
would consider to be a competitor of sorts. If you go through the threads you 
will also see company-specific data on a product but that’s not even referenced 
in the old white paper to which you refer. That’s not even our company website 
- it’s a blockchain project.

I'm confused. You said that "I provided data and insight to how website identity UI can work" and  
"I did however, provide a massive amount of data..." then when I asked for a paper showing the data 
(on the effectiveness of "how [your proposed] website identity UI can work") and how you got it -- 
so I can understand what you're proposing and what effect it might have -- you seem to have told me that 
there's no paper to cite?

There’s so much text/data in my previous messages that if you copied and pasted 
it into a document and then PDF’d it, you’d have a paper.
By "paper", I mean a document that (1) proposes a testable hypothesis; 
(2) describes the methods its authors used to test the hypothesis; (3) 
describes the results, ideally including links to raw data; and (4) 
summarizes the highlights and briefly discusses any implications. Read 
anything in 

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/8/2019 7:04 PM, Paul Walsh via dev-security-policy wrote:

On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy 
 wrote:

On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:

On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
 wrote:

[snip]

Some other changes that might help reduce phishing are:
1. Site owners should avoid using multiple domains, because using them 
habituates users to the idea that there are several valid domains for a given 
entity. Once users have that idea, phishers are most of the way to success. 
Some of the biggest names in, e.g., brokerage services are offenders on this 
front.

[PW] Companies like Google own so many domains and sub-domains that it’s 
difficult to stay ahead of them. I think this is an unrealistic expectation. So 
if other browser vendors have the same opinion, they should look inward.

It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to use only 
"www.blahblahinvestments.com" for everything related to its retail investment 
services. It *is* unreasonable to habituate users to bad practices.

[PW] I hear you Ronald. And I agree. My point was that it’s unrealistic for us 
to expect this pattern of domain use to change. I can’t see how any stakeholder 
can force or encourage organizations to use a single domain name or even a 
small number of them for a given purpose. So there’s little point in directing 
energy to something we can’t change.
Absent regulation, there's no "force". However, the formal adoption of 
best practices, perhaps via an RFC, could help gradually to clean up the 
namespace, and to install other good practices in place of the many bad 
practices that currently are training users to do unsafe things.

2. Site owners should not use URL-shortening services, for the same reason as 
(1).
[PW] ...We can try to encourage companies to stop using shortening 
services, but we’re not likely to have much of an impact


Still it's worth including in a best-practices document (RFC?).

People who don’t belong to a brand or organization will continue to 
use shortening services too.

I have some ideas for shortening services. They can implement better trust. 
Example: a URL that belongs to a site with website identity verified, could 
look like https://verified.tinyurl.com/345kss or they could direct to a TinyURL 
webpage where it informs the user of the verified destination.
That's something, but it also continues to put the shortening service 
inside the security perimeter of every legitimate site that uses it. 
This is itself a Bad Thing that should be discouraged (and yes, here's 
lookin' at every website that includes JS from ad brokers, which is very 
nearly all of 'em). I understand why shortening services are useful for 
tweets, but this modest convenience shouldn't come at the cost of the 
entire web's security.

3. Site owners should not use QR codes, since fake ones are perfect for 
phishing.

Same as above. You don’t need to mask URLs to have a successful phishing 
campaign.

No, you don't "need" to do it. It is, however, a very useful weapon in 
phishers' quivers.

[PW] I totally agree. I’d like to add, of the hundred million apps with a 
WebView, many don’t display the URL at all. We also have Google’s AMP project 
which does little to help. And then we also have social media cards and 
previews where it’s possible to trick the system by displaying the og metadata 
from the real website while linking to the malicious destination. Rabbit hole…


All this stuff should specifically be called out as bad practice in the RFC.

-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/9/2019 11:02 AM, Paul Walsh via dev-security-policy wrote:

On Oct 9, 2019, at 10:42 AM, Ronald Crane via dev-security-policy 
 wrote:

On 10/2/2019 3:50 PM, Paul Walsh via dev-security-policy wrote:

[snip]

sɑlesforce[.com] is available for purchase right now.

I was going to suggest banning non-Latin-glyph domains, since they are yet another useful 
phishing weapon. FF converts all such domains into Punycode when typed or pasted into the 
address bar, though the conversion is displayed below the address bar, not in it. So your 
example becomes "http://xn--slesforce-51d.com/;.

Just providing an example of a URL that uses .com. I can provide more without 
using special characters to demonstrate the same point.

Well, I'm sure that many domains containing "salesforce" presently are unregistered, 
e.g., "salesforcecorp.com". This fact supports the idea that internet entities should 
make a concerted effort to clean up their namespaces as I noted previously. Of course, that should 
be one among many other approaches to reducing phishing….

[PW] I agree.


Elsewhere in this thread I proposed a foundation-run *whitelist* of authentic domains that browsers 
could use to warn users about potential phishing sites (e.g., "paypal.com" is in the 
whitelist, but the ~20,000 other nonauthentic domains containing "paypal" are not). This 
approach would reduce the need for users to examine domains to determine authenticity. What's your 
view on it?

[PW] I agree. And such lists exist already. At MetaCert we aggregate all open 
source lists that are available. We have our own community with a few thousand 
members who report and validate suspicious links every day,


I'm proposing a whitelist, not a blacklist, for the very reason that


...It is technically impossible to detect every new dangerous URL or website 
[and] It’s so much easier to tell someone what’s safe, than it is to detect 
what’s dangerous.


And I'm proposing that it be foundation-supported (by, e.g., a 
well-trusted source like Mozilla) so that it also can be (1) 
trustworthy; (2) cost-free to end users; (3) as private as possible; and 
(4) simple.



So, I agree with you Ronald - your suggestion is a great one. But I’m afraid it 
doesn’t solve the problem in the same way that website identity does - as I 
described previously.


I am still not clear on how presenting website identity to users reduces 
phishing so well. Can you explain? Can you point me to one of your 
papers that discusses this idea? I see, e.g., pp. 18-19 of 
https://www.metacertprotocol.com/assets/metacert_white_paper.pdf , but 
it uses very general marketing-style language ("The feedback on this 
product has been overwhelming. Cryptonite gained over 50,000 active 
users in the first six weeks of launch. Users want to remain safe when 
buying and selling crypto and our user base continues to grow") that 
doesn't help me evaluate how well it works.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 9, 2019, at 10:42 AM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/2/2019 3:50 PM, Paul Walsh via dev-security-policy wrote:
> 
> [snip]
 sɑlesforce[.com] is available for purchase right now.
>>> I was going to suggest banning non-Latin-glyph domains, since they are yet 
>>> another useful phishing weapon. FF converts all such domains into Punycode 
>>> when typed or pasted into the address bar, though the conversion is 
>>> displayed below the address bar, not in it. So your example becomes 
>>> "http://xn--slesforce-51d.com/;.
>> Just providing an example of a URL that uses .com. I can provide more 
>> without using special characters to demonstrate the same point.
> 
> Well, I'm sure that many domains containing "salesforce" presently are 
> unregistered, e.g., "salesforcecorp.com". This fact supports the idea that 
> internet entities should make a concerted effort to clean up their namespaces 
> as I noted previously. Of course, that should be one among many other 
> approaches to reducing phishing….

[PW] I agree. 

> 
> Elsewhere in this thread I proposed a foundation-run *whitelist* of authentic 
> domains that browsers could use to warn users about potential phishing sites 
> (e.g., "paypal.com" is in the whitelist, but the ~20,000 other nonauthentic 
> domains containing "paypal" are not). This approach would reduce the need for 
> users to examine domains to determine authenticity. What's your view on it?

[PW] I agree. And such lists exist already. At MetaCert we aggregate all open 
source lists that are available. We have our own community with a few thousand 
members who report and validate suspicious links every day, while also 
submitting and validating links that should be verified as safe. These all go 
into one database and served with an API that also covers 3,500+ shortening 
services. So, call the API and get a response in 270ms. But this is not good 
enough...

We eradicated phishing for the crypto world on Slack with a security 
integration in Q4 2017 - it was rampant beyond belief. As soon as a phishing 
attack was discovered, reviewed, validated and classified, messages that 
contained those links in other communities, would be auto deleted from other 
Slack. There were times when we classified scams in less than 2 minutes. We 
even have software with machine-learning capabilities listening to the Twitter 
firehose - it detects signals attributed to scams, follows the thread, finds 
the URL or digital wallet address, detects and classifies. 

BUT, we came to learn that no matter how fast we get, no matter how much tech 
and people we throw at the problem, there will always be victims. It is 
technically impossible to detect every new dangerous URL or website. 

My team and I have even written a white paper, technical paper and mathematical 
equations for a crypto token to incentivize the decentralization of the 
decision making process. This took about 18 months.

All of this, and our R into visual indicators and URL classification dating 
back to 2004 helped us to conclude that chasing after threats just isn’t 
effective enough. I would argue that we have built the most advance URL-based 
threat intelligence system by an order of magnitude as it can also classify 
folders on sites like GitHub in a way others can't - but I’m losing faith and 
conviction in the entire threat model. 

It’s so much easier to tell someone what’s safe, than it is to detect what’s 
dangerous. 

So, I agree with you Ronald - your suggestion is a great one. But I’m afraid it 
doesn’t solve the problem in the same way that website identity does - as I 
described previously. This is not a popular belief - I never seem to pick 
things that are easy. 

- Paul


> 
> -R
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 9, 2019, at 7:30 AM, Leo Grove via dev-security-policy 
 wrote:
> 
> On Tuesday, October 8, 2019 at 10:36:19 PM UTC-5, Matt Palmer wrote:
>> On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy 
>> wrote:
>>> Why isn’t anyone’s head blowing up over the Let’s Encrypt stats?
>> 
>> Because those stats don't show anything worth blowing up ones head over.  I
>> don't see anything in them that indicates that those 14,000 certificates --
>> or even one certificate, for that matter --was issued without validating
>> control over the domain name(s) indicated in the certificates.

[PW] Here are some facts from the cybersecurity world - which is completely 
impartial to browser vendors and CAs as well as “HTTPS Everywhere” advocates. 
Security companies only care about the safety and wellbeing of people who use 
the internet - it doesn’t care about personal and emotional feelings in this 
political debate. I have already provided links to every source in previous 
emails. 

93% of breaches start with phishing
Phishing increased by 250% in 2018
Phishing URLs outnumber malicious attachments five to one
91% of all phishing sites have a DV cert
95% of phishing sites with a DV cert come from Let’s Encrypt
Phishing is growing at the same rate as that of Let’s Encrypt
Phishing can only get worse

The data suggests that automatically issued DV certs for free is a favorite for 
criminals. This is 100% because consumers who are aware of the padlock, 
automatically rely on it for trust and assume they can trust the owner.

***This means most breaches happen because people look at the padlock and fall 
for Let’s Encrypt encryption.*** This should at least, stop everyone in their 
tracks to ask, “How can we encrypt the web while not making it less safe?” If 
not, your motives are all wrong in my opinion. 

If all of this doesn’t paint a bleak picture I can’t add any more evidence to 
prove that something needs to be done about Let’s Encrypt as an entire 
initiative is an overall failure in my opinion. While it’s helping to scale 
encryption for a more “private” web, it’s an existential treat to internet 
safety. 

There is a solution to this problem:

Make website identity better so consumers stop relying on the padlock for 
trust. I’ve provided data to demonstrate how this can work. I haven’t received 
any opposing views on my data/findings. And there’s no research to prove 
otherwise. 

If consumers stopped looking at the padlock all of the above would go away - 
until threat actors find another vector. It would introduce other issues to 
address - for example, CAs would need to really tighten up all of their 
processes because threat actors might buy an EV cert if the cost is worth it. 

>> 
> 
> Validation compliance is not the topic of this thread. Stripe Inc was able to 
> get their EV certificate in a compliant way after all. It sounds like since 
> 14k DV certs were issued to phishing sites in a compliant way, everything is 
> a-ok?
> 
> What are your thoughts if those 14k certs were EV? 
> 
>> EV and DV serve different purposes, and while DV is more-or-less solving the
>> problem it sets out to solve, the credible evidence presented shows that EV
>> does not solve any problem that browsers are interested in.
>> 
>>> If people think “EV is broken” they must think DV is stuck in hell with
>>> broken legs.
>> 
>> Alternately, people realise that EV and DV serve different purposes through
>> different methods, and thus cannot be compared in the trivial and flippant
>> way you suggest.
>> 
>> - Matt
> 
> You've mentioned "EV and DV serve different purposes" twice and I think that 
> is misleading. EV requires DV validation as well, and they both serve to 
> authenticate and encrypt. However, EV goes beyond authenticating only the 
> domain name which is where DV stops. EV attempts to bind the domain name to 
> an actual owner. 
> 
> People deploying EV expect to get DV and something more. When the browsers 
> stop displaying the EV UI, it will be indistinguishable from DV on cursory 
> glance. To me, this shows EV and DV serve similar purposes, but EV attempts 
> to go further in the context of authentication.

[PW] Bravo - great reminder. If people dislike the cost, process or timing, 
they should debate those things separately. I personally believe the entire EV 
process can be massively improved with very specific tools and methodologies - 
but that’s for another conversation. This is about Mozilla removing UI instead 
of making it better.

- Paul

> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Leo Grove via dev-security-policy]

On Tuesday, October 8, 2019 at 10:36:19 PM UTC-5, Matt Palmer wrote:
> On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy 
> wrote:
> > Why isn’t anyone’s head blowing up over the Let’s Encrypt stats?
> 
> Because those stats don't show anything worth blowing up ones head over.  I
> don't see anything in them that indicates that those 14,000 certificates --
> or even one certificate, for that matter --was issued without validating
> control over the domain name(s) indicated in the certificates.
> 

Validation compliance is not the topic of this thread. Stripe Inc was able to 
get their EV certificate in a compliant way after all. It sounds like since 14k 
DV certs were issued to phishing sites in a compliant way, everything is a-ok?

What are your thoughts if those 14k certs were EV? 

> EV and DV serve different purposes, and while DV is more-or-less solving the
> problem it sets out to solve, the credible evidence presented shows that EV
> does not solve any problem that browsers are interested in.
> 
> > If people think “EV is broken” they must think DV is stuck in hell with
> > broken legs.
> 
> Alternately, people realise that EV and DV serve different purposes through
> different methods, and thus cannot be compared in the trivial and flippant
> way you suggest.
> 
> - Matt

You've mentioned "EV and DV serve different purposes" twice and I think that is 
misleading. EV requires DV validation as well, and they both serve to 
authenticate and encrypt. However, EV goes beyond authenticating only the 
domain name which is where DV stops. EV attempts to bind the domain name to an 
actual owner. 

People deploying EV expect to get DV and something more. When the browsers stop 
displaying the EV UI, it will be indistinguishable from DV on cursory glance. 
To me, this shows EV and DV serve similar purposes, but EV attempts to go 
further in the context of authentication.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Matt Palmer via dev-security-policy]

On Tue, Oct 08, 2019 at 07:16:59PM -0700, Paul Walsh via dev-security-policy 
wrote:
> Why isn’t anyone’s head blowing up over the Let’s Encrypt stats?

Because those stats don't show anything worth blowing up ones head over.  I
don't see anything in them that indicates that those 14,000 certificates --
or even one certificate, for that matter --was issued without validating
control over the domain name(s) indicated in the certificates.

EV and DV serve different purposes, and while DV is more-or-less solving the
problem it sets out to solve, the credible evidence presented shows that EV
does not solve any problem that browsers are interested in.

> If people think “EV is broken” they must think DV is stuck in hell with
> broken legs.

Alternately, people realise that EV and DV serve different purposes through
different methods, and thus cannot be compared in the trivial and flippant
way you suggest.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
>> New tools such as Modlishka now automate phishing attacks, making it 
>> virtually impossible for any browser or security solution to detect -  
>> bypassing 2FA. Google has admitted that it’s unable to detect these phishing 
>> scams as they use a phishing domain but instead of a fake website, they use 
>> the legitimate website to steal credentials, including 2FA. This is why 
>> Google banned its users from signing into its own websites via mobile apps 
>> with a WebView. If Google can prevent these attacks, Mozilla can’t.
> 
> I understand that Modlishka emplaces the phishing site as a MITM. This is yet 
> another reason for browser publishers to help train their users to use only 
> authentic domain names, and also to up their game on detecting and banning 
> phishing domains. I don't think it says much about the value, or lack 
> thereof, of EV certs. As has been cited repeatedly in this thread, most 
> phishing sites don't even bother to use SSL, indicating that most users who 
> can be phished aren't verifying the correct domain.

[PW] Ronald, I don’t believe better detection and prevention is the answer for 
anti-phishing - but not trying isn’t an option, obviously. With billions of 
dollars being invested in this area, and with hundreds of millions changing 
hands through M every year, the problem is getting worse. Every week we read 
about yet another security company with anti-phishing [insert fancy words 
here]. It’s ain’t work’n. 

I believe I demonstrated in a previous message, with data and techniques, why 
it’s impossible for any company to detect every phishing URL or website. 

And I’m afraid you’re incorrect about SSL certs. According to Webroot, over 93% 
of all new phishing sites use an SSL certificate. And according to MetaCert 
it’s over 95%.

And of those with a DV cert, over 95% come from Let’s Encrypt - because they’re 
automatically issued for free and they have a near-zero policy for detection, 
prevention or cert revocation. This is why over 14,000 SSL certs were issued by 
Let’s Encrypt for domains with PayPal in it - so if you believe in better 
detection and prevention, why don’t you/we request this of Let’s Encrypt? 

Why isn’t anyone’s head blowing up over the Let’s Encrypt stats? If people 
think “EV is broken” they must think DV is stuck in hell with broken legs.

It’s impossible to properly verify the domain by looking at it - you need to 
carry out other checks. It’s simply not solving the problem. 

I provided data and insight to how website identity UI can work - I’d really 
love to hear counterarguments around that, or agreement that it’s useful. 

- Paul

> 
> -R
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:
>> On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
>>  wrote:
> [snip]
>>> Some other changes that might help reduce phishing are:
>>> 1. Site owners should avoid using multiple domains, because using them 
>>> habituates users to the idea that there are several valid domains for a 
>>> given entity. Once users have that idea, phishers are most of the way to 
>>> success. Some of the biggest names in, e.g., brokerage services are 
>>> offenders on this front.
>> [PW] Companies like Google own so many domains and sub-domains that it’s 
>> difficult to stay ahead of them. I think this is an unrealistic expectation. 
>> So if other browser vendors have the same opinion, they should look inward.
> It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to use 
> only "www.blahblahinvestments.com" for everything related to its retail 
> investment services. It *is* unreasonable to habituate users to bad practices.

[PW] I hear you Ronald. And I agree. My point was that it’s unrealistic for us 
to expect this pattern of domain use to change. I can’t see how any stakeholder 
can force or encourage organizations to use a single domain name or even a 
small number of them for a given purpose. So there’s little point in directing 
energy to something we can’t change.


>>> 2. Site owners should not use URL-shortening services, for the same reason 
>>> as (1).
>> Site owners using shortened URLs isn’t the problem in my opinion. Even if 
>> shortened URLs went away, phishing wouldn’t stop. Unless you have research 
>> to provides more insight?
> Where did I say that phishing would "stop" if URL shortening services 
> disappeared? I said avoiding them would be helpful, since it would reinforce 
> the idea that there is one correct domain per entity, or at least per entity 
> service. Probably all the entity services should be subdomains of the one 
> correct domain, but alas it will take a sustained security campaign and a 
> decade to make a dent in that problem.

[PW] I apologize if I gave the impression that you were saying something that 
you were not. That wasn’t my intention. We can try to encourage companies to 
stop using shortening services, but we’re not likely to have much of an impact. 
People who don’t belong to a brand or organization will continue to use 
shortening services too. 

I have some ideas for shortening services. They can implement better trust. 
Example: a URL that belongs to a site with website identity verified, could 
look like https://verified.tinyurl.com/345kss or they could direct to a TinyURL 
webpage where it informs the user of the verified destination.


>>> 3. Site owners should not use QR codes, since fake ones are perfect for 
>>> phishing.
>> Same as above. You don’t need to mask URLs to have a successful phishing 
>> campaign.
> No, you don't "need" to do it. It is, however, a very useful weapon in 
> phishers' quivers.

[PW] I totally agree. I’d like to add, of the hundred million apps with a 
WebView, many don’t display the URL at all. We also have Google’s AMP project 
which does little to help. And then we also have social media cards and 
previews where it’s possible to trick the system by displaying the og metadata 
from the real website while linking to the malicious destination. Rabbit hole…

>> sɑlesforce[.com] is available for purchase right now.
> 
> I was going to suggest banning non-Latin-glyph domains, since they are yet 
> another useful phishing weapon. FF converts all such domains into Punycode 
> when typed or pasted into the address bar, though the conversion is displayed 
> below the address bar, not in it. So your example becomes 
> "http://xn--slesforce-51d.com/“.
> 
>> 
>>> 4. Browser publishers should petition ICANN to revoke most of the gTLDs it 
>>> has approved, since they provide fertile ground for phishing.
>> Petitioning them won’t work. gTLDs are here to stay, even if we dislike 
>> them. Also, most phishing sites use .com and other well known TLDs. I’m not 
>> saying gTLDs aren’t used, they are. But they’re not needed.
> Of course they're not "needed" for phishing. They are, however, useful for 
> phishing.
>> So, bringing it back to Mozilla. I’d still love to see recent research/data 
>> to back up Mozilla’s decision to remove identity UI in Firefox. By promoting 
>> the padlock without education about phishing, browser vendors are actually 
>> making the web more dangerous.
> 
> I also would like to see more research.

- Paul

> 
> -R
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: [FORGED] Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:52 PM, Peter Gutmann  wrote:
> 
> Paul Walsh ​ writes:
> 
>> I would like to see one research paper published by one browser vendor to
>> show that website identity visual indicators can not work.
> 
> Uhhh... are you serious with that request?  You're asking for a study from a
> browser vendor, a group who in any case don't publish research papers but
> write browsers, indicating that their own UI doesn't work?

[PW] I see where you are coming from Peter. I wouldn’t expect any browser 
vendor to provide studies or evidence to explain why they’re implementing 
features. And separately, I wouldn’t expect Google to provide anything to 
anyone for any reason, because they pretty much do what they do for profit. 
Chrome dev is directed by advertising dollars, not by privacy or user safety. 

However, I'd love to think that the Mozilla team still care about the developer 
community and end users more than they care about profit [1] or following other 
browser vendors. Firefox isn’t the “leader” it was, but I still love the brand 
and cause.  

I’m sure you don’t need to be reminded that Mozilla is a foundation, but I 
personally wanted to remind myself of their core values. So with this in mind, 
I’d like to think that the team would stop and rethink decisions that have a 
massive impact on stakeholders and end-users. And when asked for some 
supporting evidence, they wouldn’t fall silent but engage in a meaningful 
debate.  

It has been a long time since my team or I were involved in any way, so this 
might have changed. 

[1] https://www.mozilla.org/en-US/about/ 
> 
>> I’d love you to show me the type of research I’ve asked for. I’m open to
>> learning more. I’m not new to this game. I worked on integrated browsers and
>> search engines in the 90’s at AOL.
> 
> If it's OK to cite peer-reviewed papers from universities published at
> conferences and in journals, I can dig up a few of those.

[PW] If you ever do find the time to dig them out, please do. No pressure.

- Paul

> 
> Peter.
> 
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 4:05 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/2/2019 3:27 PM, Peter Gutmann wrote:
>> Ronald Crane via dev-security-policy  
>> writes:
>> 
>>> "Virtually impossible"? "Anyone"? Really? Those are big claims that need 
>>> real
>>> data.
>> How many references to research papers would you like?  Would a dozen do, or
>> do you want two dozen?
> One well-done paper would do.
>> I'm pretty sure I haven't been phished yet.
>> How would you know?
> 
> Since most phishing appears to be financial, I would expect unauthorized 
> withdrawals from financial accounts, unauthorized credit card charges, 
> unordered packages showing up, dunning notices from the IRS because I filed 
> my tax returns with a phisher, etc. I haven't observed these indicia of 
> getting phished.

[PW] I agree that financial is a good incentive. But it’s by no means the only 
incentive. 

According to Verizon, 93% of data breaches start with phishing - to steal 
credentials. 

Here’s what happens:

Marriott Starwood Hotels, Aadhar, Exactis, MyFitnessPal and Quora were breached 
last year.
Over 2 billion records were compromised.

Most people changed their password on the site that was compromised.
Most people use the same password for many services.
Most people didn’t change their credentials on sites that weren’t compromised.
Threat actor searches a one or more databases for a company or person and buys 
their credentials. Or just buys them in bulk.
Threat actor tries the person’s credentials on internal systems or services 
with sensitive information.
Another company is comprised.
Loop.

While the media talks about hacking and breaches and other cool “cyber” terms, 
what they’re not saying, is that social engineering is at the core of many of 
these attacks. Social engineering is cheaper, quicker and easier than trying to 
find computer or network based vulnerabilities. 

The latter does happen and there are many amazing security professionals 
building systems to detect and prevent those types of attacks. I’m not one of 
them because I’m not smart enough to address those weaknesses. 

> 
>> And how does this help the other 7.53 billion people who
>> will be targets for phishers?
> Alas it doesn't. We do need better phishing prevention. Do you have a 
> suggestion?

[PW] While phishing detection and prevention is improving all the time, it will 
never be good enough. It’s much easier for a user to know that PayPal.com is 
who they think it is based on a visual indicator, than it is to detect the 
14,000 PayPal phishing sites with a Let’s Encrypt DV certificate. 

Yes, I just went there :)

- Paul


>>> In any case, have we ever really tried to teach users to use the correct
>>> domain?
>> Yes, we've tried that.  And that.  And that too.  And the other thing.  Yes,
>> that too.
>> 
>> None of them work.
> 
> Please cite the best study you know about on this topic (BTW, I am *not* 
> snidely implying that there isn't one).
> 
> -R
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updated website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

I finally got around to digesting the email below. Summary/Reminder: CA related 
data on website identity from the perspective of website owners. 

As Homer Simpson said, "70% of all reports are made up”. So, everything put 
forward by me in previous messages, or anyone else, must be taken with a pinch 
of salt. That said, data does give meaning to personal opinions. Without data, 
we’re left with just opinions.

If we set the data aside for a second, we all know (fingers crossed) that 
opening the wrong link and signing into the wrong website, is something that 
people either worry about, or should be worried about. 

I pitched a company last week. The Director of Threat Intelligence for a 
multi-billion dollar security company in Silicon Valley thought he’d prove that 
he couldn't be caught out. I wasn’t testing the room, but he jumped in and said 
"#10 is the real domain". He was wrong (unfortunately because I felt bad) - it 
was a fake. I had to explain how it wasn’t a reflection on his expertise but 
rather, an emotional state of mind at a given point in time under specific 
circumstances. What the eyes can’t see, the brain fills in [1].

This subject is so important I would love Mozilla to consider implementing a 
beta program. I’d proudly contribute. 

Here’s something we did at MetaCert, that Mozilla could do - auto classify 
regulated TLDs and gTLDs. For example, you could light up the visual indicator 
for URLs on .GOV domains - without any need for third-party interaction. This 
would make it virtually impossible for anyone to fall for a phishing scam when 
filing taxes - for example. Perhaps it would encourage the DNC (and GOP) to 
only use .GOV domains and avoid being hacked by Russians in the future. These 
are just a few use cases where there’s a potential for massive real world 
benefit.

Rather than remove website identity based on the response to poor design 
implementation, we should consider making it better. I believe website owners 
would be more likely to seek verification if they can really protect their 
brand online. And consumers would proactively look for it. 

Website identity won’t ever be perfect, but with new technologies and 
methodologies that have come out in the past 18 months, so much more can also 
be achieved by CAs and other providers, to tighten up the verification process, 
while making it faster and lower cost for customers.

[1] https://www.gla.ac.uk/news/archiveofnews/2011/april/headline_194655_en.html 


- Paul




> On Oct 2, 2019, at 5:12 PM, Kirk Hall via dev-security-policy 
>  wrote:
> 
> 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 

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/3/2019 8:44 PM, Matt Palmer via dev-security-policy wrote:

On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy 
wrote:

On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:

[snip]

I guess I wasn't specific enough. I am looking for a good study that
supports the proposition that the Internet community has (1) made a
concerted effort to ensure that there is only one authentic domain per
entity (or, at most, per entity-service, e.g, retail brokerage
services); and (2) has made a concerted effort to educate users to use
only that domain; and (3) that those steps have failed to significantly
reduce the successful phishing rate of the users that steps (1) and (2)
targeted.


Was it intentional to presume that (1) is correct or desirable? It’s
unclear if you believe it is, but if it isn’t (and for many reasons, it
isn’t), then naturally one might assume (2) and (3) don’t exist.

Yes, I do believe that (1) is desirable. It has a long history in the
context of brand identity (e.g., "Coke" in red and white script), where
virtually all consumers use it to identify authentic products and reject
counterfeits.

This is a valuable analogy, but I'm not sure how it advances the argument
you appear to be making.

To take the specific example you've provided, there is more than one product
made under the general brand of "Coke", most -- but not all -- involving the
word "Coke" in way or another.  If we take the "domain name per product"
analogy, there would be a bunch of different "domains" for these products:
coke, newcoke, cocacolaclassic, dietcoke, cokezero, vanillacoke,
caffeinefreecoke, and so on.

That's before we start considering other products produced and marketed by
the same company under different names.  There's a bunch of other carbonated
beverages, plus uncarbonated beverages, and even non-beverage foodstuffs,
that are all produced and/or marketed by the company that produces and
markets "Coke", at least in the country I'm from.


This is something of a nit, but my proposal is more along the lines of 
"one domain per entity, or per entity-service", so in this case there 
would be perhaps the single domain "cokedrinks.com", and paths or 
subdomains for Coke Classic, New Coke, etc. Or, even better, the single 
domain "coke.com" whose paths and/or subdomains house Coca-Cola's entire 
product web presence.



...
Where the analogy breaks down is that in the case of phishing, people don't
typically try to "counterfeit" the domain name, merely "confuse"...

Agree.

Basically, many internet-based entities appear to have brought phishing upon
themselves by failing to extend the above to their internet presences.
Instead, they've trained their users to accept as authentic any domain that
has a passing resemblance to their rat's-nest of legitimate domains.

While there's a certain amount of truth to that, I think quite a lot of it
is users just not checking *anything* about the link they're clicking.  The
amount of spam I get inviting me to login to various banking websites using
a link to yevgeniysflowershoppe.ua or the like would suggest that phishing
doesn't not absolutely rely on confusion.  Your hypothesis relies on the
idea that users can be trained in any meaningful fashion, which the research
seems to not support at all.


Hmm. The idea that users are untrainable seems so foreign to me. One 
reason is that, as I noted above, so many internet entities have been 
training users to do the *wrong* things. It's not just rat's-nests of 
legitimate domains. It's also non-ASCII-128 characters, thousand of 
gTLDs, JS on-click handlers that make the link destination in the 
browser's status bar unreliable, the app culture (e.g., install Joe's 
Gas Station app today and get discounts!), and, unfortunately, even the 
nature of hypertext itself (click, click, click, BOOM!). It's registrars 
registering obvious phishing domains (are there no BRs for registrars?). 
It's users running everything as root, mostly because they don't know 
better. It's security bugs (ugh! I've reported  >200 of these over the 
past few years). It's caller-ID impersonation. It's


To switch topics a bit, I am wondering whether a foundation-run 
whitelist might help cut confusion-related phishing. This is not fleshed 
out, but the basic idea that the user's browser tests domains against a 
whitelist of domains that are known to be authentic. The foundation 
running this project should prefill the whitelist with all 
known-authentic domains. It should identify probable-phishing domains 
(e.g., pretty much anything containing a string like "paypal" or 
"facebook") and omit them from the whitelist unless it obtains 
permission to include them from the appropriate administrative contact 
for the authentic domain(s) that they're suspected of phishing. Domains 
that do not appear to be phishing domains, and that don't appear in 
major blacklists (e.g, GSB), should be added to the whitelist.


When the 

Re: Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Matt Palmer via dev-security-policy]

On Thu, Oct 03, 2019 at 05:36:50PM -0700, Ronald Crane via dev-security-policy 
wrote:
> 
> On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:
> > [snip]
> > > I guess I wasn't specific enough. I am looking for a good study that
> > > supports the proposition that the Internet community has (1) made a
> > > concerted effort to ensure that there is only one authentic domain per
> > > entity (or, at most, per entity-service, e.g, retail brokerage
> > > services); and (2) has made a concerted effort to educate users to use
> > > only that domain; and (3) that those steps have failed to significantly
> > > reduce the successful phishing rate of the users that steps (1) and (2)
> > > targeted.
> > > 
> > > 
> > > Was it intentional to presume that (1) is correct or desirable? It’s
> > > unclear if you believe it is, but if it isn’t (and for many reasons, it
> > > isn’t), then naturally one might assume (2) and (3) don’t exist.
> 
> Yes, I do believe that (1) is desirable. It has a long history in the
> context of brand identity (e.g., "Coke" in red and white script), where
> virtually all consumers use it to identify authentic products and reject
> counterfeits.

This is a valuable analogy, but I'm not sure how it advances the argument
you appear to be making.

To take the specific example you've provided, there is more than one product
made under the general brand of "Coke", most -- but not all -- involving the
word "Coke" in way or another.  If we take the "domain name per product"
analogy, there would be a bunch of different "domains" for these products:
coke, newcoke, cocacolaclassic, dietcoke, cokezero, vanillacoke,
caffeinefreecoke, and so on.

That's before we start considering other products produced and marketed by
the same company under different names.  There's a bunch of other carbonated
beverages, plus uncarbonated beverages, and even non-beverage foodstuffs,
that are all produced and/or marketed by the company that produces and
markets "Coke", at least in the country I'm from.

Contrariwise, neither the word "Coke", nor white writing on a red
background, nor even the specific font used, unambiguously identify one
particular brand -- and even then, it is only in the context of beverages
(attempts by trademark-maximalists notwithstanding).  Further, as the rather
extensive examples of counterfeit goods demonstrate, the mere existence of a
trademark, or even active measures, does not stop counterfeiting, nor does
it even attempt to -- it only tries to make counterfeiting commercially
unattractive.

Where the analogy breaks down is that in the case of phishing, people don't
typically try to "counterfeit" the domain name, merely "confuse".  If I make
a product called "Matt's Coke" and sell it, I may certainly find myself in
some legal hot water, but it won't be because of "counterfeiting", but
rather a more nebulous form of trademark infringement around confusion.

> Basically, many internet-based entities appear to have brought phishing upon
> themselves by failing to extend the above to their internet presences.
> Instead, they've trained their users to accept as authentic any domain that
> has a passing resemblance to their rat's-nest of legitimate domains.

While there's a certain amount of truth to that, I think quite a lot of it
is users just not checking *anything* about the link they're clicking.  The
amount of spam I get inviting me to login to various banking websites using
a link to yevgeniysflowershoppe.ua or the like would suggest that phishing
doesn't not absolutely rely on confusion.  Your hypothesis relies on the
idea that users can be trained in any meaningful fashion, which the research
seems to not support at all.

- Matt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/3/2019 2:09 PM, Ryan Sleevi via dev-security-policy wrote:

[snip]

I guess I wasn't specific enough. I am looking for a good study that
supports the proposition that the Internet community has (1) made a
concerted effort to ensure that there is only one authentic domain per
entity (or, at most, per entity-service, e.g, retail brokerage
services); and (2) has made a concerted effort to educate users to use
only that domain; and (3) that those steps have failed to significantly
reduce the successful phishing rate of the users that steps (1) and (2)
targeted.


Was it intentional to presume that (1) is correct or desirable? It’s
unclear if you believe it is, but if it isn’t (and for many reasons, it
isn’t), then naturally one might assume (2) and (3) don’t exist.


Yes, I do believe that (1) is desirable. It has a long history in the 
context of brand identity (e.g., "Coke" in red and white script), where 
virtually all consumers use it to identify authentic products and reject 
counterfeits. Entities also vigorously promote and protect their brand 
identities via trademarks and related litigation, and authorities even 
sometimes investigate and prosecute counterfeiters.


Basically, many internet-based entities appear to have brought phishing 
upon themselves by failing to extend the above to their internet 
presences. Instead, they've trained their users to accept as authentic 
any domain that has a passing resemblance to their rat's-nest of 
legitimate domains.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ryan Sleevi via dev-security-policy]

On Thu, Oct 3, 2019 at 3:45 PM Ronald Crane via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 10/2/2019 9:44 PM, Peter Gutmann via dev-security-policy wrote:
> > Ronald Crane via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
> >
> >> Please cite the best study you know about on this topic (BTW, I am
> *not* snidely
> >> implying that there isn't one).
> > Sure, gimme a day or two since I'm away at the moment.
> >
> > Alternatively, there's been such a vast amount of work done on this that
> a few
> > seconds of googling should find plenty of publications.  As the first
> search
> > text that came to mind, "browser ui phishing" returns just under half a
> million
> > hits.  Making it "browser ui phishing inurl:.pdf" to get just papers
> (rather than
> > web articles, blog posts, etc) reduces that to 30,000 results.
>
> I guess I wasn't specific enough. I am looking for a good study that
> supports the proposition that the Internet community has (1) made a
> concerted effort to ensure that there is only one authentic domain per
> entity (or, at most, per entity-service, e.g, retail brokerage
> services); and (2) has made a concerted effort to educate users to use
> only that domain; and (3) that those steps have failed to significantly
> reduce the successful phishing rate of the users that steps (1) and (2)
> targeted.



Was it intentional to presume that (1) is correct or desirable? It’s
unclear if you believe it is, but if it isn’t (and for many reasons, it
isn’t), then naturally one might assume (2) and (3) don’t exist.


>
> -R
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 9:44 PM, Peter Gutmann via dev-security-policy wrote:

Ronald Crane via dev-security-policy  
writes:


Please cite the best study you know about on this topic (BTW, I am *not* snidely
implying that there isn't one).

Sure, gimme a day or two since I'm away at the moment.

Alternatively, there's been such a vast amount of work done on this that a few
seconds of googling should find plenty of publications.  As the first search
text that came to mind, "browser ui phishing" returns just under half a million
hits.  Making it "browser ui phishing inurl:.pdf" to get just papers (rather 
than
web articles, blog posts, etc) reduces that to 30,000 results.


I guess I wasn't specific enough. I am looking for a good study that 
supports the proposition that the Internet community has (1) made a 
concerted effort to ensure that there is only one authentic domain per 
entity (or, at most, per entity-service, e.g, retail brokerage 
services); and (2) has made a concerted effort to educate users to use 
only that domain; and (3) that those steps have failed to significantly 
reduce the successful phishing rate of the users that steps (1) and (2) 
targeted.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Peter Gutmann via dev-security-policy]

Ronald Crane via dev-security-policy  
writes:

>Please cite the best study you know about on this topic (BTW, I am *not* 
>snidely 
>implying that there isn't one).

Sure, gimme a day or two since I'm away at the moment.

Alternatively, there's been such a vast amount of work done on this that a few
seconds of googling should find plenty of publications.  As the first search 
text that came to mind, "browser ui phishing" returns just under half a million 
hits.  Making it "browser ui phishing inurl:.pdf" to get just papers (rather 
than
web articles, blog posts, etc) reduces that to 30,000 results.

Peter.
___
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

[Kirk Hall via dev-security-policy]

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 

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 3:27 PM, Peter Gutmann wrote:

Ronald Crane via dev-security-policy  
writes:


"Virtually impossible"? "Anyone"? Really? Those are big claims that need real
data.

How many references to research papers would you like?  Would a dozen do, or
do you want two dozen?

One well-done paper would do.

I'm pretty sure I haven't been phished yet.
How would you know?


Since most phishing appears to be financial, I would expect unauthorized 
withdrawals from financial accounts, unauthorized credit card charges, 
unordered packages showing up, dunning notices from the IRS because I 
filed my tax returns with a phisher, etc. I haven't observed these 
indicia of getting phished.



And how does this help the other 7.53 billion people who
will be targets for phishers?
Alas it doesn't. We do need better phishing prevention. Do you have a 
suggestion?

In any case, have we ever really tried to teach users to use the correct
domain?

Yes, we've tried that.  And that.  And that too.  And the other thing.  Yes,
that too.

None of them work.


Please cite the best study you know about on this topic (BTW, I am *not* 
snidely implying that there isn't one).


-R

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:41 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> On 10/2/2019 3:00 PM, Paul Walsh via dev-security-policy wrote:
>> On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
>>  wrote:
> [snip]
>>> Some other changes that might help reduce phishing are:
>>> 1. Site owners should avoid using multiple domains, because using them 
>>> habituates users to the idea that there are several valid domains for a 
>>> given entity. Once users have that idea, phishers are most of the way to 
>>> success. Some of the biggest names in, e.g., brokerage services are 
>>> offenders on this front.
>> [PW] Companies like Google own so many domains and sub-domains that it’s 
>> difficult to stay ahead of them. I think this is an unrealistic expectation. 
>> So if other browser vendors have the same opinion, they should look inward.
> It is not unrealistic to expect, e.g., Blahblah Investments, SIPC, to use 
> only "www.blahblahinvestments.com" for everything related to its retail 
> investment services. It *is* unreasonable to habituate users to bad practices.

I agree. 

>>> 2. Site owners should not use URL-shortening services, for the same reason 
>>> as (1).
>> Site owners using shortened URLs isn’t the problem in my opinion. Even if 
>> shortened URLs went away, phishing wouldn’t stop. Unless you have research 
>> to provides more insight?
> Where did I say that phishing would "stop" if URL shortening services 
> disappeared? I said avoiding them would be helpful, since it would reinforce 
> the idea that there is one correct domain per entity, or at least per entity 
> service. Probably all the entity services should be subdomains of the one 
> correct domain, but alas it will take a sustained security campaign and a 
> decade to make a dent in that problem.

I agree. I said, if they disappeared it wouldn’t stop phishing. So it’s still a 
problem. I wanted to use an extreme example to demonstrate a point. 


>>> 3. Site owners should not use QR codes, since fake ones are perfect for 
>>> phishing.
>> Same as above. You don’t need to mask URLs to have a successful phishing 
>> campaign.
> No, you don't "need" to do it. It is, however, a very useful weapon in 
> phishers' quivers.

I agree.

>> sɑlesforce[.com] is available for purchase right now.
> 
> I was going to suggest banning non-Latin-glyph domains, since they are yet 
> another useful phishing weapon. FF converts all such domains into Punycode 
> when typed or pasted into the address bar, though the conversion is displayed 
> below the address bar, not in it. So your example becomes 
> "http://xn--slesforce-51d.com/;.

Just providing an example of a URL that uses .com. I can provide more without 
using special characters to demonstrate the same point. 



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: [FORGED] Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:27 PM, Peter Gutmann via dev-security-policy 
>  wrote:
> 
> Ronald Crane via dev-security-policy  
> writes:
> 
>> "Virtually impossible"? "Anyone"? Really? Those are big claims that need real
>> data.
> 
> How many references to research papers would you like?  Would a dozen do, or
> do you want two dozen?

I would like to see one research paper published by one browser vendor to show 
that website identity visual indicators can not work. 

I’m not asking for an individual who tricked the system to get an EV cert - 
that doesn’t prove anything in relation to visual indicators and the 
effectiveness of well designed UI. It just proves that a specific process of 
getting verified can be improved. 

> 
> (This has been researched to death, it's not rocket science, given a bit of
> time you can dig up vast numbers of references.  The only reason I haven't do
> it for this post is that I get the feeling I'd be wasting said time doing so).

I’ve been working on URL classification since I co-instigated the W3C Standard 
in 2004. Here’s a link to where you can see one of the first browser add-ons we 
built with visual indicators for more context around URLs 
https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
 Segala was the first 
company I founded. 

I’d love you to show me the type of research I’ve asked for. I’m open to 
learning more. I’m not new to this game. I worked on integrated browsers and 
search engines in the 90’s at AOL. 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:20 PM, Kurt Roeckx  wrote:
> 
> On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
 In separate research, CAs have shown data to demonstrate that website 
 owners want to have their identity verified. 
>>> 
>>> They have not. In fact, I would say that most website owners are perfectly
>>> happy with DV certificates.
>> 
>> What’s your source of data to substantiate what you “would say”? We need to 
>> start talking about facts and data.
> 
> How many DV, OV and EV certificates are there? I think it's rather
> clear what most website owners use.

Let’s try this another way. 

If there was a well implemented visual indicator that users relied on for 
trust, and ID verification was low cost, fast and accessible, more website 
owners would be more likely to want that visual indicator - especially if their 
customers asked them why they didn’t have it.

We saw this from our research - crypto exchanges and wallets were being 
requested by their customers to seek verification. It can work. 

> 
> 
> Kurt
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:18 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> 
> On 10/2/2019 2:47 PM, Paul Walsh via dev-security-policy wrote:
>> On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
>>  wrote:
>>> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
 New tools such as Modlishka now automate phishing attacks, making it 
 virtually impossible for any browser or security solution to detect -  
 bypassing 2FA. Google has admitted that it’s unable to detect these 
 phishing scams as they use a phishing domain but instead of a fake 
 website, they use the legitimate website to steal credentials, including 
 2FA. This is why Google banned its users from signing into its own 
 websites via mobile apps with a WebView. If Google can prevent these 
 attacks, Mozilla can’t.
>>> I understand that Modlishka emplaces the phishing site as a MITM. This is 
>>> yet another reason for browser publishers to help train their users to use 
>>> only authentic domain names, and also to up their game on detecting and 
>>> banning phishing domains. I don't think it says much about the value, or 
>>> lack thereof, of EV certs. As has been cited repeatedly in this thread, 
>>> most phishing sites don't even bother to use SSL, indicating that most 
>>> users who can be phished aren't verifying the correct domain.
>> Ronald - it’s virtually impossible for anyone to spot well designed phishing 
>> attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
>> with a single test, every time.
> 
> "Virtually impossible"? "Anyone"? Really? Those are big claims that need real 
> data. I'm pretty sure I haven't been phished yet.

Yes :)

I have results from 1,845 people so far. I published the test on Twitter, 
inside our Telegram group and presented it many times at many blockchain 
conferences around the world. Only 4 people got it right - and I also put it in 
front of great security professionals. My point is that it’s virtually 
impossible to spot some phishing scams for almost everyone. I’ve seen some top 
social engineers own up to falling for a phishing test at work on Twitter - and 
this is what they do for a living. It’s not a measurement of experience or 
expertise. 

Here’s one test https://twitter.com/Paul__Walsh/status/1174359874932621316?s=20

> 
> In any case, have we ever really tried to teach users to use the correct 
> domain? As I noted in a recent response, many site owners do things -- such 
> as using multiple domains for a single entity, using URL-shortening services, 
> using QR codes, etc. -- that habituate users to the idea that there's more 
> than one correct domain, and/or that they can get it from untrustworthy 
> sources. Once they have that idea, phishing is easy.

This won’t resolve the problem unfortunately. Companies that use few domains 
are high profile targets. 

> 
>> It’s the solution if users had a reliable way to check website identity as 
>> I’ve explained
> And EV certs do this how? Please address https://stripe.ian.sh .

I already addressed this by asking for a single instance of where an attacker 
used an EV certificate. I provide quite a lot of text around this point - 
pointing out that just because you can prove something can be done, doesn’t 
mean it will be. No security solution on the market is 100%. No company is 
hack-proof. Threat actors will only spend time, energy and cost if it’s worth 
it. 

From a security POV, the bar to attaining an EV cert is too high for it to be a 
real threat. They have to setup a real company and it can only be used once. So 
when the cert is revoked that’s the end of it. But, the process could be 
improved.

Back to my question, can you provide examples of attacks that used an EV cert?

I’m not here to defend EV certs or CAs. I’m here to ask that you stop and 
rethink your decision to remove UI for website identity. This isn’t to say that 
we can’t rethink the CA model and tech. From what I can see, browser vendors 
are railroading everyone, including CAs. There’s no collaboration here. Just a 
few people who *think* they know what’s best. I see no evidence to substantive 
any decisions. 


>> Perhaps you can comment on my data about users who do rely on a new visual 
>> indicator and the success that has seen?
> Please post a link to a paper describing it, including the methodology you 
> used.

I’ve already published the methodology used on a thread in this forum with all 
the data collected in relation to this point. I just haven’t taken the time to 
PDF it and stick it on a website. It will however, be published on a website in 
the form of a guest post - later this week. 


>> Any opinion I’ve read is just that, opinion, with zero data/evidence to 
>> substantiate anything cited. The closest I’ve seen is exceptionally old 
>> research that’s more than 10 years old.
> Um, 
> 

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 03:17:31PM -0700, Paul Walsh wrote:
> >> In separate research, CAs have shown data to demonstrate that website 
> >> owners want to have their identity verified. 
> > 
> > They have not. In fact, I would say that most website owners are perfectly
> > happy with DV certificates.
> 
> What’s your source of data to substantiate what you “would say”? We need to 
> start talking about facts and data.

How many DV, OV and EV certificates are there? I think it's rather
clear what most website owners use.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

> On Oct 2, 2019, at 3:11 PM, Kurt Roeckx  wrote:
> 
> On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
>> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
>>  wrote:
>>> 
>>> On 2019-10-02 09:20, Kurt Roeckx wrote:
 On 2019-10-02 02:39, Paul Walsh wrote:
> 
> According to Ellis, the goal for a customer survey is to get feedback 
> from people who had recently experienced "real usage" of the product. The 
> key question in the survey for these people according to Ellis, is:
> 
> "How would you feel if you could no longer rely on MetaCert's green 
> shield?
 No, the question he would be asking is:
 "How would you feel if you could no longer use MetaCert's EV certificates?"
>>> 
>>> And it's probably better to even turn that into:
>>> How would you feel if you could no longer buy MetaCert's EV certificates?
>> 
>> [PW] MetaCert is not a CA. We don’t have any relationships with any CAs 
>> either. 
> 
> Well, for what Ellis is talking about, it's asking about a
> product, and how the user would feel if that product can't be used
> anymore.
> 
> That just shows that there are users that want your product, not
> that everybody wants it.

I’m not sure I understand the point you would like me to take from this. Not 
every person in the world wants to use Firefox. That doesn’t stop Mozilla from 
building browser software. No company in the world tries to sell to everyone. 
If most people want browser UI for website identity, are you saying we 
shouldn’t give it to them because everyone didn’t proactively say they wanted 
it? 


> 
>> Our research was aimed at end-users, as I said previously. We have proof 
>> that users want to use a visual indicator for trust. And we also 
>> demonstrated that it’s possible to protect users with well designed browser 
>> UI/UX.
> 
> Sure, there will be users that want that, nobody is denying that.

Great. Perhaps we can talk about the things that we agree on. 

> 
>> In separate research, CAs have shown data to demonstrate that website owners 
>> want to have their identity verified. 
> 
> They have not. In fact, I would say that most website owners are perfectly
> happy with DV certificates.

What’s your source of data to substantiate what you “would say”? We need to 
start talking about facts and data.

> 
> 
> Kurt
> 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/2/2019 2:47 PM, Paul Walsh via dev-security-policy wrote:

On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
 wrote:

On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:

New tools such as Modlishka now automate phishing attacks, making it virtually 
impossible for any browser or security solution to detect -  bypassing 2FA. 
Google has admitted that it’s unable to detect these phishing scams as they use 
a phishing domain but instead of a fake website, they use the legitimate 
website to steal credentials, including 2FA. This is why Google banned its 
users from signing into its own websites via mobile apps with a WebView. If 
Google can prevent these attacks, Mozilla can’t.

I understand that Modlishka emplaces the phishing site as a MITM. This is yet 
another reason for browser publishers to help train their users to use only 
authentic domain names, and also to up their game on detecting and banning 
phishing domains. I don't think it says much about the value, or lack thereof, 
of EV certs. As has been cited repeatedly in this thread, most phishing sites 
don't even bother to use SSL, indicating that most users who can be phished 
aren't verifying the correct domain.

Ronald - it’s virtually impossible for anyone to spot well designed phishing 
attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
with a single test, every time.


"Virtually impossible"? "Anyone"? Really? Those are big claims that need 
real data. I'm pretty sure I haven't been phished yet.


In any case, have we ever really tried to teach users to use the correct 
domain? As I noted in a recent response, many site owners do things -- 
such as using multiple domains for a single entity, using URL-shortening 
services, using QR codes, etc. -- that habituate users to the idea that 
there's more than one correct domain, and/or that they can get it from 
untrustworthy sources. Once they have that idea, phishing is easy.



It’s the solution if users had a reliable way to check website identity as I’ve 
explained

And EV certs do this how? Please address https://stripe.ian.sh .

Perhaps you can comment on my data about users who do rely on a new visual 
indicator and the success that has seen?
Please post a link to a paper describing it, including the methodology 
you used.

Any opinion I’ve read is just that, opinion, with zero data/evidence to 
substantiate anything cited. The closest I’ve seen is exceptionally old 
research that’s more than 10 years old.
Um, 
https://casecurity.org/wp-content/uploads/2017/09/Incidence-of-Phishing-Among-DV-OV-and-EV-Websites-9-13-2017-short-vepdf 
(see table on p.2) is from 2017. That is not "more than 10 years old" 
nor just "opinion, with zero data/evidence to substantiate anything 
cited". Let's debate the merits with more light and less heat.

According to Webroot 93% of all new phishing sites have an SSL certificate. 
According to MetaCert it’s more than 96%. This is increasing as Let’s Encrypt 
issues more free certs.


Please link the surveys you cite. In any case, the Lets Encrypt issue 
*does* appear to be a problem, as you noted elsewhere. Does Google Safe 
Browsing automatically add these (fake Paypal and similar) domains to 
its probable-phish list? They should.



If you want to talk about certificate issuance that’s broken, look at how Let’s 
Encrypt has issued more than 14,000 DV certs to domains with PayPal in it.


I'm agnostic on the EV UI, but have seen little evidence that it's 
useful. Maybe your paper will help convince me otherwise.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On Wed, Oct 02, 2019 at 02:48:56PM -0700, Paul Walsh wrote:
> On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
>  wrote:
> > 
> > On 2019-10-02 09:20, Kurt Roeckx wrote:
> >> On 2019-10-02 02:39, Paul Walsh wrote:
> >>> 
> >>> According to Ellis, the goal for a customer survey is to get feedback 
> >>> from people who had recently experienced "real usage" of the product. The 
> >>> key question in the survey for these people according to Ellis, is:
> >>> 
> >>> "How would you feel if you could no longer rely on MetaCert's green 
> >>> shield?
> >> No, the question he would be asking is:
> >> "How would you feel if you could no longer use MetaCert's EV certificates?"
> > 
> > And it's probably better to even turn that into:
> > How would you feel if you could no longer buy MetaCert's EV certificates?
> 
> [PW] MetaCert is not a CA. We don’t have any relationships with any CAs 
> either. 

Well, for what Ellis is talking about, it's asking about a
product, and how the user would feel if that product can't be used
anymore.

That just shows that there are users that want your product, not
that everybody wants it.

> Our research was aimed at end-users, as I said previously. We have proof that 
> users want to use a visual indicator for trust. And we also demonstrated that 
> it’s possible to protect users with well designed browser UI/UX.

Sure, there will be users that want that, nobody is denying that.

> In separate research, CAs have shown data to demonstrate that website owners 
> want to have their identity verified. 

They have not. In fact, I would say that most website owners are perfectly
happy with DV certificates.


Kurt

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 2:52 PM, Ronald Crane via dev-security-policy 
 wrote:
> 
> On 10/2/2019 1:16 PM, Ronald Crane via dev-security-policy wrote:
>> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
>>> New tools such as Modlishka now automate phishing attacks, making it 
>>> virtually impossible for any browser or security solution to detect -  
>>> bypassing 2FA. Google has admitted that it’s unable to detect these 
>>> phishing scams as they use a phishing domain but instead of a fake website, 
>>> they use the legitimate website to steal credentials, including 2FA. This 
>>> is why Google banned its users from signing into its own websites via 
>>> mobile apps with a WebView. If Google can prevent these attacks, Mozilla 
>>> can’t.
>> 
>> I understand that Modlishka emplaces the phishing site as a MITM. This is 
>> yet another reason for browser publishers to help train their users to use 
>> only authentic domain names, and also to up their game on detecting and 
>> banning phishing domains. I don't think it says much about the value, or 
>> lack thereof, of EV certs. As has been cited repeatedly in this thread, most 
>> phishing sites don't even bother to use SSL, indicating that most users who 
>> can be phished aren't verifying the correct domain.
>> 
>> -R
>> 
> Some other changes that might help reduce phishing are:
> 
> 1. Site owners should avoid using multiple domains, because using them 
> habituates users to the idea that there are several valid domains for a given 
> entity. Once users have that idea, phishers are most of the way to success. 
> Some of the biggest names in, e.g., brokerage services are offenders on this 
> front.

[PW] Companies like Google own so many domains and sub-domains that it’s 
difficult to stay ahead of them. I think this is an unrealistic expectation. So 
if other browser vendors have the same opinion, they should look inward.

> 
> 2. Site owners should not use URL-shortening services, for the same reason as 
> (1).

Site owners using shortened URLs isn’t the problem in my opinion. Even if 
shortened URLs went away, phishing wouldn’t stop. Unless you have research to 
provides more insight?

> 
> 3. Site owners should not use QR codes, since fake ones are perfect for 
> phishing.

Same as above. You don’t need to mask URLs to have a successful phishing 
campaign. sɑlesforce[.com] is available for purchase right now. 

> 
> 4. Browser publishers should petition ICANN to revoke most of the gTLDs it 
> has approved, since they provide fertile ground for phishing.

Petitioning them won’t work. gTLDs are here to stay, even if we dislike them. 
Also, most phishing sites use .com and other well known TLDs. I’m not saying 
gTLDs aren’t used, they are. But they’re not needed. 

So, bringing it back to Mozilla. I’d still love to see recent research/data to 
back up Mozilla’s decision to remove identity UI in Firefox. By promoting the 
padlock without education about phishing, browser vendors are actually making 
the web more dangerous. 

- Paul


> There appear to be ~1900 such gTLDs [1]. I doubt that even the largest 
> corporations have registered their base domains under every such gTLD. Where 
> does "www.microsoft.somenamethatICANNmightaddasagTLD" go? I sure don't know 
> where "www.zippenhop.[pick a non-.com gTLD] goes.
> 
> [1]  Search for "delegated" status at 
> https://newgtlds.icann.org/en/program-status/delegated-strings .
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 12:52 AM, Kurt Roeckx via dev-security-policy 
 wrote:
> 
> On 2019-10-02 09:20, Kurt Roeckx wrote:
>> On 2019-10-02 02:39, Paul Walsh wrote:
>>> 
>>> According to Ellis, the goal for a customer survey is to get feedback from 
>>> people who had recently experienced "real usage" of the product. The key 
>>> question in the survey for these people according to Ellis, is:
>>> 
>>> "How would you feel if you could no longer rely on MetaCert's green shield?
>> No, the question he would be asking is:
>> "How would you feel if you could no longer use MetaCert's EV certificates?"
> 
> And it's probably better to even turn that into:
> How would you feel if you could no longer buy MetaCert's EV certificates?

[PW] MetaCert is not a CA. We don’t have any relationships with any CAs either. 

We do not sell verification services to website owners. We’re doing 
verification at scale, for free. We generate revenue on the other end - selling 
security services as well as API access to the data. Trying to protect users 
from threats is clearly not working. So they need to know what’s verified as 
not-unsafe. I’m afraid to use the word safe too often because it’s vague.

Our research was aimed at end-users, as I said previously. We have proof that 
users want to use a visual indicator for trust. And we also demonstrated that 
it’s possible to protect users with well designed browser UI/UX.

In separate research, CAs have shown data to demonstrate that website owners 
want to have their identity verified. 

I haven’t seen any research / data to show why Mozilla should remove UI instead 
of improving it. 

FWIW my COO and engineers built the official Firefox add-ons for digg, 
Delicious, Yahoo!, eBay, PayPal, Google and Microsoft. And they built and 
maintained spreadfirefox .com - so we have a lot of experience working "with” 
Mozilla. We're blown away by the team’s decision to remove UI without any 
research to back up their decisions.

Was there anything you disagreed with in my lengthy responses Kurt? 

Thanks,
Paul




___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Oct 2, 2019, at 1:16 PM, Ronald Crane via dev-security-policy 
 wrote:
> 
> On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:
>> New tools such as Modlishka now automate phishing attacks, making it 
>> virtually impossible for any browser or security solution to detect -  
>> bypassing 2FA. Google has admitted that it’s unable to detect these phishing 
>> scams as they use a phishing domain but instead of a fake website, they use 
>> the legitimate website to steal credentials, including 2FA. This is why 
>> Google banned its users from signing into its own websites via mobile apps 
>> with a WebView. If Google can prevent these attacks, Mozilla can’t.
> 
> I understand that Modlishka emplaces the phishing site as a MITM. This is yet 
> another reason for browser publishers to help train their users to use only 
> authentic domain names, and also to up their game on detecting and banning 
> phishing domains. I don't think it says much about the value, or lack 
> thereof, of EV certs. As has been cited repeatedly in this thread, most 
> phishing sites don't even bother to use SSL, indicating that most users who 
> can be phished aren't verifying the correct domain.

Ronald - it’s virtually impossible for anyone to spot well designed phishing 
attacks. Teaching people to check the URL doesn’t work - I can catch out 99% 
with a single test, every time. It’s the solution if users had a reliable way 
to check website identity as I’ve explained. Almost all breaches start with 
phishing and it’s getting worse. 

Perhaps you can comment on my data about users who do rely on a new visual 
indicator and the success that has seen? 

Any opinion I’ve read is just that, opinion, with zero data/evidence to 
substantiate anything cited. The closest I’ve seen is exceptionally old 
research that’s more than 10 years old.

According to Webroot 93% of all new phishing sites have an SSL certificate. 
According to MetaCert it’s more than 96%. This is increasing as Let’s Encrypt 
issues more free certs. I think people are mixing up spam with phishing. Or 
they’re just guessing based on what they see personally. It’s time to reference 
facts from the security world.

With billions of dollars being invested in cybersecurity and many billions 
spent paying for those services, it’s still technically impossible for any 
company with any solution to detect every new malicious URL - and it will never 
be possible to detect every new dangerous URL. 

So, most attacks start with phishing. Most phishing sites have a padlock. Most 
people trust sites with a padlock. Security companies can’t stop all new 
threats.

What’s the answer? It certainly isn’t removing website identity and promoting 
the padlock.

- Paul

> 
> -R
> 
> 
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ronald Crane via dev-security-policy]

On 10/1/2019 6:56 PM, Paul Walsh via dev-security-policy wrote:

New tools such as Modlishka now automate phishing attacks, making it virtually 
impossible for any browser or security solution to detect -  bypassing 2FA. 
Google has admitted that it’s unable to detect these phishing scams as they use 
a phishing domain but instead of a fake website, they use the legitimate 
website to steal credentials, including 2FA. This is why Google banned its 
users from signing into its own websites via mobile apps with a WebView. If 
Google can prevent these attacks, Mozilla can’t.


I understand that Modlishka emplaces the phishing site as a MITM. This 
is yet another reason for browser publishers to help train their users 
to use only authentic domain names, and also to up their game on 
detecting and banning phishing domains. I don't think it says much about 
the value, or lack thereof, of EV certs. As has been cited repeatedly in 
this thread, most phishing sites don't even bother to use SSL, 
indicating that most users who can be phished aren't verifying the 
correct domain.


-R


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 09:20, Kurt Roeckx wrote:

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback 
from people who had recently experienced "real usage" of the product. 
The key question in the survey for these people according to Ellis, is:


"How would you feel if you could no longer rely on MetaCert's green 
shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"


And it's probably better to even turn that into:
How would you feel if you could no longer buy MetaCert's EV certificates?


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kurt Roeckx via dev-security-policy]

On 2019-10-02 02:39, Paul Walsh wrote:


According to Ellis, the goal for a customer survey is to get feedback from people who had 
recently experienced "real usage" of the product. The key question in the 
survey for these people according to Ellis, is:

"How would you feel if you could no longer rely on MetaCert's green shield?


No, the question he would be asking is:
"How would you feel if you could no longer use MetaCert's EV certificates?"

Which is something totally different. It's very important to get the 
question right.



Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

On Sunday, September 22, 2019 at 7:49:14 AM UTC-7, Gijs Kruitbosch wrote:

[snip]

> On 22/09/2019 00:52, Kirk Hall wrote:
> > (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."
> 
> Although I intuitively would like to think that we have a right to know 
> "who is running a website", this doesn't mean that EV certificate 
> information is an appropriate vehicle for this information. Even without 
> all the significant issues that EV certification has, if we pretended it 
> was perfect, it still only shows UI for the tls connection made for the 
> toplevel document, whereas other resources and subframes could easily 
> have (and usually do) come from other domains that either do not have an 
> EV cert or have one belonging to a different entity. And even if that 
> were not the case, the entity controlling the website does not 
> necessarily control the data in a legal sense.*** So the EV UI does not, 
> in the legal sense, always indicate who will control the "sensitive 
> data" that users/customers submit.

[PW] I agree with some of this. When I co-instigated the creation of the W3C 
Standard for URL Classification and Content Labeling that replaced PICS in 
2009, it was for this reason; PICS didn’t support assertions about folders - 
only domains. Furthermore, when I co-founded the W3C Mobile Web Initiative I 
helped to write the first draft of the “mobileOK” specification - the ability 
to make assertions about any part of a URI was also a priority then. So, I 
agree with general observations about the importance of being able to 
distinguish between domains, sub-domains, folders etc. when making assertions 
about the content or content creator. 

However, there’s so much to unbundle and it’s drawing the wrong conclusions. 
Allow me to first paint the problem that browser vendors are making worse with 
their decision to scrap website identity instead of fixing what they got wrong 
with the UI and UX.

According to Verizon, phishing represents 93% of all data breaches.

According to Proofpoint, in the first quarter of 2019, cyberattacks using 
dangerous links outnumbered those with malicious attachments by five to one.

According to the Webroot nearly 1.5 million new phishing sites are created each 
month.

According to Wombat Security 76% of businesses reported being a victim of a 
phishing attack in the last year.

According to IBM, phishing attacks increased 250% in 2018.

According to Palo Alto Networks, 70% of all newly registered domains are 
malicious, suspicious or not safe for work.

New tools such as Modlishka now automate phishing attacks, making it virtually 
impossible for any browser or security solution to detect -  bypassing 2FA. 
Google has admitted that it’s unable to detect these phishing scams as they use 
a phishing domain but instead of a fake website, they use the legitimate 
website to steal credentials, including 2FA. This is why Google banned its 
users from signing into its own websites via mobile apps with a WebView. If 
Google can prevent these attacks, Mozilla can’t. 

What’s the common thread? Almost all the cybersecurity problems we read about, 
start with one user falling for a counterfeit website. 

According to Webroot, 93% of all new phishing domains display a padlock thanks 
to free, automatically issued DV certificates. According to MetaCert and some 
CAs, 98% of DV certs used for phishing were issued for free by Let’s Encrypt. 
Given that Let’s Encrypt's growth is exploding, this problem can only get 
worse. 

If browser vendors designed proper UI and UX for website identity in the first 
place, the web would be a much safer place. CAs are not responsible for browser 
UI. EV certs aren’t responsible for browser UI. Browser vendors designed the UI 
and UX and it’s totally broken. 

People who say website identity is broken, are in fact pointing the finger at 
browser vendors, even if they don’t realize it.

It’s pretty easy to make assertions about different parts of a website. It’s 
not rocket science. If you want to talk about certificate issuance that’s 
broken, look at how Let’s Encrypt has issued more than 14,000 DV certs to 
domains with PayPal in it. But what’s weird, is that the same people who think 
CAs are doing things wrong and EV certs are bad, are the same people who say 
it’s not Let’s Encrypt’s responsibility to fight phishing. Pot, kettle, black. 

And Google doesn’t agree with Google - "keep URLs simple and only show the 
domain name for safety, but allow me to introduce you to AMP”…  where URLs and 
brand identity goes to die. A big company is only as good as the few people who 
work on a given project. I have seen zero data from Mozilla (or Google) when it 
comes to website identity and their decision to remove it from the UI. I can 
dig out many instances of where browser 

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Paul Walsh via dev-security-policy]

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.

[snip]

> 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?

[PW] The following response is to address the questions/comments regarding 
dataset type and size. 

Sean Ellis [1] was the head of marketing at LogMeIn and Uproar from launch to 
IPO. He was the first marketer at Dropbox, Lookout and Xobni, and he coined the 
term "growth hacker" in 2010. So, he knows a thing or two when it comes to 
product/market fit research - including the type of questions to ask, and the 
size of the dataset required to derive a good understanding of the responses.

According to Ellis, the goal for a customer survey is to get feedback from 
people who had recently experienced "real usage" of the product. The key 
question in the survey for these people according to Ellis, is:

"How would you feel if you could no longer rely on MetaCert's green shield?

a) Very disappointed
b) Somewhat disappointed
c) Not disappointed
d) N/A I no longer use the product

According to Ellis, to get an indication of product/market fit, you'll want to 
know the percentage of people who would be "very disappointed" if they could no 
longer use your product. In his experience, it becomes possible to sustainably 
grow a product when it reaches around 40% of users who try it that would be 
"very disappointed" if they could no longer use it.

For this percentage to be meaningful, you need to have a fairly large sample 
size. In Ellis' experience, a minimum of 30 responses is needed before the 
survey becomes directionally useful. At 100+ responses he is much more 
confident in the results. 

Based on Ellis' observations, it would appear that Entrust DataCard's dataset 
is big enough. 

I'm not debating the merits of the research, as I have my own research to prove 
that browser-based visual indicators for website identity does protect 
end-users - but only when designed properly. 

[1] 
https://blog.growthhackers.com/using-product-market-fit-to-drive-sustainable-growth-58e9124ee8db
 


Regards,
Paul



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Peter Gutmann via dev-security-policy]

Kirk Hall via dev-security-policy  
writes:

>To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server
>certificate customers

And what a marvellously disingenous "survey" it is too, artfully constructed
to produce exactly the result the CA's marketing department wants.  Mixed in
with a series of motherhood-and-apple-pie leading questions that no-one could
answer "no" to to yes-prime the respondents, a few vaguely-word EV questions
that you want the yes response to (by vague I mean nonsense like "Do you
believe that positive visual signals in the browser UI are important to
encourage website owners to choose EV certificates and undergo the EV
validation process for their organization?", which translates to "Do you
believe browsers should act as marketing agents for our EV certificates?"
while totally avoiding ever asking the real question, "Do you believe EV
certificates make the web safer to use?").

Even then, the response is a little surprising because the priming questions
aren't 100% - what sort of pinko commie subversive answers "no" to "Customers
/ users have the right to know which organization is running a website if the
website asks the user to provide sensitive data"?.

Allow me to propose an equivalent dishonest poll that gets the exact opposite
result.  First a few push-poll questions to set the scene, "Given that Russian
criminals have stolen $2B from US citizens via web browser phishing attacks in
the last 12 months + ".  Then the same motherhood-and-apple-pie questions to yes-bias the
repondents.  Finally, the question I want the yes answer to.  What would you
like?  Fine CAs whose certificates are misused?  Force browser vendors to
provide security guarantees for the web sites where they display all-OK
indicators?  Death penalty for phishers?  I can get you any result you like,
what's it worth to you?

In any case, as with a previous EV cert poll done by another CA a few years
ago, this one surveys the efficacy of EV certificate marketing, not their
utility in preventing phishing and whatnot.

Peter.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Gijs Kruitbosch via dev-security-policy]

(For the avoidance of doubt, although I work for Mozilla, as noted on 
the wiki I post in a personal capacity)


In addition to Ryan's excellent points, I wanted to briefly point out a 
few things related to your survey:


On 22/09/2019 00:52, Kirk Hall wrote:

(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."


Although I intuitively would like to think that we have a right to know 
"who is running a website", this doesn't mean that EV certificate 
information is an appropriate vehicle for this information. Even without 
all the significant issues that EV certification has, if we pretended it 
was perfect, it still only shows UI for the tls connection made for the 
toplevel document, whereas other resources and subframes could easily 
have (and usually do) come from other domains that either do not have an 
EV cert or have one belonging to a different entity. And even if that 
were not the case, the entity controlling the website does not 
necessarily control the data in a legal sense.*** So the EV UI does not, 
in the legal sense, always indicate who will control the "sensitive 
data" that users/customers submit.



(2) *93%* of respondents agreed or strongly agreed with the statement “Identity 
on the Internet is becoming increasingly important over time..


This sounds very nice but doesn't mean anything. What kind of identity? 
Whose identity? Important to whom? Why does it have anything to do with EV?



(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%*).


This again sounds very nice, but surely the actually important thing is 
that (potential) customers realize when they are *not* at that official 
website when some other website tries to persuade them to part with 
their data/money (so that they don't, or if they do, don't blame the 
"real" company later)? As has been pointed out repeatedly in this forum, 
we have pretty good evidence that customers do not, in fact, realize the 
absence of the EV indicator, as well as evidence that such indicators 
can be "spoofed", viz. the Stripe Inc. work.


If anything, this survey shows that the 87% of people who thought this 
was important misunderstood where the risks of digital identity 
confusion lie.



(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%*).


This implies that the UI is the/a main motivator for people to get these 
certificates, but doesn't by itself have any implications for the 
importance of that UI in keeping consumers and businesses safe.


If 90% of people surveyed think that people should wear helmets when 
cycling, that's good for people selling bicycle helmets but doesn't have 
anything to do with how effective those helmets are at preventing 
injuries in cyclists.



(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.


Both of these actually appear to be arguments for Firefox not to 
reinstate its in-address-bar EV UI, given that all the other browsers 
have moved this information out of there. The most consistent UI is only 
providing this information when activating (clicking/tapping/...) the 
lock icon, which is what browsers have now pretty universally implemented.



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.


With due respect to the good folks at Apple, I do not believe this is an 
accessible solution (distinguishing information only by colour, 
https://www.w3.org/TR/WCAG20/#visual-audio-contrast ).


Additionally, (even if we presuppose EV certs were perfect) it does not 
help address the requests made in your survey's questions #1 and #3, ie 
which organization is 

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Cynthia Revström via dev-security-policy]

Kirk, may I remind you that Ryan Sleevi is posting in personal capacity
here, as is the default on m.d.s.p unless otherwise specified.
So please do not drag his employer into this discussion.

Ryan SleeviPeer of the CA Certificates Module
; Works for Google
; PKI policy for Chrome/ChromeOS; Posting in a
personal capacity, with posts not necessarily representing the views of
Google or the Mozilla CA Certificate Module, except where otherwise noted.
From: https://wiki.mozilla.org/CA/Policy_Participants

- Cynthia

On Sun, Sep 22, 2019 at 6:56 AM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Kirk Hall via dev-security-policy]

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

Re: Website owner survey data on identity, browser UIs, and the EV UI

[Ryan Sleevi via dev-security-policy]

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?
___
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

[Kirk Hall via dev-security-policy]

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