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

[Peter Bowen via dev-security-policy]

On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> A policy of switching from positive to negative indicators of security
> differences is no justification to switch to NO indication.  And it
> certainly doesn't help user understanding of any indicator to
> arbitrarily change it with 3 days of no meaningful discussion.
>
> The only thing that was insecure with Firefox EV has been that the
> original EV indicator only displayed the O= and C= field without enough
> context (ST, L).  The change fixes nothing, but instead removes the direct
> indication of
> the validation strength (low-effort DV vs. EV) AND removes the one piece
> of essential context that was previously there (country).
>
> If something should be done, it would be to merge the requirements for
> EV and OV with an appropriate transition period to cause the distinction
> to disappear (so at least 2 years from new issuance policy).  UI
> indication should continue to distinguish between properly validated OV
> and the mere "enable encryption with no real checks" DV certificates.
>

I have to admit that I'm a little confused by this whole discussion.  While
I've been involved with PKI for a while, I've never been clear on the
problem(s) that need to be solved that drove the browser UIs and creation
of EV certificates.

On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before and
after.  For example, "It used to take 10 minutes for the fire sprinklers to
activate after sensing excessive heat in our building.  With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long before
it spreads."

If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view chains,
etc), what user experience problem would you be solving by adding
information about certificates to the UI?

Thanks,
Peter

(speaking only for myself, not my employer)
___
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

[Jakob Bohm via dev-security-policy]

On 14/08/2019 18:18, Peter Bowen wrote:

On Tue, Aug 13, 2019 at 4:24 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


A policy of switching from positive to negative indicators of security
differences is no justification to switch to NO indication.  And it
certainly doesn't help user understanding of any indicator to
arbitrarily change it with 3 days of no meaningful discussion.

The only thing that was insecure with Firefox EV has been that the
original EV indicator only displayed the O= and C= field without enough
context (ST, L).  The change fixes nothing, but instead removes the direct
indication of
the validation strength (low-effort DV vs. EV) AND removes the one piece
of essential context that was previously there (country).

If something should be done, it would be to merge the requirements for
EV and OV with an appropriate transition period to cause the distinction
to disappear (so at least 2 years from new issuance policy).  UI
indication should continue to distinguish between properly validated OV
and the mere "enable encryption with no real checks" DV certificates.



I have to admit that I'm a little confused by this whole discussion.  While
I've been involved with PKI for a while, I've never been clear on the
problem(s) that need to be solved that drove the browser UIs and creation
of EV certificates.


EV was originally an initiative to make the CAs properly vet OV
certificates, and to mark those CAs that had done a proper job.
EV issuing CAs were permitted to still sell the sloppily validated
OV certs to compete against the CAs that hadn't yet cleaned up their
act.

This was before the BRs took effect, meaning that the bar for issuing OV
certs was very low.

To heavihandidly pressure the bad CAs to get in line, Firefox 
simultaneously started to display exaggerated and untruthful warnings 
for OV certificates, essentially telling users they were merely DV 
certificates.


So the intended long term benefit would be that less reliable CAs would
exit the market, making the certificate information displayed more
reliable for users.

The intended short term benefit would be to prevent users from believing
unvalidated certificate information from CAs that didn't check things 
properly.


As BRs and audits for OV certs have been ramped up, the difference 
between OV and EV has become less significant, while the difference 
between DV and OV has massively increased.


Thus blurring the line between OV and EV could now be justified, but 
blurring the line between DV and EV can not.






On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before and
after.  For example, "It used to take 10 minutes for the fire sprinklers to
activate after sensing excessive heat in our building.  With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long before
it spreads."



It used to be easy for fraudsters to get an OV certificate with untrue 
company information from smaller CAs.  By only displaying company 
information for more strictly checked EV certificates, it now becomes 
much more difficult for fraudsters to pretend to be someone else, making 
fewer users fall for such scams.


Displaying an overly truncated form of the company information, combined 
with genuine high-trust companies (banks, credit card companies) often 
using obscure subsidiary names instead of their user trusted company 
names for their EV certs has greatly reduced this benefit.





If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view chains,
etc), what user experience problem would you be solving by adding
information about certificates to the UI?


