Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

On Oct 14, 2019, at 12:07 PM, Ronald Crane via dev-security-policy 
 wrote:
> 
> The finding is from public information that is relevant to the current value 
> of EV certificates, which is a central part of this discussion.

[PW] For the record, we didn't purchase an EV cert because the browser UI and 
UX was (and still is in Firefox) so terrible that almost no end-user could tell 
when a website owner had their identity verified or not. It doesn’t take a 
product person or designer or a user experience expert to see this.

Had the browsers implemented good UI/UX you would see an EV cert for our 
corporate website. 

If Mozilla implements meaningful UI/UX in the future, I’ll immediately switch 
to whatever it is that Firefox uses to read identity information. If that’s EV, 
great. If it’s something else, great. As long as the price is right.

- Paul

> 
> -R
> 
> On 10/14/2019 11:10 AM, Paul Walsh via dev-security-policy wrote:
>> I have two questions Ronald:
>> 
>> 1. What should I look for? I just see a DV cert from Let’s Encrypt.
>> 
>> 2. Why did you message the entire community about whatever it is you’ve 
>> found?
>> 
>> Thanks,
>> Paul
>> 
>> Sent from my iPhone
>> 
>>> On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy 
>>>  wrote:
>>> 
>>> Just FYI, metacert.com served up this cert recently: 
>>> https://crt.sh/?id=1884181370 .
>>> 
>>> -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
> ___
> 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: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

> On Oct 14, 2019, at 12:07 PM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> The finding is from public information that is relevant to the current value 
> of EV certificates, which is a central part of this discussion.

[PW] I’m still confused Ronald. And, sorry for taking so long to respond. I 
moved to Vancouver recently and it was Thanksgiving / long weekend.

I’m not sure I understand why you're pointing out that MetaCert uses a Let’s 
Encrypt DV cert. 

Our use of Let’s Encrypt and/or a DV certificate doesn't prove or disprove 
anything that I have said about the need for new browser UI for website 
identity to help make the web safer. If anything, it should help to demonstrate 
that I’m impartial to the CA/Browser battles as an unbiased commentator - I 
literally didn’t want to chose a CA because I knew people would look to see who 
we used. 

Please try to see the good in what I say and do - I have no ulterior motives or 
hidden agendas. If you disagree with something I do or say please say so, and 
let’s debate that. 

And while I have your attention, I would like to point out that I believe 
encryption is vital. HTTPS is vital. SSL certs are vital. I love that DV certs 
can be free. None of these opinions mean that the problems I talk about in my 
thesis aren’t real. It’s ok to like a thing, while trying discussing the 
problems that are introduced by that thing. Lifting out a single point I make, 
can take what I mean out of context - just like removing a single word or 
adding an Oxford comma can change the meaning of a sentence. 

It would be strange for me not to support encryption or DV certs. DV and EV use 
the same technology. EV just happens to have ownership identity info for 
browsers to display to end-users. 

I rarely use the term “EV" because I believe website identity is bigger and 
wider. And who’s to the say tech and/or methodology behind the tech doesn’t 
change. The term “EV” seems to upset so many people because they can’t see 
beyond their hate for CAs. This is immature. This discussion shouldn’t be EV vs 
DV. 

I’m motivated by the longterm possibilities of decentralizing the decision 
making process for URL classification.

Back to my thesis about the need for new and better browser UI for website 
identity to help make the web safer, was there something that you disagreed 
with Ronald? 
https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/ 


Thanks,
- Paul

> 
> -R
> 
> On 10/14/2019 11:10 AM, Paul Walsh via dev-security-policy wrote:
>> I have two questions Ronald:
>> 
>> 1. What should I look for? I just see a DV cert from Let’s Encrypt.
>> 
>> 2. Why did you message the entire community about whatever it is you’ve 
>> found?
>> 
>> Thanks,
>> Paul
>> 
>> Sent from my iPhone
>> 
>>> On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy 
>>>  wrote:
>>> 
>>> Just FYI, metacert.com served up this cert recently: 
>>> https://crt.sh/?id=1884181370 .
>>> 
>>> -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
> ___
> 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

Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KQlt:ref

[Support TheFork via dev-security-policy]

We have received your request 03531375 and it is being processed by our support 
team. To leave additional comments, reply to this email.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

The finding is from public information that is relevant to the current 
value of EV certificates, which is a central part of this discussion.


-R

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

I have two questions Ronald:

1. What should I look for? I just see a DV cert from Let’s Encrypt.

2. Why did you message the entire community about whatever it is you’ve found?

Thanks,
Paul

Sent from my iPhone


On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy 
 wrote:

Just FYI, metacert.com served up this cert recently: 
https://crt.sh/?id=1884181370 .

-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

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

Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KPuw:ref

[Support TheFork via dev-security-policy]

We have received your request 03531223 and it is being processed by our support 
team. To leave additional comments, reply to this email.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

I have two questions Ronald:

1. What should I look for? I just see a DV cert from Let’s Encrypt. 

2. Why did you message the entire community about whatever it is you’ve found?

Thanks,
Paul

Sent from my iPhone

> On Oct 12, 2019, at 11:04 AM, Ronald Crane via dev-security-policy 
>  wrote:
> 
> Just FYI, metacert.com served up this cert recently: 
> https://crt.sh/?id=1884181370 .
> 
> -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

Request received : Re: Intent to Ship: Move Extended Validation Information out of the URL bar ref:_00DU0Lfqj._5001v17KLYI:ref

[Support TheFork via dev-security-policy]

We have received your request 03530327 and it is being processed by our support 
team. To leave additional comments, reply to this email.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[carsten.mueller.gl--- via dev-security-policy]

Already the screenshots of the report from 2016 on page 3 show why no normal 
user can recognize if a website was encrypted or if an EV certificate was in 
use.
The browser manufacturers must agree on a uniform, easy-to-understand 
presentation of the security indicators and not change them every month.

The screenshot from the 2019 report also shows why normal users cannot tell if 
an EV certificate is in use: it is simply not recognizable cause most of the 
indicators are deleted.
Please repeat the test with a browser that displays the full company name in 
green AND the complete address bar in green.

In my opinion, the two linked reports are not acceptable due to deliberate 
destruction of the security features in the browser UX.

Am Donnerstag, 10. Oktober 2019 00:23:28 UTC+2 schrieb Ryan Sleevi:
> On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I believe an alternative icon to the encryption lock would make a massive
> > difference to combating the security threats that involve dangerous links
> > and websites. I provided data to back up my beliefs.
> >
> 
> Here's peer-reviewed data, in top-tier venues, that shows the beliefs are
> unfounded:
> https://ai.google/research/pubs/pub48199
> https://ai.google/research/pubs/pub45366
> 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[balasanjay--- via dev-security-policy]

I agree, based on your numbers, Let's Encrypt does seem incredibly dangerous. 
It reminds me of my own research into car safety; did you know over 90% of car 
accidents involve cars with roofs?

Despite this iron-clad evidence of a massive problem, a nice gentleman from the 
NTSB refused to endorse my idea of requiring all cars to be convertibles. 
Despite the fact that this simple solution would probably save thousands of 
lives. There's probably something nefarious going on there, too.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

Just FYI, metacert.com served up this cert recently: 
https://crt.sh/?id=1884181370 .


-R

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

Everything I have ever said on this thread can now be found in one article:

https://casecurity.org/2019/10/10/the-insecure-elephant-in-the-room/

This was by invitation of the CA Security Council a few months ago.

I have never worked for a CA and I have never had any reason to say anything in 
favor of CA’s or EV certificates. This is important to say because some people 
will automatically assume that I’m on one side of this debate. 

A few people asked me off-list for my “white paper”. I don’t have one. But this 
has more than 5,000 words and will likely be turned into one - if I can find 
someone to clean it up and make it better. 

Thanks,
Paul

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

I’ve replied for the record even though you say this is your last post on this 
particular thread, or to me. I’m good with that as I don’t think you care about 
what anything anyone says outside the browser vendor world anyway. 

> On Oct 9, 2019, at 5:09 PM, Ryan Sleevi  wrote:
> 
> 
> 
> On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh  > wrote:
> We can all agree that almost no user knows the difference between a site with 
> a DV cert and a site with an EV cert. I personally came to that conclusion 
> years ago. I wanted data, so I asked more than 3,000 people. Almost everyone 
> assumed the padlock represents identity/safety. 
> 
> If you read the research linked, you'll find it specifically addresses this, 
> and points to the fact that positive security indicators lead to inaccurate 
> conclusions like this, whether EV or DV, and thus important to remove them to 
> assure folks do not make attribution errors.

[PW] Our data with 85,000 active users proves otherwise. And you’ve done 
nothing to counter anything I actually said. I can’t find any product screen 
shots that users used when researching ***new*** visual indicators for website 
identity. Research on EV/DV is completely meaningless as we’ve already 
established that browser implementation was poor at best.

> 
> Since the you later glibly joke about taking your e-mails as a post and 
> publishing as a PDF and calling it peer reviewed, I think it's reasonable to 
> conclude you didn't actually read the links, nor look at the publication 
> venues, or that you don't recognize and/or respect them as leading scientific 
> and academic conferences at the forefront of the space and industry you 
> participate in.

Generally, I question everything that Google has to say about anything in 
relation to privacy and security - so there is a lack of respect in regards to 
motives. But that doesn’t mean I don’t read them. And it doesn’t mean I don’t 
have friends who work for Google. My comment about me PDF’ing something was me 
making fun of myself - it had nothing to do with my opinions about other 
people’s work. I’m not an academic. I never even went to university, so my 
writing skills aren’t as good as anyone who actually writes papers like the 
ones you referenced. What I write is based on real world use cases - not 
theory-based research. They are very different and both are important. 

>  
> I can cite research for search annotation through a browser add-on (2007). It 
> was formally endorsed by the W3C Semantic Web Education and Outreach Program 
> as one of the most compelling implementations of the Semantic Web. But it’s 
> out of date and doesn’t answer the right questions. But here it is 
> https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
> 
> 
> Thanks. This helps confirm that it was not peer reviewed research, but a 
> marketing case study, completed in 2007.

[PW] This one in particular was reviewed in great detail by all of the W3C 
Semantic Web Education & Outreach participants. They reviewed and voted that it 
was “one of the most compelling implementations of the Semantic Web”. Segala 
and its work was then used as a use case for the W3C POWDER initiative, which 
formally replaced PICS in 2009. But it’s all very old and out of date - that 
was the point I was actually trying to make. 

https://www.w3.org/blog/SWEO/ 
>  
>> Do you have any peer-reviewed data to support your beliefs? It seemed like 
>> the only data shared was from vendors marketing solutions in this space, 
>> although perhaps it was overlooked.
> 
> [PW] Perhaps you did overlook it - hard to say as you didn’t reply to the 
> thread that contained the data. 
> 
> Apologies, the volume of the mail you write, versus the new data provided, 
> makes it difficult. Since I must have missed it, it might be useful to 
> provide specific links to your message, or better yet, specific links to the 
> data that has undergone the similar level of scientific rigor and 
> well-respected peer-review.

[PW]  You’re right about my messages - but it’s because people are asking me 
the same questions that have already been answered - but rather than say that, 
I prefer to reply. If you want “peer-review” evidence please stop referencing 
Google and reference companies that aren’t biased and who actually have other 
stakeholders and users best interests in mind. Unless there were non-Google 
employees involved, in which case I would apologize. 

>  
> [PW] Why haven’t you provided any insight to suggest why I’m wrong, instead 
> of asserting that I haven’t provided evidence to back up my assertions? 
> 
> https://twitter.com/krelnik/status/472046082135162881 
> 
> 
> If you review the links provided, you will see that the claims made in your 
> prior e-mail are directly, and easily, contradicted, as being both 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Wed, Oct 9, 2019 at 7:17 PM Paul Walsh  wrote:

> We can all agree that almost no user knows the difference between a site
> with a DV cert and a site with an EV cert. I personally came to that
> conclusion years ago. I wanted data, so I asked more than 3,000 people.
> Almost everyone assumed the padlock represents identity/safety.
>

If you read the research linked, you'll find it specifically addresses
this, and points to the fact that positive security indicators lead to
inaccurate conclusions like this, whether EV or DV, and thus important to
remove them to assure folks do not make attribution errors.

Since the you later glibly joke about taking your e-mails as a post and
publishing as a PDF and calling it peer reviewed, I think it's reasonable
to conclude you didn't actually read the links, nor look at the publication
venues, or that you don't recognize and/or respect them as leading
scientific and academic conferences at the forefront of the space and
industry you participate in.


> I can cite research for search annotation through a browser add-on (2007).
> It was formally endorsed by the W3C Semantic Web Education and Outreach
> Program as one of the most compelling implementations of the Semantic Web.
> But it’s out of date and doesn’t answer the right questions. But here it is
> https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/
>

Thanks. This helps confirm that it was not peer reviewed research, but a
marketing case study, completed in 2007.


> Do you have any peer-reviewed data to support your beliefs? It seemed like
> the only data shared was from vendors marketing solutions in this space,
> although perhaps it was overlooked.
>
>
> [PW] Perhaps you did overlook it - hard to say as you didn’t reply to the
> thread that contained the data.
>

Apologies, the volume of the mail you write, versus the new data provided,
makes it difficult. Since I must have missed it, it might be useful to
provide specific links to your message, or better yet, specific links to
the data that has undergone the similar level of scientific rigor and
well-respected peer-review.


> [PW] Why haven’t you provided any insight to suggest why I’m wrong,
> instead of asserting that I haven’t provided evidence to back up my
> assertions?
>

https://twitter.com/krelnik/status/472046082135162881

If you review the links provided, you will see that the claims made in your
prior e-mail are directly, and easily, contradicted, as being both
factually false and ahistorical. The assertion that WebView-based logins
were disabled (in 2016) were because of failures in the SafeBrowsing API
(not implemented until March 2017) is so easily disproved as factually
false and ahistorical that it beggars belief that I have to refute it.


> But because you asked so nicely:
>
> The following was published by Jonathan Skelker, Product Manager, Account
> Security Google April 2019
>
> “[snip]… one form of phishing, known as “man in the middle
> ”
> (MITM), is hard to detect when an embedded browser framework (e.g., Chromium
> Embedded Framework  - CEF) or
> another automation platform is being used for authentication. MITM
> intercepts the communications between a user and Google in real-time to
> gather the user’s credentials (including the second factor in some cases)
> and sign in. Because we can’t differentiate between a legitimate sign in
> and a MITM attack on these platforms, we will be blocking sign-ins from
> embedded browser frameworks starting in June. This is similar to the 
> restriction
> on webview
> 
>  sign-ins
> announced in April 2016.
>
>
> https://security.googleblog.com/2019/04/better-protection-against-man-in-middle.html
>
> I must extrapolate that if Google is unable to detect these attacks inside
> apps that use the Chromium embedded framework, it means it is unable to
> detect the same attacks inside desktop and mobile versions of Chrome. I
> don’t think any company can - I’m not pointing the finger at Google - I’m
> pointing it at the problem and lack of solutions to the problem globally.
>
> Separately, I wrote about the potential threats of WebView / frameworks
> that display web content inside apps in April 2015, so I’m very much aware
> of everything you say
> https://developer.metacert.com/blog/how-webview-has-weakened-the-tcb-of-the-web-infrastructure/
>  In
> fact, it took people like me to bring these problems to the attention of
> their makers. While I didn’t turn this into a paper, it was referenced by
> senior security researchers at some big firms. Perhaps I should PDF it and
> you can call it a peer-reviewed paper :)
>

Again, I have to refer to the tweet.

The suggestion that you must extrapolate that a third-party fork is
equivalent to a browser is another example of a conclusions being 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul Walsh via dev-security-policy]

I’m sorry for the follow up message - I know we all get too many notifications 
already. But I forgot to add that I was the founder and CEO of Segala - the 
company referenced on the W3C website that I referred to below.

Sorry about that.

Paul



> On Oct 9, 2019, at 4:17 PM, Paul Walsh  wrote:
> 
> 
> 
>> On Oct 9, 2019, at 3:23 PM, Ryan Sleevi > > wrote:
>> 
>> 
>> 
>> On Wed, Oct 9, 2019 at 6:06 PM Paul Walsh via dev-security-policy 
>> > > wrote:
>> I believe an alternative icon to the encryption lock would make a massive 
>> difference to combating the security threats that involve dangerous links 
>> and websites. I provided data to back up my beliefs. 
>> 
>> Here's peer-reviewed data, in top-tier venues, that shows the beliefs are 
>> unfounded:
>> https://ai.google/research/pubs/pub48199 
>> 
>> https://ai.google/research/pubs/pub45366 
>> 
> 
> I don’t disagree with this research. But it’s the wrong research Ryan, asking 
> the wrong questions. You haven’t explained why any of my research draws the 
> wrong conclusions, but I’ll explain why Google's is fundamentally wrong. 
> 
> Perhaps you can do the same for me when you get time. 
> 
> We can all agree that almost no user knows the difference between a site with 
> a DV cert and a site with an EV cert. I personally came to that conclusion 
> years ago. I wanted data, so I asked more than 3,000 people. Almost everyone 
> assumed the padlock represents identity/safety. 
> 
> I can cite research for search annotation through a browser add-on (2007). It 
> was formally endorsed by the W3C Semantic Web Education and Outreach Program 
> as one of the most compelling implementations of the Semantic Web. But it’s 
> out of date and doesn’t answer the right questions. But here it is 
> https://www.w3.org/2001/sw/sweo/public/UseCases/Segala/ 
> 
>> 
>> Do you have any peer-reviewed data to support your beliefs? It seemed like 
>> the only data shared was from vendors marketing solutions in this space, 
>> although perhaps it was overlooked.
> 
> [PW] Perhaps you did overlook it - hard to say as you didn’t reply to the 
> thread that contained the data. 
> 
> The research to which you refer, is from a vendor’s marketing solution. 
> Google is the vendor and Chrome is the marketing solution. This is no 
> different to MetaCert asking 85k power users. 
> 
> We had absolutely no reason to lie to ourselves or to skew opinions for this 
> conversation. 
> 
> We sell security services while verifying domains for free. We needed to do 
> the research to find out if we had a solution to a problem. In theory, we are 
> putting CAs out of business. And if all browsers implemented better UI for 
> website identity, it would put our flagship solution out of business. If I 
> convinced you that you are wrong and I’m right, I’d have more to lose than I 
> would to gain. Right now I’m putting industry and people’s safety ahead of my 
> shareholders. I’m completely impartial to browser vendor vs CA debates on all 
> fronts.
> 
>>  
>> The reverse-proxy phishing technique bypasses Google’s own Safe Browser API 
>> inside their own WebView while their own users sign into Google pages while 
>> using Google’s Authenticator for 2FA. So their answer? In June 2019 they 
>> banned users from signing into Google’s pages while using mobile apps with a 
>> WebView. This tells you what you need to know about Safe Browser API - 
>> finally I have the evidence to prove that it’s an “ok” solution at best. 
>> Most security companies still think it’s great - because they’re not in 
>> possession of all the facts. 
>> 
>> While I suspect I'll regret replying to this message, since so much of it is 
>> off-topic for this discussion Forum, I do want to point out the attribution 
>> error being made with correlation versus causation. You're making a specific 
>> conclusion about why WebView-based sign-ins were banned, without any 
>> supporting data, along with factually-suspect statements that are 
>> unsupported.
> 
> [PW] Why haven’t you provided any insight to suggest why I’m wrong, instead 
> of asserting that I haven’t provided evidence to back up my assertions? 
> 
> But because you asked so nicely:
> 
> The following was published by Jonathan Skelker, Product Manager, Account 
> Security Google April 2019
> 
> “[snip]… one form of phishing, known as “man in the middle 
> ” 
> (MITM), is hard to detect when an embedded browser framework (e.g., Chromium 
> Embedded Framework  - CEF) or 
> another automation platform is being used for authentication. MITM intercepts 
> the communications between a user and Google in real-time to gather the 
> user’s 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Eric Mill via dev-security-policy]

Hi Paul,

Those statements are both hyperbolic representations of others' points of
view.

There are plenty of people who are skeptical about the effectiveness of EV
and its associated UI who nonetheless believe that some sense of
trustworthiness about websites is important. For example, Mozilla
integrates the Safe Browsing system into its applications to protect users
from malicious websites, regardless of whether the connection to that
website was secure.

There are also plenty of people who don't enjoy the sight of certificates
imitating PayPal domains being issued by Let's Encrypt, and may think that
this is a symptom of a larger problem - but still don't agree that
intervention by the CA is the appropriate tool to handle that problem, for
reasons such as the lack of a formal process for adjucating claims (like
the UDPR for registrars), or a general concern about censorship, or an
observation that malware and phishing sites are often deployed to specific
pages on otherwise-good services and that hostname-level enforcement is a
mismatch for the problem.

Putting the hyperbole aside, the general sentiment behind both of those
statements is consistent, and not something I think is in urgent need of
clarification by Mozilla. Further, there are ongoing efforts to improve
online security and trustworthiness that don't rely on CAs doing anything
at all. Services like Microsoft SmartScreen and Google Safe Browsing are
one of those. The deployment of phishing-resistant WebAuthn-based
authentication is another.

Not speaking for anyone else here, I personally see it as futile to rely on
user education for nearly any aspect of security. Instead, we should be
designing systems that do the right thing on the user's behalf wherever
possible. This doesn't necessarily have to rely on large benevolent central
services: WebAuthn is an excellent example of a standard that can be
implemented by anyone in software or hardware, without getting any
company's permission, and integrated in the way that makes the most sense
for users of that service or platform. WebAuthn relies on the domain name
to resist phishing, but doesn't rely on the user having to watch to make
sure they are at the right domain name. If someone ends up at g00gle.com
and doesn't notice, the WebAuthn-based authenticator (whether a YubiKey, a
smartphone fingerprint reader, or a Macbook Touchbar, etc.) will notice on
the user's behalf that the domain name differs from the website that the
authenticator was originally registered at.

That's a very smart model that renders many common classes of attacks
infeasible for even highly well-resourced attackers, while requiring no
user education about how websites or certificates work. And as people get
used to using authenticators that are built into their phone or laptop, and
use the same ceremony that people use to log into those devices themselves
to also log into websites, there will be no user education required for how
to benefit from these advancements.

