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

2019-09-04 Thread 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

2019-09-04 Thread 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

2019-09-04 Thread 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

2019-09-03 Thread 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

2019-09-02 Thread 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

2019-08-31 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-30 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread Lee via dev-security-policy
On 8/29/19, Nick Lamb  wrote:
> 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.

I'm expecting to see the same string I've seen every other time I
visited that site.

I did have one bank that was bought out by another & they even sent a
letter about the upcoming name change.  ^shrug^ 1st time after the
change I still called & had them read me the new company name string.

> As a domain expert I know why my good bank says:
  <.. snip examples ..>

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

Right.  I get the implication.  I disagree with it because I'm not
guessing what the displayed name is supposed to be, I already know.
Which is why I don't like the proposed change - it makes it harder to
verify the site.  (yes, one or two mouse clicks isn't all _that_ much
harder, but I'm going to be ranting at mozilla every time I make those
clicks.  Great PR move Moz://a!  Remind me every time I visit a
banking site how much more I liked the older version of FF)

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

How does that square with a few msgs upthread where bgp hijacks were mentioned?

I'd agree that's a low probability event, but if someone manages to
hijack the routes for dns + my bank & gets a free cert 2 minutes later
for what is supposedly my bank...  it seems like that ev cert is the
only thing left preventing me from entering my credentials on an
imposter web site.

> In a broader picture, there isn't much you should bother trying to do,
> the onus is largely on the bank.

Even if the onus _is_ largely on the bank, I'd much rather not find
out how long it's going to take & what all I have to do to recover
from entering my credentials on an imposter site.

Regards,
Lee
___
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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread Jonathan Rudenberg via dev-security-policy
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
___
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

2019-08-29 Thread 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

2019-08-29 Thread 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

2019-08-29 Thread Lee via dev-security-policy
On 8/29/19, Nick Lamb via dev-security-policy
 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?

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.

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.

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?

Thanks,
Lee
___
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

2019-08-29 Thread 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

2019-08-29 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-28 Thread 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

2019-08-28 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-27 Thread 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

2019-08-27 Thread 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

2019-08-27 Thread 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

2019-08-27 Thread 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

2019-08-27 Thread 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

2019-08-27 Thread 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

2019-08-26 Thread 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

2019-08-26 Thread 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

2019-08-26 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-26 Thread 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

2019-08-26 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-24 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-23 Thread 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

2019-08-22 Thread 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

2019-08-22 Thread 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

2019-08-22 Thread 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  for
> phishing.
> 
> More recently, it has been shown  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
> .
> 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
>  (thanks :evilpie for
> working on it!). We're planning to flip this pref to false in bug 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 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.

Likewise, some 

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

2019-08-21 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-17 Thread 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: Intent to Ship: Move Extended Validation Information out of the URL bar

2019-08-17 Thread 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

2019-08-17 Thread 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

2019-08-16 Thread 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


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

2019-08-16 Thread Jakob Bohm via dev-security-policy

On 17/08/2019 03:15, Peter Gutmann wrote:

Corey Bonnell via dev-security-policy  
writes:


the effectiveness of the EV UI treatment is predicated on whether or not the
user can memorize which websites always use EV certificates *and* no longer
proceed with using the website if the EV treatment isn't shown. That's a huge
cognitive overhead for everyday web browsing


In any case things like Perspectives and Certificate Patrol already do this
for you, with no overhead for the user, and it's not dependent on whether the
cert is EV or not.  They're great add-ons for detecting sudden cert changes.

Like EV certs though, they have no effect on phishing.  They do very
effectively detect MITM, but for most users it's phishing that's the real
killer.



Your legendary dislike for all things X.509 is showing.  You are
constantly arguing that because they are not perfect, they are useless,
while ignoring any and all improvements since you original write ups.

You really should look at the long term agendas at work here and
reconsider what you may be inadvertently supporting.


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

2019-08-16 Thread Peter Gutmann via dev-security-policy
Corey Bonnell via dev-security-policy  
writes:

>the effectiveness of the EV UI treatment is predicated on whether or not the
>user can memorize which websites always use EV certificates *and* no longer
>proceed with using the website if the EV treatment isn't shown. That's a huge
>cognitive overhead for everyday web browsing