This hasn't been the case since before Mozilla was founded.

But lets assume we started from there, the benefit would be to tell
users when they were dealing with the company they know from the
physical world versus someone almost quite unlike them.

Making this visible with as few (maybe 0) extra user actions increases
the likelihood that users will spot the problem when there is one.



Enjoy

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

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

[Ryan Sleevi via dev-security-policy]

On Wed, Aug 14, 2019 at 1:16 PM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> EV was originally an initiative to make the CAs properly vet OV
> certificates, and to mark those CAs that had done a proper job.
> EV issuing CAs were permitted to still sell the sloppily validated
> OV certs to compete against the CAs that hadn't yet cleaned up their
> act.
>
> This was before the BRs took effect, meaning that the bar for issuing OV
> certs was very low.


> To heavihandidly pressure the bad CAs to get in line, Firefox
> simultaneously started to display exaggerated and untruthful warnings
> for OV certificates, essentially telling users they were merely DV
> certificates.
>
> So the intended long term benefit would be that less reliable CAs would
> exit the market, making the certificate information displayed more
> reliable for users.
>

This does not seem to be supported by the statements by Opera, Mozilla, the
KDE Foundation, and Microsoft at the time, so unfortunately, I must point
out that you are either mistaken or being dishonest, or both.

https://web.archive.org/web/20060316082248/http://www.opera.com/security/toronto/
https://dot.kde.org/2005/11/22/web-browser-developers-work-together-security
http://hecker.org/mozilla/ssl-ui
https://blogs.msdn.microsoft.com/ie/2005/11/21/better-website-identification-and-extended-validation-certificates-in-ie7-and-other-browsers/

Perhaps you'd like to correct the misstatements, having been pointed to
contemporaneous statements from people actually there and involved in the
decisions, which I can hope you were simply unaware of?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Peter Bowen via dev-security-policy]

On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote:

> On 14/08/2019 18:18, Peter Bowen wrote:
> > On thing I've found really useful in working on user experience is to
> > discuss things using problem & solution statements that show the before
> and
> > after.  For example, "It used to take 10 minutes for the fire sprinklers
> to
> > activate after sensing excessive heat in our building.  With the new
> > sprinkler heads we installed they will activate within 15 seconds of
> > detecting heat above 200ºC, which will enable fire suppression long
> before
> > it spreads."
> >
>
> It used to be easy for fraudsters to get an OV certificate with untrue
> company information from smaller CAs.  By only displaying company
> information for more strictly checked EV certificates, it now becomes
> much more difficult for fraudsters to pretend to be someone else, making
> fewer users fall for such scams.
>
> Displaying an overly truncated form of the company information, combined
> with genuine high-trust companies (banks, credit card companies) often
> using obscure subsidiary names instead of their user trusted company
> names for their EV certs has greatly reduced this benefit.
>
> > If we assume for a minute that Firefox had no certificate information
> > anywhere in the UI (no subject info, no issuer info, no way to view
> chains,
> > etc), what user experience problem would you be solving by adding
> > information about certificates to the UI?
>
> This hasn't been the case since before Mozilla was founded.
>
> But lets assume we started from there, the benefit would be to tell
> users when they were dealing with the company they know from the
> physical world versus someone almost quite unlike them.
>
> Making this visible with as few (maybe 0) extra user actions increases
> the likelihood that users will spot the problem when there is one.
>

What is the problem being solved?  You specify the benefit but I'm still
not clear why this info is needed in the first place.

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

Re: Use of Certificate/Public Key Pinning

[Ryan Sleevi via dev-security-policy]