I'm not trying to argue that WebAuthn alone will save the web, but rather
pointing to it as a fruitful example of where resources are being poured
*instead* of user education or on greater reliance on CAs for ecosystem
monitoring. No one's just sitting back and not caring about phishing:
instead, the ecosystem is responding to the threats as they've observed
them, using a model that is already showing real results in the real world
with real users.

On Tue, Oct 8, 2019 at 2:04 PM Paul Walsh via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> > On Oct 8, 2019, at 4:19 AM, carsten.mueller.gl--- via
> dev-security-policy  wrote:
> >
> >> But the target audience for phishing are uninformed people. People
> which have no idea what a EV cert is. People who don't even blink if the
> English on the phishing page is worse than a 5-year old could produce.
> >>
> >> You cannot base the decision if a EV indication in the browser is
> useful on those people.
> >>
> > The discussions that many users don't even recognize the difference
> between EV/OV/DV certificates is unfortunately true, BUT forced by the
> browsers:
> >
> > When EV certificates were introduced, each browser displayed a green
> address bar including the company name and the country abbreviation of the
> certificate applicant.
> > Gradually the green colouring of the address bar was removed and only
> the company name and country abbreviation were displayed in green.
> > To top it all off, the lock symbol of ALL certificates was displayed in
> green to make the confusion of the users perfect.
> > Google Chrome also removed the green color of the company name.
> >
> > Each browser then had a different display of all certificate types at
> short intervals.
> >
> >
> > In the early days of EV certificates, it was easy for me to tell my
> mother and " uninformed" friends that they should pay attention to the
> green address bar and the company name displayed there, and if possible not

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[carsten.mueller.gl--- via dev-security-policy]

> But the target audience for phishing are uninformed people. People which have 
> no idea what a EV cert is. People who don't even blink if the English on the 
> phishing page is worse than a 5-year old could produce.
> 
> You cannot base the decision if a EV indication in the browser is useful on 
> those people.
> 
The discussions that many users don't even recognize the difference between 
EV/OV/DV certificates is unfortunately true, BUT forced by the browsers:

When EV certificates were introduced, each browser displayed a green address 
bar including the company name and the country abbreviation of the certificate 
applicant.
Gradually the green colouring of the address bar was removed and only the 
company name and country abbreviation were displayed in green.
To top it all off, the lock symbol of ALL certificates was displayed in green 
to make the confusion of the users perfect.
Google Chrome also removed the green color of the company name.

Each browser then had a different display of all certificate types at short 
intervals.


In the early days of EV certificates, it was easy for me to tell my mother and 
" uninformed" friends that they should pay attention to the green address bar 
and the company name displayed there, and if possible not make any purchases or 
data inputs at all on other sites.

It was so simple: green address bar + some intelligence > 99% security

Today: 
- no normal user can display the contents of certificates
- no normal user can recognize which certificate types are actually involved


Of course, you can never be 100% sure that when calling a website with an EV 
certificate:
- no one has stolen the certificate
- another company with a similar name operates a phishing site
However, the effort to do this is so much higher that it is hardly worth it, 
see below.


Also it is pointed out here again and again that EV certificates are so 
insecure, because e.g. a certificate for https://stripe.ian.sh was issued for 
Stripe, Inc located in Kentucky and was displayed by the browsers exactly like 
the EV certificate from Stripe, Inc.
This is not a reason for abolishing EV certificates, but rather a reason to 
talk about the UI of the known browsers.
Each EV certificate lists both the location of the company and the registry. 
Therefore, you can also display "Fima/State/Country" in the address bar of the 
browser.

In addition, it is still much more complicated to operate a fake website with 
an EV certificate (I come from Germany, therefore related to Germany):
- Foundation of a corporation (GmbH):
o min 15.000,- EUR
o Appearance of at least one person at a notary and verification of all data
o Verification of all data by commercial register
- Application for EV certificate

I would like to link to a study on the use of EV certificates for phishing:
https://sectigo.com/uploads/resources/Understanding-the-Role-of-Extended-Validation-Certificates-in-Internet-Abuse.pdf

If the formation of a corporation in other countries is faster/simpler/cheaper, 
it still does not contribute to abuse.


My opinion:
EV certificates are not 100% secure, BUT they increase security enormously.


Why do browsers want to make the Internet less secure? Instead of abolishing 
the EV indicators, they should rather be fully activated again, including the 
green address bar.

Carsten


Translated with www.DeepL.com/Translator
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Wed, Sep 04, 2019 at 03:50:40PM +0200, Kurt Roeckx via dev-security-policy 
wrote:
> On 2019-09-04 14:14, Matt Palmer wrote:
> > If EV information is of use in anti-phishing efforts, then it would be best
> > for the providers of anti-phishing services to team up with CAs to describe
> > the advantages of continuing to provide an EV certificate.  If site owners,
> > who are presumably smart people with significant technical skills making
> > decisions on a rational basis, don't see the benefits (after a little
> > training), perhaps you should accept their decision, even if you disagree
> > with them or have a different commercial interest.
> 
> So I think what you're saying is that sites with EV will still be more
> trusted, but the browser isn't really aware of it.

I trust the security of sites that I manage more than I trust rando sites on
the Internet, but the browser isn't really aware of it either.  Did you have
a useful point to make?

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kurt Roeckx via dev-security-policy]

On 2019-09-04 14:14, Matt Palmer wrote:


If EV information is of use in anti-phishing efforts, then it would be best
for the providers of anti-phishing services to team up with CAs to describe
the advantages of continuing to provide an EV certificate.  If site owners,
who are presumably smart people with significant technical skills making
decisions on a rational basis, don't see the benefits (after a little
training), perhaps you should accept their decision, even if you disagree
with them or have a different commercial interest.


So I think what you're saying is that sites with EV will still be more 
trusted, but the browser isn't really aware of it.



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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Tue, Sep 03, 2019 at 06:16:23PM -0700, Kirk Hall via dev-security-policy 
wrote:
> However, I did receive authority to post the following statement from
> someone who works for a major browser phishing filter (but without
> disclosing the person's name or company).  Here is the authorized
> statement:
> 
> “A browser phishing filter representative has confirmed that (1) their
> research teams do look at EV certificate attributes and do feel there
> is signal there for phish/malware detection, and (2) they would like
> to have continued access to this EV data.”
> 
> I think this establishes the point I made last week – that EV data is
> valuable for anti-phishing efforts and so EV should be supported by the
> browsers.

I think you're overstating the case somewhat.  The statement you quoted
establishes that EV data is *used* for anti-phishing efforts.  It certainly
says nothing in support of the assertion that EV should be supported by
browsers.  It also doesn't address the concerns that Ryan put forward
regarding the advisability of using EV data for anti-phishing.

> I’m still concerned that removing the EV UI in Firefox could cause some EV
> sites to stop using EV certificates which in turn would eliminate the
> availability of their EV website data from the security ecosystem.  This
> possible adverse outcome should be considered by Mozilla before it removes
> its EV UI.

Mozilla should do what is best for the users of Mozilla products[1].  Asking
Mozilla to carry a feature in Firefox that is of zero-to-negative value to
Firefox users, so as to provide benefits to anti-phishing systems, is as
nonsensical as asking Mozilla to do the same purely to provide revenue
benefits to CAs.

If EV information is of use in anti-phishing efforts, then it would be best
for the providers of anti-phishing services to team up with CAs to describe
the advantages of continuing to provide an EV certificate.  If site owners,
who are presumably smart people with significant technical skills making
decisions on a rational basis, don't see the benefits (after a little
training), perhaps you should accept their decision, even if you disagree
with them or have a different commercial interest.

- Matt

[1] within the context of the use of Mozilla products, at any rate.  I'm
sure it would be best for the users of Mozilla products if everyone
using Firefox got a million dollars and a pony, but I hope nobody's
going to start agitating for Mozilla to get into the equine distribution
game.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

Last week I posted reasons why Mozilla shouldn’t remove the EV UI from Firefox. 
 In addition to the discussion on how the EV UI can inform users when a website 
does or does not have confirmed identity before they choose to type in their 
password or credit card number (after a little user training), I also mentioned 
that EV certificate Subject information (organization name, etc.) is currently 
used by browser phishing filters and by anti-phishing services.  I was then 
asked to corroborate that, and so I have communicated with some of our sources 
(the Labor Day holiday has slowed things down) to ask them for an authorized 
statement.

As some have suggested on this list, there may be reluctance by some services 
that use EV cert data to repeat on a public list what they have told us in 
private over the years both for competitive reasons and also to avoid giving 
phishers clues as to how to beat their algorithms.  

However, I did receive authority to post the following statement from someone 
who works for a major browser phishing filter (but without disclosing the 
person's name or company).  Here is the authorized statement:

 “A browser phishing filter representative has confirmed that (1) their 
research teams do look at EV certificate attributes and do feel there is signal 
there for phish/malware detection, and (2) they would like to have continued 
access to this EV data.”

I think this establishes the point I made last week – that EV data is valuable 
for anti-phishing efforts and so EV should be supported by the browsers.  I’m 
still concerned that removing the EV UI in Firefox could cause some EV sites to 
stop using EV certificates which in turn would eliminate the availability of 
their EV website data from the security ecosystem.  This possible adverse 
outcome should be considered by Mozilla before it removes its EV UI.

If and when I am authorized to post more statements from others, I will.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Josef Schneider via dev-security-policy]

Am Sonntag, 1. September 2019 04:27:04 UTC+2 schrieb Peter Gutmann:

> Since the value to criminals of EV web certs is low, it seems they're not
> doing much to stop what the criminals are doing.  If they did have any value
> then criminals would be prepared to pay more for them, like they already do
> for EV code-signing certs.

But the target audience for phishing are uninformed people. People which have 
no idea what a EV cert is. People who don't even blink if the English on the 
phishing page is worse than a 5-year old could produce.

You cannot base the decision if a EV indication in the browser is useful on 
those people.

Same as you all, I don't have any “official” data to base these beliefs on. But 
for example there are studies which conclude that email scammers intentionally 
use unbelievable stories and bad grammar. Why do they do this? Because sending 
mails is free but interacting with replies is costly. They only want the most 
gullible people to answer in the first place.

In the same way, I argue, even if criminals would create scam websites with EV 
certificates, fewer people would notice immediately that the page is wrong. But 
this people are not the target group of the scammer anyway. This are the users 
that are already aware of the dangers on the internet. If they wouldn't leave 
the page because of the missing EV certificate, they would most likely find 
another sign that the page is fake and still leave.

The reason why criminals don't need EV certificates is: The people caring about 
EV indicators are not their target group.

The problem is that the data actually needed is missing and many here just use 
the easily available data and pretend it is possible to draw any valid 
conclusions from that.

The data we would need is: How many people do leave a malicious webpage because 
the EV indicator is missing?

The only data I have seen here is: (Estimated) how many people do enter their 
data in malicious websites.

It is just simply not possible to draw any information about the first question 
from answers to the second.

Using the same logic applied by many in favor of removing the EV indication one 
could argue against almost anything. E.g. for arguing against DUI laws:
1. Find a point in time when no DUI laws existed in a jurisdiction and there 
were fewer cases of drunk drivers than now. (trivial, because at some time 
there even where fewer drivers in total than drunk drivers now)
2. Argue that the DUI laws obviously don't prevent drunk driving, because not 
only are there still people driving drunken, but there are even a lot more of 
them than at the time found in 1.

I hope no one would believe that drunk driving wouldn't increase a lot if the 
laws were removed now.

For the EV indicator, we just don't know how many people prevented being 
scammed because of this. And removing a security feature because we don't know 
if it is successful is a dangerous thing to do. The better way would be to find 
out if it is really so useless as argued by some here. If it is that obvious 
that it is not helping, producing this data should be an easy task.

But the information “some people fall for scams with DV certificates” is not 
the right information to decide this. The interesting people are the ones NOT 
falling for a scam because it is using a DV certificate and I haven't seen 
anyone giving any data about them here.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Gutmann via dev-security-policy]

Kirk Hall via dev-security-policy  
writes:

>does GSB use any EV certificate identity data in its phishing algorithms.

Another way to think about this this is to look at it from the criminals'
perspective: What's the value to criminals?  To use a silly example, the value
to criminals of an unregistered handgun is quite high, while the value to
criminals of a plastic water pistol is negligible.  We know from black-market
EV-cert vendors that the value of an EV code-signing cert to criminals is
high, and one with reputation attached is even higher because it gets you
instant malware execution with no warnings from anti-malware software.  OTOH
the value to criminals of EV web site certs appears to be low to nonexistent
because the sites selling them advertise them as also-rans, "we've also got
some of these if you want them", they barely feature.

Since the value to criminals of EV web certs is low, it seems they're not
doing much to stop what the criminals are doing.  If they did have any value
then criminals would be prepared to pay more for them, like they already do
for EV code-signing certs.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Fri, 30 Aug 2019 12:02:42 -0500
Matthew Hardeman via dev-security-policy
 wrote:

> What's not discussed in that mechanism is how Google decides what
> pages are unsafe and when?

Yes, but the point was to show what shape Safe Browsing API is, I guess
I'd assumed this makes it obvious that EV doesn't really fit well but
didn't spell that out properly.

Google doesn't end up able to interrogate whether the site the user is
visiting presented them an EV certificate. Indeed in most cases it will
have no idea they visited a site, let alone which certificate was
presented.

But yes, it would be possible to use EV as an input to a manual
process to create the list of phishing pages. It would also be possible
to use astrology. If I were tasked with this I would not do either.


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

Kirk,

I know you are really passionate about extended validation and it does
come across in your correspondences on this forum and the CAB Forum
but sometimes our passion or frustration leads us to divulge private
information which shouldn't have been released into the public domain.
Before you post any other correspondences to this forum or any other
forum, give it a check over or leave it until you are in a better
frame of mind. You don't want to accidentally break the NDA agreements
you have signed over the course of your work.

Thank you,

Burton

On Fri, Aug 30, 2019 at 8:45 PM Kirk Hall via dev-security-policy
 wrote:
>
> On Friday, August 30, 2019 at 11:38:55 AM UTC-7, Peter Bowen wrote:
> > On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > I'll just reiterate my point and then drop the subject.  EV certificate
> > > subject information is used by anti-phishing services and browser phishing
> > > filters, and it would be a loss to the security ecosystem if this EV data
> > > disappears (meaning that the decision on removal of the EV UI has greater
> > > repercussions than just whether or not users can tell in the primary UI if
> > > their website does or does not have any confirmed identity information).
> > >
> >
> > Kirk,
> >
> > I have to admit that the first time I ever heard of browser phishing
> > filters and Internet security products (such as Trend Micro, Norton,
> > Mcafee, etc) differentiating between DV and EV SSL certificates as part of
> > their algorithm is in this thread, from you.  As someone who has a website,
> > I would really appreciate it if you could point to where this is
> > documented.  This morning I looked at a couple of network security vendor
> > products I've used and couldn't find any indication they differentiate, but
> > if there are ones that do it would certainly influence my personal decision
> > on the kind of certificates to use and to recommend others to use.
> >
> > I'm not personally aware of anyone doing this.  Are you aware of any
> > product literature that discusses this?
> >
> > Thanks,
> > Peter
>
> I have some emails out asking permission to share information that was given 
> to us in the past.  If I receive permission, I will post something further.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Friday, August 30, 2019 at 11:38:55 AM UTC-7, Peter Bowen wrote:
> On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > I'll just reiterate my point and then drop the subject.  EV certificate
> > subject information is used by anti-phishing services and browser phishing
> > filters, and it would be a loss to the security ecosystem if this EV data
> > disappears (meaning that the decision on removal of the EV UI has greater
> > repercussions than just whether or not users can tell in the primary UI if
> > their website does or does not have any confirmed identity information).
> >
> 
> Kirk,
> 
> I have to admit that the first time I ever heard of browser phishing
> filters and Internet security products (such as Trend Micro, Norton,
> Mcafee, etc) differentiating between DV and EV SSL certificates as part of
> their algorithm is in this thread, from you.  As someone who has a website,
> I would really appreciate it if you could point to where this is
> documented.  This morning I looked at a couple of network security vendor
> products I've used and couldn't find any indication they differentiate, but
> if there are ones that do it would certainly influence my personal decision
> on the kind of certificates to use and to recommend others to use.
> 
> I'm not personally aware of anyone doing this.  Are you aware of any
> product literature that discusses this?
> 
> Thanks,
> Peter

I have some emails out asking permission to share information that was given to 
us in the past.  If I receive permission, I will post something further.  
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 30, 2019 at 12:06 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> This is super easy, and doesn't even require you to do any work, like
> contacting Google Safe Browsing and asking them to participate in this
> conversation.
>
> Here's the question, and all I'm asking you to do is answer "Yes," "No,"
> or "I Don't Know"
>
> **Based on your personal knowledge, does Google Safe Browsing use any EV
> certificate Subject information in its anti-phishing algorithms?**


That is indeed the question I was asking you, and I hope you can answer.
Will you answer it?

To recall, since you've shifted the conversation rather substantially, and
thus perhaps forgotten the original question, which you've repeatedly
avoided:
- You made a definitive claim this information is used by one or more
parties, and described how it was used.
- I asked for details, to understand how they address the obvious issues
with using it like this.

If you have personal knowledge that GSB uses it like you described, it's
reasonable to ask to report back as to how those issues are addressed, from
whoever you obtained this knowledge from.

If you do not have personal knowledge that GSB uses it like you described,
then continuing to discuss GSB is not useful for this discussion.

I had thought the question originally asked, of your bold claim, was
simple. I'm not sure why you've focused on trying to find out new
information, rather than simply sharing more information about what you
presented.

It would be very useful information to everyone on this list if you would
share any sort of information about what you described. Since you made it
clear you knew of some organizations using this, it seemed reasonable that
you could ask them how they address this, without having to reveal who they
are. After all, if they're comfortable with you sharing that they do this,
surely they'd have no problem with you sharing, anonymously, how they solve
it.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Bowen via dev-security-policy]

On Fri, Aug 30, 2019 at 10:22 AM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I'll just reiterate my point and then drop the subject.  EV certificate
> subject information is used by anti-phishing services and browser phishing
> filters, and it would be a loss to the security ecosystem if this EV data
> disappears (meaning that the decision on removal of the EV UI has greater
> repercussions than just whether or not users can tell in the primary UI if
> their website does or does not have any confirmed identity information).
>

Kirk,

I have to admit that the first time I ever heard of browser phishing
filters and Internet security products (such as Trend Micro, Norton,
Mcafee, etc) differentiating between DV and EV SSL certificates as part of
their algorithm is in this thread, from you.  As someone who has a website,
I would really appreciate it if you could point to where this is
documented.  This morning I looked at a couple of network security vendor
products I've used and couldn't find any indication they differentiate, but
if there are ones that do it would certainly influence my personal decision
on the kind of certificates to use and to recommend others to use.

I'm not personally aware of anyone doing this.  Are you aware of any
product literature that discusses this?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

> OK, I'll try one last time to see if you are willing to share Google 
> information that you have with this group on the question at hand (Do browser 
> phishing filters and anti-virus apps use EV data in their anti-phishing 
> algorithms).  
> 
> This is super easy, and doesn't even require you to do any work, like 
> contacting Google Safe Browsing and asking them to participate in this 
> conversation.
> 
> Here's the question, and all I'm asking you to do is answer "Yes," "No," or 
> "I Don't Know"
> 
> **Based on your personal knowledge, does Google Safe Browsing use any EV 
> certificate Subject information in its anti-phishing algorithms?**
> 
> This will be useful information to everyone on this list.
> 
> Thanks for your cooperation.

I want to withdraw the question above that I posed to Ryan - I posted this last 
night in frustration, but I was wrong to put someone on the spot like that.

I'll just reiterate my point and then drop the subject.  EV certificate subject 
information is used by anti-phishing services and browser phishing filters, and 
it would be a loss to the security ecosystem if this EV data disappears 
(meaning that the decision on removal of the EV UI has greater repercussions 
than just whether or not users can tell in the primary UI if their website does 
or does not have any confirmed identity information).

I hope Mozilla will pivot to a redesigned EV UI (instead of removing it 
entirely) like the Apple UI (green lock and URL when EV identity is present, 
black lock symbol/UI for anonymous sites).  

That solution (1) seems to satisfy the concerns Mozilla started with (that 
users don't understand specific ownership data presently shown in the Firefox 
UI), (2) allows users to know the identity status of a website before they 
enter their password or credit card number, (3) would allow for easy user 
training on the meaning of the new Firefox UI, (4) would continue to 
incentivize enterprise website owners to continue using EV certificates, 
thereby continuing to populate the security ecosystem with very useful data 
related to website domains that can be used for anti-phishing purposes, (5) 
work very well in a mobile environment where space is limited, (6) probably 
represent a modest engineering effort to make the change and maintain it, and 
(7) start the process of creating a common UI among different browsers (Apple 
is there already), which can only be good for user security.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matthew Hardeman via dev-security-policy]

On Fri, Aug 30, 2019 at 11:56 AM Nick Lamb via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

>
> For readers unfamiliar, let me briefly explain what Safe Browsing gives
> browsers:
>
> For every URL you're considering displaying you calculate a whole bunch
> of cryptographic hashes, of the whole URL, just the FQDN and certain
> other combinations. Then you truncate the hashes and you see if the
> truncated hashes are in a small list Google gave you (a browser will
> update this list periodically using a synchronisation API Google
> designed for the purpose).
>
> If one of your truncated hashes /is/ in the list, maybe this is
> Phishing! You call Google, telling them the truncated hash you are
> worried about, and Google gives you a complete list of full (not
> truncated) hashes you should worry about with this prefix. It might be
> empty (the phishing attack is gone) or have multiple entries.
>
> Only if the full hash you were worried about is in that fresh list from
> Google do you tell the user "Ohoh. Phishing, probably go somewhere
> else" in all other cases everything is fine.
>

What's described here is how the browser determines with the service
whether the page you visit is on the list of what Google considers to be a
likely unsafe page.

What's not discussed in that mechanism is how Google decides what pages are
unsafe and when?