In any case things like Perspectives and Certificate Patrol already do this
for you, with no overhead for the user, and it's not dependent on whether the
cert is EV or not.  They're great add-ons for detecting sudden cert changes.

Like EV certs though, they have no effect on phishing.  They do very
effectively detect MITM, but for most users it's phishing that's the real
killer.

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

2019-08-16 Thread James Burton via dev-security-policy
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.

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

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.
>
> 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 you color the pad lock in a 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.
> >
> > (3) Also, I wanted to ask, if you want to remove the UI indicator,
> because
> > you think that EV certificates give the feeling of false security, then
> > please tell me: What is the alternative? Removing the UI bling without
> > giving any alternative solution is just wrong in my opinion. Yes, there
> > might be a tiny amount of phishing sites that use EV certificates, but
> the
> > EV indicator bar is still better than just nothing. AntiPhishing filters
> > are not a good alternative because they only protect when the harm is
> > already done to some users.
> > ___
> > 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

2019-08-16 Thread Matthew Hardeman via dev-security-policy
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.

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 you color the pad lock in a 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.
>
> (3) Also, I wanted to ask, if you want to remove the UI indicator, because
> you think that EV certificates give the feeling of false security, then
> please tell me: What is the alternative? Removing the UI bling without
> giving any alternative solution is just wrong in my opinion. Yes, there
> might be a tiny amount of phishing sites that use EV certificates, but the
> EV indicator bar is still better than just nothing. AntiPhishing filters
> are not a good alternative because they only protect when the harm is
> already done to some users.
> ___
> 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

2019-08-16 Thread Daniel Marschall via dev-security-policy
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 you color the pad lock in a 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.

(3) Also, I wanted to ask, if you want to remove the UI indicator, because you 
think that EV certificates give the feeling of false security, then please tell 
me: What is the alternative? Removing the UI bling without giving any 
alternative solution is just wrong in my opinion. Yes, there might be a tiny 
amount of phishing sites that use EV certificates, but the EV indicator bar is 
still better than just nothing. AntiPhishing filters are not a good alternative 
because they only protect when the harm is already done to some 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

2019-08-16 Thread Kurt Roeckx via dev-security-policy
On Fri, Aug 16, 2019 at 12:42:35PM -0700, tim--- via dev-security-policy wrote:
> 
> By way of background, until recently almost all phishing and malware was on 
> unencrypted http sites. They received a neutral UI, and the bad guys didn’t 
> have to spend time and money getting a certificate, even a DV certificate, 
> that might leave traces as to their identity. Users were told (and remembered 
> the advice) to “look for the lock symbol” for greater security.
> 
> Then a few things happened in close proximity: (1) Google incentivized all 
> websites to move to encryption through the use of its “Not secure” warning, 
> (2) Mozilla instituted a similar “Not Secure” warning, and (3) Let’s Encrypt 
> began offering anonymous, automated DV certificates to everyone, including 
> known phishing sites, in part through Platinum-level financial support from 
> Mozilla and Google.
> 
> As a result, virtually all phishing has now moved to DV encrypted websites 
> which receive the lock symbol in Firefox, which was predictable. In fact, the 
> FBI just issued a warning to consumers not to trust the https or lock symbol 
> in browsers anymore [1], as half or more of phishing sites now display the 
> lock symbol. [2]
> 
> It’s unclear how Mozilla plans to ramp up protection for Firefox users. 
> Browser phishing filters such as Google Safe Browsing are good, but not 
> perfect. According to the most recent NSS labs report issued in October 2018, 
> GSB offers only about 79% user protection at “zero hour”, gradually rising to 
> 95% protection after 2 days. [3] However, most phishing sites are shut down 
> by then anyway. If a browser phishing filter is the main defense provided to 
> users by Firefox, this means thousands of users can be harmed before a site 
> is flagged for phishing. Clearly Mozilla should be looking for other ways to 
> protect them.
> 
> That’s where EV certificates can help. Data shows that websites with EV 
> certificates have a very low incidence of phishing. New research from RWTH 
> Aachen University presented at Usenix this week measured the incidence of 
> phishing sites using certificates of various validation levels [4]. EV 
> certificates made up 0.4% of the total population of phishing sites with 
> certificates but 7% of the “benign” (non-phishing) sites. Compare that to OV, 
> where 15% of phishing sites had that certificate type and 35% of benign sites 
> had the same. And compare that again to Let’s Encrypt certificates, which 
> made up 34% of certificates for phishing sites and only 17% for benign sites.
> 
> 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%)
> OV145 phishing sites (4.15%)*
> DV3,349 phishing sites (95.85%)
> 
> *(These phishing OV certs were mostly multi-SANs certs requested by CDNs such 
> as Cloudflare containing multiple URLs for websites whose content the Subject 
> of the OV cert did not control. Perhaps such certificates should be DV rather 
> than OV.)
> 
> Furthermore, research from Georgia Tech shows that EV sites have an 
> exceedingly low incidence of association with malware and known bad actors 
> [6].
> 
> 
> These studies show that the presence of an EV certificate has a strong 
> negative correlation with criminal activity intent on victimizing the site 
> visitor. In plain terms, users are safer when they visit sites with EV certs. 
> Now, how do we use that?