On Tue, Aug 13, 2019 at 11:12 AM Nuno Ponte via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear m.d.s.p.,
>
> I would like to bring into discussion the use of certificate/public key
> pinning and the impacts on the 5-days period for certificate revocation
> according to BR §4.9.1.1.
>
> Recently, we (Multicert) had to rollout a general certificate replacement
> due to the serial number entropy issue. Some of the most troubled cases to
> replace the certificates were customers doing certificate pinning on mobile
> apps. Changing the certificate in these cases required configuration
> changes in the code base, rebuild app, QA testing, submission to App
> stores, call for expedited review of each App store, wait for review to be
> completed and only then the new app version is made available for
> installation by end users (which is turn are required to update the app the
> soonest).
>
> Meeting the 5-days deadline with this sort of process is “challenging”, at
> best.
>
> A first approach is to move from certificate pinning to public key pinning
> (PKP). This prevents the need to update the app in many of the certificate
> replacement operations, where the public key is reused and the certificate
> can be replaced transparently to the app (generically, an “User Agent”
> doing PKP).
>
> However, in the event of a serious security incident that requires re-key
> (such as key compromise), the certificate must be revoked in less than 24
> hours (for the benefit of everyone – subscriber, relying parties, issuing
> CA, etc). It’s virtually impossible to release a new app version within
> this timeframe. And this, I think, make a very strong point against the use
> of PKI.
>
> On the other side, PKP is a simple yet powerful and effective technique to
> protect against MITM and other attacks. It seems to be widely used in apps
> with advanced threat models (mobile banking, sensitive personal
> information, etc) and there are many frameworks available (including native
> support in Android via Network Security Configuration [1]).
>
> There are several possible mitigation actions, such as pinning more than
> one public key to have more than one certificate to quickly rollover in
> case of a revocation. Even then, it is very likely that all the redundant
> key pairs were generated and maintained by the same systems and procedures,
> and thus all of them will become effectively compromised.
>
> Ultimately, it may become common practice that 1) PKP frameworks are set
> to bypass revocation checks or 2) PKP is done with private certificates
> (homemade, self-signed, managed ad-hoc with no CRL/OCSP services). Does any
> of this leads to a safer Internet?
>
> I don’t expect this thread to end up into an absolute conclusion
> advocating for or against, but opening it to discussion and contributions
> may help to document possible strategies, mitigations, alternatives, pros &
> cons, and hopefully provide guidance for an educated decision.
>
> Best regards,
>
> Nuno Ponte
> Multicert SA
>

Nuno,

Thanks for raising this. I appreciate that a CA is attempting to provide
guidance to their Subscribers, since, as you note, the CA is still beholden
to the Baseline Requirements, and the Subscriber still beholden to their
Subscriber Agreement.

As one of the co-authors of the HTTP Public Key Pinning RFC, RFC 7469, I
would readily encourage your Subscribers not to pin at all. However, if
they are going to pin to anything, then it:
1) Should be to the public key, not certificate
2) Should only be to the root
3) Should require an agreement with the root that the Root (i.e. Multicert)
will disclose all possible certificate paths and root certificates that are
unexpired and may exist.
  - This includes cross-signed certificates

Note that mobile devices, the scenario you discuss for pinning, already
largely do not implement revocation checks and do not offer a way for
applications to control it, so I don't think that should be a concern.

Of course, many of these techniques predate improvements to the ecosystem,
such as CAA and Certificate Transparency. Many of the concerns that
motivated HPKP, which subsequently evolved into the aforementioned OS APIs,
were predicated on an assumption of a CA that has lax validation methods.
Yet techniques such as CAA exist to give site operators meaningful control
- and to ensure that any CA that violates such checks, and ignores CAA, is
unambiguously at risk of being distrusted by the entire platform.

If there's concern about the DNS registrar being hacked, the Subscriber has
the option of choosing a better registrar before hand, without resorting to
PKP, and/or transitioning to registries with better security practices
overall. In general, this means avoiding ccTLDs, which are known lax due to
their lack of any formal IANA or ICANN agreements with respect to
operations. Certificate Transparency offers a compliment to this, ensuring
that even if the Registrar or Registry is

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

[Peter Gutmann via dev-security-policy]

Peter Bowen via dev-security-policy  
writes:

>I have to admit that I'm a little confused by this whole discussion.  While
>I've been involved with PKI for a while, I've never been clear on the
>problem(s) that need to be solved that drove the browser UIs and creation of
>EV certificates.