Say, for example, you're actively monitoring a property that historically
has had EV presentation.  For high value sites, especially in finance,
perhaps the database notes that EV is "normal" for the site.  If subsequent
checks against that site lack EV, perhaps it flags a human review to
determine if the site has been hijacked.  Perhaps it combines the change of
EV status with a change in other underlying elements (new / different a-DNS
set, A records resolving to suspicious IP space, etc.)  But I'm not sure we
can really know, unless they're willing to say.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 18:44:11 -0700 (PDT)
Kirk Hall via dev-security-policy
 wrote:

> OK, I'll try one last time to see if you are willing to share Google
> information that you have with this group on the question at hand (Do
> browser phishing filters and anti-virus apps use EV data in their
> anti-phishing algorithms).  

For the AV apps I can totally believe they'd do this because bogus
assumptions are more or less their bread and butter. "It's an EV cert
so it's safe" is exactly the kind of logic I can imagine them employing.

But it really doesn't seem like a good fit for Google Safe Browsing,
if they do try to triangulate from EV that seems like a big leap to me.

For readers unfamiliar, let me briefly explain what Safe Browsing gives
browsers:

For every URL you're considering displaying you calculate a whole bunch
of cryptographic hashes, of the whole URL, just the FQDN and certain
other combinations. Then you truncate the hashes and you see if the
truncated hashes are in a small list Google gave you (a browser will
update this list periodically using a synchronisation API Google
designed for the purpose).

If one of your truncated hashes /is/ in the list, maybe this is
Phishing! You call Google, telling them the truncated hash you are
worried about, and Google gives you a complete list of full (not
truncated) hashes you should worry about with this prefix. It might be
empty (the phishing attack is gone) or have multiple entries.

Only if the full hash you were worried about is in that fresh list from
Google do you tell the user "Ohoh. Phishing, probably go somewhere
else" in all other cases everything is fine.


This design has important privacy properties because it means Google
definitely isn't told which pages you visit, and ordinarily it doesn't
even learn roughly how many pages you're visiting or anything like
that. Only when you try to visit a phishing site, or there's a random
coincidence, it learns (if it chooses to remember) that someone from
your IP either tried to visit a phishing site or there was a random
coincidence, and not which of those options it was.

Most Phishing detections aren't for a whole site, they are
page-specific. So maybe jims-oil-change.example is a perfectly
legitimate site for Jim the auto mechanic with a Let's Encrypt cert, but
his poorly configured PHP setup means bad guys create
https://jims-oil-change.example/.temp/PayPal.com/security which is a
PayPal phish form.

The Safe Browsing design lets Google add the hash for that nasty
phishing page, without also making Jim's harmless front page get an
angry message in browsers.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matthew Hardeman via dev-security-policy]

>
> I’m not saying that this is the case, but merely to say that the
> Yes/No/IDK does not represent the full set of feasible responses.
>

So let's add "I decline to make inquiries, official or otherwise" and
"Policy prevents me from discussing that" to the list.  It would be
interesting to get one of any of the mentioned responses back.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Neil Dunbar via dev-security-policy]

> On 30 Aug 2019, at 02:44, Kirk Hall via dev-security-policy 
>  > wrote:
> 
> OK, I'll try one last time to see if you are willing to share Google 
> information that you have with this group on the question at hand (Do browser 
> phishing filters and anti-virus apps use EV data in their anti-phishing 
> algorithms).  
> 
> This is super easy, and doesn't even require you to do any work, like 
> contacting Google Safe Browsing and asking them to participate in this 
> conversation.
> 
> Here's the question, and all I'm asking you to do is answer "Yes," "No," or 
> "I Don't Know"
> 
> **Based on your personal knowledge, does Google Safe Browsing use any EV 
> certificate Subject information in its anti-phishing algorithms?**

Kirk,

There is also the possibility that Ryan may have such knowledge, but absent 
permission from his employer, he is not at liberty to disclose internal company 
policies and procedures on an open forum. Indeed, it would not surprise me if 
this were the situation.

I’m not saying that this is the case, but merely to say that the Yes/No/IDK 
does not represent the full set of feasible responses.

Regards,

Neil

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 6:15:44 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > What the heck does it mean when sometimes you say you are posting "in a
> > personal capacity" and sometimes you don't?
> 
> 
> It sounds like you were very prescient in your inability to remember
> things, as you mentioned at
> https://groups.google.com/d/msg/mozilla.dev.security.policy/cCeLZuxAOvQ/iM1cbmxjDgAJ
> 
> Hope that helps explain how things work. I sometimes include it to help jog
> the memory of folk who tend to forget, so sorry that the extra reminder
> sounds like it might have confused you.
> 
> 
> > does GSB use any EV certificate identity data in its phishing algorithms.
> > My understanding is that the answer is yes,
> >
> 
> That's a good question, but I'm not sure where your understanding came
> from! I was hoping you could share more, since that would definitely be the
> easiest way to confirm it. It sounds like you're not sure, and you don't
> have any evidence handy. If you can find out more information, can you
> report back? It seems like you have some contacts or some information that
> led you to your conclusion, I'm sure there is no one more effective or
> efficient at finding an answer than you.
> 
> I've never heard of that, so of course, I wouldn't know where to start. On
> the other hand, if you're not sure, it might be clearer not to definitively
> state that's how things work, or presume they work? That might make it a
> bit clearer about what's real and what's imagined, in case you're just
> misremembering things. After all, if you don't know, and I don't know, and
> no one else here knows, maybe it's worth focusing on the things we do know
> instead of speculating?
> 
> The information I have about use of EV identity data for anti-phishing
> > algorithms was all provided in private communications, so I would not be
> > able to name any names without permission.  I have already emailed two
> > people about this,
> >
> 
> Great! Then it sounds like we're on track to having you report back once
> you know more. I look forward to hearing how they've solved this, as it
> sounds like EV might have be valuable even when the UI isn't shown. That
> would be great validation that you don't need to show prominent UI to get
> user benefit.

OK, I'll try one last time to see if you are willing to share Google 
information that you have with this group on the question at hand (Do browser 
phishing filters and anti-virus apps use EV data in their anti-phishing 
algorithms).  

This is super easy, and doesn't even require you to do any work, like 
contacting Google Safe Browsing and asking them to participate in this 
conversation.

Here's the question, and all I'm asking you to do is answer "Yes," "No," or "I 
Don't Know"

**Based on your personal knowledge, does Google Safe Browsing use any EV 
certificate Subject information in its anti-phishing algorithms?**

This will be useful information to everyone on this list.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Leo Grove via dev-security-policy]

On Thursday, August 29, 2019 at 5:26:55 PM UTC-5, Kirk Hall wrote:
> On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> > 
> > >
> > > Don't argue with me, argue with the browser phishing filters and
> > > anti-phishing services who do, in fact, use EV website information to
> > > protect users as I described.  Presumably they know what they are doing.
> > 
> > 
> > Sorry that it sounded like I'm arguing. I'm just trying to understand the
> > premise, since it so obviously has security holes that would make EV
> > certificates more dangerous for any user who relied on such services.
> > 
> > Could you point to the browsing phishing filters and anti-phishing services
> > that do? It might be an opportunity for you to find out how they deal with
> > this, and report back, so we don't have to presume anything.
> 
> Let's hear directly from the experts - can you get someone from Google Safe 
> Browsing to post to this list, and then we can all ask him or her our 
> questions and get the definitive answers.  Thanks.

Kirk,

What you are implying about GSB (and possibly other phishing filters) using the 
information contained within EV SSL certificates as part of their algorithm 
changes the reliance of EV SSL/TLS in fundamental ways.

The end result of removing the EV UI is that the decision to trust a website 
based on EV is practically transferred from the user to GSB and other phishing 
filters since the user cannot see the EV UI. The user is still impacted by the 
EV information depending on how GSB interprets it along with other signals. 

If GSB does factor in EV, I'm curious to learn how they use the jurisdiction 
information in the EV certificates as well as other information. Some posters 
on this thread advocate doing away with the EV UI due to issues discussed 
previously, but I wonder if they are aware that this information still might be 
used to block certain websites or influence the user's behavior without the 
user ever knowing that the EV information was used.

Will CAs market EV SSL as a way for sites to increase their "scores" with GSB 
and other phishing filters?


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Thu, Aug 29, 2019 at 02:14:10PM -0700, Kirk Hall via dev-security-policy 
wrote:
> For EV certificates, the appeal for website owners over the past 10 years
> has been that they get a distinctive EV UI that they believe protects
> their consumers and their brands (again, don't argue with me but argue
> with them - but these website owners include many of the top enterprises
> and brands, so presumably they are smart people too with significant
> technical skills and have made their own EV decisions on a rational basis,
> even if you disagree with them or have a different commercial interest in
> supporting or not supporting website identity).

On the contrary, I think it's perfectly reasonable to discuss this stance
with representatives of CAs, as it is, in my estimation, primarily the
marketing activities of CAs which has created this belief in website owners.

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 8:54 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> What the heck does it mean when sometimes you say you are posting "in a
> personal capacity" and sometimes you don't?


It sounds like you were very prescient in your inability to remember
things, as you mentioned at
https://groups.google.com/d/msg/mozilla.dev.security.policy/cCeLZuxAOvQ/iM1cbmxjDgAJ

Hope that helps explain how things work. I sometimes include it to help jog
the memory of folk who tend to forget, so sorry that the extra reminder
sounds like it might have confused you.


> does GSB use any EV certificate identity data in its phishing algorithms.
> My understanding is that the answer is yes,
>

That's a good question, but I'm not sure where your understanding came
from! I was hoping you could share more, since that would definitely be the
easiest way to confirm it. It sounds like you're not sure, and you don't
have any evidence handy. If you can find out more information, can you
report back? It seems like you have some contacts or some information that
led you to your conclusion, I'm sure there is no one more effective or
efficient at finding an answer than you.

I've never heard of that, so of course, I wouldn't know where to start. On
the other hand, if you're not sure, it might be clearer not to definitively
state that's how things work, or presume they work? That might make it a
bit clearer about what's real and what's imagined, in case you're just
misremembering things. After all, if you don't know, and I don't know, and
no one else here knows, maybe it's worth focusing on the things we do know
instead of speculating?

The information I have about use of EV identity data for anti-phishing
> algorithms was all provided in private communications, so I would not be
> able to name any names without permission.  I have already emailed two
> people about this,
>

Great! Then it sounds like we're on track to having you report back once
you know more. I look forward to hearing how they've solved this, as it
sounds like EV might have be valuable even when the UI isn't shown. That
would be great validation that you don't need to show prominent UI to get
user benefit.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 5:28:29 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > > dev-security-policy@lists.mozilla.org> wrote:
> > >
> > > > > Could you point to the browsing phishing filters and anti-phishing
> > > > services
> > > > > that do? It might be an opportunity for you to find out how they deal
> > > > with
> > > > > this, and report back, so we don't have to presume anything.
> > > >
> > > > Let's hear directly from the experts - can you get someone from Google
> > > > Safe Browsing to post to this list, and then we can all ask him or her
> > our
> > > > questions and get the definitive answers.  Thanks.
> > >
> > >
> > > I think it’s a great idea to hear from the experts!
> > >
> > > So far, it’s hard to tell who they are, because you haven’t been able to
> > > provide any details about who does what you describe. It sounded
> > initially
> > > like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> > > could provide sources? And then ask folks at those organizations and
> > report
> > > back? It seems that you’re passionate about this, and I can’t think of
> > > anyone better suited to demonstrate whether or not this actually happens
> > > than someone as passionate for the truth as you. I’m sure you’ll be able
> > to
> > > find out whether or not the world works like you described and report
> > back
> > > to us all.
> > >
> > > Look forward to hearing more about who actually does this, and how they
> > > solve the very obvious security risks. I’m assuming that if we don’t hear
> > > back, it might mean no one actually does this, or that perhaps no one has
> > > solved this obvious security issues.
> >
> > Uh... Ryan...  some of the experts work down the hall from you.  Google
> > Safe Browsing.  This was the question I posed to you:
> >
> > "Can you get someone from Google Safe Browsing to post to this list, and
> > then we can all ask him or her our questions and get the definitive
> > answers."
> >
> > What is your response?
> >
> 
> Oh, I thought I made it clear, I'm posting in a personal capacity.
> 
> As you're the one making the claim, I was hoping you might demonstrate
> whether there's any truth. I certainly wouldn't want to bother anyone just
> because someone on the Internet said something. I'm sure no one would get
> any work done if they had to respond to everyone who had a half-baked idea
> about how things might work.
> 
> Of course, that also wouldn't help answer the question I asked of you, in
> the context of what you claimed:
> "Could you point to the browsing phishing filters and anti-phishing
> services that do? It might be an opportunity for you to find out how they
> deal with this, and report back, so we don't have to presume anything."
> 
> What is your response?

What the heck does it mean when sometimes you say you are posting "in a 
personal capacity" and sometimes you don't?  To me, it always appears that your 
postings on the Mozilla list are always the same as your postings on the 
CA/Browser Forum list and are always for the purpose of promoting Google's 
policies and objectives.  Is there really a difference?

Ryan, seriously - please (acting in a personal capacity, or in an official 
capacity, you choose) pull in a Google Safe Browsing expert so we can all get 
some answers on this fairly important question - does GSB use any EV 
certificate identity data in its phishing algorithms.  My understanding is that 
the answer is yes, but there is an easy way to confirm that (or change that) by 
talking to a Google Safe Browsing expert, and it's in your hands.

The information I have about use of EV identity data for anti-phishing 
algorithms was all provided in private communications, so I would not be able 
to name any names without permission.  I have already emailed two people about 
this, but if you're not even willing to put this group in contact with GSB or 
provide any information from GSB (either yes or no on whether GSB uses EV cert 
identity information), then I'm not going to bother any further.  Your 
unwillingness to help the group on this list get that information from GSB 
speaks volumes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 8:23 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> > On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> > > > Could you point to the browsing phishing filters and anti-phishing
> > > services
> > > > that do? It might be an opportunity for you to find out how they deal
> > > with
> > > > this, and report back, so we don't have to presume anything.
> > >
> > > Let's hear directly from the experts - can you get someone from Google
> > > Safe Browsing to post to this list, and then we can all ask him or her
> our
> > > questions and get the definitive answers.  Thanks.
> >
> >
> > I think it’s a great idea to hear from the experts!
> >
> > So far, it’s hard to tell who they are, because you haven’t been able to
> > provide any details about who does what you describe. It sounded
> initially
> > like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> > could provide sources? And then ask folks at those organizations and
> report
> > back? It seems that you’re passionate about this, and I can’t think of
> > anyone better suited to demonstrate whether or not this actually happens
> > than someone as passionate for the truth as you. I’m sure you’ll be able
> to
> > find out whether or not the world works like you described and report
> back
> > to us all.
> >
> > Look forward to hearing more about who actually does this, and how they
> > solve the very obvious security risks. I’m assuming that if we don’t hear
> > back, it might mean no one actually does this, or that perhaps no one has
> > solved this obvious security issues.
>
> Uh... Ryan...  some of the experts work down the hall from you.  Google
> Safe Browsing.  This was the question I posed to you:
>
> "Can you get someone from Google Safe Browsing to post to this list, and
> then we can all ask him or her our questions and get the definitive
> answers."
>
> What is your response?
>

Oh, I thought I made it clear, I'm posting in a personal capacity.

As you're the one making the claim, I was hoping you might demonstrate
whether there's any truth. I certainly wouldn't want to bother anyone just
because someone on the Internet said something. I'm sure no one would get
any work done if they had to respond to everyone who had a half-baked idea
about how things might work.

Of course, that also wouldn't help answer the question I asked of you, in
the context of what you claimed:
"Could you point to the browsing phishing filters and anti-phishing
services that do? It might be an opportunity for you to find out how they
deal with this, and report back, so we don't have to presume anything."

What is your response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 5:07:03 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > > Could you point to the browsing phishing filters and anti-phishing
> > services
> > > that do? It might be an opportunity for you to find out how they deal
> > with
> > > this, and report back, so we don't have to presume anything.
> >
> > Let's hear directly from the experts - can you get someone from Google
> > Safe Browsing to post to this list, and then we can all ask him or her our
> > questions and get the definitive answers.  Thanks.
> 
> 
> I think it’s a great idea to hear from the experts!
> 
> So far, it’s hard to tell who they are, because you haven’t been able to
> provide any details about who does what you describe. It sounded initially
> like a hypothetical, but now that you’ve stated it’s factual, perhaps you
> could provide sources? And then ask folks at those organizations and report
> back? It seems that you’re passionate about this, and I can’t think of
> anyone better suited to demonstrate whether or not this actually happens
> than someone as passionate for the truth as you. I’m sure you’ll be able to
> find out whether or not the world works like you described and report back
> to us all.
> 
> Look forward to hearing more about who actually does this, and how they
> solve the very obvious security risks. I’m assuming that if we don’t hear
> back, it might mean no one actually does this, or that perhaps no one has
> solved this obvious security issues.

Uh... Ryan...  some of the experts work down the hall from you.  Google Safe 
Browsing.  This was the question I posed to you:

"Can you get someone from Google Safe Browsing to post to this list, and then 
we can all ask him or her our questions and get the definitive answers."

What is your response?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 6:26 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > Could you point to the browsing phishing filters and anti-phishing
> services
> > that do? It might be an opportunity for you to find out how they deal
> with
> > this, and report back, so we don't have to presume anything.
>
> Let's hear directly from the experts - can you get someone from Google
> Safe Browsing to post to this list, and then we can all ask him or her our
> questions and get the definitive answers.  Thanks.


I think it’s a great idea to hear from the experts!

So far, it’s hard to tell who they are, because you haven’t been able to
provide any details about who does what you describe. It sounded initially
like a hypothetical, but now that you’ve stated it’s factual, perhaps you
could provide sources? And then ask folks at those organizations and report
back? It seems that you’re passionate about this, and I can’t think of
anyone better suited to demonstrate whether or not this actually happens
than someone as passionate for the truth as you. I’m sure you’ll be able to
find out whether or not the world works like you described and report back
to us all.

Look forward to hearing more about who actually does this, and how they
solve the very obvious security risks. I’m assuming that if we don’t hear
back, it might mean no one actually does this, or that perhaps no one has
solved this obvious security issues.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Josef Schneider via dev-security-policy]

Am Donnerstag, 29. August 2019 10:59:40 UTC+2 schrieb Nick Lamb:
> On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
> Josef Schneider via dev-security-policy
>  wrote:
> 
> > Not legally probably and this also depends on the jurisdiction. Since
> > an EV cert shows the jurisdiction, a user can draw conclusions from
> > that.
> 
> Yes it is true that crimes are illegal. This has not previously stopped
> criminals, and I think your certainty that it will now is misplaced.
> 
> What conclusions would you draw from the fact that the jurisdiction is
> the United Kingdom of Great Britain and Northern Ireland? Or the US
> state of Delaware ?

If I expect to be on the website of my German bank, I would conclude that I am 
not at the correct website!

If they would use just a DV certificate, I wouldn't be able to come to that 
conclusion easily!

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 3:10:49 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > > In this case, the use of EV certificates, and the presumption of
> > > reputation, would lead to actively worse security.
> > >
> > > Did I misunderstand the scenario?
> >
> > Don't argue with me, argue with the browser phishing filters and
> > anti-phishing services who do, in fact, use EV website information to
> > protect users as I described.  Presumably they know what they are doing.
> 
> 
> Sorry that it sounded like I'm arguing. I'm just trying to understand the
> premise, since it so obviously has security holes that would make EV
> certificates more dangerous for any user who relied on such services.
> 
> Could you point to the browsing phishing filters and anti-phishing services
> that do? It might be an opportunity for you to find out how they deal with
> this, and report back, so we don't have to presume anything.

Let's hear directly from the experts - can you get someone from Google Safe 
Browsing to post to this list, and then we can all ask him or her our questions 
and get the definitive answers.  Thanks.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 5:18 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > In this case, the use of EV certificates, and the presumption of
> > reputation, would lead to actively worse security.
> >
> > Did I misunderstand the scenario?
>
> Don't argue with me, argue with the browser phishing filters and
> anti-phishing services who do, in fact, use EV website information to
> protect users as I described.  Presumably they know what they are doing.


Sorry that it sounded like I'm arguing. I'm just trying to understand the
premise, since it so obviously has security holes that would make EV
certificates more dangerous for any user who relied on such services.

Could you point to the browsing phishing filters and anti-phishing services
that do? It might be an opportunity for you to find out how they deal with
this, and report back, so we don't have to presume anything.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 12:17:22 PM UTC-7, Ryan Sleevi wrote:
> On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> 
> > Sure, I’m happy to explain, using Bank of America as an example.
> 
> 
> Kirk,
> 
> Thanks for providing this example. Could you help me understand how it
> helps determine that things are safe? For example, the reputation system
> you described, which is more akin to code signing than what is generally
> practiced an anti-phishing, seems like if it was implemented, it would
> leave users at significant risk from compromise on EV sites. That is, if an
> EV-using site was compromised and displayed a phishing form, the fact that
> it had "good" reputation would actually be actively harmful to users
> security, because it would make it harder to provide timely responsiveness.
> That is, it would be a false negative.
> 
> In this case, the use of EV certificates, and the presumption of
> reputation, would lead to actively worse security.
> 
> Did I misunderstand the scenario?

Don't argue with me, argue with the browser phishing filters and anti-phishing 
services who do, in fact, use EV website information to protect users as I 
described.  Presumably they know what they are doing.

And go argue with Facebook, which has just decided that binding confirmed 
identity information to Facebook posts will help in combating fraud, fake 
identities, foreign powers, etc.  Presumably they also know what they are doing.

There's also a difference between EV code signing and EV websites.  For EV code 
signing, this creates a permanent artifact associated  with the signed code 
that helps applications decide whether or not to trust the code - and it has 
become a de facto requirement in some environments.  

For EV certificates, the appeal for website owners over the past 10 years has 
been that they get a distinctive EV UI that they believe protects their 
consumers and their brands (again, don't argue with me but argue with them - 
but these website owners include many of the top enterprises and brands, so 
presumably they are smart people too with significant technical skills and have 
made their own EV decisions on a rational basis, even if you disagree with them 
or have a different commercial interest in supporting or not supporting website 
identity).  

EV identity information as used by phishing filters and anti-phishing services 
is an *incidental* benefit (but a huge one), and is not a benefit that most EV 
website owners are focused on - and website owners may not be willing to 
continue using EV certs for their websites for this incidental anti-phishing 
benefit alone if the EV UI goes away.