So they either don't have anything to do, just check some box, or need
to spend 1 minute to get a DV certs. And as your research shows,
DV certs are good enough to do phishing, they don't need EV certs,
so why would they bother?

But they you also say that 0.4% actually used an EV certificate.
My guess in that case is that they didn't actually bother to get
an EV ceritificate, but just hacked some website that just happens
to have an EV certificate.

I also think that 7% of the non-phising sites using EV
certificates doesn't make sense at all, and that's most likely a
sample bias.

> This is where the argument that “users don’t see the absence of positive 
> indicators” misses the mark for several reasons. 
> 1. The internet is in possession of a clear signal of a site’s safety for the 
> end user. The fact that popular end-user software fails to take advantage of 
> this signal is a shortcoming of that software, not the signal.

So here you turn a correlation into a causation.

> 3. User behavior also changes based on context. The site visitor who suffers 
> from interface blindness when everything is going well may become hyper aware 
> when something suspicious occurs. If nothing else, the presence of an EV cert 
> gives the likes of law enforcement a clear path forward when pursuing 
> perpetrators of online crime.

phishing sites don't expect everybody to be fooled. If 1 in 1
is 

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

2019-08-16 Thread Paul van Brouwershaven via dev-security-policy
Thanks Tim, well written and I completely agree!

In this thread Issues have been raised about that EV validation is not
perfect and that criminals can obtain an EV certificate (if they reveal
their identity). I also agree that the validation can be improved, but as
Tim stated, that doesn't mean its not useful today.

Take for example Troy Hunt, who has been feeding this whole discussion, he
wrote in his own comments that he trusts an website with an EV certificate
more than others.

Training users to make good security decisions based on available identity
information is something that would make a real difference.

I feel that browsers can have significant impact, if they would explain the
EV information when a user starts the browser for the first time and when
they attend the user on the presence of the organization name when they
haven't seen one recently for example. But don't get me wrong, this is not
only the responsibility of the browsers, also the CA's should take
responsibility and reserve a part of the revenue for user education.

On Fri, 16 Aug 2019, 22:17 tim--- via dev-security-policy, <
dev-security-policy@lists.mozilla.org> wrote:

> My apologies for not weighing in earlier, but like many others I was
> surprised by this announcement and had to make time to craft this message
> around other pressing demands. The original announcement above that the EV
> UI would be removed in October cited authorities and articles that were in
> favor of what Mozilla wants to do. It would be useful to this community to
> understand and consider other relevant evidence and arguments that were not
> included there.
>
> By way of background, until recently almost all phishing and malware was
> on unencrypted http sites. They received a neutral UI, and the bad guys
> didn’t have to spend time and money getting a certificate, even a DV
> certificate, that might leave traces as to their identity. Users were told
> (and remembered the advice) to “look for the lock symbol” for greater
> security.
>
> Then a few things happened in close proximity: (1) Google incentivized all
> websites to move to encryption through the use of its “Not secure” warning,
> (2) Mozilla instituted a similar “Not Secure” warning, and (3) Let’s
> Encrypt began offering anonymous, automated DV certificates to everyone,
> including known phishing sites, in part through Platinum-level financial
> support from Mozilla and Google.
>
> As a result, virtually all phishing has now moved to DV encrypted websites
> which receive the lock symbol in Firefox, which was predictable. In fact,
> the FBI just issued a warning to consumers not to trust the https or lock
> symbol in browsers anymore [1], as half or more of phishing sites now
> display the lock symbol. [2]
>
> It’s unclear how Mozilla plans to ramp up protection for Firefox users.
> Browser phishing filters such as Google Safe Browsing are good, but not
> perfect. According to the most recent NSS labs report issued in October
> 2018, GSB offers only about 79% user protection at “zero hour”, gradually
> rising to 95% protection after 2 days. [3] However, most phishing sites are
> shut down by then anyway. If a browser phishing filter is the main defense
> provided to users by Firefox, this means thousands of users can be harmed
> before a site is flagged for phishing. Clearly Mozilla should be looking
> for other ways to protect them.
>
> That’s where EV certificates can help. Data shows that websites with EV
> certificates have a very low incidence of phishing. New research from RWTH
> Aachen University presented at Usenix this week measured the incidence of
> phishing sites using certificates of various validation levels [4]. EV
> certificates made up 0.4% of the total population of phishing sites with
> certificates but 7% of the “benign” (non-phishing) sites. Compare that to
> OV, where 15% of phishing sites had that certificate type and 35% of benign
> sites had the same. And compare that again to Let’s Encrypt certificates,
> which made up 34% of certificates for phishing sites and only 17% for
> benign sites.
>
> 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:
>
> EV  0 phishing sites (0%)
> OV  145 phishing sites (4.15%)*
> DV  3,349 phishing sites (95.85%)
>
> *(These phishing OV certs were mostly multi-SANs certs requested by CDNs
> such as Cloudflare containing multiple URLs for websites whose content the
> Subject of the OV cert did not control. Perhaps such certificates should be
> DV rather than OV.)
>
> Furthermore, research from Georgia Tech shows that EV sites have an
> exceedingly low incidence of association with malware and known bad actors
> [6].
>
> These studies show that the presence of an EV certificate has a strong
> negative correlation with criminal activity intent on victimizing the site
> 

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

2019-08-16 Thread tim--- via dev-security-policy
My apologies for not weighing in earlier, but like many others I was surprised 
by this announcement and had to make time to craft this message around other 
pressing demands. The original announcement above that the EV UI would be 
removed in October cited authorities and articles that were in favor of what 
Mozilla wants to do. It would be useful to this community to understand and 
consider other relevant evidence and arguments that were not included there.

By way of background, until recently almost all phishing and malware was on 
unencrypted http sites. They received a neutral UI, and the bad guys didn’t 
have to spend time and money getting a certificate, even a DV certificate, that 
might leave traces as to their identity. Users were told (and remembered the 
advice) to “look for the lock symbol” for greater security.

Then a few things happened in close proximity: (1) Google incentivized all 
websites to move to encryption through the use of its “Not secure” warning, (2) 
Mozilla instituted a similar “Not Secure” warning, and (3) Let’s Encrypt began 
offering anonymous, automated DV certificates to everyone, including known 
phishing sites, in part through Platinum-level financial support from Mozilla 
and Google.

As a result, virtually all phishing has now moved to DV encrypted websites 
which receive the lock symbol in Firefox, which was predictable. In fact, the 
FBI just issued a warning to consumers not to trust the https or lock symbol in 
browsers anymore [1], as half or more of phishing sites now display the lock 
symbol. [2]

It’s unclear how Mozilla plans to ramp up protection for Firefox users. Browser 
phishing filters such as Google Safe Browsing are good, but not perfect. 
According to the most recent NSS labs report issued in October 2018, GSB offers 
only about 79% user protection at “zero hour”, gradually rising to 95% 
protection after 2 days. [3] However, most phishing sites are shut down by then 
anyway. If a browser phishing filter is the main defense provided to users by 
Firefox, this means thousands of users can be harmed before a site is flagged 
for phishing. Clearly Mozilla should be looking for other ways to protect them.

That’s where EV certificates can help. Data shows that websites with EV 
certificates have a very low incidence of phishing. New research from RWTH 
Aachen University presented at Usenix this week measured the incidence of 
phishing sites using certificates of various validation levels [4]. EV 
certificates made up 0.4% of the total population of phishing sites with 
certificates but 7% of the “benign” (non-phishing) sites. Compare that to OV, 
where 15% of phishing sites had that certificate type and 35% of benign sites 
had the same. And compare that again to Let’s Encrypt certificates, which made 
up 34% of certificates for phishing sites and only 17% for benign sites.

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:

EV  0 phishing sites (0%)
OV  145 phishing sites (4.15%)*
DV  3,349 phishing sites (95.85%)

*(These phishing OV certs were mostly multi-SANs certs requested by CDNs such 
as Cloudflare containing multiple URLs for websites whose content the Subject 
of the OV cert did not control. Perhaps such certificates should be DV rather 
than OV.)

Furthermore, research from Georgia Tech shows that EV sites have an exceedingly 
low incidence of association with malware and known bad actors [6].

These studies show that the presence of an EV certificate has a strong negative 
correlation with criminal activity intent on victimizing the site visitor. In 
plain terms, users are safer when they visit sites with EV certs. Now, how do 
we use that?

This is where the argument that “users don’t see the absence of positive 
indicators” misses the mark for several reasons. 
1. The internet is in possession of a clear signal of a site’s safety for the 
end user. The fact that popular end-user software fails to take advantage of 
this signal is a shortcoming of that software, not the signal.
2. Users are not a single homogenous group, and they don’t all behave the same. 
Proof positive of that fact is that most of the people participating in this 
thread do, in fact, notice whether or not an EV indicator is there. They are 
not the only ones in the world. In the absence of compelling reasons to remove 
the indicator, providing this evidence to some users is superior to providing 
it to none.
3. User behavior also changes based on context. The site visitor who suffers 
from interface blindness when everything is going well may become hyper aware 
when something suspicious occurs. If nothing else, the presence of an EV cert 
gives the likes of law enforcement a clear path forward when pursuing 
perpetrators of online crime.
4. Positive security indicators do work in many other 

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

2019-08-16 Thread Nick Lamb via dev-security-policy
On Fri, 16 Aug 2019 13:31:08 +
Doug Beattie via dev-security-policy
 wrote:

> DB: One of the reasons that phishers don't get EV certificates is
> because the vetting process requires several interactions and
> corporate repositories which end up revealing more about their
> identity.  This leaves a trail back to the individual that set up the
> fake site which discourages the use of EV. DV is completely anonymous
> and leaves very few traces.

It's really tangential to Mozilla's purpose but it's worth dispelling
this myth.

Nothing about your identity is revealed. Let's take the country I live
in as an example, it looks superficially as though you need to reveal a
lot of personal details to register a company in the United Kingdom.
Surely this is all backed up with the considerable power of the
government of a major world power, and so if I can track down which
company is behind a phishing site then the individuals responsible
won't be hard to find right?

Er, no. If you just lie on the paperwork nothing will happen. If
private citizens point out specifically that the paperwork for your
company is a tissue of lies, Companies House will reply to explain that
alas the government doesn't have sufficient resources to investigate or
do anything about it and so it's just too bad their records are largely
fictitious nonsense. Still they promise they _care_ about this, it's
a top priority, just not one that anything will be done about...

There has been exactly one prosecution for lying to Companies House in
the modern era. They had the money and pursued it through the courts
very enthusiastically on exactly that one occasion and no other. Guess
why? Because someone wrote up paperwork for a bogus company naming
famous politicians who'd done nothing to fix this for years. That was
bad publicity, and so the government threw resources at "fixing" the
problem, ie prosecuting the person who pointed out the corruption.

Read "Where there's Muck there's Brass Plates" for further examples of
how much worse than few fraudsters phishing for bank credentials the
rot in British companies already is:
https://www.private-eye.co.uk/special-reports/where-theres-muck


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

2019-08-15 Thread Nick Lamb via dev-security-policy
On Thu, 15 Aug 2019 22:11:37 +0200
Eric Rescorla via dev-security-policy
 wrote:

> I expect this is true, but it seems to me that if anything it is an
> argument that EV doesn't provide security value, not the other way
> around: DV certificates are much cheaper to obtain than EV, and so
> naturally if you just need a certificate you're going to get DV.
> OTOH, if users actually trusted EV more, it might be worthwhile for
> an attacker to get EV anyway.

It is as ever simultaneously reassuring and annoying to see EKR wrote
what I was thinking but more succinctly and a few hours before I get
time to draft an email.

Further:

My interpretation is that a LOT of phishing sites in 2019 only
have DV certificates because that was the default. The crooks didn't
think "I need a certificate" they thought "I need a web site" and in
2019 a typical web site comes with a certificate - same as you don't
need to buy separate seatbelts for your car these days.

If we are looking to protect users from Phishing, we should promote
WebAuthn, not Extended Validation, because we know WebAuthn actually
protects users from phishing.

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

2019-08-15 Thread deanjc18--- via dev-security-policy
On Thursday, August 15, 2019 at 7:30:46 AM UTC-4, Kurt Roeckx wrote:
> On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via 
> dev-security-policy wrote:
> > In old Firefox, I get a green bar if I visit google.com and paypal.com, 
> > telling me that this is a well-known company that got the EV certificate.
> > The other fake domains goog1e.com and paypa1.com only have DV certificates 
> > by Let's Encrypt.
> 
> The green bar does not indicate that it's a well-known company. It
> means someone payed for an EV certificate. The green bar does not
> in any way say it's more secure or indicate that you're talking to
> some trustworthy company. It only gives you a false sense of
> security.
> 
> 
> Kurt

That's a pretty disingenuous description of EV certificates. Whether they paid 
for it or not isn't the issue. It means that some entity applied for an EV 
certificate, the CA used the vetting methods described in the CA/B Forum EV 
guidelines (which were agreed to by CAs and browsers) to verify the domain, the 
company, the address, location, etc. Only after that is complete is an EV 
certificate issued.  The CA was then audited against the work they did (in 
addition to assuring they meet physical, network and other audit requirements), 
annually. 
I have to agree with Jakob, it's remarkable that Mozilla would make such a 
drastic change with only a 2 day announcement and no discussion.
___
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

2019-08-15 Thread Kurt Roeckx via dev-security-policy
On Wed, Aug 14, 2019 at 11:52:46PM -0700, Daniel Marschall via 
dev-security-policy wrote:
> In old Firefox, I get a green bar if I visit google.com and paypal.com, 
> telling me that this is a well-known company that got the EV certificate.
> The other fake domains goog1e.com and paypa1.com only have DV certificates by 
> Let's Encrypt.

The green bar does not indicate that it's a well-known company. It
means someone payed for an EV certificate. The green bar does not
in any way say it's more secure or indicate that you're talking to
some trustworthy company. It only gives you a false sense of
security.


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

2019-08-15 Thread Daniel Marschall via dev-security-policy
Please tell me if I understand this correctly...
Is it that DV and EV certificates now both show the same lock symbol?
That would be a great harm in my opinion. And I do not understand why you want 
this change.

I think EV is very important and I explain why.

Let's look at following hypothetical case: We have google.com, paypal.com as 
well as goog1e.com and paypa1.com . Notice the two number 1 (one) instead of a 
lower case L in the latter two domains. (lowecase "L" and "one" look perfectly 
equal in Times New Roman. And lowercase "L" looks perfectly equal to uppercase 
"i" in Arial.)

In old Firefox, I get a green bar if I visit google.com and paypal.com, telling 
me that this is a well-known company that got the EV certificate.
The other fake domains goog1e.com and paypa1.com only have DV certificates by 
Let's Encrypt.

In the newer Firefox, both domains, the real one and the fake one both get a 
lock symbol. And I need to click the lock to see if it is DV or EV.

Do I understand that correctly?

And in regards to the comparison of Peter Bowen: If we assume that an 
improvement is that a fire sprinkler does react faster and more accurate, then 
why it is an improvement that old Firefox shows something, and the new Firefox 
does not show something? Is that an enhancement? No, it's removing something 
from the UI.



Am Montag, 12. August 2019 20:31:22 UTC+2 schrieb Wayne Thayer:
> 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  for
> phishing.
> 
> More recently, it has been shown  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
> .
> 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
>  (thanks :evilpie for
> working on it!). We're planning to flip this pref to false in bug 1572936
> .
> 
> Please let us know if you have any questions or concerns,
> 
> Wayne & Johann
___
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

2019-08-12 Thread Paul Wouters via dev-security-policy


> On Aug 12, 2019, at 14:30, Wayne Thayer via dev-security-policy 
>  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.

Relocate seems a wrong word here. You are basically removing it. A few geeks 
will be able to find it at the new location and I wonder why Firefox even 
bothered to leave it at the new location.

Paul

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