"Cert spam", or certs with huge numbers of hosts.

[John Nagle]

Examine the cert of "https://www.sevendays.co".

Here's one of those certs with a huge number of unrelated hosts.
This seems to be a Cloudflare legacy setup from the pre-TLS era.
Unfortunately, this cert became valid on 10/09/2014. It's
not a legacy cert.

Should certs like this be rejected as misrepresenting the identity of
the organization? Junk certs like this let any domain in the cert
impersonate any other domain, so they are a form of "wildcard" cert.
Now that all major browsers have TLS, they are unnecessary and can
be phased out, correct?

Firefox displays "You are connected to sevendays.co. Verified
by GlobalSign NV-SA" for this site. That misrepresents what the
cert really told Firefox. The message should read "You are
connected to one of the following sites, and give the list.
Or perhaps "You are connected to ssl2910.cloudflare.com" which
appears to be authorized to host sevendays.co". That would
assist in accelerating the phaseout of these old certs.

There's a real risk here. A break-in at any of those sites
allows impersonating all of them. This creates a huge
attack surface.

John Nagle
SiteTruth

Domain www.sevendays.co

Server identity

countryName=US
stateOrProvinceName=CA
localityName=San Francisco
organizationName=CloudFlare, Inc.
commonName=ssl2910.cloudflare.com


Hosts allowed by certificate

ssl2910.cloudflare.com
ssl2910.cloudflare.com
*.kitchensurfing.com
*.kontrekulture.com
guardian.co.tt
storio.com
zcloud.ws
lazycoins.com
mywvbar.org
*.francescomugnai.com
*.versatrussplus.com
neurotoxininstitute.com
*.mywvbar.org
*.fitfashion.fi
*.prenonslemaquis.fr
*.neurotoxininstitute.com
cresters.com
*.zcloud.ws
*.skinnymom.com
anchoragemovies.com
*.anchoragemovies.com
skinnymom.com
*.cresters.com
francescomugnai.com
kitchensurfing.com
sevendays.co
*.sevendays.co
kontrekulture.com
*.guardian.co.tt
fitfashion.fi
prenonslemaquis.fr
*.storio.com
*.bikeindex.org
*.lazycoins.com
versatrussplus.com
bikeindex.org

[Matt Palmer]

On Thu, Oct 23, 2014 at 01:08:25PM -0700, John Nagle wrote:
> Examine the cert of "https://www.sevendays.co".
>
> Here's one of those certs with a huge number of unrelated hosts.
> This seems to be a Cloudflare legacy setup from the pre-TLS era.
> Unfortunately, this cert became valid on 10/09/2014. It's
> not a legacy cert.
>
> Should certs like this be rejected as misrepresenting the identity
> of the organization? Junk certs like this let any domain in the
> cert
> impersonate any other domain, so they are a form of "wildcard" cert.
> Now that all major browsers have TLS, they are unnecessary and can
> be phased out, correct?

I assume you mean s/TLS/SNI/?

Unfortunately, despite the fact that SNI-supporting browsers are widely
available, old, unsupported (and unpatched) Android, and old, unsupported
(and unpatched) IE-on-XP is still disconcertingly widely used. Hence,
you'll get massive push-back from hosting providers like Cloudflare, because
they'll be getting push-back from *their* customers about dropping support
for that subset of their customer base.

Now, personally, I say we[1]'d be doing the world a favour if we[1] actively
discouraged the use of these known-pwnable systems. Unfortunately, as
long as the people using those same known-pwnable systems give us some
portion of our daily bread (via the companies which employ us), it's
unlikely we'll be allowed to do that at any scale.

For all that, I'd call Cloudflare one of the good guys in all this. I
believe they're working to deploy (or have already deployed) code code that
delivers SHA-1 certs only to those user agents that can't handle SHA-2.
Extending that sort of differentiated response to deliver one of these ugly
mega-certs only to UAs that don't supply an SNI wouldn't be hard, either, if
you could convince Cloudflare that it'd be a net win (and I'd guess they'd
be one of the more open-to-it organizations out there -- they appear to be
Good People Working For The Good Of The Internet).

- Matt

[1] For values of "we" that equal "the people who run things that use TLS".

--
The hypothalamus is one of the most important parts of the brain, involved
in many kinds of motivation, among other functions. The hypothalamus
controls the "Four F's": 1. fighting; 2. fleeing; 3. feeding; and 4. mating.
-- Psychology professor in neuropsychology intro course

[Ryan Sleevi]