So again - why don't Mozilla and Chrome move to the simple, binary Apple UI 
which tells users at a glance whether or not the site has been identified 
(green URL and lock symbol, yes / black URL and lock symbol, no) so users can 
be informed and make their own decisions, instead of making the EV and DV UIs 
the same and hiding EV information from users.  

And please conduct one more Google research paper - but this time, don't just 
ask users what they *know* about the Chrome UI (and then show them websites 
without any training or other information - the Chrome UI has changed so often 
in recent years that no one knows what it means anymore - from green "Secure" 
for DV phishing sites until last year, to turning the EV UI gray).  Instead, 
research what users *can* know with 30 seconds of training.  I'll bet the Apple 
binary UI (identity / no identity) will be easy for users to understand.  Now 
that would be research worth using.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 29/08/2019 19:47, Nick Lamb wrote:
> On Thu, 29 Aug 2019 17:05:43 +0200
> Jakob Bohm via dev-security-policy
>  wrote:
> 
>> The example given a few messages above was a different jurisdiction
>> than those two easily duped company registries.
> 
> I see. Perhaps Vienna, Austria has a truly exemplary registry when it
> comes to such things. Do you have evidence of that? I probably can't
> read it even if you do.
> 

I have no specific knowledge, but Austrians probably do, using empirical 
data from their life experience and press coverage of all kinds of 
business and fraud related mischief: Did fraudsters get away with 
registering misleading company names? were the registrations revoked by 
authorities soon after discovery?  Was there a serious police effort to 
prosecute?

Same for any other country as known by its citizens.

> But Firefox isn't a Viennese product, it's available all over the
> world. If only some handful of exemplary registries contain trustworthy
> information, you're going to either need to persuade the CAs to stop
> issuing for all other jurisdictions, or accept that it isn't actually
> helpful in general.
> 

The point is you keep bringing up examples from exactly two countries in 
a world with more than 100 countries.

The usefulness of knowing that a Mozilla-accepted and regularly audited 
CA has confirmed the connection to match a government record in a 
country ties directly to the trust that people can reasonably attribute 
to that part of that government.  This in turn is approximately the same 
trust applicable to those government records being reflected in other 
parts of official life, such as phone books, building permits, business 
certificates posted in offices, etc. etc.

In either case there is some residual risk of fraud, as always.


>> You keep making the logic error of concluding from a few example to
>> the general.
> 
> The IRA's threat to Margaret Thatcher applies:
> 
> We only have to be lucky once. You will have to be lucky always.
> 
> Crooks don't need to care about whether their crime is "generally"
> possible, they don't intend to commit a "general" crime, they're going
> to commit a specific crime.
> 

Almost any anti-crime effort has some probability of success and 
failure.  If a measure would stop the IRA's attacks on Thatcher 99.5% of 
the time, they would, on average, have to try 100 times to get a 50/50 
chance of getting lucky.  If another measure takes away another 80% of 
their chance, she would get 99.9% and so on.  At some point her chances 
became good enough to actually retire and die of old age having 
accumulated even more enemies.

One of the measures known to have saved her at least once was a number 
of barriers forcing an IRA rocket attack to fly just far enough to miss.  
Certainly not a perfect measure, but clearly better than nothing.


>> A user can draw conclusions from their knowledge of the legal climate
>> in a jurisdiction, such as how easy it is to register fraudulent
>> untraceable business names there, and how quickly such fraudulent
>> business registrations are shut down by the legal teams of high
>> profile companies such as MasterCard Inc.
> 
> Do you mean knowledge here, or beliefs? Because it seems to me users
> would rely on their beliefs, that may have no relationship whatsoever
> to the facts.
> 

Of cause they would use their imperfect knowledge (beliefs) about the 
country they live and survive in.  Knowing what kind of official 
paperwork to trust is a basic life skill in any society with common 
literacy (illiterates wouldn't be able to read what it says on an 
official document, nor read the words in a browser UI).

>> That opinion still is lacking in strong evidence of anything but spot
>> failures under specific, detectable circumstances.
> 
> We only have to be lucky once.
> 

When fighting a wave of similar crimes committed many times, reducing 
the number of times the criminals get lucky is a win, even if that crime 
is murder instead of theft.

>> Except that any event allowing a crook to hijack http urls to a
>> domain is generally sufficient for that crook to instantly get and
>> use a corresponding DV certificate.
> 
> If the crook hijacks the actual servers, game is over anyway,
> regardless of what type of certificate is used.
> 

Hijacking the authorized server is obviously game over.

Hijacking DNS or IP routing in any repeatable manner can be used to get 
a DV cert, then a bit later presenting that to victim browsers.  Of 
cause if the hijack ability happens to not include the view from any of 
the DV issuing CAs, then that one-two punch fails.

> Domain owners can set CAA (now that it's actually enforced) to deny
> crooks the opportunity from an IP hijack. More sophisticated owners can
> use CAA and DNSSEC to deny crooks the opportunity to use this even
> against a DNS hijack, so that crooks need to attack a registrar or
> registry.
> 

DNSSEC, like certificate pinning, is unfortunately 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/29/2019 11:07 AM, Nick Lamb via dev-security-policy wrote:

...
If you _work_ for such an institution [e.g.,a bank], the best thing 
you could do to

protect your customers against Phishing, a very popular attack that
TLS is often expected to mitigate, is offer WebAuthn


You also could (1) use only one domain for everything (including email), 
and tell your customers on every login that that is the only legitimate 
domain; (2) use only one customer service number for everything, and 
ditto the customer notices.


The contrary (badly-insecure) practices are very common. I receive 
several such calls each year purporting to be from financial 
institutions at which I have accounts. So far, none have been phishes, 
but I always call back the customer service number that I originally 
obtained from the institution's website, and always submit a security 
ticket about this issue. It never gets fixed.


-R


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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

These so called "extended" validation vetting checks on companies for
extended validation certificates are supposed to provide the consumer
on the website with an high level of assurance that the company has
been properly validated but the fact is that these so called
"extended" validation vetting checks are nothing more than basic
checks. The Disclosure and Barring Service (DBS) in the United Kingdom
conducts more vetting checks on an individual applying for an basic
DBS check than CAs do for an so called "extended" validation
certificates for companies.

I serious doubts over the methods used by CAs to conduct these so
called "extended" validation vetting checks. This is from personal
experience of going through dozens of dozens of validation checks of
all types of certificates with different CAs.

These so called "extended" validation certificates should be removed
forthwith because it is not performing the intended job it was
supposed to be made for and given that these so called "extended"
validation certificates are nothing more than basic checks it is in a
way falsely advertising to consumers on these websites that uses these
so called "extended" validation certificates that they have been
validated to an "extended" level of vetting which they have not.

Burton

On Thu, Aug 29, 2019 at 8:17 PM Ryan Sleevi via dev-security-policy
 wrote:
>
> On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Sure, I’m happy to explain, using Bank of America as an example.
>
>
> Kirk,
>
> Thanks for providing this example. Could you help me understand how it
> helps determine that things are safe? For example, the reputation system
> you described, which is more akin to code signing than what is generally
> practiced an anti-phishing, seems like if it was implemented, it would
> leave users at significant risk from compromise on EV sites. That is, if an
> EV-using site was compromised and displayed a phishing form, the fact that
> it had "good" reputation would actually be actively harmful to users
> security, because it would make it harder to provide timely responsiveness.
> That is, it would be a false negative.
>
> In this case, the use of EV certificates, and the presumption of
> reputation, would lead to actively worse security.
>
> Did I misunderstand the scenario?
> ___
> 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: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Sure, I’m happy to explain, using Bank of America as an example.


Kirk,

Thanks for providing this example. Could you help me understand how it
helps determine that things are safe? For example, the reputation system
you described, which is more akin to code signing than what is generally
practiced an anti-phishing, seems like if it was implemented, it would
leave users at significant risk from compromise on EV sites. That is, if an
EV-using site was compromised and displayed a phishing form, the fact that
it had "good" reputation would actually be actively harmful to users
security, because it would make it harder to provide timely responsiveness.
That is, it would be a false negative.

In this case, the use of EV certificates, and the presumption of
reputation, would lead to actively worse security.

Did I misunderstand the scenario?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ian Carroll via dev-security-policy]

On Thursday, August 29, 2019 at 11:49:16 AM UTC-7, Kirk Hall wrote:
> On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote:
> > On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote:
> > > This string is about Mozilla’s announced plan to remove the EV UI from 
> > > Firefox in October.  Over time, this will tend to eliminate confirmed 
> > > identity information about websites from the security ecosystem, as EV 
> > > website owners may decide it’s not worth using a n EV certificate if 
> > > browsers decide to hide the data from users.  As noted in my last 
> > > message, this will be a tragedy for users, as browser phishing filters 
> > > and other anti-phishing services currently rely on website EV data in 
> > > their algorithms for protecting users.
> > 
> > Can you provide more detail (preferably with citations) about how browser 
> > phishing filters, and specifically Google Safe Browsing (used by Firefox), 
> > rely on EV data?
> > 
> > It's not clear to me how this could possibly be useful in detecting 
> > phishing given the data that you've previously published[1] showing that an 
> > extremely small number sites with EV certificates were detected as phishing.
> > 
> > Jonathan
> > 
> > [1] 
> > https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf
> 
> 
> Sure, I’m happy to explain, using Bank of America as an example.
> 
> The EV data securing the domain www.bankofamerica.com is as follows:
> 
> CN = www.bankofamerica.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> This data uniquely and unambiguously identifies the owner of the domain as 
> “Bank of America Corporation”, a Delaware, US corporation with the Delaware 
> registry serial number 2927442 – no other corporation in the world can get 
> that place of incorporation and serial number.  There’s no “Stripe” problem 
> here – even if a phisher or academic could create a new corporation in 
> another state (e.g., Kentucky) in the name of “Bank of America Corporation” 
> and then get an EV cert, it would show state of incorporation as Kentucky and 
> show a different serial number –it’s easy for phishing algorithms to notice 
> the difference and know these are not the same organization who own the 
> websites.
> 
> Phishing services tend to capture and retain this kind of website identity 
> information and use it in their algorithms to create a “reputation” for 
> specific domains and for specific organizations named in EV certificates that 
> they re-use later.  
> 
> Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose 
> it’s only secured by a DV certificate.  In that case, this is the only 
> certificate information available to the anti-phishing service:
> 
> CN = bankofamerica-alerts.com
> 
> That could be a site owned by the real Bank of America, or owned by a phisher 
> – who knows, as there is no identity information available about the site.  
> So a phishing service would be very cautious.
> 
> Now suppose the new website “bankofamerica-alerts.com” is instead secured by 
> an EV certificate.  The certificate identity information for that site would 
> be as follows:
> 
> CN = bankofamerica-alerts.com
> SERIALNUMBER = 2927442
> OU = eComm Network Infrastructure
> 2.5.4.15 = Private Organization
> O = Bank of America Corporation
> 1.3.6.1.4.1.311.60.2.1.2 = Delaware
> 1.3.6.1.4.1.311.60.2.1.3 = US
> L = Chicago
> S = Illinois
> C = US
> 
> Only the CN field would be different from the EV certificate securing 
> www.bankofamerica.com.  Anti-phishing services will notice this similarity, 
> and will likely rely on the “reputation” already established for the site 
> www.bankofamerica.com (and for the organization “Bank  of America 
> Corporation, Delaware serial number 2927442”) and so feel confident based on 
> that good reputation that the new EV website “bankofamerica-alerts.com” is 
> unlikely to be a phishing site.  This helps speed up decisions on which sites 
> are likely safe for users and which should be flagged for phishing.
> 
> Anti-phishing algorithms like lots of data, particularly strongly confirmed 
> data like EV data.  Website owners who use EV certificates today do so 
> because they believe EV certs protect their customers and their brands, 
> chiefly through the EV UI.  If the browsers eliminate the EV UI and hide 
> identity data from users, over time website owners may stop using EV 
> certificates, and the EV identity data will disappear from the security 
> ecosystem – a real loss.

EV code signing certificates do not display any trusted UI -- their chief 
purpose is to inform Smartscreen and other relying parties of identity 
information, similar to the anti-phishing services you mention. UAC/etc will 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

On Thursday, August 29, 2019 at 11:01:27 AM UTC-7, Jonathan Rudenberg wrote:
> On Thu, Aug 29, 2019, at 13:39, Kirk Hall via dev-security-policy wrote:
> > This string is about Mozilla’s announced plan to remove the EV UI from 
> > Firefox in October.  Over time, this will tend to eliminate confirmed 
> > identity information about websites from the security ecosystem, as EV 
> > website owners may decide it’s not worth using a n EV certificate if 
> > browsers decide to hide the data from users.  As noted in my last 
> > message, this will be a tragedy for users, as browser phishing filters 
> > and other anti-phishing services currently rely on website EV data in 
> > their algorithms for protecting users.
> 
> Can you provide more detail (preferably with citations) about how browser 
> phishing filters, and specifically Google Safe Browsing (used by Firefox), 
> rely on EV data?
> 
> It's not clear to me how this could possibly be useful in detecting phishing 
> given the data that you've previously published[1] showing that an extremely 
> small number sites with EV certificates were detected as phishing.
> 
> Jonathan
> 
> [1] 
> https://casecurity.org/wp-content/uploads/2018/06/Summary-Report-Incidence-of-Phishing-04-16-2018.pdf


Sure, I’m happy to explain, using Bank of America as an example.

The EV data securing the domain www.bankofamerica.com is as follows:

CN = www.bankofamerica.com
SERIALNUMBER = 2927442
OU = eComm Network Infrastructure
2.5.4.15 = Private Organization
O = Bank of America Corporation
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
L = Chicago
S = Illinois
C = US

This data uniquely and unambiguously identifies the owner of the domain as 
“Bank of America Corporation”, a Delaware, US corporation with the Delaware 
registry serial number 2927442 – no other corporation in the world can get that 
place of incorporation and serial number.  There’s no “Stripe” problem here – 
even if a phisher or academic could create a new corporation in another state 
(e.g., Kentucky) in the name of “Bank of America Corporation” and then get an 
EV cert, it would show state of incorporation as Kentucky and show a different 
serial number –it’s easy for phishing algorithms to notice the difference and 
know these are not the same organization who own the websites.

Phishing services tend to capture and retain this kind of website identity 
information and use it in their algorithms to create a “reputation” for 
specific domains and for specific organizations named in EV certificates that 
they re-use later.  

Now, suppose a new website appears, “bankofamerica-alerts.com” and suppose it’s 
only secured by a DV certificate.  In that case, this is the only certificate 
information available to the anti-phishing service:

CN = bankofamerica-alerts.com

That could be a site owned by the real Bank of America, or owned by a phisher – 
who knows, as there is no identity information available about the site.  So a 
phishing service would be very cautious.

Now suppose the new website “bankofamerica-alerts.com” is instead secured by an 
EV certificate.  The certificate identity information for that site would be as 
follows:

CN = bankofamerica-alerts.com
SERIALNUMBER = 2927442
OU = eComm Network Infrastructure
2.5.4.15 = Private Organization
O = Bank of America Corporation
1.3.6.1.4.1.311.60.2.1.2 = Delaware
1.3.6.1.4.1.311.60.2.1.3 = US
L = Chicago
S = Illinois
C = US

Only the CN field would be different from the EV certificate securing 
www.bankofamerica.com.  Anti-phishing services will notice this similarity, and 
will likely rely on the “reputation” already established for the site 
www.bankofamerica.com (and for the organization “Bank  of America Corporation, 
Delaware serial number 2927442”) and so feel confident based on that good 
reputation that the new EV website “bankofamerica-alerts.com” is unlikely to be 
a phishing site.  This helps speed up decisions on which sites are likely safe 
for users and which should be flagged for phishing.

Anti-phishing algorithms like lots of data, particularly strongly confirmed 
data like EV data.  Website owners who use EV certificates today do so because 
they believe EV certs protect their customers and their brands, chiefly through 
the EV UI.  If the browsers eliminate the EV UI and hide identity data from 
users, over time website owners may stop using EV certificates, and the EV 
identity data will disappear from the security ecosystem – a real loss. 

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 13:33:26 -0400
Lee via dev-security-policy 
wrote:

> That it isn't my financial institution.  Hopefully I'd have the
> presence of mind to save the fraud site cert, but I'd either find the
> business card of the person I've been dealing with there or find an
> old statement, call and ask to be transferred to the fraud dept.

I commend this presence of mind.

> Same deal if the displayed info ends with (US) but doesn't match what
> I'm expecting, except I'd be asking the fraud dept about the name
> change instead of telling them.

Perhaps American banks are much better about this than those I've
handled but certainly here in the UK "expecting" is tricky for ordinary
customers. As a domain expert I know why my good bank says:

first direct (HSBC Bank plc) (GB)

... but I won't be surprised if many of their customers didn't know
they're technically part of the enormous HSBC

NS's certificate spells their name out. Unfortunately their name is
quite long, which is why they prefer the abbreviation, so my browser
shows:

National Savings and Investme... (GB)

... but it would be perfectly legal to set up businesses with different
names that truncate exactly the same as this.

My mother banks with Halifax. Again I understand why, but I suspect
she'd be astonished if she stopped to read that it says:

Lloyd Banking Group PLC (GB)

... in fact her bank is part of a larger group under a different name
and they didn't bother to get certificates that mention Halifax at all.


> I understand that ev certs aren't a panacea, but for the very few web
> sites that I really care about I like having the company name
> displayed automatically.  I think they're helpful and, since I use
> bookmarks instead of email links or search results, provide an
> adequate assurance that I've actually ended up on the web site I want.
> Is that an incorrect assumption?  What more should I be doing?

The implication of the UI change is that you needn't bother trying to
guess whether the Company Name is what you expected, if you are
visiting the bookmark for your bank (credit union, card issuer,
whatever), that will be your bank. As you have seen in this thread,
some people don't agree, but I endorse this view.

In a broader picture, there isn't much you should bother trying to do,
the onus is largely on the bank. You could try to use countermeasures
they provide e.g. per account images to re-assure you that they know
who you are before you complete login, but they're pretty likely to get
rid of them or change to new ones on a whim so it's scarcely worth it.

If you _work_ for such an institution, the best thing you could do to
protect your customers against Phishing, a very popular attack that
TLS is often expected to mitigate, is offer WebAuthn. Unfortunately the
FIDO tokens to enable WebAuthn are not cheap, making the idea of just
mailing one to every customer prohibitive. But certainly it could make
sense to offer this to High Net Worth Individuals or just let customers
use their own tokens if they want to.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Thu, 29 Aug 2019 17:05:43 +0200
Jakob Bohm via dev-security-policy
 wrote:

> The example given a few messages above was a different jurisdiction
> than those two easily duped company registries.

I see. Perhaps Vienna, Austria has a truly exemplary registry when it
comes to such things. Do you have evidence of that? I probably can't
read it even if you do.

But Firefox isn't a Viennese product, it's available all over the
world. If only some handful of exemplary registries contain trustworthy
information, you're going to either need to persuade the CAs to stop
issuing for all other jurisdictions, or accept that it isn't actually
helpful in general.

> You keep making the logic error of concluding from a few example to
> the general.

The IRA's threat to Margaret Thatcher applies:

We only have to be lucky once. You will have to be lucky always.

Crooks don't need to care about whether their crime is "generally"
possible, they don't intend to commit a "general" crime, they're going
to commit a specific crime.

> A user can draw conclusions from their knowledge of the legal climate
> in a jurisdiction, such as how easy it is to register fraudulent 
> untraceable business names there, and how quickly such fraudulent 
> business registrations are shut down by the legal teams of high
> profile companies such as MasterCard Inc.

Do you mean knowledge here, or beliefs? Because it seems to me users
would rely on their beliefs, that may have no relationship whatsoever
to the facts.

> That opinion still is lacking in strong evidence of anything but spot 
> failures under specific, detectable circumstances.

We only have to be lucky once.

> Except that any event allowing a crook to hijack http urls to a
> domain is generally sufficient for that crook to instantly get and
> use a corresponding DV certificate.

If the crook hijacks the actual servers, game is over anyway,
regardless of what type of certificate is used.

