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

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

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

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

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

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

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

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


Re: 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-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-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: Fwd: Intent to Ship: Move Extended Validation Information out of the URL bar

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

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

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

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

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


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

2019-08-16 Thread Leo Grove via dev-security-policy
I don't know about other CAs, but at SSL.com we issue a very limited number of 
EV SSL certificates in comparison to other certificates so it's not a big 
revenue driver.

However, as a user I support EV SSL. I personally have never come across a scam 
site that displayed an EV SSL (I'm not saying they don't exist). Has anyone 
else come across a "scam site" displaying EV that's not part of an academic 
exercise?

An EV SSL only connects the site domain to its registered owner, nothing more. 
After that, I can decide whether to trust that company or if more research is 
warranted. At the end of the day, the user must make a decision based on the 
information they are given. This includes reviewing the EV SSL, domain name, 
site contents and third party reviews and listings. With the removal of EV from 
the browser UI, that's one less signal users can rely on. 

For instance, my inbox receives increasingly sophisticated spam and phishing 
mailers that require me to do double and triple takes. This results in 
legitimate emails potentially being flagged as spam. One of the signals I use 
to verify linked sites within the emails is if they display EV certificates. I 
do not entirely rely on EV, but it helps to build a subconscious trust profile 
of that site along with the domain, content, site reviews and search listings. 
As a result, I've determined on a number of occasions that the emails were 
indeed authentic in part because of the EV. In this business, paranoia is 
survival.

Recently a neighbor asked me to verify a shoe site that he just purchased 
loafers from. Several red flags (ie Chanel header banner, unfamiliar domain 
name, etc) and no EV SSL prompted me to recommend he dispute the charge. Weeks 
later he confirmed it was indeed a scam site. Had the site displayed an EV SSL, 
I would have investigated more knowing the extra effort required to pass EV 
validation. But since no EV SSL appeared on the site, I didn't feel the need to 
waste any more time on the site.

I can't be the only person whose aunt, neighbor or spouse asks me to help 
verify a site. This tells me that they do not understand how to properly read 
the EV information, not that EV SSL is bad or ineffective.

I'm confounded why anyone would want less independently verified information on 
a site as opposed to more for fear EV doesn't perfectly suit their 
expectations. Well-known sites like google.com and amazon.com might not need EV 
as much as less well-known sites, but there are only a small number of these 
well-known sites. 

In comparison, the vast majority of sites are lesser-known and could benefit 
from as many validation signals as possible. I would think a local hospital or 
credit union who are increasingly targeted by phishing scams might argue an EV 
certificate would be one of the tools to help combat these types of scams. 

No single solution is perfect to eliminate online scams including EV SSL, but 
by removing the EV UI, the proverbial baby bath water comes to mind. I think 
the original intent of EV was and still remains noble. We should try to improve 
upon it, not discard it or relegate it to a virtually useless state. 

Scammers are a wily bunch, and they will always find some success in gaming or 
circumventing any system where human trust is involved. Let's try to make if 
harder for them, not throw our hands in the air and give up. At a minimum, 
consider keeping a color coded lock that would not take up any additional 
browser real estate and would give users "in the know" the EV signal. 

Otherwise, if the browsers have finalized their collective decisions on the 
matter, I do hope something better comes along that will benefit everyone. 
Treating all SSL/TLS certs as DV I think is a step backwards to 2007 when there 
was no EV, but we all knew something more than DV or OV was needed.

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


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

2019-08-16 Thread Leo Grove via dev-security-policy
> 
> See also the screenshot I posted earlier.  That was from a black-market web
> site selling EV certificates to anyone with the stolen credit cards to pay for
> them.  These are legit EV certs issued to legit companies, available off the
> shelf for criminals to use.  For a little extra payment you can get ones with
> high SmartShield scores so your malware is instantly trusted by the victim's
> PC.
> 

Peter,

Are you referring to EV Code Signing certificates? I agree that needs to be 
addressed in another forum, but this discussion in on EV SSL/TLS and their 
value (or lack thereof) in the browser UI. Browsers do not support EV Code 
Signing in the UI as far as I know. 

It's been documented that EV Code Signing certificates are on the black market. 
Did you see the same thing for EV SSL/TLS? 

Leo

> >The burden is not on the web browsers to prove that EV is detrimental to
> >security - the burden is on third parties to prove that EV is beneficial.
> 
> Yup, as per my previous post.  We've got a vast amounts of data on this, if
> there was a benefit to users then it shouldn't be hard to show that from the
> data.
> 
> Peter.

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


Re: DNS fragmentation attack subverts DV, 5 public CAs vulnerable

2018-12-11 Thread Leo Grove via dev-security-policy
On Tuesday, December 11, 2018 at 11:27:52 AM UTC-6, Hector Martin 'marcan' 
wrote:
> On 12/12/2018 01.47, Ryan Sleevi via dev-security-policy wrote:
> > Is this new from the past discussion?
> 
> I think what's new is someone actually tried this, and found 5 CAs that
> are vulnerable and for which this attack works in practice.
> 
> > https://groups.google.com/d/msg/mozilla.dev.security.policy/KvQc102ZTPw/iLQLKfbbAwAJ
> 
> Looking back, this attack is also documented in the paper linked in that
> thread, but unfortunately it's not open access. I get the feeling this
> may be why that discussion didn't really proceed further in that thread.
> I certainly missed it.
> 
> The paper does list the vulnerable CAs, which are:
> 
> > • COMODO, InstantSSL, NetworkSolutions, SSL.com: these CAs
> > use the same MX email server mcmail1.mcr.colo.comodo.net
> > which uses the same caching DNS resolver. The results from our
> > cache overwriting methods indicates that the DNS resolver software
> > is New BIND 9.x with DNSSEC-validation.

I want to clarify that the only DNS mappings to Comodo from SSL.com are crl and 
crt CNAMEs for UserTrust issued SSL.com SubCAs operated and maintained wholly 
by Sectigo. 

The SSL.com Root CA, which is operated and maintained by SSL.com, does not have 
any dependency on the Comodo/Sectigo DNS and therefore should not be listed as 
one of the vulnerable CAs.

Regards,

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


Re: Francisco Partners acquires Comodo certificate authority business

2017-11-01 Thread Leo Grove via dev-security-policy
On Wednesday, November 1, 2017 at 2:23:07 PM UTC-5, westm...@gmail.com wrote:
> Hello,
> 
> Why you're removed the post of Peter Gutmann (Nov. 1, 2017, 4:08)?
> 
> If I understand correctly, at the time of the public discussion for new root 
> certificates SSL.com (RA Comodo) Mozilla concealed information about the 
> acquisition of SSL business of Comodo and that now the past public discussion 
> about new root certificates SSL.com can be considered incorrect on this 
> moment of time.
> 
> Regards,
> Andrew.

Andrew,

I'm not sure where you got your information, but SSL.com is a completely 
separate company from Comodo. We are based in Houston, Texas.

Although we have a reseller agreement with Comodo, which is quite common among 
CAs in the industry, we are not an RA of Comodo as we cannot do our own 
validation on certificates chained to Comodo's Root certificates.

Regards,

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