On Thu, October 23, 2014 1:08 pm, John Nagle wrote:
> Examine the cert of "https://www.sevendays.co".
>
> Here's one of those certs with a huge number of unrelated hosts.
> This seems to be a Cloudflare legacy setup from the pre-TLS era.
> Unfortunately, this cert became valid on 10/09/2014. It's
> not a legacy cert.

So? It's perfectly valid and conforming with all of the policies set out
by Mozilla and the CA/Browser Forum.

>
> Should certs like this be rejected as misrepresenting the identity of
> the organization? Junk certs like this let any domain in the cert
> impersonate any other domain, so they are a form of "wildcard" cert.
> Now that all major browsers have TLS, they are unnecessary and can
> be phased out, correct?

So what?

1) It's not misrepresenting the organization. BR certs do not, have not,
and have never been a means of asserting the organization. Thinking that
TLS certs do that is a fabrication that some CAs promulgate, but has
nothing to do with the purpose of TLS certificates (which assert a binding
between a *domain* and a key)

2) Calling them junk certs implies you think there's something wrong with
them, but you'd need to spell that out. Nothing is wrong with them by any
of the root store policies.

3) Wildcard certs are both valid and useful. They are expressly permitted
in the BRs.

>
> Firefox displays "You are connected to sevendays.co. Verified
> by GlobalSign NV-SA" for this site. That misrepresents what the
> cert really told Firefox.

No it doesn't. You connected to the IP address returned by dns for
sevendays.co, and received a cert certified by GlobalSign NV-SA that
asserts that an entity with operational control over sevendays.co has
control over a private key presented in the certificate and the TLS chain.

This is all truthful and accurate information.

> The message should read "You are
> connected to one of the following sites, and give the list.
> Or perhaps "You are connected to ssl2910.cloudflare.com" which
> appears to be authorized to host sevendays.co". That would
> assist in accelerating the phaseout of these old certs.

Accelerating the phaseout of these certs is a non-goal with no positive
security value.

>
> There's a real risk here. A break-in at any of those sites
> allows impersonating all of them. This creates a huge
> attack surface.

This doesn't change at all if they're using separate certs, if the certs
are still hosted by the same company on the same machine.

I'm sorry, but I believe you've been confused as to what the purpose is,
but there's nothing wrong with these certs.

[Richard Barnes]

> On Oct 23, 2014, at 4:51 PM, Ryan Sleevi <ryan-mozde...@sleevi.com> wrote:
>
> On Thu, October 23, 2014 1:08 pm, John Nagle wrote:
>> Examine the cert of "https://www.sevendays.co".
>>
>> Here's one of those certs with a huge number of unrelated hosts.
>> This seems to be a Cloudflare legacy setup from the pre-TLS era.
>> Unfortunately, this cert became valid on 10/09/2014. It's
>> not a legacy cert.
>
> So? It's perfectly valid and conforming with all of the policies set out
> by Mozilla and the CA/Browser Forum.

And I suspect it is related to this:
http://blog.cloudflare.com/introducing-universal-ssl/

>> Should certs like this be rejected as misrepresenting the identity of
>> the organization? Junk certs like this let any domain in the cert
>> impersonate any other domain, so they are a form of "wildcard" cert.
>> Now that all major browsers have TLS, they are unnecessary and can
>> be phased out, correct?
>
> So what?
>
> 1) It's not misrepresenting the organization. BR certs do not, have not,
> and have never been a means of asserting the organization. Thinking that
> TLS certs do that is a fabrication that some CAs promulgate, but has
> nothing to do with the purpose of TLS certificates (which assert a binding
> between a *domain* and a key)
>
> 2) Calling them junk certs implies you think there's something wrong with
> them, but you'd need to spell that out. Nothing is wrong with them by any
> of the root store policies.
>
> 3) Wildcard certs are both valid and useful. They are expressly permitted
> in the BRs.

And notably, multi-SAN certs are not wild-card certs; they are far more limited. A wildcard can be used for an indefinite number of names, none of which are individually validated. A multi-SAN cert has a prescribed list of domains, each of which must be individually validated according to the BRs.

--Richard