Domain owners can set CAA (now that it's actually enforced) to deny
crooks the opportunity from an IP hijack. More sophisticated owners can
use CAA and DNSSEC to deny crooks the opportunity to use this even
against a DNS hijack, so that crooks need to attack a registrar or
registry.

If the crook only does some sort of IP hijack they need to control the
IP from the perspective of the issuer as well as from the perspective
of their target in order to obtain and use a DV certificate with methods
like 3.2.2.4.6

This means small hijacks (e.g. of a single ISP or public access point)
are unlikely to be effective for obtaining a certificate.

You are correct that a large hijack (e.g. BGP hijack to move an
entire /24 for most of the Internet to some system you control) would
work on most domains, BUT this is relatively difficult for an attacker,
cannot be done silently and is already being addressed by numerous
initiatives by people over in that community rather than m.d.s.policy

> Yes, I think you have repeatedly used the failures of UK and US
> company registries as reason to dismiss all other governments.

I don't have examples from other countries either way. I assure you if
I could say "Oh, in New Zealand it works great" based on solid
information like a track record of actually prosecuting people who
make bogus registrations - I'd do that.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

This string is about Mozilla’s announced plan to remove the EV UI from Firefox 
in October.  Over time, this will tend to eliminate confirmed identity 
information about websites from the security ecosystem, as EV website owners 
may decide it’s not worth using a n EV certificate if browsers decide to hide 
the data from users.  As noted in my last message, this will be a tragedy for 
users, as browser phishing filters and other anti-phishing services currently 
rely on website EV data in their algorithms for protecting users.

It’s interesting to note that others in the security ecosystem, such as 
Facebook, are going exactly the opposite direction from Mozilla to deal with 
fraudsters operating under false names or posting anonymously (like phishers 
do), and are now actually *requiring* the use of third-party confirmed identity 
information before they are allowed to use Facebook’s platform.  I include a 
link to today’s New York Times article on Facebook’s policy changes [1], and 
also Facebook’s actual announcement of the new rules requiring identity 
confirmation before posting. [2]

I hope Mozilla will reconsider its plan to remove the EV UI and instead work on 
a better, more streamlined design for a new Firefox UI that tells users when 
confirmed identity is present, and when it is not.  Apple seems to be handling 
this UI challenge well – just compare the UI on an iPhone for apple.com (green 
lock symbol, green URL for EV identity) to the UI for mozilla.org (black lock 
symbol, black URL for DV).  Easy for users to see the difference, no need for 
users to scrutinize the actual EV identity information (unless they want to), 
tells users in a simple, binary way whether or not the website has confirmed 
identity behind it or is anonymous.  And it fits nicely on mobile devices like 
iPhones – I assume Firefox is going to continue to show users at least what URL 
they’re at (like now), so that copying the Apple UI instead of the Chrome UI 
seems like it would be a relatively easy engineering task.  By making the 
Mozilla and Apple UIs the same, we would also be taking a step forward in 
standardization of browser UIs, which makes it easier to educate users on how 
to understand what the UI means – something we should all support.

@Mozilla – please give Facebook’s announcement on the importance of identity 
some consideration before you make a final decision on changing the Firefox UI.

***

Facebook Announcement: Updates to Ads About Social Issues, Elections or 
Politics in the US

People should know who is trying to influence their vote and advertisers 
shouldn’t be able to  cover up who is paying for ads. That’s why over the past 
few years, we’ve made important changes to help ensure more transparency and 
authenticity in ads about social issues, elections or politics.

Today, we’re sharing additional steps we’re taking to protect elections and 
prepare for the US 2020 election. Those steps include strengthening the 
authorization process for US advertisers, showing people more information about 
each advertiser and updating our list of social issues in the US to better 
reflect the public discourse on and off Facebook. 

New Disclaimer Requirements

In 2018, we started requiring advertisers to get authorized before running ads 
about social issues, elections or politics. We also save those ads in an Ad 
Library so they’re publicly available for seven years.

The authorization process already requires advertisers in the US to provide 
identification to confirm who they are and where they are located. Advertisers 
must also place a “Paid for by” disclaimer on their ads to communicate who is 
responsible for them. Despite these requirements, there are a number of cases 
where advertisers have attempted to put misleading “Paid for by” disclaimers on 
their ads. That’s why, starting mid-September, advertisers will need to provide 
more information about their organization before we review and approve their 
disclaimer. If they do not provide this information by mid-October, we will 
pause their ads. While the authorization process won’t be perfect, it will help 
us confirm the legitimacy of an organization and provide people with more 
details about who’s behind the ads they are seeing. 

Advertisers will have five options for providing more information, three of 
which demonstrate they are registered with the US government. If they choose 
one of the three government resource options, they will be allowed to use their 
registered organization name in disclaimers and the “i” icon that appears in 
the upper right-hand corner of their ads will read “Confirmed Organization.”
In addition to providing their US street address, phone number, business email 
and a business website matching the email, they must provide one of the 
following: 

1. Tax-registered organization identification number (i.e. EIN)

2. A government website domain that matches an email ending in .gov or .mil

3. Federal Election 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 29/08/2019 10:58, Nick Lamb wrote:
> On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
> Josef Schneider via dev-security-policy
>  wrote:
> 
>> Not legally probably and this also depends on the jurisdiction. Since
>> an EV cert shows the jurisdiction, a user can draw conclusions from
>> that.
> 
> Yes it is true that crimes are illegal. This has not previously stopped
> criminals, and I think your certainty that it will now is misplaced.
> 
> What conclusions would you draw from the fact that the jurisdiction is
> the United Kingdom of Great Britain and Northern Ireland? Or the US
> state of Delaware ?
> 
> Those sound fine right? Lots of reputable businesses?
> 
> Yes, because those are great places to register a business,
> tremendously convenient. They have little if any regulation on
> registering businesses, light touch enforcement and they attract a
> modest fee for each one.
> 
> This is of course also exactly the right environment for crooks.
> 

The example given a few messages above was a different jurisdiction than 
those two easily duped company registries.

You keep making the logic error of concluding from a few example to the 
general.

A user can draw conclusions from their knowledge of the legal climate in 
a jurisdiction, such as how easy it is to register fraudulent 
untraceable business names there, and how quickly such fraudulent 
business registrations are shut down by the legal teams of high profile 
companies such as MasterCard Inc.

Such knowledge can be expected to be greater among residents of said 
jurisdiction, who may also be in a much better position to recognize 
that an address is a building site, the city stadium etc.

> 
>> But removing the bar is also not the correct solution. If you find
>> out that the back door to your house is not secured properly, will
>> you remove the front door because it doesn't matter anyway or do you
>> strengthen the back door?
> 
> Certainly if crooks are seen to walk in through the back door and none
> has ever even attempted to come through the upstairs windows, it is
> strange to insist that removing the bars from your upstairs windows to
> let in more light makes the house easier to burgle.
> 

None attempting to enter through the visibly barred window says nothing 
about how many turned away when seeing the bars.  Nor does it say 
anything about which other measures have been taken to deal with the 
known problems of the back door (Maybe they make a habit of blocking the 
door between the back entrance and the stairwell whenever leaving the 
house).

>> The current
>> EV validation information in the URL works and is helpful to some
>> users (maybe only a small percentage of users, but still...)
> 
> Is it helpful, or is it misleading? If you are sure it's helpful, and
> yet as we saw above you don't really understand the nuances of what
> you're looking at (governments are quite happy to collect business
> registration fees from crooks) then I'd say that means it's misleading.
> 

You presume government failures in some jurisdictions imply such 
failures everywhere.  Some jurisdictions require various economic 
assurances of registered companies, often tiered by the desired level of 
incorporation.  Some require a known arrestable citizen or liability 
insured public accountant to securely sign off on the registration.

>> EV certificates do make more assurances about the certificate owner
>> than DV certificates. This is a fact. This information can be very
>> useful for someone that understands what it means. Probably most
>> users don't understand what it means. But why not improve the display
>> of this valuable information instead of hiding it?
> 
> The information is valuable to my employer, which does with it
> something that is useless to Mozilla's users and probably not in line
> with what EV certificate purchasers were intending, but I'm not on
> m.d.s.policy to speak for my employer, and they understood that
> perfectly well when they hired me.
> 
> In my opinion almost any conceivable display of this information is
> likely to mislead users in some circumstances and bad guys are ideally
> placed to create those circumstances. So downgrading the display is a
> reasonable choice especially when screen real estate is limited.
> 

That opinion still is lacking in strong evidence of anything but spot 
failures under specific, detectable circumstances.


>> Certificates cannot magically bring security. Certificates are about
>> identity. But the fact that the owner of the website somebank.eu is
>> the owner of the domain somebank.eu is not that helpful in
>> determining the credibility.
> 
> If I process a link (as browsers do many times in constructing even
> trivial web pages these days) then this assures me it actually links to
> what was intended.
> 
> This is enough to bootstrap WebAuthn (unphishable second factor
> credentials) and similar technologies, to safeguard authentication
> cookies and sandbox active code inside an 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Nick Lamb via dev-security-policy]

On Wed, 28 Aug 2019 11:51:37 -0700 (PDT)
Josef Schneider via dev-security-policy
 wrote:

> Not legally probably and this also depends on the jurisdiction. Since
> an EV cert shows the jurisdiction, a user can draw conclusions from
> that.

Yes it is true that crimes are illegal. This has not previously stopped
criminals, and I think your certainty that it will now is misplaced.

What conclusions would you draw from the fact that the jurisdiction is
the United Kingdom of Great Britain and Northern Ireland? Or the US
state of Delaware ?

Those sound fine right? Lots of reputable businesses?

Yes, because those are great places to register a business,
tremendously convenient. They have little if any regulation on
registering businesses, light touch enforcement and they attract a
modest fee for each one.

This is of course also exactly the right environment for crooks.


> But removing the bar is also not the correct solution. If you find
> out that the back door to your house is not secured properly, will
> you remove the front door because it doesn't matter anyway or do you
> strengthen the back door?

Certainly if crooks are seen to walk in through the back door and none
has ever even attempted to come through the upstairs windows, it is
strange to insist that removing the bars from your upstairs windows to
let in more light makes the house easier to burgle.

> The current
> EV validation information in the URL works and is helpful to some
> users (maybe only a small percentage of users, but still...)

Is it helpful, or is it misleading? If you are sure it's helpful, and
yet as we saw above you don't really understand the nuances of what
you're looking at (governments are quite happy to collect business
registration fees from crooks) then I'd say that means it's misleading.

> EV certificates do make more assurances about the certificate owner
> than DV certificates. This is a fact. This information can be very
> useful for someone that understands what it means. Probably most
> users don't understand what it means. But why not improve the display
> of this valuable information instead of hiding it?

The information is valuable to my employer, which does with it
something that is useless to Mozilla's users and probably not in line
with what EV certificate purchasers were intending, but I'm not on
m.d.s.policy to speak for my employer, and they understood that
perfectly well when they hired me.

In my opinion almost any conceivable display of this information is
likely to mislead users in some circumstances and bad guys are ideally
placed to create those circumstances. So downgrading the display is a
reasonable choice especially when screen real estate is limited.

> Certificates cannot magically bring security. Certificates are about
> identity. But the fact that the owner of the website somebank.eu is
> the owner of the domain somebank.eu is not that helpful in
> determining the credibility.

If I process a link (as browsers do many times in constructing even
trivial web pages these days) then this assures me it actually links to
what was intended.

This is enough to bootstrap WebAuthn (unphishable second factor
credentials) and similar technologies, to safeguard authentication
cookies and sandbox active code inside an eTLD+1 or narrower. All very
useful even though the user isn't aware of them directly.

For end users it means bookmarks they keep and links they follow from
outside actually lead where they should, and not somewhere else as
would trivially happen without this verification.

> But the information that the owner of
> somebank.eu is a incorporated company from Germany officially called
> "Somebank AG" is more valuable. Maybe some people don't care and
> enter their account data happily at s0m1b4nk.xyz, maybe most people
> do. We don't know and we probably can't know how many people stopped
> and thought if they are actually at the correct website because the
> green bar was missing. But I am certain that it was more than zero. 

Why are you certain of this? Just gut feeling?

> Why not for example always open a small overlay with information when
> someone starts entering data in a password field? Something like "You
> are entering a password at web.page. You visited this page 5 times
> before, first on August 4th 2019. We don't know anything about the
> owner" or for EV "You are entering a password at web.page. You
> visited this page 5 times before, first on August 4th 2019. This
> server is run by "WebPage GmbH" from Vienna, Austria [fancy flag
> picture]".

This server is run by "Authorised Web Site" from London, UK [Union
flag].

Sounds legitimate.

Remember, the British government doesn't care that Authorised Web Site
is a stupid name for a company, that its named officers are the
characters in Toy Story, that its claimed offices are a building site,
nor even that it has never filed (and never will file) any business
accounts. They collected their registration fee and that's all they

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Wed, Aug 28, 2019 at 11:51:37AM -0700, Josef Schneider via 
dev-security-policy wrote:
> Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> > On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via 
> > dev-security-policy wrote:
> > > Sure I can register a company and get an EV certificate for that company. 
> > > But can I do this completely anonymous like getting a DV cert?
> > 
> > Yes.
> 
> Not legally probably

Someone planning to commit fraud is unlikely to be deterred by the need to
commit fraud in order to commit fraud.

> and this also depends on the jurisdiction.  Since an
> EV cert shows the jurisdiction, a user can draw conclusions from that.

You're suggesting that Relying Parties need to familiarise themselves with
the validation procedures of every jurisdiction which is listed in an EV
certificate they are presented with, in order to establish the
trustworthiness of that EV certificate?

I'm just going to leave that there.  For posterity.

> > > Nobody is arguing that EV certificates are perfect and everything is good
> > > if you use them.  But they do raise the bar for criminals.  And in my
> > > opinion, significantly.
> > 
> > Except criminals don't need them.  Raising the bar doesn't help if you don't
> > need to go over the bar.
> 
> But removing the bar is also not the correct solution.  If you find out
> that the back door to your house is not secured properly, will you remove
> the front door because it doesn't matter anyway or do you strengthen the
> back door?

The problem with your analogy is that, in the case under discussion, there
is no known way to secure the back door, and it's the broken and unfixable
back door, not the front door, that is being removed.

So yes, if my back door was insecure, and the best information available
indicated that it couldn't be secured, and it was causing me time and money
to maintain in its current, insecure, state, I would absolutely remove it. 
I expect you would, too.  Although I can certainly understand that if you
were making money by allowing people to use my broken back door, you might
want to encourage me not to remove it.

> > > What I propose is for mozilla to not say "Fuck it, it's not working, just
> > > remove it!" but instead try to focus on finding a better UX solution to
> > > the problem that end users are not aware if a site that should have an EV
> > > certificate is not presenting one.
> > 
> > Why should Mozilla do all this work?  So far, all the evidence suggests that
> > EV certs do not do what their advocates say they do, and have a significant
> > cost to browsers (code complexity, administration of EV bits, etc) and
> > relying parties (need to learn what the EV UI means, what it does and
> > doesn't claim, etc).
> 
> Why should Mozilla do work to make the situation worse?  The current EV
> validation information in the URL works and is helpful to some users
> (maybe only a small percentage of users, but still...).  Why is mozilla
> interested in spending money making the situation worse.  If mozilla
> doesn't care about the empowerment of their users, the default would be to
> not change anything, not actively making it worse.

Not being Mozilla, I wouldn't presume to speak for them, but two
possibilities leap immediately to mind:

* It costs time and money to maintain the list of trust anchors approved for
  EV treatment -- OID mappings, evaluating EV sections of CP/CPSes, chasing
  audit reports, dealing with incident reports relating to EV validation
  failures, and discussing and evaluating proposed changes to the EVGLs.

* EV-related code in Mozilla software requires maintenance as other changes
  in surrounding code are made.  Less code == ess things to change, so
  gutting the EV support reduces maintenance costs.

> EV certificates do make more assurances about the certificate owner than
> DV certificates.  This is a fact.  This information can be very useful for
> someone that understands what it means.  Probably most users don't
> understand what it means.  But why not improve the display of this
> valuable information instead of hiding it?

Because there is no indication of what an improved EV UI would look like.

I note that you've neglected to answer the question I posed.  If CAs sat
down and did some research into what an actual, useful EV UI would involve,
then Mozilla would have something to work from.  But it would appear that
CAs -- the organisations, I'll reiterate, that benefit financially from the
continued special UI treatment of EV certificates -- are not interested in
making such a contribution.

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ryan Sleevi via dev-security-policy]

(Posting in a personal capacity)

On Wed, Aug 28, 2019 at 7:01 PM Kirk Hall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Most of the comments against EV certificates on this list have been
> focused on whether or not the current Firefox EV UI is relied on by Firefox
> users to make security decisions.  (Actually, I have only seen a Google
> paper on this issue in Chrome, no research from Firefox.)
>
> But there is an ecosystem of anti-phishing browser filters (e.g., Google
> Safe Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as
> well as others that use the current identity information in EV certs to
> make better determinations of positive and false positive phishing sites
> and thereby protect users, as well as for other user security purposes.
>
> Many on this discussion would like to see EV certs disappear entirely and
> move all websites to DV certs.  But remember, if EV certs disappear, so
> does all the EV identity information that’s being used today by security
> software to protect users.
>
> So my question to those who want EV certificates to disappear is this: OK,
> then what is *your* plan for protecting users?  Browser filters will be
> weaker without EV information (and some browser filters today miss 20% of
> phishing sites at zero hour, according to NSS studies).  How will you
> replace the EV information that’s being used today by phishing filters and
> services to protect users?
>

These are very reasonable concerns, and a very valid question to ask.
However, with respect to Mozilla's original posting here, or the
announcements from the Chrome team, it does not sound as if any of the
browsers are presently proposing removing EV.

So perhaps that's worthy of a separate conversation?


> Any decision on removing the EV UI in Firefox should consider all the
> related impacts on user security, and not just focus on a single issue
> (namely, “Do users rely on the EV UI?”), especially when the current
> Firefox EV UI is doing no harm.
>

I may have missed something in the hundred messages in this thread, but
could you highlight what other "impacts on user security" were identified
that are specific to the UI, and that are not intrinsically linked to the
question of "Do users rely on the EV UI"? Perhaps it might be worth
exploring Peter Bowen's questions, in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/TaXQb7VcAQAJ
, or those offered in
https://groups.google.com/d/msg/mozilla.dev.security.policy/iVCahTyZ7aw/gBqfc3XPAAAJ
, which seemed to identify both the question of harm and how this change
would not negatively impair other improvements.

With respect to "doing no harm," a position others on the thread have also
mentioned, I don't know that conclusion has been demonstrated. Could you
point to any peer-reviewed research or literature that suggests it does no
harm? There appears to be a sizable and growing body with respect to
Human-Computer Interaction, as well as within the broader behavioural
sciences, that the studies around EV have referenced or mentioned in terms
things like "alarm fatigue" and "information overload".

Much like the discussion around correlation versus causation, it seems like
there might be two separable pieces:
1) A question about whether users rely on EV UI
2) A question about whether the EV UI causes harm

With respect to the second question, it seems folks have identified that if
the answer to 1 is yes, then the answer to 2 is also yes - for example, the
mentioned-in-the-original-post Stripe example causing user confusion, or
situations like the organization "Identity Verified".
If the answer to 1 is no, then is it reasonable to infer that it causes
harm both in terms of software maintenance costs to support that UI, but
also in that it may lead users to believe the answer to 1 is or should be
yes, thus bringing us back to the harm caused when users rely upon it.

Perhaps I've missed some research on it doing no harm? Given the issues
identified, that would seem to be the burden to demonstrate: folks have
provided example of it doing harm, so it doesn't seem the conclusion is
there?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Kirk Hall via dev-security-policy]

Most of the comments against EV certificates on this list have been focused on 
whether or not the current Firefox EV UI is relied on by Firefox users to make 
security decisions.  (Actually, I have only seen a Google paper on this issue 
in Chrome, no research from Firefox.)   

But there is an ecosystem of anti-phishing browser filters (e.g., Google Safe 
Browsing, Microsoft Smart Screen) and services (e.g., PhishLabs) as well as 
others that use the current identity information in EV certs to make better 
determinations of positive and false positive phishing sites and thereby 
protect users, as well as for other user security purposes.

Many on this discussion would like to see EV certs disappear entirely and move 
all websites to DV certs.  But remember, if EV certs disappear, so does all the 
EV identity information that’s being used today by security software to protect 
users.

So my question to those who want EV certificates to disappear is this: OK, then 
what is *your* plan for protecting users?  Browser filters will be weaker 
without EV information (and some browser filters today miss 20% of phishing 
sites at zero hour, according to NSS studies).  How will you replace the EV 
information that’s being used today by phishing filters and services to protect 
users?

Any decision on removing the EV UI in Firefox should consider all the related 
impacts on user security, and not just focus on a single issue (namely, “Do 
users rely on the EV UI?”), especially when the current Firefox EV UI is doing 
no harm.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Josef Schneider via dev-security-policy]

Am Dienstag, 27. August 2019 00:48:38 UTC+2 schrieb Matt Palmer:
> On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via 
> dev-security-policy wrote:
> > Sure I can register a company and get an EV certificate for that company. 
> > But can I do this completely anonymous like getting a DV cert?
> 
> Yes.

Not legally probably and this also depends on the jurisdiction. Since an EV 
cert shows the jurisdiction, a user can draw conclusions from that.

> > Nobody is arguing that EV certificates are perfect and everything is good
> > if you use them.  But they do raise the bar for criminals.  And in my
> > opinion, significantly.
> 
> Except criminals don't need them.  Raising the bar doesn't help if you don't
> need to go over the bar.
> 
But removing the bar is also not the correct solution. If you find out that the 
back door to your house is not secured properly, will you remove the front door 
because it doesn't matter anyway or do you strengthen the back door?


> > What I propose is for mozilla to not say "Fuck it, it's not working, just
> > remove it!" but instead try to focus on finding a better UX solution to
> > the problem that end users are not aware if a site that should have an EV
> > certificate is not presenting one.
> 
> Why should Mozilla do all this work?  So far, all the evidence suggests that
> EV certs do not do what their advocates say they do, and have a significant
> cost to browsers (code complexity, administration of EV bits, etc) and
> relying parties (need to learn what the EV UI means, what it does and
> doesn't claim, etc).

Why should Mozilla do work to make the situation worse? The current EV 
validation information in the URL works and is helpful to some users (maybe 
only a small percentage of users, but still...). Why is mozilla interested in 
spending money making the situation worse. If mozilla doesn't care about the 
empowerment of their users, the default would be to not change anything, not 
actively making it worse.

EV certificates do make more assurances about the certificate owner than DV 
certificates. This is a fact. This information can be very useful for someone 
that understands what it means. Probably most users don't understand what it 
means. But why not improve the display of this valuable information instead of 
hiding it?

Certificates cannot magically bring security. Certificates are about identity. 
But the fact that the owner of the website somebank.eu is the owner of the 
domain somebank.eu is not that helpful in determining the credibility. But the 
information that the owner of somebank.eu is a incorporated company from 
Germany officially called "Somebank AG" is more valuable. 
Maybe some people don't care and enter their account data happily at 
s0m1b4nk.xyz, maybe most people do. We don't know and we probably can't know 
how many people stopped and thought if they are actually at the correct website 
because the green bar was missing. But I am certain that it was more than zero. 

What mozilla now is proposing is: EV certificates have no use in any situation 
so basically remove them. I don't think that's true.

I am not a UX designer, but I am sure there are methods to incorporate this 
valuable information from EV certificates in a way that it is helpful to users.

Why not for example always open a small overlay with information when someone 
starts entering data in a password field? Something like "You are entering a 
password at web.page. You visited this page 5 times before, first on August 4th 
2019. We don't know anything about the owner" or for EV "You are entering a 
password at web.page. You visited this page 5 times before, first on August 4th 
2019. This server is run by "WebPage GmbH" from Vienna, Austria [fancy flag 
picture]".

As said, I am not a UX designer (or any graphical type of designer) so probably 
this idea is stupid. But my point is that the information in an EV certificate 
is useful **to the user** and should be presented in a way to empower the user 
and not be hidden.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Leo Grove via dev-security-policy]