Oh, that's easy:

  A few years ago certificates still cost several hundred dollars, but now
  that the shifting baseline of certificate prices and quality has moved to
  the point where you can get them for $9.95 (or even for nothing at all) the
  big commercial CAs have had to reinvent themselves by defining a new
  standard and convincing the market to go back to the prices paid in the good
  old days.

  This déjà-vu-all-over-again approach can be seen by examining Verisign’s
  certificate practice statement (CPS), the document that governs its
  certificate issuance.  The security requirements in the EV-certificate 2008
  CPS are (except for minor differences in the legalese used to express them)
  practically identical to the requirements for Class 3 certificates listed in
  Verisign’s version 1.0 CPS from 1996 [ ].  EV certificates simply roll back
  the clock to the approach that had already failed the first time it was
  tried in 1996, resetting the shifting baseline and charging 1996 prices as a
  side-effect.  There have even been proposals for a kind of sliding-window
  approach to certificate value in which, as the inevitable race to the bottom
  cheapens the effective value of established classes of certificates, they’re
  regarded as less and less effective by the software that uses them (for
  example browsers would no longer display a padlock for them), and the
  sliding window advances to the next generation of certificates until
  eventually the cycle repeats.

That was written about a decade ago.  As recent events have shown, it was
remarkably accurate.  The sliding window has just slid.

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

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

[Jakob Bohm via dev-security-policy]

On 14/08/2019 21:55, Peter Bowen wrote:

On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote:


On 14/08/2019 18:18, Peter Bowen wrote:

On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before

and

after.  For example, "It used to take 10 minutes for the fire sprinklers

to

activate after sensing excessive heat in our building.  With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long

before

it spreads."



It used to be easy for fraudsters to get an OV certificate with untrue
company information from smaller CAs.  By only displaying company
information for more strictly checked EV certificates, it now becomes
much more difficult for fraudsters to pretend to be someone else, making
fewer users fall for such scams.

Displaying an overly truncated form of the company information, combined
with genuine high-trust companies (banks, credit card companies) often
using obscure subsidiary names instead of their user trusted company
names for their EV certs has greatly reduced this benefit.


If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view

chains,

etc), what user experience problem would you be solving by adding
information about certificates to the UI?


This hasn't been the case since before Mozilla was founded.

But lets assume we started from there, the benefit would be to tell
users when they were dealing with the company they know from the
physical world versus someone almost quite unlike them.

Making this visible with as few (maybe 0) extra user actions increases
the likelihood that users will spot the problem when there is one.



What is the problem being solved?  You specify the benefit but I'm still
not clear why this info is needed in the first place.



Problem example: User wants to visit the website of the well-known high
street bank whose massive sign on the outside wall and letterhead in
actual paper documents is "Example Bank of Lalaland".  User receives a
(fake) e-mail telling him to go to "example.net" (or just makes a
trivial typo) for their new online offerings, that mail is genuinely
from "notificati...@example.net", because the scammers actual registered
example.net (the real bank is example.com).  User opens
https://example.net in the latest browser and
is told by the UI that they are safely (padlock) connected to
example.net.  But not that this isn't the "Example Bank of Lalaland"
properly registered with "the companies registry of Lalaland" and
regulated by "the banking authority of Lalaland" and with an official
company address at "central square 2, capitalcity, Lalaland" (a well
known 19th century banking building currently containing the mahogany
board room and a regular branch office).

With EV as currently implemented they (don't if the wrong domain) get a
green color indicating this certificate was issued to someone with a
proven ID, the name actually verified by the national corporate registry
(responsible for uniqueness) and the Lalaland country code.  All with
near 0 user effort.

With the proposed UI change they get nothing (just a default padlock)
and with a bit of effort that this certificate was EV validated for
"Example Bank Ltd" (but not if this is "Example Bank of Lalaland" or
"Example Bank of Enemy Country Full of Phishers").  Users have to dig
into technical dialogs to see that this EV certificate may have the
wrong "JurisdictionOfIncorporation" value.  And there's nothing that
Example Bank of Lalaland or even the government of Lalaland can do to
stop this or even prosecute the phishers, because there is no legal
cooperation with that enemy country.


See also the original summary from 2007 by Gerv:
 https://blog.gerv.net/2007/06/spot_the_dog/




Enjoy

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

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

[Peter Gutmann via dev-security-policy]

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

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

[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