>>
>> Firefox displays "You are connected to sevendays.co. Verified
>> by GlobalSign NV-SA" for this site. That misrepresents what the
>> cert really told Firefox.
>
> No it doesn't. You connected to the IP address returned by dns for
> sevendays.co, and received a cert certified by GlobalSign NV-SA that
> asserts that an entity with operational control over sevendays.co has
> control over a private key presented in the certificate and the TLS chain.
>
> This is all truthful and accurate information.
>
>> The message should read "You are
>> connected to one of the following sites, and give the list.
>> Or perhaps "You are connected to ssl2910.cloudflare.com" which
>> appears to be authorized to host sevendays.co". That would
>> assist in accelerating the phaseout of these old certs.
>
> Accelerating the phaseout of these certs is a non-goal with no positive
> security value.
>
>>
>> There's a real risk here. A break-in at any of those sites
>> allows impersonating all of them. This creates a huge
>> attack surface.
>
> This doesn't change at all if they're using separate certs, if the certs
> are still hosted by the same company on the same machine.
>
> I'm sorry, but I believe you've been confused as to what the purpose is,
> but there's nothing wrong with these certs.
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

[John Nagle]

On 10/23/2014 02:00 PM, Richard Barnes wrote:
illa and the CA/Browser Forum.
>
> And I suspect it is related to this:
> http://blog.cloudflare.com/introducing-universal-ssl/

You're probably right. What Cloudflare provides by default is
"Flexible SSL", in which Cloudflare acts as a MITM:
"For a site that did not have SSL before, we will default to our
Flexible SSL mode, which means traffic from browsers to CloudFlare will
be encrypted, but traffic from CloudFlare to a site's origin server will
not."

It's a form of security theater. Just enough to turn on the lock
icon.

For policy, here are the current CA/Browser Forum baseline
requirements.

https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf

The cert being discussed here has an Organization
field (O) of "Cloudflare, Inc." Per section 9.2.4(a),
"If present, the subject:organizationName field MUST contain either the
Subject’s name or DBA as verified under Section 11.2".

The issue here is that the cert contains domain names who
are not the Subject of the certificate.

There's no reason to do this any more. We have TLS now.

John Nagle
SiteTruth

[Matt Palmer]

On Thu, Oct 23, 2014 at 02:30:59PM -0700, John Nagle wrote:
> On 10/23/2014 02:00 PM, Richard Barnes wrote:
> You're probably right. What Cloudflare provides by default is
> "Flexible SSL", in which Cloudflare acts as a MITM:

Cloudflare acts as a MITM for *all* SSL modes -- because it needs to see the
content to work its mojo. Even with keyless SSL, Cloudflare's still seeing
the content in the clear. I'm wondering how any bank or other institution
dealing with financial data would consider that OK, but I'm not in that
business...

/me shoves the bundles of bills further under the mattress

> It's a form of security theater. Just enough to turn on the lock
> icon.

Hey, it means the NSA has to watch less wires, right? Just watch the
traffic coming out of Cloudflare's facilities to the origin servers!

> For policy, here are the current CA/Browser Forum baseline
> requirements.
>
> https://cabforum.org/wp-content/uploads/BRv1.2.3.pdf
>
> The cert being discussed here has an Organization
> field (O) of "Cloudflare, Inc." Per section 9.2.4(a),
> "If present, the subject:organizationName field MUST contain either
> the Subject’s name or DBA as verified under Section 11.2".
>
> The issue here is that the cert contains domain names who
> are not the Subject of the certificate.