> 
> There are also opportunities for browsers here.  I have to admit I
> primarily use Google Chrome, rather than Firefox, so my observations may be
> a little tainted, but I see various places where signals far more valuable
> than the green lock could be implemented.  Consider that most browsers
> recognize credit card entry fields -- wouldn't it be great if clicking on
> one on an EV site showed a little drop down under the input box that said
> "[CA name here] has certified that [EV info here] is receiving your credit
> card information"?
> 

I like this idea, but putting my browser UI designer hat on, I would ask myself 
some questions. Would these indicators appear in input and textarea html tags? 
Or should it be at the form tag level? What about form elements that completely 
hide the native appearance via css? What about ajax and/or reactive apps? Then 
I would think it's just simpler to put the EV UI in the address bar. I'm 
curious if the browser developers went through this process, and we all ended 
up with what we have now. It might be time to (re)examine this.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

Resend again to fix spelling errors and add extra details

The correct way to vet a UK company would be to:
1. The CA checks Companies House to check if the company is incorporated.
2. The CA sends a letter with verification code to the company address
listed on Companies House.
3. The CA requests the company to send them a bank statement / tax bill to
prove operation.
4. Once the company has sent the information provided in (3) and is it
confirmed by CA then (5) otherwise (3).
5. Once the company receives the letter with verification code then (6)
otherwise vetting on hold until company receives letter with verification
code.
6. The CA initiates video call with the director who is listed at Companies
House and then the CA does the following:
a) The CA asks the director to hold up his/her passport to the side of
their face to confirm that the face matches the passport photo and then the
CA confirms the details such as full name and DOB matches the information
printed on the passport.
(optionally: For high profile companies the CA could also ask for the
passport to be countersigned and put the video call on hold while they
confirm the countersignature with the individual.)
(optionally: For high profile companies the CA could also ask for the
incorporation certificate to be countersigned and put the video call on
hold while they confirm the countersignature with the individual.)
b) The CA asks the director to hold up the verification letter in front of
the camera to confirm company address.
c) The CA calls the company number listed on 3rd party register (automated
phone call like the Google verification phone call) and the director tell
that verification code to the CA to confirm the phone number belongs to the
company.
d) Signs the agreement.
7. That's it.


This method confirms that:
a) The company is in active operation at the address listed on Companies
House.
b) The company phone number is in active operation at the company.
c) The director of the company has been vetted and confirmed certificate
request by signing the agreement.

Burton

On Tue, Aug 27, 2019 at 10:44 AM James Burton  wrote:

> Companies House (
> http://resources.companieshouse.gov.uk/serviceInformation.shtml#compInfo)
> says "We carry out basic checks on documents received to make sure that
> they have been fully completed and signed, but we do not have the statutory
> power or capability to verify the accuracy of the information that
> companies send to us. The fact that the information has been placed on the
> public record should not be taken to indicate that Companies House has
> verified or validated it in any way."
>
> Dun and Bradstreet takes a copy of this information without any
> verification checking and can be easily updated here
> https://www.dnb.co.uk/utility-pages/data-update.html again without any
> verification checks.
>
> When a CA is vetting an organization for an EV certificate, what
> information is actually vetted? Does the organization operate at that
> address? Am I actually speaking to the director James Burton in the
> verification call?
>
> The correct way to vet a UK company would be to:
> 1. The CA checks Companies House to check if the company is incorporated.
> 2. The CA sends a letter with verification code to the company address
> listed on Companies House.
> 3. The CA requests the company to send them a bank statement / tax bill to
> prove operation.
> 4. Once the company has sent the information provided in (3) and is it
> confirmed by CA then (5) otherwise (3).
> 5. Once the company receives the letter with verification code then (6)
> otherwise vetting on hold until company receives letter with verification
> code.
> 6. The CA initiates video call with the director at the listed at
> Companies House and then the CA does the following:
> a) Asks the director to hold up his/her passport to the side of their face
> to confirm that the face matches the passport photo and then the CA
> confirms the details such full name and DOB matches the information printed
> on the passport.
> b) The CA asks the director to hold up the verification letter in front of
> the camera to confirm company address.
> c) The CA then calls the company number listed on 3rd party register
> (automated phone call like Google verification phone call) and the director
> tell that verification code to the CA to confirm the phone number is
> belongs to the company.
> d) Signs the agreement.
> 7. That's it.
>
> On Tue, Aug 27, 2019 at 9:21 AM Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 27/08/2019 08:03, Peter Gutmann wrote:
>> > Jakob Bohm via dev-security-policy <
>> dev-security-policy@lists.mozilla.org> writes:
>> >
>> >>  and
>> >>  both took advantage of weaknesses in two
>> >> government registries
>> >
>> > They weren't "weaknesses in government registries", they were registries
>> > working as designed, 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

Companies House (
http://resources.companieshouse.gov.uk/serviceInformation.shtml#compInfo)
says "We carry out basic checks on documents received to make sure that
they have been fully completed and signed, but we do not have the statutory
power or capability to verify the accuracy of the information that
companies send to us. The fact that the information has been placed on the
public record should not be taken to indicate that Companies House has
verified or validated it in any way."

Dun and Bradstreet takes a copy of this information without any
verification checking and can be easily updated here
https://www.dnb.co.uk/utility-pages/data-update.html again without any
verification checks.

When a CA is vetting an organization for an EV certificate, what
information is actually vetted? Does the organization operate at that
address? Am I actually speaking to the director James Burton in the
verification call?

The correct way to vet a UK company would be to:
1. The CA checks Companies House to check if the company is incorporated.
2. The CA sends a letter with verification code to the company address
listed on Companies House.
3. The CA requests the company to send them a bank statement / tax bill to
prove operation.
4. Once the company has sent the information provided in (3) and is it
confirmed by CA then (5) otherwise (3).
5. Once the company receives the letter with verification code then (6)
otherwise vetting on hold until company receives letter with verification
code.
6. The CA initiates video call with the director at the listed at Companies
House and then the CA does the following:
a) Asks the director to hold up his/her passport to the side of their face
to confirm that the face matches the passport photo and then the CA
confirms the details such full name and DOB matches the information printed
on the passport.
b) The CA asks the director to hold up the verification letter in front of
the camera to confirm company address.
c) The CA then calls the company number listed on 3rd party register
(automated phone call like Google verification phone call) and the director
tell that verification code to the CA to confirm the phone number is
belongs to the company.
d) Signs the agreement.
7. That's it.

On Tue, Aug 27, 2019 at 9:21 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 27/08/2019 08:03, Peter Gutmann wrote:
> > Jakob Bohm via dev-security-policy <
> dev-security-policy@lists.mozilla.org> writes:
> >
> >>  and
> >>  both took advantage of weaknesses in two
> >> government registries
> >
> > They weren't "weaknesses in government registries", they were registries
> > working as designed, and as intended.  The fact that they don't work in
> > they way EV wishes they did is a flaw in EV, not a problem with the
> > registries.
> >
>
> "Working as designed" doesn't mean "working as it should".
>
> The confusion that could be created online by getting EV certificates
> matching those company registrations were almost the same as those that
> could be created in the offline world by the registrations directly.
>
>
> >> Both demonstrations caused the researchers real name and identity to
> become
> >> part of the CA record, which was hand waved away by claiming that could
> >> have been avoided by criminal means.
> >
> > It wasn't "wished away", it's avoided without too much trouble by
> criminals,
> > see my earlier screenshot of just one of numerous black-market sites
> where
> > you can buy fraudulent EV certs from registered companies.  Again, EV may
> > wish this wasn't the case, but that's not how the real world works.
> >
>
> The screenshots you showed were for code signing EV certificates, not
> TLS EV certificates.  They seem related to a report a few years ago that
> spurned work to check the veracity of those screenshots and create
> appropriate countermeasures.
>
> >> 12 years old study involving en equally outdated browser.
> >
> > So you've published a more recent peer-reviewed academic study that
> > refutes the earlier work?  Could you send us the reference?
> >
>
> These two studies are outdated because they study the effects in a
> different overall situation (they were both made when the TLS EV concept
> had not yet been globally deployed).  They are thus based on entirely
> different facts (measured and unmeasured) than the situation in 2019.
>
> Very early in this thread someone quoted from a very recent study
> published at usenix, comparing the prevalence of malicious sites with
> different types of certificates.  The only response was platitudes,
> such as a emphasizing a small number being nonzero.
>
> Someone is trying very hard to create a fait acompli without going
> through proper debate and voting in relevant organizations such as
> the CAB/F.  So when challenged they play very dirty, using every
> rhetorical trick they can find to overpower criticism of 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 27/08/2019 08:03, Peter Gutmann wrote:
> Jakob Bohm via dev-security-policy  
> writes:
> 
>>  and
>>  both took advantage of weaknesses in two
>> government registries
> 
> They weren't "weaknesses in government registries", they were registries
> working as designed, and as intended.  The fact that they don't work in
> they way EV wishes they did is a flaw in EV, not a problem with the
> registries.
> 

"Working as designed" doesn't mean "working as it should".

The confusion that could be created online by getting EV certificates 
matching those company registrations were almost the same as those that 
could be created in the offline world by the registrations directly.


>> Both demonstrations caused the researchers real name and identity to become
>> part of the CA record, which was hand waved away by claiming that could
>> have been avoided by criminal means.
> 
> It wasn't "wished away", it's avoided without too much trouble by criminals,
> see my earlier screenshot of just one of numerous black-market sites where
> you can buy fraudulent EV certs from registered companies.  Again, EV may
> wish this wasn't the case, but that's not how the real world works.
> 

The screenshots you showed were for code signing EV certificates, not 
TLS EV certificates.  They seem related to a report a few years ago that 
spurned work to check the veracity of those screenshots and create 
appropriate countermeasures.

>> 12 years old study involving en equally outdated browser.
> 
> So you've published a more recent peer-reviewed academic study that
> refutes the earlier work?  Could you send us the reference?
> 

These two studies are outdated because they study the effects in a 
different overall situation (they were both made when the TLS EV concept 
had not yet been globally deployed).  They are thus based on entirely 
different facts (measured and unmeasured) than the situation in 2019.

Very early in this thread someone quoted from a very recent study 
published at usenix, comparing the prevalence of malicious sites with 
different types of certificates.  The only response was platitudes, 
such as a emphasizing a small number being nonzero.

Someone is trying very hard to create a fait acompli without going 
through proper debate and voting in relevant organizations such as 
the CAB/F.  So when challenged they play very dirty, using every 
rhetorical trick they can find to overpower criticism of the action.



Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

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

>
> Because no actual proof that DV versus EV makes no difference in the
> current (not ancient or anecdotal) situation has been posted.
>
>
To me that sounds like you are suggesting that we prove that nothing
happened, which is pretty much impossible.
Why don't you or the CAs offering EV prove that it did have a significant
impact?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

> and
> both took advantage of weaknesses in two
>government registries 

They weren't "weaknesses in government registries", they were registries
working as designed, and as intended.  The fact that they don't work in
they way EV wishes they did is a flaw in EV, not a problem with the
registries.

>Both demonstrations caused the researchers real name and identity to become 
>part of the CA record, which was hand waved away by claiming that could 
>have been avoided by criminal means.

It wasn't "wished away", it's avoided without too much trouble by criminals,
see my earlier screenshot of just one of numerous black-market sites where
you can buy fraudulent EV certs from registered companies.  Again, EV may 
wish this wasn't the case, but that's not how the real world works.

>12 years old study involving en equally outdated browser.

So you've published a more recent peer-reviewed academic study that
refutes the earlier work?  Could you send us the reference?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Mon, Aug 26, 2019, at 20:44, Jakob Bohm via dev-security-policy wrote:
> On 26/08/2019 21:49, Jonathan Rudenberg wrote:
> > On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
> >>  and
> >>  both took advantage of weaknesses in two
> >> government registries to create actual dummy companies with misleading
> >> names, then trying to get EV certs for those (with mixed success, as at
> >> least some CAs rejected or revoked the certs despite the government
> >> failures).
> > 
> > There were no "weaknesses" or "government failures" here, everything was 
> > operating exactly as designed.
> > 
> 
> The weakness is that those two government registries don't prevent 
> conflicting or obviously bad registrations, not even by retroactively 
> aborting the process in a few business days.
> 
> Even without the Internet this constitutes an obvious avenue for frauds.

There was no conflict. In the US, each state has unique laws around 
incorporation of entities. There is certainly no requirement that you can't 
have a corporate entity with the same name in two different states. There was 
nothing "conflicting" or "obviously bad" about Ian's corporation.

> >> At least the first of those demonstrations involved a no
> >> longer trusted CA (Symantec).
> > 
> > This doesn't appear to be relevant. The process followed was compliant with 
> > the EVGLs, and Symantec was picked because they were one of the most 
> > popular CAs at the time.
> > 
> 
> Symantec was distrusted for sloppy operation, that document version 
> (which we have since been informed was not the final version) claimed 
> that the only other CA tried did in fact reject the cert application, 
> indicating that issuing may not have been following "best current 
> practice" at the time.  The revised link posted tonight reverses this 
> information.

The original decision not to issue an EV certificate by Comodo was arbitrary 
and not based on any documented practices or guidelines. Additionally, as James 
mentioned and you can see here, Comodo issued the certificate: 
https://crt.sh/?id=438718367

> > 
> >> Both demonstrations caused the
> >> researchers real name and identity to become part of the CA record,
> >> which was hand waved away by claiming that could have been avoided by
> >> criminal means.
> > 
> > It's not handwaving to make the assertion that a fraudster would be willing 
> > to commit fraud while committing fraud. Can you explain why you think this 
> > argument is flawed?
> > 
> 
> The EVG requires the CA to attempt to verify the personal identity 
> information.  Stating without evidence that this verification is easily 
> defrauded is hand waving it away.

This is incorrect, Private Organization subjects (EVG 8.5.2) do not require any 
individual identity verification. Additionally, assuming that "personal 
identity information" can be validated without the opportunity for fraud has no 
basis in reality.

> >> Studies quoted by Tom Ritter on 24/08/2019:
> >>
> >>>
> >>> "By dividing these users into three groups, our controlled study
> >>> measured both the effect of extended validation certificates that
> >>> appear only at legitimate sites and the effect of reading a help file
> >>> about security features in Internet Explorer 7. Across all groups, we
> >>> found that picture-in-picture attacks showing a fake browser window
> >>> were as effective as the best other phishing technique, the homograph
> >>> attack. Extended validation did not help users identify either
> >>> attack."
> >>>
> >>> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >>>
> >>
> >> 12 years old study involving en equally outdated browser.
> > 
> > Can you explain why you believe the age this study is disqualifying? What 
> > components of the study do you believe are no longer valid due to their 
> > age? Are you aware of subsequent studies showing different results?
> > 
> 
> IE7 may have had a bad UI since changed.  12 years ago, there had not 
> been any big outreach campaigns telling users to look for the green bar, 
> nor a 10 year build up of user expectation that it would be there for 
> such sites.
>

Can you provide some references to these "big outreach campaigns" and 
documentation of the "build up of user expectation"?

> >>> "Our results showed that the identity indicators used in the
> >>> unmodified FF3browser did not influence decision-making for the
> >>> participants in our study interms of user trust in a web site. These
> >>> new identity indicators were ineffectivebecause none of the
> >>> participants even noticed their existence."
> >>>
> >>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
> >>>
> >>
> >> An undated(!) study involving highly outdated browsers.  No indication
> >> this was ever in a peer reviewed journal.
> > 
> > This is a peer-reviewed paper that was published in the 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 26/08/2019 21:49, Jonathan Rudenberg wrote:
> On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
>>  and
>>  both took advantage of weaknesses in two
>> government registries to create actual dummy companies with misleading
>> names, then trying to get EV certs for those (with mixed success, as at
>> least some CAs rejected or revoked the certs despite the government
>> failures).
> 
> There were no "weaknesses" or "government failures" here, everything was 
> operating exactly as designed.
> 

The weakness is that those two government registries don't prevent 
conflicting or obviously bad registrations, not even by retroactively 
aborting the process in a few business days.

Even without the Internet this constitutes an obvious avenue for frauds.

> 
>> At least the first of those demonstrations involved a no
>> longer trusted CA (Symantec).
> 
> This doesn't appear to be relevant. The process followed was compliant with 
> the EVGLs, and Symantec was picked because they were one of the most popular 
> CAs at the time.
> 

Symantec was distrusted for sloppy operation, that document version 
(which we have since been informed was not the final version) claimed 
that the only other CA tried did in fact reject the cert application, 
indicating that issuing may not have been following "best current 
practice" at the time.  The revised link posted tonight reverses this 
information.

> 
>> Both demonstrations caused the
>> researchers real name and identity to become part of the CA record,
>> which was hand waved away by claiming that could have been avoided by
>> criminal means.
> 
> It's not handwaving to make the assertion that a fraudster would be willing 
> to commit fraud while committing fraud. Can you explain why you think this 
> argument is flawed?
> 

The EVG requires the CA to attempt to verify the personal identity 
information.  Stating without evidence that this verification is easily 
defrauded is hand waving it away.

> 
>> Studies quoted by Tom Ritter on 24/08/2019:
>>
>>>
>>> "By dividing these users into three groups, our controlled study
>>> measured both the effect of extended validation certificates that
>>> appear only at legitimate sites and the effect of reading a help file
>>> about security features in Internet Explorer 7. Across all groups, we
>>> found that picture-in-picture attacks showing a fake browser window
>>> were as effective as the best other phishing technique, the homograph
>>> attack. Extended validation did not help users identify either
>>> attack."
>>>
>>> https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
>>>
>>
>> 12 years old study involving en equally outdated browser.
> 
> Can you explain why you believe the age this study is disqualifying? What 
> components of the study do you believe are no longer valid due to their age? 
> Are you aware of subsequent studies showing different results?
> 

IE7 may have had a bad UI since changed.  12 years ago, there had not 
been any big outreach campaigns telling users to look for the green bar, 
nor a 10 year build up of user expectation that it would be there for 
such sites.


> 
>>> "Our results showed that the identity indicators used in the
>>> unmodified FF3browser did not influence decision-making for the
>>> participants in our study interms of user trust in a web site. These
>>> new identity indicators were ineffectivebecause none of the
>>> participants even noticed their existence."
>>>
>>> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
>>>
>>
>> An undated(!) study involving highly outdated browsers.  No indication
>> this was ever in a peer reviewed journal.
> 
> This is a peer-reviewed paper that was published in the proceedings of 
> ESORICS 2008: 13th European Symposium on Research in Computer Security, 
> Málaga, Spain, October 6-8, 2008. Dates are actually (unfortunately) uncommon 
> on CS papers unless the publication metadata/frontmatter is intact.
> 

The link posted on Saturday did not in any way provide that publication 
data, attempting to remove the "type=pdf" parameter from the link just 
provided a 404, rather than the expected metadata page or link, which is 
probably a failure of the citeseerx software.

Once again, the study is more than 10 years old, not reflecting the 
public consciousness after years of outreach and user experience.


> 
>>> DV is sufficient. Why pay for something you don't need?
>>>
>>
>> Unproven claim, especially by studies from before free DV without
>> traceable credit card payments became the norm.
> 
> I don't follow your argument here. The evidence shows that DV is sufficient 
> for phishing, as has been repeatedly explained on this thread.
> 

Because no actual proof that DV versus EV makes no difference in the 
current (not ancient or anecdotal) situation has been posted.

Back when DV certificates cost money, the mere 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[James Burton via dev-security-policy]

Jakob,

Before I touch on your comments, I wanted to point out that I am fairly
well known in the CA industry even back then and that fact might have
tainted the results sightly because I am treated some what differently to
other orders as the validation staff look more carefully at the information
presented in the order. If the order came from an anonymous body then the
chance of the success of the order is very high because the validation
staff would process it as normal without higher level intervention which
mostly happens with my orders.

The reasons why I chose Symantec:
a) They were the largest and most popular CA at that present time and most
of the largest companies in the world used that CA.
b) Symantec also provided a 30 day risk-free trial of their EV SSL and my
thinking was at the time that criminals would take advantage of that fact.

I did try Comodo first time and it did fail, the second time I tried Comodo
it worked. I publish it here:
https://www.typewritten.net/writer/ev-phishing-final/

Thank you

Burton

On Mon, Aug 26, 2019 at 8:00 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 24/08/2019 05:55, Tom Ritter wrote:
> > On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
> >  wrote:
> >>
> >> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
> >>> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> >>>
> >>> Whatever the merits of EV (and perhaps there are some -- I'm not
> >>> convinced either way) this data is negligible evidence of them. A DV
> >>> cert is sufficient for phishing, so there's no reason for a phisher to
> >>> obtain an EV cert, hence very few phishing sites use them, hence EV
> >>> sites are (at present) mostly not phishing sites.
> >>
> >> Can you proove that your assumption "very few phishing sites use EV
> (only) because DV is sufficient" is correct?
> >
> > As before, the first email in the thread references the studies
> performed.
>
> The (obviously outdated) studies quoted below were NOT referenced by the
> first message in this thread.  The first message only referenced two
> highly unpersuasive demonstrations of the mischief possible in
> controlled experiments.
>
>  and
>  both took advantage of weaknesses in two
> government registries to create actual dummy companies with misleading
> names, then trying to get EV certs for those (with mixed success, as at
> least some CAs rejected or revoked the certs despite the government
> failures).  At least the first of those demonstrations involved a no
> longer trusted CA (Symantec).  Both demonstrations caused the
> researchers real name and identity to become part of the CA record,
> which was hand waved away by claiming that could have been avoided by
> criminal means.
>
>
> Studies quoted by Tom Ritter on 24/08/2019:
>
> >
> > "By dividing these users into three groups, our controlled study
> > measured both the effect of extended validation certificates that
> > appear only at legitimate sites and the effect of reading a help file
> > about security features in Internet Explorer 7. Across all groups, we
> > found that picture-in-picture attacks showing a fake browser window
> > were as effective as the best other phishing technique, the homograph
> > attack. Extended validation did not help users identify either
> > attack."
> >
> > https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> >
>
> 12 years old study involving en equally outdated browser.
>
> > "Our results showed that the identity indicators used in the
> > unmodified FF3browser did not influence decision-making for the
> > participants in our study interms of user trust in a web site. These
> > new identity indicators were ineffectivebecause none of the
> > participants even noticed their existence."
> >
> >
> http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
> >
>
> An undated(!) study involving highly outdated browsers.  No indication
> this was ever in a peer reviewed journal.
>
> > DV is sufficient. Why pay for something you don't need?
> >
>
> Unproven claim, especially by studies from before free DV without
> traceable credit card payments became the norm.
>
>
> Enjoy
>
> Jakob
> --
> Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
> Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
> This public discussion message is non-binding and may contain errors.
> WiseMo - Remote Service Management for PCs, Phones and Embedded
> ___
> 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: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Mon, Aug 26, 2019 at 05:39:14AM -0700, Josef Schneider via 
dev-security-policy wrote:
> Sure I can register a company and get an EV certificate for that company. 
> But can I do this completely anonymous like getting a DV cert?

