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

2019-08-15 Thread Eric Rescorla via dev-security-policy
On Thu, Aug 15, 2019 at 2:46 PM Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Peter,
>
> Do you have any empirical data to backup the claims that there is no
> benefit
> from EV certificates?  From the reports I've seen, the percentage of
> phishing and malware sites that use EV is drastically lower than DV (which
> are used to protect the cesspool of websites).
>

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.

-Ekr

Doug
>
>
>
> -Original Message-
> From: dev-security-policy 
> On
> Behalf Of Peter Gutmann via dev-security-policy
> Sent: Wednesday, August 14, 2019 9:04 PM
> To: mozilla-dev-security-pol...@lists.mozilla.org; Jakob Bohm
> 
> Subject: Re: Fwd: Intent to Ship: Move Extended Validation Information out
> of the URL bar
>
> Jakob Bohm via dev-security-policy 
> writes:
>
> >Problem example:
> >[...]
>
> You're explaining how it's supposed to work in theory, not in the real
> world.
>
> We have a decade of real-world data showing that it doesn't work, that
> there's no benefit from EV certificates apart from the one to CA's balance
> sheets.  So the browser vendors are doing the logical thing, responding to
> the real-world data and no longer pretending that EV certs add any security
> value, both in terms of protecting users and of keeping out the bad guys -
> see the attached screen clip, in this case for EV code-signing certs for
> malware, but you can buy web site EV certs just as readily.
>
> Peter.
> ___
> 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: FF52 beta send SSL record layer with min=1 and max=3or4

2017-02-21 Thread Eric Rescorla via dev-security-policy
This was filed as:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341375

For those following at home:

1. This is conformant behavior, though apparently it makes some servers sad.
2. I can't repro it in FF 52, so I'm going to need more detail to work on it

-Ekr



On Tue, Feb 21, 2017 at 8:10 AM, Richard Barnes via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi Phil,
>
> Sorry to redirect again, but this mailing list probably isn't the right
> place either (it's mainly about certificates, not TLS).  The best thing to
> do is probably to file a bug on this.  That will get the attention of the
> folks who can diagnose and fix this issue.
>
> https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS=Libraries
>
> Thanks,
> --Richard
>
> On Tue, Feb 21, 2017 at 7:04 AM, Phil Raptor via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hello Experts,
> > We have a server that supports TLS1.0/1.1/1.2 and restricts SSL. FF 52
> > beta's tls config is min=1 and max=4 by default. Upon trying to access
> our
> > server with FF 52, we are getting the below error -
> >
> > Secure Connection Failed
> >
> > The connection to xx.xx.xx.xx was interrupted while the page was loading.
> >
> > The page you are trying to view cannot be shown because the
> > authenticity of the received data could not be verified.
> > Please contact the website owners to inform them of this problem.
> >
> > Packet captures show Client Hello to be carrying SSL record layer instead
> > of TLS record layer. This happens if the max value is set as 3 or 4. For
> > other values, Client Hello is properly sent.
> > With FF 51.0.1, everything worked just fine.
> >
> > So, we would like to know-
> > Why is FF 52 sending SSL record layer when it is configured to send TLS
> > record layer?
> > As this is beta version, would you recommend using this version and the
> > final version will have a proper implementation?
> >
> > I have also raised a case in the common Mozilla forum and was advised to
> > touch base here - https://support.mozilla.org/t5/Firefox/How-does-FF-
> > determine-what-SSL-protocol-to-use-in-Client-Hello/m-p/
> > 1365371/highlight/false#M1034432
> >
> > Kindly advise!
> > ___
> > 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