That's not what the BRs are requiring, though. The O field must list the
organization to whom the certificate was issued (and, presumably, that must
be the organization which is operating the endpoint to which the TLS
connection is established, although that's not as clear-cut). The BRs
*don't* require that the serverAltNames listed in the certificate are owned
by the organization listed in the certificate.

> There's no reason to do this any more. We have TLS now.

Again, s/TLS/SNI/?

- Matt

--
I seem to have my life in reverse. When I was a wee'un, it seemed perfectly
normal that one could pick up the phone and speak to anybody else in the
world who also has a phone. Now I'm older and more experienced, I'm amazed
that this could possibly work. -- Peter Corlett, in the Monastery

[Peter Gutmann]

John Nagle <na...@sitetruth.com> writes:

>There's a real risk here. A break-in at any of those sites allows
>impersonating all of them. This creates a huge attack surface.

It's actually a lot worse than that, see "Virtual Host Confusion: Weaknesses
and Exploits" by Antoine Delignat-Lavaud and Karthikeyan Bhargavan from this
year's Black Hat.

Peter.

[Hubert Kario]

On Thursday 23 October 2014 14:30:59 John Nagle wrote:
> On 10/23/2014 02:00 PM, Richard Barnes wrote:

> illa and the CA/Browser Forum.
>
> > And I suspect it is related to this:
> > http://blog.cloudflare.com/introducing-universal-ssl/
>

> You're probably right. What Cloudflare provides by default is
> "Flexible SSL", in which Cloudflare acts as a MITM:

> "For a site that did not have SSL before, we will default to our
> Flexible SSL mode, which means traffic from browsers to CloudFlare will
> be encrypted, but traffic from CloudFlare to a site's origin server will
> not."
>

> It's a form of security theater. Just enough to turn on the lock
> icon.

To use Cloudflare you need to transfer the domain to Cloudflare. So it's
hardly a MITM. It's a forward proxy service.

And while it doesn't tell you if the servers themselves are securely
configured, it does help against skriptkiddies riding on your local coffee
shop wifi.
--
Regards,
Hubert Kario

[John Nagle]

On 10/24/2014 06:14 AM, Hubert Kario wrote:
> On Thursday 23 October 2014 14:30:59 John Nagle wrote:
>
> To use Cloudflare you need to transfer the domain to Cloudflare. So it's
> hardly a MITM. It's a forward proxy service.

Not quite. You have to aim the DNS at Cloudflare, not transfer the
ownership or control of the domain to them.

In this situation, Firefox should display the (O) field,
indicating that you're connected to Cloudflare. At least tell the
user they're being MITMed.

This isn't a theoretical problem. There's an attack:

https://bh.ht.vc/vhost_confusion.pdf

I'm trying to get data from one of the cert observatories to
see how prevalent this problem is. It's a big deal for those of
us who are trying to figure out who's really behind the web site.

John Nagle
SiteTruth

[fhw...@gmail.com]

‎The other way to have a MITM situation is if the CloudFlare network becomes compromised. The amount of damage a hacker can inflict is significantly greater now because of both the Universal SSL and Keyless SSL offerings.

‎To your issue, John, are you requesting a change to the Firefox UI or is there another concern? I agree that it is probably necessary to show the O field because of situations like this and others where "I want you to trust me but I won't tell you who I am". Showing just the domain name isn't enough. For the example you mentioned (sevendays-dot-co) the whois lists a privacy service in Panama, so who exactly are they?!?



  Original Message  
From: John Nagle
Sent: Friday, October 24, 2014 12:29 PM
To: dev-secur...@lists.mozilla.org
Reply To: na...@sitetruth.com
Subject: Re: "Cert spam", or certs with huge numbers of hosts.

[John Nagle]

Here's a nice example of Mozilla not fully understanding Organization
information in certificates: "www.facebook.com".

Firefox says, for "https://www.facebook.com",

"This web site does not supply ownership information".

But, in fact, not only does it supply ownership information
(the Subject contains O, L, ST, and C), DigiCert, which generated
the certificate, promises in their CPS that the info is valid. DigiCert
attached Policy OID 2.16.840.1.114412.1.1, promising
valid organization data.

Remember, there are three levels of certs now: DV, OV, and EV.
The CA/Browser Forum has established (finally) standard policy
OIDs for them, but these are still optional. They are

OID 2.23.140.1.2.1 - DV (domain validated only)
OID 2.23.140.1.2.2 - OV (organization validated)
OID 2.23.140.1.1 - EV (extended validation)

These standard Policy OIDs are relatively new, though, and not
widely used yet.

Originally, each CA had its very own EV Policy OID.
(There's a list in Wikipedia, painfully put together.)

Without much notice, the same thing was done for
OV certs. DigiCert's Certification Practice Statement
(https://www.digicert.com/docs/cps/DigiCert_CP_v406-May-14-2014.pdf)
lists the values DigiCert uses.

OID 2.16.840.1.114412.1.2 - DV (Domain‐Validated SSL)
OID 2.16.840.1.114412.1.1 - OV (Organizationally‐Validated SSL)
OID 2.16.840.1.11441 - EV (Extended Validation SSL Certificates)

These are in wide use; I'm finding lots of them in the certificate
dumps. (Does anyone have the full list? Is there any reason not
to make it public? The info is in the Certification Practice
Statements of each CA.)

Firefox understands the EV values for each CA, but not, apparently,
the OV values. That, I think, is a bug. One which affects
high-profile sites.

John Nagle
SiteTruth

[John Nagle]

(Resend, after error "The message could not be delivered to the
following recipient:")

[Ryan Sleevi]

> OID 2.16.840.1.114412.1.2 - DV (Domain†Validated SSL)
> OID 2.16.840.1.114412.1.1 - OV (Organizationally†Validated SSL)

> OID 2.16.840.1.11441 - EV (Extended Validation SSL Certificates)
>
> These are in wide use; I'm finding lots of them in the certificate
> dumps. (Does anyone have the full list? Is there any reason not
> to make it public? The info is in the Certification Practice
> Statements of each CA.)
>
> Firefox understands the EV values for each CA, but not, apparently,
> the OV values. That, I think, is a bug. One which affects
> high-profile sites.
>
> John Nagle
> SiteTruth

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

John,

I'm sorry, but you're overstating the value of OV, which is not something
that any browser recognizes, nor is it, as you suggest, something
standardized by the CA/Browser Forum.

The CA/Browser Forum does state how the O field should contain, *IF*
present, along with several other *optional* fields, but these are neither
strong requirements nor are they mandatory in the same sense that EV is.

Mozilla's position on OV is well documented - the "bug" you described is
INVALID WONTFIX. You know this, because you've participated in past
discussions -
https://groups.google.com/d/msg/mozilla.dev.security.policy/al0GUnprZuI/3e28Iv08WdAJ
, but it's also been discussed at
https://groups.google.com/d/msg/mozilla.dev.security.policy/al0GUnprZuI/3e28Iv08WdAJ
,
https://groups.google.com/d/msg/mozilla.dev.security.policy/-mCAK5zfhFQ/hEOQK-ubGRcJ
. This was also affirmed again by Mozilla (and other browsers) during the
most recent China CA/Browser Forum F2F (unfortunately, the minutes have
not been posted yet, AFAICT).

I would say Mozilla understands very well what the organization
information is, how it's vetted, and why that information is not
meaningfully worthwhile to communicate to users as an effective security
measure. In a world where "EV" provides no positive technical security
benefits (due to the same origin policy), it would be a pretty nasty
mistake to think "OV" (which does not formally exist as a consistent
standard as it does either EV or DV) provides some actionable value.

I suspect that you will continue to have issue with certain policy
decisions, as it seems you are opposed to DV. That's unfortunate, because
DV is the single-largest driver for SSL/TLS, and rightfully so. That is, a
certificate exists as a binding between a key and a domain. Whether that
domain is operated by a CDN such as CloudFlare, a hosting service such as
AWS, Azure, or Appspot, a user with a shared server, a user with a VPS, or
a user with a dedicated server is irrelevant, and neither misleading nor
wrong for the browser to express a secure icon regardless.

Multi-san certs are perfectly compliant with the BRs, as are wildcard
certs, and both are extremely important to encouraging the adoption of
TLS.

If you're trusting certificates to assert information about either the
identity of the entity behind the key or that the CA has done due
diligence, well, you're using certificates for something they're neither
intended for nor well suited for, so you'll have a bad time.

Cheers,
Ryan

[Rob Stradling]

On 27/10/14 08:16, Ryan Sleevi wrote:
<snip>

> If you're trusting certificates to assert information about either the
> identity of the entity behind the key or that the CA has done due
> diligence, well, you're using certificates for something they're neither
> intended for nor well suited for, so you'll have a bad time.

Ryan, you are of course free to reach your own conclusions about what
certs are / aren't well suited for.

However, I'm utterly baffled by your claim that certificates aren't
intended to "assert information about...the identity of the entity
behind the key". That claim is true for DV, but it's clearly false for
EV and OV.

As for due diligence, BRs Section 11.2 clearly says that CAs are
required to verify organization info in accordance with Section 11.2 and
as documented in their CP/CPS.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Erwann Abalea]

Le lundi 27 octobre 2014 07:54:04 UTC+1, John Nagle a écrit :
> Here's a nice example of Mozilla not fully understanding Organization
> information in certificates: "www.facebook.com".
>
> Firefox says, for "https://www.facebook.com",
>
> "This web site does not supply ownership information".
>
> But, in fact, not only does it supply ownership information
> (the Subject contains O, L, ST, and C), DigiCert, which generated
> the certificate, promises in their CPS that the info is valid. DigiCert
> attached Policy OID 2.16.840.1.114412.1.1, promising
> valid organization data.

CertificatePolicies extension cannot reliably be used for some CAs to assert some DV/OV compliance.

DigiCert attached policyId 2.16.840.1.114412.1.1 to the subscriber certificate, but this certificate has been issued by a CA limited to policyId=2.16.840.1.114412.1.3.0.2 (by its issuing CA), which itself was limited to policyId=1.3.6.1.4.1.6334.1.0.

[John Nagle]

> On 27/10/14 08:16, Ryan Sleevi wrote: <snip> If you're trusting
> certificates to assert information about either the identity of the
> entity behind the key or that the CA has done due diligence, well,
> you're using certificates for something they're neither intended for
> nor well suited for, so you'll have a bad time.

In May 2012, when this was last discussed, that was a reasonable
position. There have been some changes in standard CA practice since then.

Originally, the CA/Browser Forum was only concerned with EV certs.
Back in May 2012 the CA/Browser Forum was discussing the Baseline
Guidelines, but they were not in effect yet. So, in May 2012, it was
reasonable to say that extracting reliable Organization and Location
information from non-EV certs was an unreliable process.

In July 2012, the CA/Browser Forum Baseline Guidelines for
all certs, not just EV, took effect. Once those came out,
CAs started making a clear distinction between DV, OV, and EV
certs. Previously, DV vs OV had only been an informal distinction.
Two years later, many issued certs (soon I'll know how many)
bear OIDs which clearly identify them as OV certs, with the CA
standing behind the Organization and Location information.

It's appropriate for browsers to show that new information with
users. In the browser, there are two issues: 1) detecting OV
certs, which requires a list of per-CA OIDs, and 2) displaying
something in the GUI.

John Nagle
SiteTruth

[Peter Bowen]

On Mon, Oct 27, 2014 at 10:58 AM, John Nagle <na...@sitetruth.com> wrote:
>> On 27/10/14 08:16, Ryan Sleevi wrote: <snip> If you're trusting
>> certificates to assert information about either the identity of the
>> entity behind the key or that the CA has done due diligence, well,
>> you're using certificates for something they're neither intended for
>> nor well suited for, so you'll have a bad time.
>
> In May 2012, when this was last discussed, that was a reasonable
> position. There have been some changes in standard CA practice since then.

Yes, however there are plenty of certs still in use that are unexpired
which don't follow these "standard" practices.

Specifically, from the CT logs, 139935 certificates that are unexpired
meet the following criteria:
- Do not have a State/Province or Locality Name in the Subject
- Have the same string for Organization and Common Name in the subject

The string used for the Organization Name appears to be a fully
qualified domain name in the certificates that I checked.

I trust that this practice is not happening in new certificates, but
thousands of existing certificates clearly have Organization Name
attributes that are not usable.

Thanks,
Peter

[Chris Palmer]

On Mon, Oct 27, 2014 at 10:58 AM, John Nagle <na...@sitetruth.com> wrote:

> It's appropriate for browsers to show that new information with
> users. In the browser, there are two issues: 1) detecting OV
> certs, which requires a list of per-CA OIDs, and 2) displaying
> something in the GUI.