Yes.

> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them.  But they do raise the bar for criminals.  And in my
> opinion, significantly.

Except criminals don't need them.  Raising the bar doesn't help if you don't
need to go over the bar.

> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to
> the problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.

Why should Mozilla do all this work?  So far, all the evidence suggests that
EV certs do not do what their advocates say they do, and have a significant
cost to browsers (code complexity, administration of EV bits, etc) and
relying parties (need to learn what the EV UI means, what it does and
doesn't claim, etc).

Instead of Mozilla continuing to take on the burden of keeping this ship
afloat, why don't the parties that benefit from selling EV certs (ie CAs) do
the hard yards to figure out what works, in a rigorous and scientific way,
and then present the results of that research to the wider community?

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jonathan Rudenberg via dev-security-policy]

On Mon, Aug 26, 2019, at 15:01, Jakob Bohm via dev-security-policy wrote:
>  and
>  both took advantage of weaknesses in two
> government registries to create actual dummy companies with misleading
> names, then trying to get EV certs for those (with mixed success, as at
> least some CAs rejected or revoked the certs despite the government
> failures).

There were no "weaknesses" or "government failures" here, everything was 
operating exactly as designed.


> At least the first of those demonstrations involved a no
> longer trusted CA (Symantec).

This doesn't appear to be relevant. The process followed was compliant with the 
EVGLs, and Symantec was picked because they were one of the most popular CAs at 
the time.


> Both demonstrations caused the
> researchers real name and identity to become part of the CA record,
> which was hand waved away by claiming that could have been avoided by
> criminal means.

It's not handwaving to make the assertion that a fraudster would be willing to 
commit fraud while committing fraud. Can you explain why you think this 
argument is flawed?


> Studies quoted by Tom Ritter on 24/08/2019:
> 
> > 
> > "By dividing these users into three groups, our controlled study
> > measured both the effect of extended validation certificates that
> > appear only at legitimate sites and the effect of reading a help file
> > about security features in Internet Explorer 7. Across all groups, we
> > found that picture-in-picture attacks showing a fake browser window
> > were as effective as the best other phishing technique, the homograph
> > attack. Extended validation did not help users identify either
> > attack."
> > 
> > https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf
> > 
> 
> 12 years old study involving en equally outdated browser.

Can you explain why you believe the age this study is disqualifying? What 
components of the study do you believe are no longer valid due to their age? 
Are you aware of subsequent studies showing different results?


> > "Our results showed that the identity indicators used in the
> > unmodified FF3browser did not influence decision-making for the
> > participants in our study interms of user trust in a web site. These
> > new identity indicators were ineffectivebecause none of the
> > participants even noticed their existence."
> > 
> > http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf
> > 
> 
> An undated(!) study involving highly outdated browsers.  No indication
> this was ever in a peer reviewed journal.

This is a peer-reviewed paper that was published in the proceedings of ESORICS 
2008: 13th European Symposium on Research in Computer Security, Málaga, Spain, 
October 6-8, 2008. Dates are actually (unfortunately) uncommon on CS papers 
unless the publication metadata/frontmatter is intact.


> > DV is sufficient. Why pay for something you don't need?
> > 
> 
> Unproven claim, especially by studies from before free DV without
> traceable credit card payments became the norm.

I don't follow your argument here. The evidence shows that DV is sufficient for 
phishing, as has been repeatedly explained on this thread.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 24/08/2019 05:55, Tom Ritter wrote:

On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
 wrote:


Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:

On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:

Whatever the merits of EV (and perhaps there are some -- I'm not
convinced either way) this data is negligible evidence of them. A DV
cert is sufficient for phishing, so there's no reason for a phisher to
obtain an EV cert, hence very few phishing sites use them, hence EV
sites are (at present) mostly not phishing sites.


Can you proove that your assumption "very few phishing sites use EV (only) because 
DV is sufficient" is correct?


As before, the first email in the thread references the studies performed.


The (obviously outdated) studies quoted below were NOT referenced by the
first message in this thread.  The first message only referenced two
highly unpersuasive demonstrations of the mischief possible in
controlled experiments.

 and
 both took advantage of weaknesses in two
government registries to create actual dummy companies with misleading
names, then trying to get EV certs for those (with mixed success, as at
least some CAs rejected or revoked the certs despite the government
failures).  At least the first of those demonstrations involved a no
longer trusted CA (Symantec).  Both demonstrations caused the
researchers real name and identity to become part of the CA record,
which was hand waved away by claiming that could have been avoided by
criminal means.


Studies quoted by Tom Ritter on 24/08/2019:



"By dividing these users into three groups, our controlled study
measured both the effect of extended validation certificates that
appear only at legitimate sites and the effect of reading a help file
about security features in Internet Explorer 7. Across all groups, we
found that picture-in-picture attacks showing a fake browser window
were as effective as the best other phishing technique, the homograph
attack. Extended validation did not help users identify either
attack."

https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf



12 years old study involving en equally outdated browser.


"Our results showed that the identity indicators used in the
unmodified FF3browser did not influence decision-making for the
participants in our study interms of user trust in a web site. These
new identity indicators were ineffectivebecause none of the
participants even noticed their existence."

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf



An undated(!) study involving highly outdated browsers.  No indication
this was ever in a peer reviewed journal.


DV is sufficient. Why pay for something you don't need?



Unproven claim, especially by studies from before free DV without
traceable credit card payments became the norm.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/26/2019 5:39 AM, Josef Schneider via dev-security-policy wrote:

Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:

On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:

Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but 
using an EV SSL in conjunction with a domain name and website with the true 
intent to dupe potential customers is another matter. I'm trying to get past 
the theoretical and get to real world instances.

I don't understand the idea that the Stripe proof-of-concept is
"theoretical". We know that phishing is epidemic, and we also know that
phishers presently need -- at most -- a DV cert. The POC shows that --
should something cause phishers to need an EV cert -- they can also get
one of those quickly and inexpensively. But why would a phisher bother
with an EV cert if a DV cert works just as well?

The important question is can they get this without making them easily 
traceable?
Sure I can register a company and get an EV certificate for that company. But 
can I do this completely anonymous like getting a DV cert?

How long do you think would it have taken for the police to come and get Ian 
Carroll if he'd actually committed fraud?


Probably years, if ever, particularly if he lived in a subpoena-haven 
like Russia. My impression (as a U.S. citizen) is that U.S. police don't 
take online crimes seriously, and neither does the federal government. 
This idea is supported by the enormous amount of phishing and other 
online frauds in the U.S. My email client flags several new 
phishes/frauds each day. True, there has been a bit of action about the 
online crimes that subverted U.S. elections in 2016, but that's an 
unusual exception to the rule. Russia is, of course, refusing to 
extradite the people that Sp. Counsel Mueller indicted.



...What I propose is for mozilla to not say "Fuck it, it's not working, just remove 
it!" but instead try to focus on finding a better UX solution to the problem that 
end users are not aware if a site that should have an EV certificate is not presenting 
one.


I think this is a reasonable idea, particularly the last clause. I am 
not against EV, but neither am I convinced of its usefulness.


-R

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Wayne Thayer via dev-security-policy]

On Mon, Aug 26, 2019 at 5:39 AM Josef Schneider via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:
> > On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:
> > > Deploying a Stripe Inc EV SSL from a state other than CA is one thing,
> but using an EV SSL in conjunction with a domain name and website with the
> true intent to dupe potential customers is another matter. I'm trying to
> get past the theoretical and get to real world instances.
> >
> > I don't understand the idea that the Stripe proof-of-concept is
> > "theoretical". We know that phishing is epidemic, and we also know that
> > phishers presently need -- at most -- a DV cert. The POC shows that --
> > should something cause phishers to need an EV cert -- they can also get
> > one of those quickly and inexpensively. But why would a phisher bother
> > with an EV cert if a DV cert works just as well?
>
>
> The important question is can they get this without making them easily
> traceable?
> Sure I can register a company and get an EV certificate for that company.
> But can I do this completely anonymous like getting a DV cert?
>
> How long do you think would it have taken for the police to come and get
> Ian Carroll if he'd actually committed fraud?
>
> Nobody is arguing that EV certificates are perfect and everything is good
> if you use them. But they do raise the bar for criminals. And in my
> opinion, significantly.
>
> What I propose is for mozilla to not say "Fuck it, it's not working, just
> remove it!" but instead try to focus on finding a better UX solution to the
> problem that end users are not aware if a site that should have an EV
> certificate is not presenting one.
>
>
The counter-argument is that not all problems can be solved with UX, and
getting browser users to recognize and respond to the lack of an EV
indicator is in that class of unsolvable problems.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Josef Schneider via dev-security-policy]

Am Sonntag, 18. August 2019 20:05:42 UTC+2 schrieb Ronald Crane:
> On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:
> > Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but 
> > using an EV SSL in conjunction with a domain name and website with the true 
> > intent to dupe potential customers is another matter. I'm trying to get 
> > past the theoretical and get to real world instances.
> 
> I don't understand the idea that the Stripe proof-of-concept is 
> "theoretical". We know that phishing is epidemic, and we also know that 
> phishers presently need -- at most -- a DV cert. The POC shows that -- 
> should something cause phishers to need an EV cert -- they can also get 
> one of those quickly and inexpensively. But why would a phisher bother 
> with an EV cert if a DV cert works just as well?


The important question is can they get this without making them easily 
traceable?
Sure I can register a company and get an EV certificate for that company. But 
can I do this completely anonymous like getting a DV cert?

How long do you think would it have taken for the police to come and get Ian 
Carroll if he'd actually committed fraud?

Nobody is arguing that EV certificates are perfect and everything is good if 
you use them. But they do raise the bar for criminals. And in my opinion, 
significantly.

What I propose is for mozilla to not say "Fuck it, it's not working, just 
remove it!" but instead try to focus on finding a better UX solution to the 
problem that end users are not aware if a site that should have an EV 
certificate is not presenting one.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jernej Simončič via dev-security-policy]

On Fri, 23 Aug 2019 15:53:21 -0700 (PDT), Daniel Marschall wrote:

> Can you proove that your assumption "very few phishing sites use EV (only) 
> because DV is sufficient" is correct? I do think the truth is "very few 
> phishing sites use EV, because EV is hard to get".

Before browsers started showing dire warnings on non-secure pages,
basically no phishing site bothered with SSL at all, since their target
audience simply didn't notice anything wrong.

-- 
begin  .sig
< Jernej Simončič ><>◊<>< jernej|s-ng at eternallybored.org >
end
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Tom Ritter via dev-security-policy]

On Fri, 23 Aug 2019 at 22:53, Daniel Marschall via dev-security-policy
 wrote:
>
> Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
> > On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> >
> > Whatever the merits of EV (and perhaps there are some -- I'm not
> > convinced either way) this data is negligible evidence of them. A DV
> > cert is sufficient for phishing, so there's no reason for a phisher to
> > obtain an EV cert, hence very few phishing sites use them, hence EV
> > sites are (at present) mostly not phishing sites.
>
> Can you proove that your assumption "very few phishing sites use EV (only) 
> because DV is sufficient" is correct?

As before, the first email in the thread references the studies performed.

"By dividing these users into three groups, our controlled study
measured both the effect of extended validation certificates that
appear only at legitimate sites and the effect of reading a help file
about security features in Internet Explorer 7. Across all groups, we
found that picture-in-picture attacks showing a fake browser window
were as effective as the best other phishing technique, the homograph
attack. Extended validation did not help users identify either
attack."

https://www.adambarth.com/papers/2007/jackson-simon-tan-barth.pdf

"Our results showed that the identity indicators used in the
unmodified FF3browser did not influence decision-making for the
participants in our study interms of user trust in a web site. These
new identity indicators were ineffectivebecause none of the
participants even noticed their existence."

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.543.2117=rep1=pdf

DV is sufficient. Why pay for something you don't need?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Bowen via dev-security-policy]

On Thu, Aug 22, 2019 at 1:44 PM kirkhalloregon--- via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Some have responded there is no research saying EV sites have
> significantly less phishing (and are therefore safer) than DV sites – Tim
> has listed two studies that say exactly that, and I’m not aware of any
> studies that say the opposite.  I can tell you that anti-phishing services
> and browser phishing filters have also have concluded that EV sites are
> very unlikely to be phishing sites and so are safer for users.
>
> Some opponents of the EV UI say it should go away because users don’t
> understand or know how to evaluate the specific organization information
> that’s displayed.  That’s true to a point – but an improved EV UI for
> Firefox could follow Apple’s example by showing a binary “identity/no
> identity” UI that would be easy for users to understand – green lock symbol
> and URL for identity (EV), black for no identity (DV).  If users want to
> see the specific organization information for the identity sites, it can be
> displayed with one click on the green lock symbol.
>


> users will have different needs to scrutinize identity information at
> different times.  Let’s look at currency, for example.  Currency contains
> many marks to validate its legitimacy such as watermarks, holograms, and
> the like.  The same person may treat currency differently based on
> context.  The same person might take cash out of the ATM with little close
> scrutiny but then look closely at the money received from a scalper at a
> sporting event or concert.  In the first case, the context is considered to
> be low risk, and in the second it’s considered to be high risk.  The
> security indicators are always there, so the relying party can take
> advantage of them when they’re warranted.



> To close - browsers love data, and Mozilla has a lot of really smart
> engineers.  That’s why I hope Mozilla will come up with innovative ways to
> use EV data, and not just drop it.
>

Kirk,

I think you hit the nail on the head here.  One of the big advantages of
the PKI model used in the public Internet is that certificates are
independent of browsers.   Different systems can use information contained
in the same certificate in different ways.  The validated information is
present in the certificate regardless of the browser UI.  Many browser
users have plugins installed to help detect malicious websites and software
downloads (frequently as part of an overall Internet security suite along
with anti-virus and anti-malware scanners).  These Internet security tools
can use the EV data to help implement user controllable policies completely
independent of the core browser UI.

Additionally, many people and organizations have filtering proxies that can
do some level of introspection.  My home router can do network filtering
and I know large enterprise firewalls do the same.  In TLS 1.2, they can
review the certificate and terminate the connection if it doesn't meet the
policies of the proxy owner.  This is an ideal place to check EV and does
not rely upon the end user remembering to check if the lock is black or
green.

There are also opportunities for browsers here.  I have to admit I
primarily use Google Chrome, rather than Firefox, so my observations may be
a little tainted, but I see various places where signals far more valuable
than the green lock could be implemented.  Consider that most browsers
recognize credit card entry fields -- wouldn't it be great if clicking on
one on an EV site showed a little drop down under the input box that said
"[CA name here] has certified that [EV info here] is receiving your credit
card information"?

I don't see the currently proposed change in the Firefox UI as having a
notable impact on the future of EV certificates.

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/23/2019 3:53 PM, Daniel Marschall via dev-security-policy wrote:

Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:

On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:

Whatever the merits of EV (and perhaps there are some -- I'm not
convinced either way) this data is negligible evidence of them. A DV
cert is sufficient for phishing, so there's no reason for a phisher to
obtain an EV cert, hence very few phishing sites use them, hence EV
sites are (at present) mostly not phishing sites.

Can you proove that your assumption "very few phishing sites use EV (only) because DV is 
sufficient" is correct? I do think the truth is "very few phishing sites use EV, because 
EV is hard to get".


Well, I can't "prove" the assertion, but I can provide some evidence for 
it. For example, Russia's GRU phished (Hillary Clinton's campaign 
manager) John Podesta in 2016 using the URL-shortening service bit.ly. 
[1] Since such services are widely used for legitimate links, most 
people click on them as a matter of course, except for some denizens of 
security forums such as this one. In any case, the link forwarded him to 
an GRU site, into which he entered his Gmail credentials, and the rest 
is history. I don't know whether the GRU site used an EV cert, but I am 
unaware of any evidence for that idea.


Someone earlier in this thread cited a stat that the vast majority of 
phishing sites that use certs use DV certs. According an (apparently 
CA-sponsored) study from 2017 [2], only about 12% of phishing sites even 
bother to use SSL. Of those, basically all use DV certs (Id. at p.2-3). 
This data implies that most users who can be phished can be phished 
without even using SSL, and most of the remainder can be phished using a 
DV cert.


Now *maybe* (1) if EV certs were widely used, and (2) verification was 
uniformly-strong, and (3) browser publishers really tried to train 
users, and (4) legitimate sites stopped using URL-shortening services 
and multiple domains, and (5) we solved the Stripe POC issue (multiple 
domains presented as owned by a company with a name similar to the 
desired one, but actually registered to a different entity in a 
different jurisdiction), *then* EV would significantly improve users' 
safety. Maybe.


-R

[1] 
https://www.cbsnews.com/news/the-phishing-email-that-hacked-the-account-of-john-podesta/ 
. This article claims that the GRU successfully used the same trick on 
(Former U.S. Secretary of State) Colin Powell and the Democratic 
National Committee.


[2] 
https://casecurity.org/wp-content/uploads/2017/09/Incidence-of-Phishing-Among-DV-OV-and-EV-Websites-9-13-2017-short-vepdf




I do not think EV certificates are easy to get. The black market stories are 
probably more about code signing certificates, I guess. And even if you would 
find an EV SSL certificate on the black market, then it would be revoked as 
soon as it is used, and that organization will never get an EV certificate 
again. So the harm that black market certificates (if there are any at all...) 
is very small!
___
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: Intent to Ship: Move Extended Validation Information out of the URL bar

[Daniel Marschall via dev-security-policy]

Am Freitag, 23. August 2019 00:50:35 UTC+2 schrieb Ronald Crane:
> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> 
> Whatever the merits of EV (and perhaps there are some -- I'm not 
> convinced either way) this data is negligible evidence of them. A DV 
> cert is sufficient for phishing, so there's no reason for a phisher to 
> obtain an EV cert, hence very few phishing sites use them, hence EV 
> sites are (at present) mostly not phishing sites.

Can you proove that your assumption "very few phishing sites use EV (only) 
because DV is sufficient" is correct? I do think the truth is "very few 
phishing sites use EV, because EV is hard to get".

I do not think EV certificates are easy to get. The black market stories are 
probably more about code signing certificates, I guess. And even if you would 
find an EV SSL certificate on the black market, then it would be revoked as 
soon as it is used, and that organization will never get an EV certificate 
again. So the harm that black market certificates (if there are any at all...) 
is very small!
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[sslcorp.team--- via dev-security-policy]

> 
> Correlation does not imply causation.
> 
> There are studies that show phishing sites tend not to be EV - yes.
> That's a correlation.
> 
> If we studied phishing sites and domain name registration fees I'm
> sure we'd find a correlation there too - I'd bet the .cfd TLD (which
> apparently costs $16K to register) has a low incident of pishing as
> well.
> 
> There are also studies that indicate users don't pay attention to the
> (positive) security indicators. To phish users, it's unnecessary to
> get an EV indicator vs a DV indicator. The simpler explanation for the
> correlation is that EV is more expensive (both in direct cost, and in
> effort to get misleading documents), so why would you pay for
> something you don't need?
> 
> -tom

I find this to a bit of a false equivalency. 

Put another way, if EV was just as easy to obtain (in terms of cost and effort) 
as DV, everything else being equal, would phishing scammers still prefer DV 
over EV? Could the same be said about .cfd vs .com or .io? 

My guess is that phishing sites would have more success, however incremental, 
(especially on high value sites such as banking) displaying EV UI, and the 
opposite would happen on a .cfd domain. In fact, one of the arguments against 
EV was that it gave a false sense of security to would-be victims. If I'm a 
scammer, that's what I want for my phishing site.

It does come down to cost vs benefit in the world of phishing economics. The 
incremental boost of an EV indicator is just not worth the expense in 
comparison with DV to most scammers. Now that the EV UI is going away, this is 
one less concern they will need to bother with. I don't think they're sad about 
this.

So I do see causation to low adoption of EV on phishing sites. But since DV is 
good enough for most run-of-the-mill scam sites, that's the common path.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/23/2019 6:41 AM, Tom Ritter via dev-security-policy wrote:

On Fri, 23 Aug 2019 at 05:00, Leo Grove via dev-security-policy
 wrote:

On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote:

On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:

I can tell you that anti-phishing services and browser phishing filters have 
also have concluded that EV sites are very unlikely to be phishing sites and so 
are safer for users.

Whatever the merits of EV (and perhaps there are some -- I'm not
convinced either way) this data is negligible evidence of them. A DV
cert is sufficient for phishing, so there's no reason for a phisher to
obtain an EV cert, hence very few phishing sites use them, hence EV
sites are (at present) mostly not phishing sites.

-R

So you agree it's safe to assume with high probability that when I come across 
a site displaying an EV SSL, it's not a phishing site. I think that is one of 
the purposes of EV.

Or should we remove the EV bling because phishing sites prefer to use DV?

Correlation does not imply causation.

There are studies that show phishing sites tend not to be EV - yes.
That's a correlation.

If we studied phishing sites and domain name registration fees I'm
sure we'd find a correlation there too - I'd bet the .cfd TLD (which
apparently costs $16K to register) has a low incident of pishing as
well.
I agree. Also, we really should be interested in what proportion of 
legitimate EV sites are being impersonated, versus what proportion of 
legitimate OV/DV sites are being impersonated. We also should be 
interested in what happens when a legitimate site moves from OV/DV to 
EV, or vice versa. Those stats would tell us something about EV's 
effectiveness.

...To phish users, it's unnecessary to
get an EV indicator vs a DV indicator. The simpler explanation for the
correlation is that EV is more expensive (both in direct cost, and in
effort to get misleading documents), so why would you pay for
something you don't need?


Yep.

-R

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Tom Ritter via dev-security-policy]