If users perceive the new information — and that's a big if — what do
you expect that they will do with it?

While formulating your response, please keep these facts in mind:

* Users understand their task well enough to complete it, but are also
distracted (including by security indicators and their numerous false
positives), and busy. 0 people in the world understand 100% of the ins
and outs of X.509 and TLS; normal people have no chance and should not
have to. X.509-style PKI is an engineering failure in part because of
its absurd complexity.

* Users are, quite reasonably, focused on the viewport. After all,
that's where the content is and where the task is. Many people simply
never see the Location Bar or its security indicators.

* The only security boundary on the web is the origin (the tuple
scheme, host, port).

* URLs are incredibly hard to parse, both for engineers (search the
web for hundreds of attempts to parse URLs with regular expressions!)
and for normal people.

* The only part of the origin that users understand is the hostname;
it's better if the hostname is just effective TLD + 1 label below
(e.g. example + co.sg, or example + com). Long hostnames look phishy.

* User who look away from the viewport have a chance to understand 1
bit of security status information: "Secure" or "Not secure".
Currently, the guaranteed-not-safe schemes like http, ws, and ftp are
the only ones guaranteed to never incur any warning or bad indicator,
leading people to reasonably conclude that they are safe. Fixing that
is the/a #1 priority for me; it ranks far higher than
ever-more-fine-grained noise about organization names, hostnames,
OV/DV/EV, and so on.

* You can try to build a square by cramming a bunch of different
Zooko's Triangles together, but it's probably going to be a major
bummer. After all, that's the status quo; why would more triangles
help?

* We have to design products that work for most people in the world
most of the time, and which are not egregiously unsafe or egregiously
hard to understand. It's good to satisfy small populations of power
users if we can, but not at the expense of normal every day use.

* There are some threat models for which no defense can be computed.
For example, attempts to get to the "true" business entity, and to
ensure that they are not a proxy for some service behind, start to
look a lot like remote attestation. RA is not really possible even on
closed networks; on the internet it's really not happening.

[Jeremy Rowley]

As you know, the CAB Forum guidelines do not mandate use of CAB Forum policy OIDs to assert DV/OV compliance. We'd happily support a change in this policy at the CAB Forum and plan to update our certs accordingly if such ballot passes.

Jeremy

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+jeremy.rowley=digice...@lists.mozilla.org] On Behalf Of Erwann Abalea
Sent: Monday, October 27, 2014 4:23 AM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Organization info in certs not being properly recognized by Firefox

Le lundi 27 octobre 2014 07:54:04 UTC+1, John Nagle a écrit :

> Here's a nice example of Mozilla not fully understanding Organization
> information in certificates: "www.facebook.com".
>
> Firefox says, for "https://www.facebook.com",
>
> "This web site does not supply ownership information".
>
> But, in fact, not only does it supply ownership information (the
> Subject contains O, L, ST, and C), DigiCert, which generated the
> certificate, promises in their CPS that the info is valid. DigiCert
> attached Policy OID 2.16.840.1.114412.1.1, promising valid
> organization data.