On Fri, 23 Aug 2019 at 05:00, Leo Grove via dev-security-policy
 wrote:
>
> On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote:
> > On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> > > I can tell you that anti-phishing services and browser phishing filters 
> > > have also have concluded that EV sites are very unlikely to be phishing 
> > > sites and so are safer for users.
> >
> > Whatever the merits of EV (and perhaps there are some -- I'm not
> > convinced either way) this data is negligible evidence of them. A DV
> > cert is sufficient for phishing, so there's no reason for a phisher to
> > obtain an EV cert, hence very few phishing sites use them, hence EV
> > sites are (at present) mostly not phishing sites.
> >
> > -R
>
> So you agree it's safe to assume with high probability that when I come 
> across a site displaying an EV SSL, it's not a phishing site. I think that is 
> one of the purposes of EV.
>
> Or should we remove the EV bling because phishing sites prefer to use DV?

Correlation does not imply causation.

There are studies that show phishing sites tend not to be EV - yes.
That's a correlation.

If we studied phishing sites and domain name registration fees I'm
sure we'd find a correlation there too - I'd bet the .cfd TLD (which
apparently costs $16K to register) has a low incident of pishing as
well.

There are also studies that indicate users don't pay attention to the
(positive) security indicators. To phish users, it's unnecessary to
get an EV indicator vs a DV indicator. The simpler explanation for the
correlation is that EV is more expensive (both in direct cost, and in
effort to get misleading documents), so why would you pay for
something you don't need?

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Leo Grove via dev-security-policy]

On Thursday, August 22, 2019 at 5:50:35 PM UTC-5, Ronald Crane wrote:
> On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:
> > I can tell you that anti-phishing services and browser phishing filters 
> > have also have concluded that EV sites are very unlikely to be phishing 
> > sites and so are safer for users.
> 
> Whatever the merits of EV (and perhaps there are some -- I'm not 
> convinced either way) this data is negligible evidence of them. A DV 
> cert is sufficient for phishing, so there's no reason for a phisher to 
> obtain an EV cert, hence very few phishing sites use them, hence EV 
> sites are (at present) mostly not phishing sites.
> 
> -R

So you agree it's safe to assume with high probability that when I come across 
a site displaying an EV SSL, it's not a phishing site. I think that is one of 
the purposes of EV.

Or should we remove the EV bling because phishing sites prefer to use DV? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/22/2019 1:43 PM, kirkhalloregon--- via dev-security-policy wrote:

I can tell you that anti-phishing services and browser phishing filters have 
also have concluded that EV sites are very unlikely to be phishing sites and so 
are safer for users.


Whatever the merits of EV (and perhaps there are some -- I'm not 
convinced either way) this data is negligible evidence of them. A DV 
cert is sufficient for phishing, so there's no reason for a phisher to 
obtain an EV cert, hence very few phishing sites use them, hence EV 
sites are (at present) mostly not phishing sites.


-R

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[kirkhalloregon--- via dev-security-policy]

On Monday, August 12, 2019 at 2:31:22 PM UTC-4, Wayne Thayer wrote:
> Mozilla has announced that we plan to relocate the EV UI in Firefox 70,
> which is expected to be released on 22-October. Details below.
> 
> If the before and after images are stripped from the email, you can view
> them here:
> 
> Before:
> https://lh4.googleusercontent.com/pSX4OAbkPCu2mhBfeleKKe842DgW28-xAIlRjhtBlwFdTzNhtNE7R43nqBS1xifTuB0L8LO979yhpPpLUIOtDdfJd3UwBmdxFBl7eyX_JihYi7FqP-2LQ5xw4FFvQk2bEObdKQ9F
> 
> After:
> https://lh5.googleusercontent.com/kL-WUskmTnKh4vepfU3cSID_ooTXNo9BvBOmIGR1RPvAN7PGkuPFLsSMdN0VOqsVb3sAjTsszn_3LjRf4Q8eoHtkrNWWmmxOo3jBRoEJV--XJndcXiCeTTAmE4MuEfGy8RdY_h5u
> 
> - Wayne
> 
> -- Forwarded message -
> From: Johann Hofmann 
> Date: Mon, Aug 12, 2019 at 1:05 AM
> Subject: Intent to Ship: Move Extended Validation Information out of the
> URL bar
> To: Firefox Dev 
> Cc: dev-platform , Wayne Thayer <
> wtha...@mozilla.com>
> 
> 
> In desktop Firefox 70, we intend to remove Extended Validation (EV)
> indicators from the identity block (the left hand side of the URL bar which
> is used to display security / privacy information). We will add additional
> EV information to the identity panel instead, effectively reducing the
> exposure of EV information to users while keeping it easily accessible.
> 
> Before:
> 
> 
> After:
> 
> 
> The effectiveness of EV has been called into question numerous times over
> the last few years, there are serious doubts whether users notice the
> absence of positive security indicators and proof of concepts have been 
> pitting
> EV against domains <https://www.typewritten.net/writer/ev-phishing/> for
> phishing.
> 
> More recently, it has been shown <https://stripe.ian.sh/> that EV
> certificates with colliding entity names can be generated by choosing a
> different jurisdiction. 18 months have passed since then and no changes
> that address this problem have been identified.
> 
> The Chrome team recently removed EV indicators from the URL bar in Canary
> and announced their intent to ship this change in Chrome 77
> <https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/h1bTcoTpfeI>.
> Safari is also no longer showing the EV entity name instead of the domain
> name in their URL bar, distinguishing EV only by the green color. Edge is
> also no longer showing the EV entity name in their URL bar.
> 
> 
> 
> On our side a pref for this
> (security.identityblock.show_extended_validation) was added in bug 1572389
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1572389> (thanks :evilpie for
> working on it!). We're planning to flip this pref to false in bug 1572936
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1572936>.
> 
> Please let us know if you have any questions or concerns,
> 
> Wayne & Johann

Thanks to Tim Callan for making the case for keeping and even improving the EV 
UI in Firefox.  I want to add a few more points to this interesting discussion.

Some have responded there is no research saying EV sites have significantly 
less phishing (and are therefore safer) than DV sites – Tim has listed two 
studies that say exactly that, and I’m not aware of any studies that say the 
opposite.  I can tell you that anti-phishing services and browser phishing 
filters have also have concluded that EV sites are very unlikely to be phishing 
sites and so are safer for users.

Some opponents of the EV UI say it should go away because users don’t 
understand or know how to evaluate the specific organization information that’s 
displayed.  That’s true to a point – but an improved EV UI for Firefox could 
follow Apple’s example by showing a binary “identity/no identity” UI that would 
be easy for users to understand – green lock symbol and URL for identity (EV), 
black for no identity (DV).  If users want to see the specific organization 
information for the identity sites, it can be displayed with one click on the 
green lock symbol.  With a little user training (such as a pop-up for a few 
months explaining what the green UI means), users could understand – after all, 
users still remember “look for the lock symbol” for user security.

Remember that the need for knowledge of a website’s identity is not homogenous 
across users and uses.  For instance, users will have different needs to 
scrutinize identity information at different times.  Let’s look at currency, 
for example.  Currency contains many marks to validate its legitimacy such as 
watermarks, holograms, and the like.  The same person may treat currency 
differently based on context.  The same person might take cash out of the ATM 
machine with little close scrutiny but then look closely at the money received 
from a scalper at a sporting event or concert.  In the 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Tadahiko Ito via dev-security-policy]

(From my personal point of view)
I read Google’s paper[1].
For me, that paper’s result could be hypothesized like “some people do care 
about some information, which is written in EV but not in DV”.

That is…
(A) If you click EV indicator, you will able to get more information about 
identity (compare to DV).
(B) If you click page info without EV indicator, you usually only see DV cert’s 
identity information, which does not say much. (number of OV is far less than 
number of DV).

Expected amount of information, from action (A) and (B) is very different, and 
expected information from (B) is small.
So, even if there were someone who is aware of physical identity, He just do A) 
for best effort.

#for me, it sounds more reasonable than “large size of the EV indicator draws 
accidental clicks” (3.2.2 of [1]).

According to above thought, I feel like browser should (at least) 
differentiates 
-DV AND
-OV or EV.
Otherwise, people who do care about information on OV or EV would become tired 
of clicking page info of DV. 
#Do we just need identity on cyber space? I do not think many people would 
agree that.

[1] The Web’s Identity Crisis:Understanding the Effectiveness of Website 
Identity Indicators,  
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/400599205ab5a1c9efa03e2a7c127eb8200bf288.pdf
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[scott.helme--- via dev-security-policy]

> 
> What evidence or research shows that the new location is providing better
> protection for the end users?

What evidence or research shows that any location provides any protection for 
the end users? 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Sun, Aug 18, 2019 at 09:14:52AM +0200, Paul van Brouwershaven wrote:
> On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, <
> dev-security-policy@lists.mozilla.org> wrote:
> > On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via
> > dev-security-policy wrote:
> > > Shouldn’t the large enterprises that see a value in identity (as
> > > does GlobalSign) drive the need for ending EV certificates?
> >
> > Can you point me to the in-progress discussion in the CA/B Forum lists
> > that is proposing to end EV certificates?  From what I can see so far,
> > browser vendors aren't "ending" EV certificates, a couple of them are
> > merely
> > modifying their UIs guided by relevant research into the efficacy (or lack
> > thereof) of the current UI.
> 
> What evidence or research shows that the new location is providing better
> protection for the end users?

I don't think it requires rigorous research to show that 0 >= 0.

- Matt

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Gutmann via dev-security-policy]

Daniel Marschall via dev-security-policy 
 writes:

>I just looked at Opera and noticed that they don't have any UI difference at
>all, which means I have to open the X.509 certificate to see if it is EV or
>not.

Does anyone know when Opera made the change?  They had EV UI at one point, and
then there's this bug report:

https://forums.opera.com/topic/17923/ev-certificate-looks-like-ov

which blames the lack of EV UI on Chromium, so something inherited from
Chrome.  It looks like it's then just a side-effect of the Chrome change and
allegedly "fixed in 44.0.2494.0", but Chrome 57 was from 2017, which means at
some point the change got reinstated.

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Sun, Aug 18, 2019 at 01:35:55PM -0700, Daniel Marschall via 
dev-security-policy wrote:
> Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:
> > [...] From what I can see so far,
> > browser vendors aren't "ending" EV certificates, a couple of them are merely
> > modifying their UIs guided by relevant research into the efficacy (or lack
> > thereof) of the current UI.
> 
> Matt, I don't understand this.  Isn't removing the UI bling the same as
> "removing" EV from the browser?

Yes, but removing EV from the browser isn't the same as ending EV
certificates, which is what was claimed in the message I responded to.

> I guess that EV will eventually ended by the Customers/CAs.

We'll have to leave it to the invisible hand of the market to sort that out. 
If CAs cease issuing EV TLS/SSL certificates, it will presumably be because
customers are no longer buying them, and customers will cease buying them if
there is no perceived value in them, which is what CAs have repeatedly said
isn't the case.  So CAs ceasing to issue EV TLS/SSL certificates will be a
confirmation that, in fact, EV TLS/SSL certificates had no value beyond the
UI "bling", as you call it, which the research overwhelmingly indicates is
of trivial value.

> I just looked at Opera and noticed that they don't have any UI difference
> at all, which means I have to open the X.509 certificate to see if it is
> EV or not.

So that's one more browser vendor that sees no value in "UI bling" for EV
certificates.  It almost makes Firefox and Chrome look like the laggards in
this decision, rather than the harbingers of a new era.

- Matt

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Daniel Marschall via dev-security-policy]

Am Sonntag, 18. August 2019 07:18:56 UTC+2 schrieb Matt Palmer:
> 
> [...] From what I can see so far,
> browser vendors aren't "ending" EV certificates, a couple of them are merely
> modifying their UIs guided by relevant research into the efficacy (or lack
> thereof) of the current UI.
> 
> - Matt

Matt, I don't understand this. Isn't removing the UI bling the same as 
"removing" EV from the browser? The UI difference is either so tiny or even 
not-existant, so I guess that EV will eventually ended by the Customers/CAs. I 
just looked at Opera and noticed that they don't have any UI difference at all, 
which means I have to open the X.509 certificate to see if it is EV or not.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Ronald Crane via dev-security-policy]

On 8/18/2019 12:39 AM, Leo Grove via dev-security-policy wrote:

Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but 
using an EV SSL in conjunction with a domain name and website with the true 
intent to dupe potential customers is another matter. I'm trying to get past 
the theoretical and get to real world instances.


I don't understand the idea that the Stripe proof-of-concept is 
"theoretical". We know that phishing is epidemic, and we also know that 
phishers presently need -- at most -- a DV cert. The POC shows that -- 
should something cause phishers to need an EV cert -- they can also get 
one of those quickly and inexpensively. But why would a phisher bother 
with an EV cert if a DV cert works just as well?


-R

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Leo Grove via dev-security-policy]

On Sunday, August 18, 2019 at 12:15:58 AM UTC-5, Matt Palmer wrote:
> On Fri, Aug 16, 2019 at 10:03:53PM -0700, Leo Grove via dev-security-policy 
> wrote:
> > However, as a user I support EV SSL.  I personally have never come across
> > a scam site that displayed an EV SSL (I'm not saying they don't exist). 
> > Has anyone else come across a "scam site" displaying EV that's not part of
> > an academic exercise?
> 
> Counter-question: why does that matter?
> 
> - Matt

It matters because someone on this discussion claimed to be able to buy an EV 
SSL on the black market and used it as a supporting argument against EV. I'd 
honestly like to know if anyone has seen one in "in the wild" so to speak.

My write-up was from the perspective of a user so I'd like to know if I've been 
putting too much faith in EV SSL since there may be scam sites employing these 
pirated certificates.

Deploying a Stripe Inc EV SSL from a state other than CA is one thing, but 
using an EV SSL in conjunction with a domain name and website with the true 
intent to dupe potential customers is another matter. I'm trying to get past 
the theoretical and get to real world instances.

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Paul van Brouwershaven via dev-security-policy]

On Sun, 18 Aug 2019, 07:18 Matt Palmer via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via
> dev-security-policy wrote:
> > Shouldn’t the large enterprises that see a value in identity (as
> > does GlobalSign) drive the need for ending EV certificates?
>
> Can you point me to the in-progress discussion in the CA/B Forum lists
> that is proposing to end EV certificates?  From what I can see so far,
> browser vendors aren't "ending" EV certificates, a couple of them are
> merely
> modifying their UIs guided by relevant research into the efficacy (or lack
> thereof) of the current UI.
>

What evidence or research shows that the new location is providing better
protection for the end users?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
> That’s where EV certificates can help.  Data shows that websites with EV
> certificates have a very low incidence of phishing.

[...]

> This research validates the results of an earlier study of 3,494 encrypted
> phishing sites in February 2019 [5].  In this study the distribution of
> encrypted phishing sites by certificate type was as follows:
> 
> EV0 phishing sites (0%)

If you replace "EV" in the above with "WombleSecure(TM)(PatPend) security
seal", it is equally as true, and equally irrelevant.  It's the old "tiger
repelling rock" spiel ("Do you see any tigers around?  See, it works
great!") with a splash of X.509 for flavour.

It is not the hardest problem in science to design and execute an experiment
to demonstrate EV's efficacy.  At the most basic level, it could be "here is
a site that was receiving X reports of users being phished per month, they
deployed an EV cert and their report rate went down to Y per month, here are
the confounding factors we considered and here's why they weren't the
cause".  Increase the number of sites to improve power as needed.

That no EV-issuing CA has published the results of such an experiment, given
the large revenues it would protect, and the strong signalling that browsers
have been making over (at least) the last several years, the most plausible
explanation to me is that EV-issuing CAs *have* done the experiments, and
they didn't show anything, so in the finest traditions of
commercially-motivated science, they just buried it.  The other option is
that the management EV-issuing CAs are just clueless, which is possible, but
not really any more comforting.

- Matt

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Fri, Aug 16, 2019 at 01:37:40PM +, Doug Beattie via dev-security-policy 
wrote:
> DB: Yes, that's true.  I was saying that phishing sites don't use EV, not
> that EV sites don't get phished
> 
> Surely this shows that EV is not needed to make phishing work, not that EV 
> reduces phishing?
> 
> [DB] It should show that users are safer when visiting an EV secured site.

When you have evidence of that, please feel free to share it.  Everything
that has been presented so far doesn't *actually* show that, it merely shows
something else that people then furiously hand-wave into "see, security!".

- Matt

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

Re: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Thu, Aug 15, 2019 at 05:58:56PM +, Doug Beattie via dev-security-policy 
wrote:
> Shouldn’t the large enterprises that see a value in identity (as
> does GlobalSign) drive the need for ending EV certificates?

Can you point me to the in-progress discussion in the CA/B Forum lists
that is proposing to end EV certificates?  From what I can see so far,
browser vendors aren't "ending" EV certificates, a couple of them are merely
modifying their UIs guided by relevant research into the efficacy (or lack
thereof) of the current UI.

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Matt Palmer via dev-security-policy]

On Fri, Aug 16, 2019 at 03:15:39PM -0700, Daniel Marschall via 
dev-security-policy wrote:
> (2) I am a pro EV person, and I do not have any financial benefit from EV
> certificates.  I do not own EV certificates, instead my own websites use
> Let's Encrypt DV certificates.  But when I visit important pages like
> Google or PayPal, I do look at the EV indicator bar, because I know that
> these pages always have an EV certificate.

This would be a stronger argument if any Google property had an EV certificate,
or if paypal.com had been displaying an EV treatment on the most commonly
used Browser/OS combo for the past year.

> different color, that would be OK for me).  We cannot say that all users
> don't care about the EV indicator.  For some users like me, it is
> important.

I'm sure a browser plugin could be developed to provide some sort of
indication that a certificate being presented was EV, and you could install
that if you were sufficiently interested.

- Matt

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

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Jakob Bohm via dev-security-policy]

On 17/08/2019 00:56, James Burton wrote:

If one compares the first EV specification with the current EV
specification one will notice that the EV specification hasn't changed that
much during its lifetime. The issues presented during the last years though
research have been known about since the first adoption of the EV
specification. If CAs really cared about EV they would have tried and
improved it during the past 10+ years but nothing happened. If browsers
decided to keep EV what would change? Nothing at all.


Latest change was May 21, 2019.  This added a way to include additional 
government identifiers and very strict validation if that was a banking 
identity.


The EV standards development has always been an adversarial thing with
relying party representatives (only browsers allowed to participate,
unfortunately) requiring stronger checks and CAs trying to minimize the
requirements imposed on them.

The alleged "issues presented during the last years through research"
are mostly red herrings.



There is no one point in discussing the removal of EV any further because
the EV specification had already died.


This change doesn't just remove EV, it kills OV too.  I have always
argued that the UI difference between EV and OV should be reduced or
removed, but removing the difference between EV and DV is so obviously
malicious it is indefensible.



On Fri, Aug 16, 2019 at 11:19 PM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


Honestly the issues, as I see them, are twofold:

1.  When I visit a site for the first time, how do I know I should expect
an EV certificate?  I am conscientious about subsequent visits, especially
financial industry sites.

2.  The browsers seem to have a bias toward the average user, that user
literally being less ...smart/aware... than half of all of users.  EV is a
feature that can only benefit people who are vigilant and know what to look
for.  It seems dismissive of the more capable users, but I suppose that's
their call.


A stronger, less confusing UI indicator of EV vs. DV (the important
distinction) would greatly reduce that problem.  Instead there has been
an agenda to gradually fade the indication into invisibility, and this
is apparently the final blow.

An obvious non-malicious way forward would be:

1. Reject and revert this malicious change from Mozilla based browsers
  and market this difference as a major benefit of Firefox over the 3
  platform browsers (IE/Edge, Safari and Chrome).  Minor browsers are
  thus shown that there still is a real choice to be better too.

2. Restore the clear rule that the entire address bar will be in the
  color of the certificate validation strength, (initially green for
  EV, white for DV/none, Red for clearly invalid).  Not just a partial
  coloration.

3. Fix the indicator weaknesses (spoofable color favicon in indicator
  area, not switching to the color of a weaker page element cert,
  showing identity fields that are not the same for all page elements).

4. Use different color for OV vs. no cert/DV to reflect the actual
  difference.

5. Display the information from OV certs like the same information in
  EV certs, even if it doesn't qualify for EV color.  For example
  company name and country in OV color where those values pass all
  checks except being EV.

6. Continue to push for stronger (but not excessive) validation of
  certificate elements other than the domain name.  For example there
  should be meaningful validation that the certificate requester
  controls the claimed street address, but having to send an man to
  physically visit every business address every few years would be too
  much for regular EV certs, but still appropriate for "high value/risk
  identities" (similar to "high value/risk domains", but different
  fields).




On Fri, Aug 16, 2019 at 5:15 PM Daniel Marschall via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


I have a few more comments/annotations:

(1) Pro EV persons argue "Criminals have problems getting an EV
certificate, so most of them are using only DV certificates".

Anti EV persons argue "Criminals just don't use EV certificates, because
they know that end users don't look at the EV indicator anyway".

I assume, we do not know which of these two assumptions fits to the
majority of criminals. So why should we make a decision (change of UI)
based on such assumptions?

(2) I am a pro EV person, and I do not have any financial benefit from EV
certificates. I do not own EV certificates, instead my own websites use
Let's Encrypt DV certificates. But when I visit important pages like

Google

or PayPal, I do look at the EV indicator bar, because I know that these
pages always have an EV certificate. If I would visit PayPal and only

see a

normal pad lock (DV), then I would instantly leave the page because I

know

that PayPal always has an EV certificate. So, at least for me, the UI
change is very negative (except if 

Re: Intent to Ship: Move Extended Validation Information out of the URL bar

[Peter Gutmann via dev-security-policy]

Jakob Bohm via dev-security-policy  
writes:

>Your legendary dislike for all things X.509 is showing. 

My dislike for persisting mindlessly with stuff we already know doesn't work
is showing (see in particular the quote typically misattributed to Einstein
about the definition of insanity), and given the rich target environment
that's available in the security field that's in no way limited to X.509.
Apart from that, you're quite correct.

It's not working.  

It's obvious that it's not working.  

It's been obvious for years that it's not working.

Time to try a new approach, rather than just repeating a new variant of what
we already know doesn't work all over again.

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