CertificatePolicies extension cannot reliably be used for some CAs to assert some DV/OV compliance.

DigiCert attached policyId 2.16.840.1.114412.1.1 to the subscriber certificate, but this certificate has been issued by a CA limited to policyId=2.16.840.1.114412.1.3.0.2 (by its issuing CA), which itself was limited to policyId=1.3.6.1.4.1.6334.1.0.

[fhw...@gmail.com]

‎It's debatable if those are actually facts but perhaps some perspective will help the conversation. I'll use this case as a launching point:

* Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators.

That‎ is certainly a true statement and I would take it a step further to say the user should not be expected to check the address bar under normal circumstances. Or, to put it differently, any security feature which requires the user to pay close attention to the address bar should be considered ineffectual.

That said, there is a use-case worth considering here: when the page being viewed doesn't look right. Examples include when I expected site A but end up at B, or when I go to login at C but instead have what looks like a phishing page. In such cases, seeing the organization info and so forth can be useful. 

Even if the best the browser can do is say ‎"this site is owned by Google, although I really can't confirm it" there is utility in that. It just might give me a fighting chance at being secure--which is not to say the alternative is no chance but that my ability to make secure decisions are diminished without it. 

	Original Message

From: Chris Palmer Sent: Monday, October 27, 2014 1:48 PM‎

closed networks; on the internet it's really not happening.‎

[John Nagle]

On 10/23/2014 02:00 PM, Richard Barnes wrote:
illa and the CA/Browser Forum.
>
> And I suspect it is related to this:
> http://blog.cloudflare.com/introducing-universal-ssl/

I previously wrote "You're probably right". He was.
As of the January 2014 U. Mich scan of IPv4 space:

Number of IPv4 sites offering an SSL cert: 66335624
Number with two different second-level domains: 154958
Number associated with cloudflare.com: 45405
Number associated with yellhosting.com: 1465

Those two services, "cloudflare.com" and "yellhosting.com",
seem to be the primary bulk users of multiple-domain certs.
(Akamai wasn't doing this.) Most other multiple-domain
certs have reasonable-looking combinations of domain names.

So that's what the data tells us. It's only Cloudflare, and
to a lesser extent Yell Hosting, who are doing this in
a big way.

More later.

John Nagle
SiteTruth

[Gervase Markham]

On 27/10/14 17:58, John Nagle wrote:
> In July 2012, the CA/Browser Forum Baseline Guidelines for
> all certs, not just EV, took effect. Once those came out,
> CAs started making a clear distinction between DV, OV, and EV
> certs. Previously, DV vs OV had only been an informal distinction.
> Two years later, many issued certs (soon I'll know how many)
> bear OIDs which clearly identify them as OV certs, with the CA
> standing behind the Organization and Location information.
>
> It's appropriate for browsers to show that new information with
> users. In the browser, there are two issues: 1) detecting OV
> certs, which requires a list of per-CA OIDs, and 2) displaying
> something in the GUI.

You forgot 0) Having sufficient trust in the validation of that
information to want to present it to users. That is what we do not have
for organizational information with anything short of EV.

I don't intend to take part further in this thread, because this
conversation has happened many, many times.

Gerv

[Dean Coclin]

I'd like to focus on this statement:

 

"Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators."
 

 But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? It's because they know that people are trained to look for the lock and https.  Granted not all the people know this but a percentage of the population does and it dictates the behavior of cybercriminals.

 

 

Dean

 

 

 

On 10/28/14, fhw...@gmail.com wrote:

 

‎It's debatable if those are actually facts but perhaps some perspective will help the conversation. I'll use this case as a launching point:

* Users are, quite reasonably, focused on the viewport. After all, that's where the content is and where the task is. Many people simply never see the Location Bar or its security indicators.

That‎ is certainly a true statement and I would take it a step further to say the user should not be expected to check the address bar under normal circumstances. Or, to put it differently, any security feature which requires the user to pay close attention to the address bar should be considered ineffectual.

That said, there is a use-case worth considering here: when the page being viewed doesn't look right. Examples include when I expected site A but end up at B, or when I go to login at C but instead have what looks like a phishing page. In such cases, seeing the organization info and so forth can be useful. 

Even if the best the browser can do is say ‎"this site is owned by Google, although I really can't confirm it" there is utility in that. It just might give me a fighting chance at being secure--which is not to say the alternative is no chance but that my ability to make secure decisions are diminished without it. 

	Original Message

From: Chris Palmer Sent: Monday, October 27, 2014 1:48 PM‎

On Mon, Oct 27, 2014 at 10:58 AM, John Nagle <na...@sitetruth.com> wrote:

> It's appropriate for browsers to show that new information with
> users. In the browser, there are two issues: 1) detecting OV
> certs, which requires a list of per-CA OIDs, and 2) displaying
> something in the GUI.

[Chris Palmer]

On Wed, Oct 29, 2014 at 2:02 PM, Dean Coclin <dean.j...@verizon.net> wrote:

> But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites? It's because they know that people are trained to look for the lock and https. Granted not all the people know this but a percentage of the population does and it dictates the behavior of cybercriminals.

Some people do look at the security indicators some of the time. Since
it's easy and affordable to get a certificate — as it should be! Thank
you! And help me convince all the web developers out there who believe
otherwise :) — phishers and fraudsters might as well pay the small
price if they can soothe the concerns of some potential victims some
of the time.

Related:

https://www.ccsl.carleton.ca/people/theses/Sobey_Master_Thesis_08.pdf

"""
5.4 Time Spent Gazing at Browser Chrome

One of the more interesting findings in the eye tracking data was how long users
spent gazing at the content of the web pages as opposed to gazing at the browser
chrome. For each participant, we compared the amount of time the participant’s
gaze data contained co-ordinates within the browser chrome during the
study tasks
with the amount of time the participant’s gaze data contained
co-ordinates in the
page content. On average, the 11 participants who were classified as
gazers spent
about 9.5% of time gazing at any part of the browser chrome. The remaining 17
participants who did not gaze at indicators spent only 4.3% of their
time focusing on
browser chrome as opposed to content (some spent as little as 1%).
"""

Tangentially related:

http://eprints.qut.edu.au/55714/1/Main-ACM.pdf

[Anne van Kesteren]

On Wed, Oct 29, 2014 at 10:02 PM, Dean Coclin <dean.j...@verizon.net> wrote:
> But many people do in fact look at the security indicators. If that statement were true, why do fraudsters bother to get SSL certs (mostly DV) for their phishing websites?

Given that "Organization" is not a globally unique identifier, it
seems they could with some more effort also spoof that field.

(Which is why EV seems to actually make things more difficult for
users as they have to carefully check the domain, the Organization
field, and ensure that neither has changed, each time they visit.)


--
https://annevankesteren.nl/

[Anne van Kesteren]

On Fri, Oct 31, 2014 at 11:22 AM, Moudrick M. Dadashov <m...@ssc.lt> wrote:
> The document below proposes a generic syntax for unique identification of
> natural/legal Subjects (see Section 5):
>
> http://docbox.etsi.org/ESI/Open/Latest_Drafts/prEN_319412-1v006-cert-profiles-common-structures_COMPLETE-draft.pdf

Even if that works out, you're at best duplicating a system that is
already in place with domain names. And it does not necessarily lead
to simpler UI. E.g. Apple now simply shows the Organization in the
address bar, but with that mozilla.org and bugzilla.mozilla.org appear
identical, while they actually have different security characteristics
as far as the end user is concerned. Perhaps that would argue for
showing both the Organization and the domain name as most other
browsers appear to be doing, but that makes the UI is more complicated
to grasp compared to DV or lacking TLS altogether.


--
https://annevankesteren.nl/